Why Most Roadmaps Are Wish Lists
A roadmap that never had to refuse anything is a record of who asked loudest.
Open your roadmap. Count the items. Now ask, for each one, who wanted it and what would have happened if you had said no. If most of the answers are a senior person would have been annoyed, you are not looking at a roadmap. You are looking at a peace treaty.
This is how it happens. Sales brings three deals that each need one thing. Support brings the top five complaints. The CEO comes back from a conference with an idea. Design has a redesign they have wanted for a year. Each request is reasonable in isolation. Nobody is behaving badly. The roadmap absorbs all of it, because absorbing is cheaper than arguing, and the quarter fills up before anyone asks what the quarter was for.
Roadmap, or a record of who asked
Wish list
- Items arrive from whoever asked
- Sequencing reflects political urgency
- Everything is committed, nothing is conditional
- Success is defined as shipped
- Removing an item requires a fight
Roadmap
- Items are selected against a stated diagnosis
- Sequencing reflects dependency and learning order
- Later items are explicitly bets that may change
- Success is defined as an outcome you can observe
- Removing an item is a normal consequence of learning
The deeper problem is that a wish list has no theory. A real roadmap encodes a belief about cause and effect: if we do this, then this changes, which makes that possible. You can be wrong about a theory, which is exactly what makes it useful. A wish list cannot be wrong. It can only be incomplete, which is why it grows forever.
Wish lists also quietly destroy your ability to say no later. Once an item is on the roadmap, it has a sponsor, a rough date, and someone who has told a customer about it. Removing it now costs more than never adding it. This is why the discipline has to live at intake, not at planning.
Three questions at intake
- What does this change?
- Name the behaviour that should look different afterwards, in the product, not in the org. Better collaboration is not a behaviour. More accounts with a second active user in week one is.
- What does it displace?
- The roadmap is fixed in size because the team is. Every yes has a name attached to the thing it pushed out. Make the requester see that name.
- What would make us drop it?
- Agree the kill condition before you start. If nothing could make you drop it, you have committed to output rather than outcome.
Worked example
Hypothetical: Parcelwise, shipping software for small retailers
Parcelwise enters the quarter with fourteen roadmap items and eleven engineers. The PM runs the displacement question on each one. Nine items survive contact with a sponsor who is willing to name what they would give up. Two turn out to be the same request described differently by two teams. Three are dropped, and in two of those cases the requester agrees within a minute, because they had asked for the item in a meeting months earlier and had not thought about it since. Nothing about the team changed. What changed is that saying yes now had a visible price.
One more habit worth stealing. Split the roadmap by confidence rather than by date. Now covers work you are committed to and understand. Next covers problems you have chosen but not yet solved. Later covers directions, not features. This costs you the false comfort of a twelve month Gantt chart and buys you the ability to change your mind in month five without it reading as failure.
Expect resistance to that format. Dates feel like accountability, and stakeholders who have been burned before will read a confidence based roadmap as evasion. The answer is to be more specific about the near term, not less. Commit hard to the current six weeks, describe the next quarter as problems with owners, and be honest that anything beyond that is a direction you will revise.
You will know it is working when a stakeholder asks for something and you say no, and the conversation stays short because the reason is already written down and they helped write it.
Quick check
What most clearly distinguishes a roadmap from a wish list?
The takeaway
A roadmap encodes a theory about what will change and what you gave up; a wish list only records who asked.
Try this tomorrow
For every item on your current roadmap, write the name of the item it displaced. Send that list to the requesters.
Answer the check above, then bank the day.
Where this comes from
- Escaping the Build Trap, Melissa Perri
- Inspired, Marty Cagan
- Good Strategy Bad Strategy, Richard Rumelt
Strategy is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.