Roadmapping (outcome roadmap)
Start from the outcome you want, work back to the milestones that get you there, and agree who owns each one and when you will look again.
- Time
- 60 min
- People
- 4–8
- Kind of work
- Plan · Scale
In short
Roadmapping is a planning session where a team lays out how an idea will reach its intended outcome over time. You start from outcomes, list the milestones needed, order them by what depends on what, and name an owner and a review date for each. Treat the roadmap as a shared plan you revisit on set dates.
What it is
A roadmap is a picture of how you plan to get from where you are to where you want to be. It shows a small number of outcomes, the milestones that lead to each, the dependencies between them, and who is looking after each step. It is drawn along a rough time line, usually in months or quarters rather than exact dates.
The useful kind of roadmap starts from outcomes, such as "most permit renewals completed online", rather than a list of features or projects. That keeps the conversation on why each piece of work matters, and lets you drop or swap work if it is not moving the outcome. Good roadmaps also say when they will be reviewed, because plans change once real work begins.
When to use it
Use it when
- An idea has been tested and approved, and the team needs a shared view of how to get it running.
- Several teams or partners must contribute and depend on each other's work.
- Leaders want to see the plan at a glance without reading a long project document.
- An existing plan has drifted and needs to be reset around its outcomes.
- You need to explain trade-offs, such as what happens if a milestone moves.
Skip it when
- You do not yet know whether the idea works; test it first rather than plan in detail.
- The work is a single small task with one owner; a short to-do list is enough.
- Someone wants a fixed promise of dates for every feature; a roadmap will be read as a contract and lose its value.
You need
- Time
- About 60 minutes for a first version, plus a 30-minute review at each review date.
- People
- Four to eight people: the service owner, leads from each contributing team, and a facilitator.
- Materials
- A long wall or board with a time line drawn across it; sticky notes or cards for milestones; the worksheet with Outcome, Milestone, Dependency, Owner and Review date.
How to run it
Step 1: Write the outcomes first
Agree two to four outcomes the work should achieve, written as changes in the world, such as "applicants get a decision within five working days". Put them on the far right of the wall. If you cannot agree outcomes, stop and settle that before planning.
Step 2: List milestones for each outcome
For each outcome, ask what must be true along the way. Write each milestone on a card as a finished state, such as "Payment works for all card types", not an activity. Aim for four to eight milestones per outcome.
Step 3: Mark dependencies
Ask for each milestone: what must happen before this can start or finish? Draw arrows between cards. Look for dependencies on other teams, partners, budgets or approvals, and note them clearly. These are where most plans slip.
Step 4: Order milestones along the time line
Place the cards along the time line in the order the dependencies allow. Use broad time bands such as months or quarters. Leave space; a roadmap packed edge to edge has no room for what you have not thought of.
Step 5: Name one owner per milestone
For each milestone, agree the role that owns it: the person who will make sure it happens and raise problems early. Write a role, not just a name, so the roadmap survives staff changes.
Step 6: Set review dates and triggers
Agree when the whole roadmap will be reviewed, usually every four to eight weeks, and what would trigger an earlier review, such as a key dependency slipping by more than two weeks. Write these on the roadmap itself.
Step 7: Check it with the people involved
Before you share it widely, show the draft to each owner and dependent team and ask: is this realistic, and what are we missing? Adjust, then publish one version in a place everyone can find.
Worked example
A city's licensing department had tested a simpler mobile food truck permit with ten operators and wanted to make it the standard route within a year. Planning, inspection, payments and the call centre all had a part to play.
The group wrote three outcomes: most food truck permits issued online, inspections booked within ten days of application, and permit status visible on the truck through a code on the paper permit.
Milestones for the first outcome included "new application form live", "payment accepts all common cards" and "call centre scripts updated". For inspections, "inspection slots open for online booking" depended on the inspection team's new rota.
Drawing dependencies showed that the printed permit with a status code could not be designed until the records system change was approved, which sat with another directorate. The group made that approval its first milestone, owned by the department's digital lead.
They set a review every six weeks and a trigger for an early review if the approval moved past the end of the first quarter. Each owner confirmed their milestone within a week, and the roadmap went on the department's shared wall and intranet page.
IllustrativeTips and mistakes
Tips
- Keep outcomes visible on every version, so any new item has to show which outcome it serves.
- Use time bands such as now, next and later when dates are still uncertain.
- Show external dependencies in a different colour so leaders can see what is outside the team's control.
- Keep the roadmap on one page; detail belongs in each team's own plan.
Common mistakes
- Starting from a list of features or projects, so the roadmap describes busyness rather than progress.
- Writing milestones as activities, such as "work on payments", which can never be called done.
- Hiding dependencies on other teams, which then surface late as surprise delays.
- Treating the roadmap as fixed and never reviewing it, so it slowly stops matching reality.
What you walk away with
You leave with a one-page roadmap that links each milestone to an outcome, shows what depends on what, and names an owning role and review date for each piece of work. It gives leaders and teams one shared view of the plan. Next, use a RACI to clarify roles on the milestones where several teams are involved, and build a rollout checklist for the milestones that put a change in front of the public.
Questions people ask
What is the difference between a roadmap and a project plan?
A roadmap shows outcomes, major milestones and dependencies on one page, across months or quarters, so people can see the shape of the work. A project plan breaks the work down into detailed tasks, dates and resources. You usually need both, and the roadmap comes first.
How far ahead should a roadmap look?
Most service roadmaps look six to eighteen months ahead. Be more precise about the next few months and broader about later ones. If you cannot say anything useful about a period, leave it as a band labelled later rather than inventing dates.
How often should we update a roadmap?
Review it on a set rhythm, often every four to eight weeks, and whenever an agreed trigger happens, such as a dependency slipping. Keep a short note of what changed and why, so people trust the latest version.
Tool card
The worksheet your team fills in, one box per field.
- Outcome
- Milestone
- Dependency
- Owner
- Review date