Your roadmap probably isn’t the problem.
I have inherited enough ‘broken’ roadmaps to be suspicious when someone says the answer is better prioritisation. Sometimes it is. More often, the roadmap is simply where all the unresolved arguments have ended up.
01
The roadmap is usually the evidence.
A roadmap gets messy when ownership is unclear, executives want different things or the commercial strategy has never been turned into an actual choice. Moving the boxes around might make the slide look better. It does not make any of those things go away.
Then the roadmap changes again. Delivery gets blamed for being slow, while the business keeps adding work and never says what matters less. I have seen that pattern far more often than I have seen a genuinely bad roadmap.
02
Find the decision nobody wants to make.
The useful question is rarely ‘What should move up the roadmap?’ It is ‘Which decision have we not made?’ It could be the customer we are really serving, the market we are backing, a platform direction, a revenue assumption or a piece of legacy technology nobody wants to own.
Make that choice and prioritisation gets much easier. The roadmap can finally reflect the strategy instead of trying to disguise the absence of one.
- Which customer or commercial outcome takes precedence?
- What are we prepared to stop or delay?
- Who owns the decision when evidence remains incomplete?
- Which technical or operational constraint is genuinely fixed?
03
Product leadership is about forcing clarity.
The job is not to run a more energetic prioritisation workshop. It is to connect the customer evidence, commercial intent, delivery reality and technical constraints—and get the organisation to make a choice it can live with.
That work is less visible than publishing a shiny new roadmap. It is also the bit that creates momentum. Once everyone agrees what they are trying to achieve, and what they are not going to do, the roadmap normally becomes simpler by itself.