The pattern is familiar. In January, leadership, product, engineering and the commercial teams agree a roadmap for the year. It’s ambitious and well presented, and everyone signs off.
By June, a third of it has been quietly dropped, another third is late, and the team is busy with work that was never on it. Nobody can point to one failure. The roadmap stopped being true a little at a time.
In our experience these roadmaps were in trouble from the day they were agreed.
Agreement is cheap
A roadmap meeting tends to optimise for consensus. Every department wants its priorities included, and the easiest way to get everyone to sign is to include something for everyone.
The result is a document everyone agrees with because nobody had to give anything up. That’s a list of wishes with dates attached.
Real alignment shows up in what’s left out. If the roadmap meeting didn’t leave at least one senior stakeholder disappointed, it probably didn’t make any real choices.
Why these roadmaps fail
It was never sized against capacity. Items were estimated loosely, if at all, and nobody added them up against what the team actually delivers. When engineering raised concerns, the answer was “let’s see how far we get”.
It ignored the work that was already there. Maintenance, technical debt, compliance changes, vendor upgrades and operational requests don’t stop because a new roadmap was signed. In many organisations they take 30 to 50 percent of capacity. A roadmap that assumes all of it goes to new features is broken before it starts.
The items were outputs. “Launch a loyalty programme” can only be delivered or cut. “Increase 90-day retention for new customers” leaves room to find a cheaper way when the first plan runs into trouble.
Dependencies weren’t mapped. Many items depended on other teams, external vendors or approvals with long lead times. Each one surfaced mid-quarter, cost a few weeks, and a few weeks at a time is how a roadmap slips by six months.
Nobody owned the trade-offs. New priorities arrived, as they always do, and were added without anything being removed.
A roadmap that holds
Start from capacity. Agree how much capacity is realistically available for new work after maintenance and unplanned demand, and plan to that number.
Write items as outcomes with a first idea of the solution. The idea can change. The goal changes only through a conscious decision.
Force a strict ranking, with no tiers and no list where half the items are “must have”. When capacity runs out, the line falls where it falls, and everything below it is explicitly not happening this quarter.
Commit firmly to the next quarter only. Hold the one after as a likely direction, and treat anything beyond that as intent. Delivery dates within the quarter can stay flexible. Work ships when it’s ready.
Then review it every month with the same people who agreed it, and make swaps explicit. When a new priority arrives, the person asking for it joins the conversation about what it replaces. In our experience that one rule changes behaviour more than any planning tool.
The meeting worth having
All of this comes down to having the uncomfortable conversation early. A roadmap that disappoints someone in January and delivers by June is worth far more than one that pleases everyone in January and disappoints everyone by summer.
If your last roadmap ended up as a document nobody opens, don’t start the next one by asking what everyone wants. Start by asking how much the organisation can actually do, and decide together what matters most within that limit.
