A roadmap is the strategy written as sequenced work, and it is where a set of choices stops being a document and starts consuming engineering time. Product economics settled how an allocation argument gets decided between two products. The same arithmetic runs inside one product, and there the things being compared are pieces of work. The roadmap is where that comparison gets recorded. For most of the organisation the roadmap is the only strategic artefact anybody ever reads. That makes writing it the moment a product manager either keeps the strategy or loses it. Everything the earlier pages settled reaches the rest of the company through this one document, and whatever fails to survive the trip is not part of the strategy at all.
The sections below explain why a dated feature list signals a missing strategy. They then trace the chain from a diagnosis down to a single roadmap item. The four formats in common use come next. Two shorter sections follow, on the column that keeps the diagnosis attached and on sequencing by assumption. The page ends with what to do about the demand for dates.
Why a dated feature list is a symptom
A roadmap listing named features against named quarters is not wrong in itself, and it becomes a symptom only when it is the only artefact the team has, because of what the format cannot carry.
A feature is a solution. Committing to it in July for delivery in November says the team already knows the best answer, four months before it will have the evidence for that. If the answer genuinely is known, which happens with regulatory work and with contractual commitments, a dated list is the honest format. If it is unknown, the list turns a guess into an obligation, and the obligation outlives the guess.
The second cost is harder to see. A feature list has nowhere to record why. Six months later the item is still on the plan, the person who understood the reasoning has moved teams and the item now survives because nobody has a reason to take it off. Teams describe this as a roadmap that never gets shorter.
The chain from a choice to an item
A team should be able to trace every roadmap item back through the reasoning that produced it. The chain has four links. A team that can recite all four for an item has a strategy in execution.
The box on the right is the only one most of the organisation ever reads. Carrying the three to its left alongside it is what stops the item being reopened each quarter by somebody who never saw them.
The example continues the refrigeration maintenance product used earlier in the course. The diagnosis came from field data showing that two visits in five ended without a repair. The guiding policy chose to compete on parts data and to leave scheduling to the incumbent, since scheduling was where every rival was already fighting. The outcome states what would have to change for the policy to be working. Only then does an item appear, and the item is one of several that could serve the outcome.
A real chain shows itself in the number of items that could have served the outcome. If exactly one possible item exists, the team has worked backwards from a solution somebody already wanted and written the reasoning afterwards.
The four formats and what each one commits to
| Format | What it commits to | Where it works | Where it breaks |
|---|---|---|---|
| Dated feature list | Named solutions on named dates | Regulatory deadlines, contractual commitments, launches with external dependencies | Anywhere the solution is still genuinely unknown |
| Now, next, later | Order and a rough horizon | Keeping the conversation on sequence and away from precision nobody has | Audiences who need a date to plan their own commitments |
| Outcome themes | The change the team is accountable for | Holding the strategy in view while the solution is discovered | Teams with no discovery practice, where it becomes a wish list |
| Release plan | Scope and date for the next release only | The near term, running alongside one of the formats above | Anything past the release it covers |
The now, next and later format, argued for over more than a decade by Janna Bastow and ProdPad, works by removing false precision. An item in the later column is a direction. An item in the now column is being worked on. Nobody has to pretend that the fourth quarter is knowable in the first.
Product Roadmaps Relaunched, published in 2017 by C. Todd Lombardo, Bruce McCarthy, Evan Ryan and Michael Connors, makes the underlying argument directly. A roadmap is a statement of intent and a prototype of the strategy. Treating it as a delivery schedule is what creates the credibility problem, and teams then blame the format for it.
Keeping the diagnosis attached
The practical version of everything above is a column on the roadmap. Beside each item goes one sentence naming the outcome it serves. Beside the outcome goes a link to the evidence that established the problem.
Two things follow once that column exists. An item can be removed without an argument once its outcome has already been reached, because the case for it has visibly expired. An item arriving from a senior stakeholder has somewhere to be placed, and the conversation becomes which outcome it serves. It stops being a conversation about how important the requester is.
Teresa Torres's opportunity solution tree, set out in Continuous Discovery Habits in 2021, is the fuller version of the same idea. One outcome sits at the root. Beneath it sit the opportunities that could move it, and beneath those sit the solutions. The tree shows how many candidate solutions the team weighed under each opportunity, and that count separates a team that is discovering from one working through a list somebody settled in advance.
Sequencing by what has to be true first
Most roadmaps are sequenced by value, by effort or by whoever asked loudest. A strategy under execution has a better ordering available, and it comes from the assumptions the strategy rests on.
If the strategy has a load bearing assumption that nothing has yet tested, the work that tests it belongs early, ahead of items with larger expected value. The reasoning is the cost of being wrong. An item delivering six months of build on top of an untested assumption puts the whole six months at risk. A two week test that settles the assumption either unlocks the six months or saves them.
This is where the assumptions list stops being a workshop artefact and starts doing work. It produces a sequence a team can defend to somebody who wanted their feature first.
What to do about dates
Refusing to give dates is rarely available. It is also usually the wrong fight. Other people have their own commitments, and those depend on this work. Refusing to help them plan gets a product manager routed around within a quarter.
The workable position separates three kinds of date. A committed date is one the organisation will be held to, and it should exist only if the scope is genuinely known and the team has said yes deliberately. A forecast is the team's current best estimate with its uncertainty stated, which is the honest answer for most near term work. A horizon is a quarter or a half, attached to a direction and carrying no promise about scope at all.
Most roadmap conflict comes from one party reading a horizon as a commitment. Labelling the three explicitly on the artefact itself removes more friction than any format change.
A roadmap says what the team will work on and in what order. It says nothing about what would count as having succeeded, and that belongs in a separate artefact. That artefact is the one most likely to be filled in badly.