How to Run a Roadmap Planning Meeting When Everyone Wants Different Things

Photo by Connor Scott McManus on Pexels

There are two kinds of roadmap planning meetings. The first is the kind where actual decisions get made: priorities get set, tradeoffs get acknowledged, the people who need to execute leave knowing what they're doing and why. The second kind is the kind where everyone performs alignment. Nobody commits to anything uncomfortable. The roadmap that comes out is either impossible or meaningless or both. People leave exhausted and nothing has changed.

Most roadmap planning meetings are the second kind.

Why roadmap meetings usually fail

The failure mode is almost always the same. The meeting is designed to produce consensus rather than to produce decisions. Consensus is pleasant. It doesn't require anyone to give anything up, or to explicitly acknowledge that one priority is more important than another, or to say out loud that a request that came from a powerful stakeholder is not going to make the plan.

So instead of having those conversations, people add everything to the roadmap. They give everything an approximate timeline. They defer the hard tradeoffs to "next quarter's planning." And then next quarter the same meeting happens, the same conversations don't happen, and the same problems compound.

Three people who make it worse

The HiPPO. The Highest Paid Person's Opinion. In most companies, there is someone in the room whose preferences implicitly outweigh the process. When the CEO says "we should also do X," the roadmap grows, regardless of what was just decided about capacity. Everyone in the room knows that "we should also do X" means "we will do X." Nobody says so explicitly. The process continues as if it's still a planning meeting and not a briefing.

If the CEO is in the meeting, their role needs to be defined in advance: are they a decision-maker, a stakeholder, or an observer? Those are very different roles, and conflating them makes the meeting unfacilitate-able. I wrote about this at length in If the CEO Isn't in the Room, You Don't Have a Roadmap.

The technical deep-diver. The engineer who uses planning meetings to surface implementation concerns that should have been raised before the meeting. These concerns are often legitimate. The timing is wrong. When the conversation shifts from "what are we doing" to "how exactly would we build this," you've lost the meeting. Planning becomes architecture. The people who need to stay strategic get lost in detail they're not equipped to resolve.

The fix is boring but effective: require technical concerns to be submitted in writing before the meeting, addressed asynchronously, and only escalated to the planning session if they genuinely affect prioritisation. Most don't.

The 70-slide PM. The person who prepared a comprehensive presentation of everything they want, in tremendous detail, with no guidance on what to prioritise. This is well-intentioned. It's also a way of deferring the hard work of prioritisation to the room — which means it doesn't get done at all, because rooms are worse at making hard decisions than individuals are.

The discipline of deciding what the top three priorities are — and committing to that decision in writing, before the meeting — is where most of the real planning work happens. The meeting is for ratifying and adjusting that decision, not for making it.

A format that produces actual decisions

Before the meeting: each team or function submits their top three priorities in a single document. Not their full backlog. Not everything they'd do if they had unlimited capacity. Three things. In order. With one sentence explaining why each one is more important than the next.

This is harder than it sounds. It requires people to make tradeoffs before they have the protection of "the room hasn't decided yet." That's the point. The discipline of writing down priorities in order forces clarity that the meeting itself almost never produces.

In the meeting: start with the constraint. How many engineering sprints does the team have available? What are we not doing this quarter because of capacity? That question — asked explicitly, with a real number — changes the character of every request that follows. "We should also do X" becomes "which of these three things do we drop to do X?" That's a much more honest conversation.

Run the meeting to produce decisions, not consensus. Someone needs to own the decision on each contested item. That person should be identified before the meeting. If it's the CTO or CPO, they need to be willing to make the call rather than searching for a consensus that isn't there.

What "aligned" actually means

Alignment doesn't mean everyone agrees. It means everyone understands what was decided, why, and what they're responsible for. Two people can leave a planning meeting having argued about a priority and still be aligned — as long as the decision was made clearly and they both accepted it.

The meetings that feel aligned but aren't are the dangerous ones. Everyone nodded. Nobody committed. The roadmap exists on a slide. None of the hard choices got made. And six weeks later, you're in the same meeting again, wondering why the company keeps planning and never executing.

The roadmap isn't the plan. The decisions are the plan. The meeting is only as useful as the decisions it produces.