A product roadmap that can say no

A product roadmap shows where a product is going, why, and what has to happen on the way. Its readers will never open the backlog: executives, sales, finance, partners. So it has to carry the reasoning as well as the output.

What a working roadmap contains

• Business goals and OKRs, written clearly enough to check a feature against. A feature that serves no goal on the page does not belong on the page.
• Problems in priority order, rather than features. RICE or MoSCoW will do the ordering; what they should order is user and business problems, because the solution can change.
• Timeframes and milestones at the right resolution: committed for the next quarter, directional after that. A date twelve months out is a promise nobody can keep. Research on the planning fallacy shows that people underestimate even short tasks, and that estimates improve when they start from how long similar work actually took.
• A success metric for every item, so that “done” means “measured” rather than “shipped”.

The mistake that ruins most roadmaps

The usual failure is to treat the roadmap as a feature list. It feels productive. The list is long, everyone's request is on it, and the quarter columns look like a plan. What it removes is the only thing that makes a roadmap useful: the argument about what not to do. A roadmap that cannot say no is a wish list with formatting.

Start from the problems and the goals instead, keep the list short, and make the trade-offs visible. When a stakeholder asks why their feature is missing, the answer should already be on the page.

A habit worth keeping

Review the roadmap on a fixed cadence, with the same people, and record every change as a decision with its reason beside it. Over time, the record of those reasons is worth more than the current version of the plan.