The five questions every roadmap should answer

Most roadmaps are lists of features. The good ones are lists of bets.

The difference matters. A list of features tells you what a team is going to build. A list of bets tells you what a team believes, what they're risking on those beliefs, and what would change their minds. The first is a manifest. The second is a stance.

If you want to write a roadmap that reads like a stance, the work is to make each line answer five questions before it earns its place.

1. What's the problem we believe is worth solving?

Almost every roadmap item is a solution wearing the costume of a problem. “Add SSO.” “Build a notifications center.” “Redesign the dashboard.” These are answers — to questions nobody bothered to write down.

Force the question to the surface. What's the problem? Whose? And — the part that flushes out the weak items — how do we know it's a real problem, not a reasonable-sounding hypothesis someone said with confidence in a meeting?

2. Who has it most acutely?

A problem that affects everyone a little is almost always less valuable to solve than a problem that affects a few people a lot. The first generates polite agreement. The second generates urgency, retention, and word-of-mouth.

Be specific. Not “users.” Not “enterprise customers.” A named cohort, ideally one you can list by hand.

3. What's our current best guess at the shape of the answer?

Hold this loosely. The point of writing it down is not to commit to it; it's to make it visible so the team can argue with it. A guess that lives in someone's head can't be wrong, only forgotten.

4. What would prove us wrong fastest?

This is the question most roadmaps refuse to ask. We are excellent at imagining how a bet might pay off and terrible at imagining the cheapest test that would tell us it won't.

For every item on the roadmap, write the one experiment that, if it failed, would give you permission to stop. If you can't name one, you don't have a bet. You have a wish.

5. What would we expect to see in six weeks if we're on the right track?

The leading indicator, not the lagging one. Revenue is a lagging indicator. Retention curves shifting in a single cohort is a leading one. Three customers using a feature unprompted is a leading one. Ten support tickets disappearing is a leading one.

If the only signal you can name is the one that will only be visible in two quarters, you have no way to course-correct in time.

A roadmap that answers these five questions is shorter than the one you were going to write. That's not a bug. The point of a roadmap is not to fit everything; it's to make the team's bets legible — to each other, to leadership, to the future versions of yourselves who will read it back in six months and ask what you were thinking.

What you were thinking should be on the page.