The Roadmap as a Prototype for Your Strategy
Treat the roadmap like a design mock-up: its value is in the feedback it provokes, not the document itself.
- Difficulty
- Easy
- Time to result
- ~ongoing to results
- Steps
- 4
- Confidence
- 93%
Bastow reframes the roadmap from a plan to be executed into a prototype to be tested. A design prototype exists to surface what is wrong with your assumptions and then be thrown away; a roadmap does the same job one level up, at the strategy layer. You lay out your assumed problem sequence, show it to teammates and customers, and let them tell you where you are wrong.
Origin
Janna Bastow's own framing, explicitly extending lean prototyping practice (from the lean startup / lean UX world) from the feature level up to the strategy level.
Core principles
- 01The value is never in the artefact; it is in the process that produced it.
- 02A roadmap is a statement of assumptions about which problems matter and in what order.
- 03Prototypes are meant to be wrong — a roadmap that never changes after exposure was never tested.
- 04Anyone who will listen is a valid reviewer: teammates, customers, adjacent functions.
How to run it
- 1
State the roadmap as an ordered set of problems
Write out: I think we have this problem, then this problem, then that one. Explicitly frame it as your current best assumption, not a commitment.
- 2
Show it early and half-finished
Share the assumption set with the team, with customers, with anybody who will listen — the same way you would push a rough mock-up in front of a user rather than polishing it first.
Pro tip Ask the same question you ask of a mock-up: what's right or wrong about this?
Watch out If you only share the roadmap once it is signed off and polished, you have converted the prototype back into a plan and lost the learning.
- 3
Collect the corrections
Listen for reordering ('I thought it was going to go this way, then this way') and for omissions ('what about this problem?'). Both are strategy-level defects caught cheaply.
- 4
Adjust and re-share
Update the roadmap based on what you learned and put it back in front of people. Repeat continuously — the roadmap is a living instrument, not an annual artefact.
Pro tip Judge the roadmap by how much it improved after exposure, not by how impressive it looks.
In the wild
Bastow's analogy: you build a mock-up of a feature, show it to someone, they tell you what is wrong, you add a clearer button, and you throw the original out because it was not very good. Nobody mourns the mock-up — it did its job.
→ Applied to strategy, the roadmap you started the quarter with should be visibly better by the end of it because it was exposed and corrected, not defended.
Common mistakes
Treating the roadmap as the deliverable
Teams optimise the document — colours, alignment, sign-off — when the actual asset being produced is the shared, corrected understanding of which problems matter.
Only circulating the roadmap once it is final
A prototype shared after the decision is made cannot change the decision. The sharing has to happen while the assumptions are still soft.
Is it for you?
Best for
Product leaders who are asked to defend a roadmap as a plan of record and want a defensible alternative framing that keeps strategy testable.
Not ideal for
Environments where the roadmap is a contractual or legal commitment to an external client and cannot be revised in response to feedback.
From the transcript
“so the whole point about a roadmap is that it's not designed to be your plan I think about it as being a prototype for…”
“so the value isn't the Prototype the values in the prototyping process the value isn't in your roadmap the values in the road mapping process…”
From the episode
Building better product roadmaps
Janna Bastow (Mind the Product, ProdPad)