Method · Delivery & Validation
Delivery Roadmap
A sequence of bets ordered by uncertainty and dependency, firm in the near term and deliberately loose further out, that shapes what you build and learn in what order.
A roadmap full of features promised on dates is not a plan. It is a commitment device wearing a plan’s clothes, and it cannot absorb a single thing you learn.
The signature visual
The confidence-gradient bet sequence
Near bets are firm: solid borders, precise scope, pre-committed gate criteria. Far bets are deliberately loose: dashed borders, intent rather than features, provisionally shaped. The learning arrows that curve backwards from later bets to earlier ones are not decoration. They are the mechanism by which the roadmap stays honest as evidence arrives.
What it is
A sequence of bets, not a list of commitments
A delivery roadmap is a time-ordered sequence of bets (decisions to invest in a specific thing with a specific expectation of what it will prove or produce) where each bet’s scope and specification is calibrated to how much you currently know. Near bets are fully specified. Far bets are deliberately loose. The gradient is the honest acknowledgment that you cannot fully specify what you have not yet started learning.
The sequence is ordered first by uncertainty and dependency, not by commercial visibility or convenience. The riskiest assumption (the one that, if wrong, invalidates everything that follows) goes first, specified cheaply. Only after that question is answered do you commit resources to the next rung.
Gates separate bets. Each gate carries pre-committed criteria (set before the bet starts, not after the evidence arrives) that determine whether to proceed, adjust, or stop. A gate you would never actually stop at is not a gate; it is a ceremony. A real gate shapes what you build next.
The learning arrows are the structural difference between a delivery roadmap and a Gantt chart. They run backwards: from later bets to earlier ones, reshaping the near term as evidence accumulates. When those arrows fire, the roadmap changes. That changeability is not a sign of poor planning. It is the point.
Explore the interactions
Click in. Resequence. Sever.
Click any bet to see what it tests and what depends on it. Toggle sequence order to see what happens when risk is reordered for convenience. Sever the learning arrows and watch the roadmap degrade into a rigid schedule: the gradient disappears, every bet looks equally confident, and the honesty is gone.
When to deploy
When you have multiple bets that need ordering
The right moment
- After assumption mapping has identified the riskiest question
- When you have more than one candidate next step and need to choose an order
- When stakeholders are asking for a plan and you need a disciplined structure to offer
- When an existing roadmap is being used as a commitment device rather than a learning sequence
Not yet ready when
- The riskiest assumption has not yet been named, sequence before mapping is premature
- There is only one viable next step with no sequencing decision to make
- The organisation will not accept gates that can actually stop work, a roadmap without real gates is a schedule
- You are planning across portfolios rather than sequencing within one delivery effort (use the Ambition Matrix instead)
How it works
Six disciplines
Map assumptions before you sequence
Run Assumption Mapping first. The leap-of-faith assumption (the riskiest one, the one whose failure invalidates everything) goes to the front of the roadmap regardless of its commercial visibility. You cannot sequence responsibly without knowing which assumption is existential.
Order by uncertainty and dependency, not convenience
The riskiest bet goes first because it is cheapest to fail at the beginning. Ordering by convenience (building what is familiar and demo-able, deferring the existential question) is the most common sequencing error. When you catch yourself doing it, stop and ask: what happens if the hard thing turns out not to work?
Specify near bets precisely; keep far bets deliberately loose
Near bets should have precise scope, clear deliverables, and pre-committed gate criteria. Far bets should describe intent, not features. They are provisionally shaped because they depend on what the near bets will teach you. The gradient is honesty. Collapsing it to uniform specification is the lie that turns a roadmap into a Gantt chart.
Design gate criteria before the bet starts
Pre-commit the criteria for each gate before the bet begins, not after the data arrives. The threshold (what “go” means, what “no-go” means, and critically, what a “no-go” would change) must be agreed when the organisation is not yet invested in a particular outcome. A gate that nobody would actually stop at is a ceremony, not a decision point.
Let the learning arrows fire
When a bet produces a finding, let that finding reshape earlier bets before the resources for the next phase are committed. This is the learning arrow firing. A roadmap that cannot be reshaped by its own evidence is not a roadmap; it is a project plan that has been scheduled rather than sequenced.
Revisit on a cadence, not just at gates
Gates are decision points, but the roadmap should be reviewed on a regular cadence between them. New market signals, changed dependencies, or updated team capacity may warrant reshaping a bet before its gate arrives. The cadence review is what keeps the far end from calcifying into false precision over time.
Sequencing ambition
The family of crawl-walk-run progressions
The confidence-gradient sequence structures HOW you deliver. But the roadmap also carries a second dimension: HOW MUCH you attempt at each rung. Ambition must be earned through gate performance. The most common sequencing failure is not wrong risk ordering but starting at full ambition before the foundation has been proven.
Crawl → walk → run
The most explicit form. Start with constrained scope, expand ambition as each stage proves the model. The delivery staircase in this method is a crawl-walk-run: PoC (crawl) → smallest release (walk) → pilot → rollout (run).
Step then leap
A controlled beachhead followed by a larger expansion once the model is proven. Common in market-entry contexts where the initial step is deliberately sub-scale to test the model cheaply.
Beachhead then expansion
Concentrate fully on one segment, geography, or channel until it is deeply won, then expand. The beachhead proves the value model and delivery model before resources are committed to adjacent territory.
Thin slice then thicken
Deliver an end-to-end thin slice (every capability, but in minimal form) then deepen each dimension as evidence warrants. Useful when proving integration is the main risk.
Horizon 1 / 2 / 3
Core, extend, and explore bets run in parallel with different gate structures and investment levels. The roadmap manages transitions between horizons as one horizon matures and another requires more resource.
Core rule: ambition must be earned.
The anti-pattern, running first, appears as organisational confidence, not recklessness. The team knows the problem well. The leadership wants to show speed. The stakeholders want full-scope delivery. The result is a commitment to full ambition before the foundation has been proven. When the foundation fails, the scale of the failure is proportional to the ambition that was front-loaded into it.
Best practices
What good looks like, and the mistakes
What a healthy roadmap looks like
- Gate criteria are pre-committed before the bet begins, not after the evidence arrives
- Far-end items describe intent and outcome, not features and dates
- Learning arrows actively reshape near-term bets when evidence warrants
- Stakeholders understand and accept that the far end is loose by design
- The roadmap is reviewed on a cadence, not only at gates
- Riskiest assumption is positioned first regardless of commercial visibility
Mistakes and pathologies
- ⚠Convenience ordering: familiar and demo-able work first, existential question scheduled last
- ⚠Uniform specification: far-end bets are as precisely defined as near-end ones, hidden uncertainty
- ⚠Sham gates: criteria that no reasonable outcome would fail, ceremonies, not decisions
- ⚠Sham looseness: the roadmap is described as Agile, but commitments and dates are fixed
- ⚠Severed learning: findings from bets are noted but do not actually reshape subsequent bets
- ⚠Feature accumulation: new ideas are added to the far end without displacing anything
Logistics
What running this requires
Time required
Ongoing: initial sequence in 1–2 weeks; revisited on a cadence as evidence arrives
Group size
Team lead(s) plus stakeholders for gate decisions; one or two people maintain the living document
Format
Works remotely and in person; the bet sequence should be a shared, visible artefact, not a slide deck filed away
Prerequisites
Assumption mapping completed; riskiest assumption named; team has authority to actually stop at a gate
Outputs
Sequenced bet list with horizon labels; gate criteria for each transition; learning arrow definitions
Revisit cadence
Weekly or fortnightly between gates; mandatory review at each gate; triggered review when a major finding fires a learning arrow
AI-reactivated
AI and the delivery roadmap
AI is genuinely excellent at roadmap mechanics: dependency detection, capacity modelling, sequencing option generation, and maintenance. The danger is that it also produces uniformly confident plans, losing the gradient that is the roadmap’s honesty. The toggle below shows what is gained and what is lost.
Worked example
A logistics platform sequences its bets
A team building a real-time driver-matching platform faces two genuine risks: whether the routing algorithm holds at scale (technical and existential) and whether operations teams will adopt a new workflow (commercial and manageable). The sequencing decision, and what happens when AI builds the roadmap instead, illustrates the method’s core logic.
Shared scenario
A company is building a logistics platform that matches drivers to deliveries in real time. The technical crux is a routing algorithm at scale. The team has never run this at the volume the business requires. The commercial question is whether operations teams in partner companies will actually adopt a new workflow. Both are genuine bets. The team must decide which goes first.
Both versions face the same sequencing decision. Only the approach differs.
The sequencing decision: which bet goes first?
The team mapped its assumptions and identified the riskiest one: not whether operations teams would adopt (that was a commercial risk, manageable) but whether the routing algorithm could actually work at the required scale. If it could not, no amount of adoption work would matter. The technical question was existential. It went first.
Bet 1: Technical proof of concept (weeks 1-3)
The team ran the algorithm against simulated load data, then against anonymised historical data from a willing pilot partner. They set a pre-committed threshold: if assignment latency exceeded two seconds at 10,000 concurrent requests, the approach would need to change. The threshold was not negotiated; it was pre-committed before the experiment started. The result: the algorithm held at scale. The existential question was answered in three weeks, not nine months.
Bet 2: Smallest real release to one operations team
With the technical foundation confirmed, the team built the smallest real product, not a prototype, but a working system for one operations team at one partner company. Pre-committed criteria: adoption rate above 70% within four weeks, and dispatch error rate below 3%. Both were met. The commercial question was answered. The team also learned that operations managers wanted an override capability the team had not planned for. That finding reshaped bet 3.
The learning arrow fires: bet 3 is reshaped before it begins
The pilot had been planned as a three-region expansion with no override feature. The release finding (that override capability was operationally essential) triggered a reshape before the pilot started. The pilot was scoped to two regions, with override built in, and the gate criteria updated to include override usage patterns. This is what the learning arrow does: a finding in bet 2 reshaped bet 3 before resources were committed to the wrong version of it.
What the roadmap actually looked like at any moment
Near bets were precisely specified with pre-committed gate criteria. Far bets were deliberately loose, described in intent, not in features. The roadmap was not a promise; it was a sequence of bets, and its far end was allowed to stay uncertain until evidence warranted specifying it.
Framework connections
Where this sits in the larger frameworks
Agile Innovation
Agile explicitly argues against long fixed roadmaps. The delivery roadmap gives Agile teams a risk-ordered bet sequence to work from rather than a feature backlog that implies equal priority.
Double Diamond
The second diamond is where the delivery sequence lives. The roadmap structures the Deliver phase into ordered bets rather than a single build-and-launch effort.
Lean Startup
Lean Startup’s core logic (riskiest assumptions first, cheapest test possible) is the sequencing principle for the delivery roadmap. The roadmap operationalises Build-Measure-Learn across multiple bets.
Front-End of Innovation
Pointed tension: FDE requires that central roadmaps subordinate themselves to discoveries from field work and experiments. The delivery roadmap must be structured so that field findings can reshape near-term bets, not just annotate a fixed plan.
Related methods
The methods that connect here
The delivery roadmap is connective tissue: it sequences and orders the other Delivery & Validation methods, carries the gate criteria between them, and provides the structure into which their outputs feed. These connections are not incidental. The methods listed below each have a specific place in the bet sequence.
The leap-of-faith assumption that surfaces from mapping goes to the front of the roadmap. Do not sequence until you know which assumption is existential.
When technical or feasibility risk is the existential question, the PoC is the roadmap’s first rung. This method specifies what that first bet looks like.
The roadmap carries the staged rollout: the pilot is the third bet, and the gate criteria for moving from pilot to wave-based rollout live here.
The DECIDE-to-SHIP junction in the feedback loop lives in the roadmap. What the loop produces at DECIDE becomes a roadmap change: a new bet, a reshaped bet, a gate that fires.
If the delivery sequence requires capability that does not yet exist, building it is itself a roadmap bet, not a prerequisite that lives outside the plan.
The smallest real release is the second rung: the bet that tests whether the product concept works for people, after the PoC has answered whether the hard thing is buildable.
Companion for the ambition axis. The matrix places bets by ambition across a portfolio; the delivery roadmap sequences ambition over time within one delivery effort. The two tools work at different scopes but share the same underlying logic.
Sources and further reading
What this draws on
The Lean Startup- Eric Ries
The foundational case for riskiest-assumption-first sequencing and Build-Measure-Learn as the structural logic of delivery planning.
Shape Up (Basecamp)- Ryan Singer
Betting as the unit of planning; appetite-based scoping rather than estimate-based commitment; shaping before sequencing.
Good Strategy / Bad Strategy- Richard Rumelt
The distinction between a real plan (a coherent sequence of choices) and a list of goals dressed as strategy: directly applicable to the roadmap-vs-commitment-device problem.
The Innovator’s Dilemma- Clayton Christensen
The logic of starting small, in a contained space, and expanding only as the delivery model proves itself, the progression logic behind crawl-walk-run.
Playing to Win- Roger Martin
Strategy as a cascade of bets across time horizons; the idea that choices about where to play and how to win must be sequenced, not listed in parallel.