Outcome roadmaps
A roadmap says which problems you will work on and in what order. This lesson shows you how to turn a long feature list into three or four outcomes with metrics, lay them out as Now, Next and Later, protect time for tech debt and keeping the lights on, and say how sure you are, so the roadmap survives contact with reality.
By the end you can
- Turn a list of 16 features into four outcomes with metrics, and park what fits none
- Lay out a Now/Next/Later roadmap and move items between columns as evidence grows
- Map dependencies on other teams, vendors and calendar freezes
- Split capacity between new work, tech debt and keep-the-lights-on, starting from last quarter's real numbers
- Communicate uncertainty, and handle the request "just give me a date"
The everyday picture
Look at a weather forecast. For tomorrow it says "rain from 3 pm, 18 degrees". For next week it says "showers likely midweek". For next month it says "wetter than usual". The forecaster is precise about the near future and honest about the far future, and she updates the forecast every day as new readings come in.
Nobody calls her a liar when next month's outlook changes, because she never promised rain at 3 pm four weeks from now. Imagine a forecaster who did: a calendar with an exact temperature for every day of the year. It would look impressive in January and be wrong by February. Many product roadmaps are that calendar. This lesson builds the forecast instead: specific for Now, likely for Next, directional for Later, and updated as you learn.
Why feature-and-date roadmaps break
The classic roadmap is a timeline: a feature on each row, a bar from a start date to an end date, months into the future. It is easy to read and it feels like control. It also makes four promises nobody can keep:
- It promises outputs. Each bar is a feature, so success means shipping it, whether or not it works (the build trap from OKRs and outcome goals).
- It promises estimates months ahead. Work that nobody has designed yet gets a date. When it slips, the team is "late" on a guess.
- It hides learning. If discovery shows a feature isn't needed, dropping it looks like failure.
- It becomes a contract. Stakeholders plan around the dates, so every change becomes a negotiation.
An outcome roadmap changes the unit. Each item is a problem to solve, with the metric that shows it is solved and the team's current bets for solving it. Features still appear, as the current best guess, and they can change without the roadmap changing. Janna Bastow designed the Now/Next/Later format at ProdPad as an alternative to timelines; ProdPad describes the timeline roadmap as "setting people up to fail". The book Product Roadmaps Relaunched (2017) makes the same case at length.
Quick check
Which roadmap item is written as an outcome?
Option 2 names the problem, the metric with a baseline and target, and lists features as bets that can change. Options 1 and 4 are features or tasks with dates. Option 3 is a label that says nothing about what will change.