Roadmap
Work back from an outcome to stage outputs, enabling resources and explicit decisions, keeping tentative windows distinct from commitments.
Use a roadmap to align direction, stage outcomes and enabling capabilities. Work back from the destination, then identify the resources and checks each stage requires. Use a Gantt chart separately when detailed task dates and dependencies are needed.
The current state, a justified outcome, stage outputs, broad windows, resource constraints, dependencies and actual commitment status.
A staged route with outputs, windows, capabilities, entry and exit checks, and review points.
On this page
How to use it
- State the current position, justified outcome and decision authority.
- Work back to necessary stages and define an output that can be checked at each one.
- Identify the approach, capabilities, resources and dependencies.
- Mark the window, entry conditions, exit checks and commitment status.
- Review as evidence changes; add task scheduling without replacing stage outcomes with dates.
Keep its limits in mind
A roadmap is not approved funding, a detailed schedule or a delivery guarantee. Distinguish tentative windows, options, commitments and achieved outputs. Gates need actual checks; a proposed pilot is not an observed improvement. Capacity is not inferred from a timeline.
Planning three stages before a booking-pilot decision
Fictional teaching example: Pinebridge is preparing a booking-service pilot. Packet F0 records one mature W0 cohort: 100 eligible requests, 60 confirmed bookings and 48 completed services within those 60. The future pilot, staffing and plans are unapproved and unexecuted.
On a small screen, scroll across the diagram to read it.
Define the destination: The preparation ends with a decision, not a promised launch or 60 completed services. Stage 1 supplies definitions; stage 2 supplies configuration, an operating checklist and rehearsal evidence.
Preserve the gates: Stage 2 depends on A; D depends on both B and C. Stage 3 requires actual readiness and resource checks. The Sponsor can decline or reschedule the pilot.
Result: This is a route for discussion. The Analyst's eight hours and Builder/Ops capacity remain proposed. No stage is recorded as completed and no approval has been obtained.
This roadmap is a preparation draft. Oct 27 is a proposed decision date, and Oct 28 is a reserve day. Neither indicates achieved business results or an approved launch.
Next step: The Lead should confirm stage outputs and resource availability, then check task dates. Record the Sponsor's actual decision separately.
Three reasons to pause before publishing a roadmap
Use a roadmap to discuss how a direction could become possible through successive outcomes. Write the destination, evidence needed at each stage and enabling capabilities before choosing attractive dates. A short roadmap may be useful when the real uncertainty is whether to proceed, not how many features can fit into a quarter.
Pause if the destination has no agreed meaning. Pause if a tentative window is being copied into a customer promise without checking authority and resources. Pause if the stages merely rename a backlog without explaining why one outcome enables the next. Resolve those problems before adding detail; a longer timeline cannot supply a missing decision.
Give each item a status such as option, proposed work, agreed commitment or verified output, using only records that support it. Keep the intended reader in mind. A Sponsor needs the decision and conditions; a delivery team also needs task-level dependencies. Neither audience benefits from a colored bar that conceals an unresolved gate.
Choose the view that matches the planning question
A roadmap can identify which capability must exist before a later choice. It does not allocate every person’s day. Move to a schedule only after the relevant scope and assumptions are explicit; return to the roadmap if the intended destination changes.
| Method | Required input | Output |
|---|---|---|
| Roadmap | Destination, stages, capabilities and gate evidence | A conditional route and review points |
| Gantt chart | Tasks, dependencies, dates and working calendar | A task schedule to check against capacity |
| PERT chart | An acyclic dependency network and duration estimates | Conditional paths and total float |
| SMART | A goal, baseline, definition and observation window | A measurable agreement to confirm |
Worked case: prepare a decision before promising a pilot
This continues the fictional Pinebridge F0 packet used in the diagram. W0 is a mature cohort: 100 eligible requests, 60 confirmed bookings and 48 completed services within those 60. The later target of 60 completed services is conditional. It is not the stage-three deliverable and does not follow automatically from preparing a pilot.
Work backward from E, the proposed October 27, 2026 go/no-go decision. The Sponsor needs readiness material, so stage two proposes B configuration, C checklist and D joint rehearsal. D requires both B and C. Those activities need common definitions from A, so stage one proposes eight Analyst hours for definitions and check criteria, with a Lead check. No task has completion evidence in the packet.
The table translates each stage into a proposed evidence question. These are suggested checks for the discussion, not extra approvals already obtained. Builder and Ops capacity is assumed at four hours each per workday and remains unconfirmed. October 28 is an unallocated reserve; an available-looking date does not reserve people or guarantee the decision.
| Stage / window | Proposed output | Gate question / status |
|---|---|---|
| A: October 19–20 | Definitions and check criteria | Can Lead check a common scope? Not completed |
| B, C, D: October 21–26 | Configuration, checklist, joint rehearsal material | Are both inputs ready for D? No execution record |
| E: October 27 | A decision request prepared by Lead | Can Sponsor decide with readiness and resources checked? Unapproved |
| October 28 | Unallocated reserve | People and decision availability not secured |
Write a conditional conclusion and retain the change reason
The conclusion is a route to a decision, with two unresolved enablers: actual readiness and available people. The Lead should confirm each stage’s output and resource assumptions, then check the detailed task dates. The Sponsor can approve, decline, narrow or reschedule the pilot; the roadmap itself selects none of these outcomes.
Consider the supplied delay scenario as a planning question: if B ends October 26, D moves to October 27 and E to October 28 under unchanged dependencies. Record the proposed shift, the consumed reserve and the need to reconfirm participants. Do not silently move the bar while continuing to advertise an October 27 decision. A missed preparation window also does not establish a change in the 48-service baseline.
At each stage review, retain the old window, new proposal, triggering evidence, affected dependencies, decision owner and actual authorization status. Ask whether the destination still matters and whether the next gate can be checked. If not, pause the downstream promise. When a decision eventually occurs, append its scope and conditions separately from execution and later service outcomes. This leaves a usable history of what was planned, what was decided and what actually happened.
Check your work
- The route links the current state to outcomes through explicit conditions.
- Windows and resource assumptions are visible; gates are not presumed passed.
- Direction and detailed scheduling are separate, and targets are not achieved benefits.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.