Commitment is a function of two things: clarity and buy-in
"Commitment is a function of two things: clarity and buy-in" -- Patrick Lencioni, The five dysfunctions of a team Clarity in either a project or an organisation...
Aug 14, 2026
It's quite common to see a leadership team where everyone wants something different.
The product team thinks conversion rate is the most important thing. The CEO is focused on this year's budget and making sure the revenue goals are hit. The CTO is worried about technical debt and the engineering teams getting a bit slower. Sales has an urgent customer request that needs to be addressed, whether it's a bug fix or a new feature.
And the same goes for everybody else in the company. All the heads of department have a reasonable argument about why their thing is the most important or why their idea is the one that will help the business achieve its goals.
It doesn't mean the leadership team is bad or not qualified. Not at all.
They're judging priorities from different perspectives and naturally have more context about their own teams and the problem spaces they're exposed to.

Resolving this often falls to the person leading product. When that role does not exist internally, a fractional Head of Product can provide the structure and neutral facilitation needed to reach a decision.
So, how do you actually make the call?
The first thing to do is work out what people disagree on. There are a few ways to look at it and I usually go from top to bottom.
First, are we trying to achieve different goals? This is really about figuring out whether we're aligned on what the company is trying to achieve.
Second, even if we agree on the overall goal, do we disagree about what matters most right now? For example, we might all agree that revenue needs to grow, but disagree about whether retention or acquisition is the bigger priority.
Third, do we disagree about what the problem actually is? It might actually be multiple problems combined into one, so unpack that first.
Fourth, we might agree on the goal and even agree on the broad problem, but disagree about what's driving it or which cause matters most. For example, everyone agrees retention is a problem, but the Sales team thinks customers are leaving because particular features are missing, while the Product team thinks there is a bigger issue with reliability and speed.
Fifth, do we agree on the problem and what's driving it, but want different solutions? Each problem can be solved in different ways and what might be happening is simply that the team has different opinions on how to solve it.
There can also be disagreement about the trade-offs between those options. Two people might prefer the same broad direction but have very different views on how much time, money or risk the company should take on.
One thing to work out separately is who actually makes the decision. You don't want to get to the end of the conversation and realise nobody knows who has the final say.
The best way to do this is through one-on-one conversations. Ideally face-to-face or on a video call, about 30 minutes each.
The goal is to speak separately to the CEO (or founder), CTO, Sales (or Commercial), Product and anyone else who can or should influence company priorities.
Ask everyone the same questions about the goals. The core idea is to go up a level from feature requests and focus on the goals, whether they're department goals or company goals what matters most right now, the problems, what they think is driving them, preferred priorities, possible solutions, trade-offs, evidence and what they would stop doing right now.
Capture the notes in the same format. Ask the same questions so you get somewhat similar answers that you can analyse later.
Avoid starting with a group meeting. Once the CEO or the loudest person gives their view, other people's answers can start moving towards that. Not always, but it tends to make people less open, especially if the group is 6-8 people.
Separate conversations will help you see what people actually think.
Once you have the responses, put everyone's answers next to each other. You can do this in FigJam, a Google Doc or a very simple spreadsheet.
Capture the goals, what matters most right now, problems, likely causes, preferred priorities, possible solutions, trade-offs, evidence if any and what they would stop or delay.
Then look for the first point where the answers start to diverge. Always start from the top.
Make sure it's also clear who actually makes the decision. There's no need to jump into debating solutions if the disagreement is higher up. There's also no reason to use five executives' time while you work that out.
Next up, you have to check your read with the CEO.
The best way to do it is to meet one-on-one before sharing any disagreement or misalignment back to the group. Keep it short, around 30 minutes. Sometimes it goes longer, but I would cap it at an hour.
There's a good reason to do this first. You don't want to go straight from private one-on-ones into a group meeting and make it look like you've interviewed everyone, formed a view and are now presenting a verdict or solution to the room. Even if that's never the intent, it can land that way.
The CEO (or founder) also has broader company context, which you probably missed if you're just starting out. They can add some flavour to why things are the way they are, surface sensitivities or explain some history and dynamics that wouldn't necessarily come up during the interviews.
It also gives the CEO visibility into the session you're about to run. You don't want to blindside them.
For the meeting, bring the patterns you found across the interviews: where the answers were consistent and where they diverged. Then share your perspective on where the real disagreement sits.
The best way to frame it is:
Here's what I heard. I think the disagreement is actually here, around the problem or the goals, not at the feature level. Does that match what you're seeing and hearing?
This is also a chance to check that you haven't missed something important before bringing it back to the wider group.
The important thing is that you're checking your read and getting additional context, not asking the CEO to approve your conclusion before everyone else sees it.
Get agreement on the upcoming leadership meeting: what specifically needs to be resolved, who needs to be in the room and who owns the final decision. Keep the scope pretty narrow. If it's retention versus acquisition, discuss that, not the whole Product roadmapA view of the product investments, problems or outcomes a team expects to work on over time.Learn more.
I would also ask the CEO to open the leadership meeting. They can help frame the session so it doesn't feel like it's coming directly from you and the group knows the CEO wants the issue resolved. Just don't ask the CEO to make the decision privately there on the spot.
All right, now the real work starts.
I know you might be quite anxious at this point, setting up a group session with the executive team. But that's where the magic happens.
Don't think about it as your problem to solve. You're facilitating the session and you don't have to have the answer yourself about what the goals should be.
When you're setting up the meeting, make sure you're clear about the purpose of it. The goal here is to put the disagreement on the table, check that you've characterised it correctly and resolve as much of it as you can.
Typically, these sessions last about 60 to 90 minutes and are preferably face-to-face, but an online session is fine for distributed teams.
You can open with something like:
Everyone agrees retention is important. Where we disagree is why customers are leaving us.
Or:
On the surface, it looks like we're trying to make a decision between Feature A and Feature B, but the actual disagreement is retention versus acquisition.
Stay at the highest unresolved level. Don't let people jump back into solution mode or down to the project level if the disagreement sits higher up.
Provide your summary, let people correct it and see if there are any disagreements with your read.
The reason to do this is that it stops the meeting becoming yet another round of everyone pitching their favourite project or feature idea. It helps narrow the conversation down to what actually needs to be resolved and quite often that disagreement sits much higher up than the feature level.
Once everybody in the room has had a chance to correct your read, move on to the first point of disagreement.
If the goals differ, stay on the goals. If the goals align but people disagree on what matters most right now, stay there. If that's agreed but people see the problem differently, stay on the problem. The same goes all the way down. Don't move into solutions while people still disagree about what's driving the problem.
Only once those things are reasonably aligned should you start debating solutions and the trade-offs between them. What not to do is jump down a level just because feature discussions are the default state for people.
Make sure the disagreements are visible. Put them on the screen or write them on a whiteboard. Show the evidence and highlight the different positions, what evidence there is, what the assumptions are and what would change people's minds.
But sometimes the evidence isn't there. In that case, work out whether getting more evidence could realistically change the decision. If it can, identify what needs to be learned, give someone ownership and bring it back.
If you're unlikely to know much more anytime soon, somebody still has to make the call. A lot of leadership decisions are made with incomplete information. The mistake is pretending you can settle an uncertain question by debating it harder in the room.
It's also common that even when the evidence is on the table, people might interpret it differently and still disagree.
When that happens, whoever owns the decision has to decide.
Most likely, it's going to be the CEO for company-level investment choices and priorities. It could be the CTO for a technical decision or Product for a product decision within already agreed goals.
And you don't need consensus here. A good approach is Amazon's "Disagree and commitA decision-making principle where people challenge a decision before it is made, then support it once the decision is final.Learn more": people can disagree with the decision, but once it's made, they commit to it.
The reason this setup works really well is because you've already done Product discoveryThe work used to understand a problem, test assumptions and reduce uncertainty before making a larger product investment.Learn more before the meeting. You're not using executive time to work out what everyone thinks while each executive shares their perspective and everyone else is essentially wasting their time.
This meeting is there to resolve a specific disagreement, whether it's about what matters most, the problem, what's driving it, the solution or the trade-offs.
What we need to aim for is that by the end of that session, every disagreement that was in scope has an outcome.
That doesn't mean every question has to be answered in the room.
Some decisions should be made there. For example, with international expansion, the CEO can decide whether there is enough appetite, budget, resources or team capacity to pursue it. They can totally just park it and move on.
It should be clear to everybody in the room that this is the decision and it gets captured in a Decision logA written record of important decisions, including what was decided, why it was decided and the context available at the time.Learn more.
Avoid the urge to investigate every idea just because somebody raised it. You've got to be picky.
Some decisions genuinely need more evidence. In that case, be clear about what specifically needs to be learned, who owns it and when it comes back for a decision. That's still an outcome and it needs to be captured in the log as well.
And at the end, once the decision is made, update the actual priorities, roadmap, goals, projects and commitment: what's been stopped, what's been decided and what's been endorsed for further investigation.
Otherwise you can have a very productive leadership session, agree that retention matters and walk out of the room still funding 6 acquisition projects.
Leadership disagreement itself is not uncommon and it's not a problem. You'd expect sales, product, engineering and the CEO to see the business differently, given their different areas of expertise.
The problem is when there is no process to work out where the disagreement actually sits, at which level and no way to resolve it and turn it into one company decision that gets logged and followed
Keep reading
"Commitment is a function of two things: clarity and buy-in" -- Patrick Lencioni, The five dysfunctions of a team Clarity in either a project or an organisation...
The CEO becomes the bottleneck Imagine a company where the CEO reviews requests and features, keeps track of what the product and engineering teams are doing an...
One thing I'm learning from building Sounding Board (peer exchange for product people)...what product people actually need is someone who's been through their e...
I'm a father of 3 from Sydney, a product and technology leader. I write about leadership, product management, technology and the messy reality of making work work.
I'm currently building and experimenting with a mildly alarming number of things. I also work as a fractional product leader, stepping in where the founder or CEO is still carrying product decisions on their own, and offer 1:1 product leadership coaching for senior PMs and emerging product leaders. I founded SoundingBoard, practical peer exchange for product people. Connect via LinkedIn, or follow me on X.
Subscribe to the best posts on product, strategy, and AI. Just one email a month.