Writing a Roadmap Doc That Explains the Tradeoffs
Most roadmap docs are a ranked list with no visible reasoning. That works fine until a stakeholder asks why feature B is above feature A, and the honest answer is a mix of gut feel and whoever asked most recently, which doesn't hold up well in the meeting.
Warning
A ranked list without reasoning isn't a decision, it's a placeholder for one. The first hard question in the room reveals whether the ranking was actually thought through.
A roadmap that can't explain its own order isn't a roadmap. It's a list waiting to be re-argued.
Why an unranked reason gets re-litigated every time
Ranking by gut feel might be right, but nobody else can evaluate it, so every stakeholder with a different intuition has grounds to push back. Without visible reasoning, the same tradeoff conversation happens again in the next meeting, and the one after that.
Before: rank features by instinct, present the list, spend the meeting defending the order from scratch.
After: give Claude the candidate features with their effort and impact, get back a ranked roadmap with the reasoning for each spot written out, and walk into the meeting with the tradeoffs already on the page.
A process for a roadmap with visible reasoning
- 1
List candidates with real effort and impact estimates
Give actual figures, even rough ones, engineering weeks for effort, expected users affected for impact, rather than vague labels like "big" or "small." Vague inputs produce a ranking with nothing solid behind it.
- 2
Ask for a ranking with a stated reason per item
Request two sentences of justification per feature, not just a ranked list. The reasoning is what makes the roadmap defensible in a room full of people with their own opinions.
- 3
Ask what would change the ranking
Once you have a first pass, ask which features are closest to swapping places, and what would need to be true for that to happen. This is where the real tradeoffs, not just the final order, become visible.
- 4
Check the reasoning against what stakeholders actually value
Compare the stated reasoning against what you know matters to the people in the room, revenue, retention, technical debt. A ranking that only reflects effort and impact can still miss the actual conversation.
“
Here are 6 candidate features with rough effort estimates and expected impact. Rank them into a Q3 roadmap, and write two sentences justifying each ranking.
”Inside Claude Tutorial
Making the reasoning behind a ranking visible is transferable.
Turning a gut-feel decision into one with stated, checkable reasoning applies well beyond roadmaps. The app has a full lesson on it, with practice that carries over to any prioritization call you need to defend.
When two features are genuinely close
Sometimes the honest answer is that two features are close enough that either order is defensible. That's worth saying directly instead of presenting false confidence in a specific rank.
Tip
Ask Claude to flag which rankings are close calls versus clear-cut. A roadmap that's honest about its close calls is more credible than one that presents every ranking with the same certainty.
“
Looking at this ranked list of 6 features, which pairs are close enough that the order could reasonably flip? Be specific about what would need to change for that to happen.
”Continue reading
- Turning Support Tickets Into Prioritized Themes: where the impact estimates a roadmap ranking depends on often come from.
- Turning a Shipped Feature Into Release Notes and a Stakeholder Update: what happens once a roadmap item actually ships.
- Writing a PRD From a One-Line Feature Request: turning a roadmap slot into a spec once it's been prioritized.
