Roadmapping
Roadmapping is the work of communicating where a product is going and why. The hard part is not drawing the timeline — it is resisting the request to commit to features on dates, because that commits you to output at exactly the moment you know least about whether it will work. This page covers the outcome-based format, who each roadmap is for, how to order the items, and when a date is genuinely owed.
- Commit to
- Outcomes, not features
- Common format
- Now / Next / Later
- Revisited
- Every quarter
What is wrong with the Gantt roadmap
The familiar roadmap is a grid: features down the side, quarters across the top, coloured bars in between. Everyone can read it, which is why it survives. It is also wrong in two independent ways at once.
The first is the obvious one: the dates are estimates made before the work is understood, so they slip, and slipping dates erode trust faster than having no dates at all. The second is the one that matters more: even if every date held, roughly half the features would not move the metric they were meant to move. A dated feature roadmap is a promise to deliver a specific set of guesses, on time.
That framing explains why the argument between product and stakeholders so often goes in circles. Both sides are right: the stakeholder genuinely needs to plan around something, and the team genuinely cannot promise features it has not validated. The way out is to change what is being promised, not to negotiate the dates harder.
Three audiences, three documents
One file cannot serve everyone who asks for a roadmap, and the attempt is why so many of them are simultaneously too vague to plan with and too specific to be true. The three readers want different things and tolerate different amounts of uncertainty.
| Audience | Needs to know | Right level of detail |
|---|---|---|
| The team | What we are trying to change and what is being tested | Opportunities and current bets, updated weekly |
| Internal stakeholders | What changes for their function and roughly when | Outcomes by horizon, plus the few real dates |
| Customers and the market | That the product is going somewhere they want | Themes only, no dates, deliberately few items |
The customer-facing one is where discipline pays most. Anything published externally will be read as a commitment regardless of the disclaimer next to it, and a sales team will quote it. Publish fewer items than you are working on, never publish a date you have not decided to defend, and expect to be asked about the item you removed.
Commit to outcomes, forecast the rest
An outcome-based roadmap replaces "what we will build" with "what we intend to change", and drops precision as it looks further out — which is honest, because that is exactly how confidence behaves.
The narrowing is the whole idea. Now is committed and specific because the work is understood. Next names the problem and the intended outcome, but not the solution, because the solution is still being tested. Later is a direction — themes with no dates and no promises, revisited every quarter as evidence arrives.
| Horizon | What is fixed | Confidence | Changes |
|---|---|---|---|
| Now | Solution and outcome | High — validated | Rarely |
| Next | Problem and outcome only | Medium — in discovery | Often, and that is fine |
| Later | Theme only | Low — a direction | Expect it to |
One rule keeps the format honest under pressure: an item may only move from Next to Now when its outcome has a number attached and the solution has survived a test. Without that gate, Now fills with things that were urgent rather than things that were ready, and the three columns become a queue with nicer headings.
How items get ordered
Format does not answer the question everyone actually argues about: which of these goes first. Four models cover almost every conversation you will have, and each is really a different opinion about what "first" means.
| Model | How it decides | Best at |
|---|---|---|
| RICE | Reach × Impact × Confidence ÷ Effort. The confidence divisor is the honest part — it penalises big claims with no evidence. | Comparing many small, similar bets |
| WSJF | Cost of delay ÷ job size. Asks what it costs to be late rather than what it is worth, which reorders things urgency alone would bury. | Sequencing work with real deadlines |
| Kano | Sorts features into basic expectations, performance features and delighters — the first category earns nothing but its absence loses everything. | Deciding what is table stakes |
| MoSCoW | Must, Should, Could, Won't. Crude, but the "Won't — this time" column is the only one of the four models that makes refusal explicit. | Fixed-scope negotiations with a client |
The other half of prioritisation is declining things, and it is a skill with its own technique. A request refused on capacity ("we have no time") invites the requester to find you more capacity, which they often can. A request refused against the outcome ("this does not move week-4 retention, which is what we agreed to change this quarter — if that is the wrong goal, that is the conversation to have") moves the discussion to the level where it can actually be settled.
When a date is genuinely needed
Refusing all dates is its own failure mode. Some dates are real: a contract, a regulatory deadline, a conference keynote, a partner integration going live. Cagan's distinction is the useful one — these are high-integrity commitments, made deliberately, for a small number of things, after enough discovery to know the shape of the work.
The sequence matters as much as the count. A high-integrity commitment is made after discovery, not before it: the team looks at the work, tests the risky assumptions, and only then says yes to a date. Being asked for the date first and the discovery afterwards is the ordinary case, and the honest answer to it is a date for when you will be able to give a date.
The practical rule that follows: a team should have very few such commitments at once, and each should be treated as a real promise rather than a line on a chart. A roadmap where every item has a date has no high-integrity commitments — it has thirty low-integrity ones, and nobody can tell which of them the company will actually be judged on.
How this shows up in real delivery
Changing the format alone does not work, and trying it is how most teams learn the second half of the lesson. If stakeholders ask for a feature roadmap and receive Now/Next/Later, they will read it as evasion unless something replaces the certainty they lost. What replaces it is rhythm: a short, regular review where they see the outcome numbers moving. Predictable information beats a predicted date, but only if the information actually arrives.
Where it degrades
- Now/Next/Later with a date quietly added to every item — the old roadmap in new columns.
- Later used as a graveyard for requests nobody wants to decline out loud.
- One roadmap sent to customers, stakeholders and the team, so it fits none of them.
- A prioritisation score treated as a decision rather than as a prompt for the argument.
- Never revisited, so the roadmap describes what was believed two quarters ago.
- Outcomes with no measurement behind them, which makes them features with better wording.
When to use it
Use it when
- The team is empowered to choose solutions, not just to schedule them.
- You can measure outcomes, so a commitment to one means something.
- Stakeholders will accept a regular review in exchange for fewer fixed dates.
- Discovery runs continuously, so Next genuinely resolves into Now.
Avoid it when
- Delivery is contractually fixed by scope and date — plan it, do not roadmap it.
- Genuine external deadlines dominate the quarter, such as regulation or a hardware launch.
- No outcome measurement exists yet — build that before promising outcomes.
- The format would change while the underlying commitment culture does not.
Found this useful?
Share it with someone who is working on the same problem.