High-Level Roadmap: How to Build One, With a 12-Month Example
8 min read ยท 2026-10-25
A high level roadmap is a one-page visual that shows the main initiatives of a product, project or program over a period, usually 6 to 18 months, grouped into themes or workstreams, with major milestones and no task-level detail. Its job is to show direction and order, so leaders can approve priorities and teams can plan their own detailed work underneath it.
This guide walks through building one in about five weeks: gathering inputs, choosing themes, sequencing by quarter, testing with stakeholders and publishing it with a review rhythm. It also gives a filled-in 12-month example, a layout you can build in PowerPoint or Excel, who owns what, how to present it and the traps that turn a high-level roadmap into a cluttered Gantt chart.
The roadmap at a glance
Goal: A one-page high-level roadmap for the next 12 months is approved by leadership, shared with every team and reviewed every quarter. Duration: 5 weeks
Gather inputs (Week 1)
Collect the strategy, constraints and commitments the roadmap must reflect.
- Get the company or department goals for the period, such as annual objectives or OKRs.
- List initiatives already committed or in flight, with their owners and current dates.
- Collect requests from stakeholders: sales, operations, finance, customers and regulators.
- Note fixed dates and constraints: contract renewals, regulatory deadlines, budget cycles, freeze periods.
- Check team capacity at a rough level: how many teams or people are available each quarter.
Milestone: An input list with goals, committed work, requests, fixed dates and rough capacity, shared with your sponsor.
Define themes and outcomes (Week 2)
Group the work into a few themes tied to goals.
- Group initiatives into three to five themes or workstreams, such as customer experience, efficiency or compliance.
- Write one outcome per theme, such as reduce onboarding time for new clients.
- Link every initiative to a theme and a goal, and question the ones that fit nowhere.
- Choose the time scale: quarters for a 12-month roadmap, months for a six-month one.
Milestone: Three to five themes with outcomes, and every initiative mapped to a theme.
Sequence and size (Weeks 2-3)
Place initiatives in time in a realistic order.
- Rank initiatives inside each theme by value, urgency and effort.
- Place them on the timeline by quarter, respecting dependencies and fixed dates.
- Mark dependencies between initiatives and with other teams.
- Check the plan against capacity and move lower-priority items to later quarters or a not-now list.
- Add a few major milestones, such as go-live or contract signature, as diamonds on the timeline.
Milestone: A draft one-page roadmap with initiatives by quarter, dependencies and milestones that fits capacity.
Review with stakeholders (Weeks 3-4)
Test the draft with the people who will deliver it and the people who rely on it.
- Walk team leads through the draft and ask what is unrealistic or missing.
- Review with key stakeholders one by one before any group meeting, so nobody is surprised in front of peers.
- Record every change request and the reason you accepted or declined it.
- Agree the confidence level for each quarter: firm for the next quarter, likely for the one after, possible beyond.
Milestone: A revised roadmap that team leads and key stakeholders have reviewed, with a log of changes and decisions.
Approve, publish and set the rhythm (Week 5)
Get formal approval and make the roadmap a living document.
- Present the roadmap to leadership and get approval for the themes and the next two quarters.
- Publish it in one shared place, such as Confluence, SharePoint or a shared drive, with a version date.
- Set a quarterly review date and a monthly status update for initiatives in progress.
- Agree a simple rule for changes: who can request one and who approves it.
Milestone: Roadmap approved by leadership, published with a version date, and the first quarterly review booked.
What goes on a high-level roadmap
A high-level roadmap answers three questions on one page: what are we working on, in what order and why. Everything on it should serve those questions. If an item does not help a leader make a decision or help a team plan its work, it belongs in a lower-level plan.
A practical rule of thumb is that someone should understand the roadmap in under a minute without you in the room. If they cannot, there is too much on it.
- Time horizon: usually 12 months in quarters, sometimes 6 or 18 months.
- Swimlanes: one row per theme, workstream or team.
- Initiatives: bars with short names, placed in the quarters when they run.
- Milestones: a few diamonds for major events, such as go-live or a regulatory deadline.
- Dependencies: simple arrows or markers between initiatives that block each other.
- Status or confidence: a color or label for done, in progress, planned and possible.
- Legend, owner and version date: so readers know who maintains it and how current it is.
High-level roadmap vs detailed project plan
A high-level roadmap shows initiatives and outcomes by quarter. A detailed project plan, often a Gantt chart in Microsoft Project, Smartsheet or Jira, shows tasks, durations, assignees and dependencies by day or week. Leaders use the first to decide priorities. Teams use the second to run the work.
Keep them linked but separate. Each bar on the roadmap can point to a project plan or an epic in your delivery tool. When you need to change a date on the roadmap, the reason should come from the plan underneath, not from a guess.
Example: a filled-in 12-month high-level roadmap
Picture a regional insurance broker that wants clients to manage their policies online. The head of digital owns the roadmap. There are three swimlanes: client portal, systems and data, and operations and change.
Notice what is not there: no tasks, no sprint numbers, no names of developers. Each line is an initiative with an owner and a milestone that leadership can check.
- Q1, owner head of digital: client research and portal design (client portal); policy system API assessment (systems and data); service team process mapping (operations). Milestone: portal scope and vendor approved.
- Q2, owner IT manager: portal build for policy viewing and documents; API connection to the policy system; data cleanup of client contact records. Milestone: portal pilot with 200 clients.
- Q3, owner operations director: full launch to all personal lines clients; staff training and new service procedures; launch campaign with marketing. Milestone: portal live for all personal lines clients.
- Q4, owner head of digital: online claims start and payment updates (planned); commercial lines assessment (possible). Milestone: next year's roadmap approved.
How to build it in PowerPoint or Excel
In PowerPoint, start with a blank slide in widescreen format. Use Insert, then Table, to create a grid with one column for the swimlane names and one column per quarter, and one row per swimlane. Add initiatives with Insert, then Shapes, using rounded rectangles that span the quarters they cover. Use Home, then Arrange, then Align to line them up. Add milestones as small diamond shapes and a legend in a corner. Keep text inside bars to four or five words.
In Excel, put initiatives in rows and months or quarters in columns. Add columns for theme, owner and status on the left. Fill the cells for the period each initiative runs using Home, then Fill Color, with one color per theme. Freeze the header row and the left columns with View, then Freeze Panes, so the sheet stays readable when it grows. Excel works well as the master list, and a PowerPoint slide works well as the view you present.
Whichever tool you use, use one color per theme or status and explain it in a legend. Avoid more than five colors.
Who owns what
A roadmap without an owner goes stale within a quarter. Name one person who maintains it and one forum that approves changes.
Write the owner and the version date on the roadmap itself, so anyone who finds an old copy knows to check for a newer one.
- Roadmap owner (product manager, PMO lead, program manager or head of department): maintains the roadmap, runs reviews and logs changes.
- Executive sponsor: approves themes and priorities and settles conflicts between teams.
- Initiative owners: keep dates and status current for their initiatives and flag risks early.
- Team leads: confirm capacity and build detailed plans under each initiative.
- Key stakeholders (sales, finance, operations): give input before each review and use the roadmap to plan their own work.
How to present it to leadership
Start with the goals, not the bars. One sentence per theme on why it matters sets up the rest. Then show the roadmap and walk through it by quarter, focusing on the next two quarters, where the plan is firm.
Show confidence clearly. Mark the next quarter as committed and later quarters as planned or possible. Leaders accept change much better when they knew from the start that a later item was a best estimate.
End with the decisions you need, such as approving a trade-off between two initiatives or extra capacity for one quarter. Leave the detailed plans, estimates and dependency lists in the appendix.
Common mistakes to avoid
- Packing tasks and sub-tasks onto the roadmap makes it unreadable, so keep only initiatives and major milestones and link to detailed plans.
- Showing exact dates for work a year away creates false promises, so use quarters and mark later items as planned or possible.
- Listing initiatives with no link to goals invites endless debate, so tie every initiative to a theme and an outcome.
- Ignoring team capacity produces a roadmap nobody can deliver, so check each quarter against the teams available before you publish.
- Building the roadmap alone and presenting it as final creates resistance, so review the draft with team leads and stakeholders first.
- Publishing once and never updating makes people stop trusting it, so set a quarterly review and show a version date on every copy.
Frequently asked questions
What is a high-level roadmap?
It is a one-page view of the main initiatives for a product, project or program over a period, usually grouped by theme and shown by quarter. It shows direction, order and major milestones, without task-level detail. Leaders use it to agree priorities, and teams use it to plan their own work.
What should be included in a high-level roadmap?
Include a time horizon, swimlanes for themes or teams, initiatives placed in time, a few major milestones, key dependencies, a status or confidence marker, an owner and a version date. Leave out tasks, assignees and daily dates.
How far ahead should a high-level roadmap go?
Most cover 12 months in quarters, with the next quarter firm and later ones less certain. Fast-moving products may use six months, while large programs may show 18 months or more. Review it at least every quarter.
What is the difference between a high-level roadmap and a Gantt chart?
A high-level roadmap shows initiatives and outcomes by quarter for decision makers. A Gantt chart shows tasks, durations, dependencies and assignees by day or week for the team running the work. Many teams keep both and link each roadmap item to its detailed plan.