Project Roadmap: Examples, Template, and How to Build One
Most project roadmaps fail in one of two ways. They are too detailed (a Gantt chart with every task that becomes a project plan in disguise). Or they are too vague (a slide with three boxes labeled Q1, Q2, Q3 and no real content). Neither version helps the team work. Neither survives the first month of execution.
This guide covers the project roadmap as it actually works in 2026. The 3 types you can choose from. What belongs on the roadmap and what does not. The crisp difference between a roadmap, a charter, a plan, and a timeline. Plus a 5-step build process. Use the visual creator below to draft a roadmap as you read, then copy the outline or open it as a Rock workspace.
Build a project roadmap
Click a bar to rename it. Drag a bar to move it. Drag the edges to resize. Rock does not render Gantt charts. Once your roadmap is drafted, copy the outline or start the project workspace in Rock.
Tip: hover a bar to see resize handles on its edges. Click + Add phase to create a new bar (it opens for you to type a name).
Quick answer. A project roadmap is a high-level visual that shows phases, milestones, and direction across months or quarters. The 3 main formats are a timeline (Gantt-style), now-next-later (no fixed dates), and outcome-driven (organized by goals). Use a roadmap to align stakeholders on direction. Use a project plan for the task-level detail. Use a project charter to authorize the work in the first place.
What a project roadmap is for
A project roadmap has a specific job. It shows where the project is going at the level a stakeholder can absorb in 30 seconds. Phases, milestones, owners, top risks. Not tasks, not assignment hours, not full risk matrices. The roadmap survives because it stays high-level and gets re-read; a plan that tries to be both roadmap and plan becomes neither.
Three things follow from that. First, the roadmap is for stakeholders, not for the team executing. The team uses the project plan and the task board. The roadmap is what you show the client, the executive, the board. Second, the roadmap should fit on one screen. If it scrolls beyond a single view, it has slipped into project-plan territory. Third, the roadmap is a living document, not a kickoff artifact. Update it monthly, at sprint boundaries, or when phases shift.
For the authorization side of the project (what the roadmap visualizes), see our project charter guide. For broader category context, see our project management framework.
The 3 types of project roadmap
The "right" roadmap format is not a universal choice. It depends on how firm your dates are, who the audience is, and whether the project organizes around a fixed timeline or a moving target.
| Type | Best when | Format | Stakeholder fit | Example use |
|---|---|---|---|---|
| Timeline (Gantt) | Dates are firm and stakeholders need to see when | Phases as colored bars across months or quarters | Clients, executives, anyone who needs delivery dates | Agency client engagement with contracted milestones |
| Now-Next-Later | Dates flex with discovery and you do not want to commit to specific months | Three columns: in motion, coming next, on the horizon | Internal teams, product orgs, agile shops | Product feature rollout where scope shifts as you learn |
| Outcome-driven | Strategy is the priority and timeline is secondary | Initiatives grouped under measurable goals or KPIs | Leadership, board, stakeholders focused on impact | Multi-quarter strategic initiative tied to revenue or retention targets |
Timeline (Gantt-style) roadmaps are the default for client-facing engagements with contracted dates. Phases as colored bars across months or quarters. Easy to read at a glance. The risk: dates feel committed even when they are estimates. Communicate ranges, not specific days, when uncertainty is real.
Now-Next-Later roadmaps drop fixed dates entirely. Three columns: what is in motion, what is coming next, what is on the horizon. Best for product work, agile teams, and engagements where discovery shapes scope as you go. The honesty about uncertainty is the feature, not a bug.
Outcome-driven roadmaps organize around measurable goals or KPIs instead of dates. Initiatives ladder up to outcomes like "increase trial conversion to 8%" or "reduce churn by 1.5 points." Best for multi-quarter strategic work. The date matters less than the impact.
Most real roadmaps mix elements of these. A timeline at the top for the firm-date phases, a now-next-later band underneath for discovery work, a list of target outcomes at the bottom. Pure types are rare in practice.
What goes in (and what stays out)
The single biggest predictor of a useful roadmap is what you leave off. Most failed roadmaps fail because they tried to be the project plan in visual form. Hold the line on the high-level frame.
| What goes in | What stays out |
|---|---|
| In Major phases or workstreams (Discovery, Build, Launch). 4 to 8 phases for a full project. |
Out Individual tasks. Daily standup items. Anything that fits on a task board. |
| In Milestones (kickoff, beta, public launch, project closure). Dated when known, range-based when not. |
Out Sub-deliverables that ladder up to a milestone. Those live in the project plan. |
| In Phase owners. One named person accountable per phase, even if a team executes. |
Out Resource hours, role assignments, capacity math. Capacity planning is a separate document. |
| In Hard dependencies between phases that gate the timeline. |
Out Soft dependencies, nice-to-haves, second-order risks. Risk register handles those. |
| In Top 2 or 3 risks that could shift dates by weeks. Mitigation owner only. |
Out Full risk matrix with probability and impact scores. That belongs in the project plan. |
| In A current-state marker showing where the team is right now, updated weekly or sprint by sprint. |
Out Real-time status of every task. The roadmap is a calendar of phases, not a kanban board. |
Two patterns to watch. First, if the team starts asking for "where do I see my tasks on the roadmap," the roadmap has slipped into project-plan territory. Move task-level detail to the task board and update the roadmap to phase level. Second, if the roadmap stops moving for a month, it is no longer a working document. Either the project is on autopilot (good news, just leave it) or no one is updating (warning sign, surface in a status review). For team capacity behind the phases, see our capacity planning guide.
Roadmap vs charter vs plan vs timeline
Four documents get confused at the start of projects. The differences are real, and conflating them is how projects end up with one bloated artifact that authorizes nothing, plans poorly, and shows nothing useful to stakeholders.
| Aspect | Project Charter | Project Roadmap | Project Plan | Project Timeline |
|---|---|---|---|---|
| Primary purpose | Authorizes the project | Visualizes phases and direction | Specifies how work gets done | Schedules tasks against dates |
| Audience | Sponsor and approvers | Leadership, clients, broader team | Project team and PM | PM and execution team |
| Granularity | High level (1 to 2 pages) | Mid level (4 to 8 phases over months) | Detailed (every task, owner, dependency) | Detailed (every task with start and end dates) |
| Time horizon | Whole project | Whole project, often by quarter | Whole project, broken to days or weeks | Whole project at task resolution |
| Update cadence | At material scope changes | Monthly or at sprint boundaries | Continuously throughout execution | Continuously throughout execution |
| Signed by | Sponsor (formal authorization) | No formal sign-off | No formal sign-off | No formal sign-off |
| When written | At project initiation, before authorization | After charter, before plan | After roadmap, before execution | After plan, refined during execution |
| Failure mode | Dies in a Word doc; team forgets the original scope | Drifts when not updated; becomes wallpaper | Goes stale within weeks if not maintained | Misleading when a slip cascades and dates do not update |
The sequence matters. The charter authorizes. The roadmap visualizes the direction the charter sets. The plan operationalizes the roadmap. The timeline schedules the plan. In practice: charter signs at initiation, roadmap goes up after the charter is signed, plan gets built once the roadmap shape is clear, timeline emerges from the plan during execution. Skip any one and you create a gap that the team fills with improvisation. For more on the SOW that often runs alongside the charter on client work, see our scope of work guide.
How to build a project roadmap
The 5-step process below works for any of the 3 formats. The difference between a timeline roadmap and a now-next-later roadmap is in how step 3 plays out, not in the steps themselves.
Step 1: Pick the format. Use the picker logic from the table above. Firm dates and external stakeholders point to a timeline. Flex dates and internal teams point to now-next-later. Strategic horizon and KPI focus point to outcome-driven. Mixed signals usually mean a timeline with a now-next band for the uncertain parts.
Step 2: Identify phases. 4 to 8 phases is the right range. Fewer than 4 and the roadmap is too coarse to be useful. More than 8 and it slides into plan territory. Common phases for client work: Discovery, Strategy, Design, Build, Test, Launch, Optimize. Common phases for internal initiatives: Plan, Pilot, Rollout, Measure.
Step 3: Place phases on the format. For timeline, set start and end months for each phase. For now-next-later, drop each phase into the right column. For outcome-driven, assign each phase to its target outcome. Use color to differentiate by workstream or by owner, not arbitrarily.
Step 4: Mark milestones. The 4 to 6 dated points where the team or stakeholders need to align. Kickoff, beta, public launch, project closure. Milestones are the fixed dots; phases are the bars between them. Skip too many and the roadmap becomes noise. Add the right ones and stakeholders track progress without asking weekly.
Step 5: Add a current-state marker. A vertical line, a colored dot, a "today" indicator. The roadmap should show where the team is right now, not just where it is going. Update the marker weekly or at every sprint review. A roadmap without a current-state marker becomes wallpaper within 30 days.
The whole process fits inside an hour for a 6-month project, longer for multi-quarter strategic work. The biggest single-source error: building a beautiful roadmap once and never touching it again. The roadmap is a working document, not a kickoff artifact.
Project roadmap examples
Two worked examples, one timeline and one now-next-later.
Example 1: Agency client engagement (timeline roadmap). A 6-month brand refresh for a software company.
Example 1: Brand refresh for a software company
A timeline roadmap. 6 months, 5 phases, fixed delivery dates.
Phases
This roadmap fits on one screen. The client knows what is happening, when, and who owns each phase. Material changes (a phase slipping by more than 2 weeks) trigger a roadmap update and a status note in the project space.
Example 2: Product launch (now-next-later roadmap). A new feature rollout for an existing product, where exact dates depend on beta feedback.
Example 2: New feature rollout for an existing product
A now-next-later roadmap. No fixed dates. Scope flexes with beta feedback.
The honesty about uncertainty makes the roadmap more useful, not less. Both formats are valid roadmaps. The choice between them is a function of project shape, not personal preference. For agile teams running quarterly planning, see our sprint duration guide.
Project roadmap template
The visual creator at the top of this page is the fastest way to draft a Gantt-style roadmap from scratch. Drag phases to reposition, drag edges to resize, double-click to rename, copy the outline. Five minutes from blank to first draft. Use the visual itself as the artifact you screenshot or paste into a slide deck.
For the project workspace that runs the work (not the Gantt visual itself), pair the roadmap with two Rock templates. The 30-60-90 day plan template structures phases as a board with milestones as cards, owners assigned, and current-state visible to anyone in the project space. The project charter template holds the authorization document the roadmap visualizes.
The honest split: Rock does not render Gantt charts. It runs the project workspace. Use the creator above (or a tool like Office Timeline or Asana for polished Gantt visuals), then run the kickoff, the charter, and the team chat in Rock alongside it.
What we recommend
The right roadmap format depends on your project shape. Most teams default to a timeline because that is what they have seen at past jobs. That is fine when dates are firm and the audience is external. It is the wrong call when discovery genuinely changes scope or when the strategic horizon outranks the calendar.
Pick a timeline roadmap when the project has firm dates and external sign-off. Client engagements with contracts. Hard launch dates tied to events or seasons. Regulated work with compliance windows. The timeline format communicates clearly to stakeholders who need to plan around your dates.
Pick a now-next-later roadmap when dates flex with discovery. Product work where scope shifts on user feedback. Internal initiatives without firm deadlines. Agile teams that prefer not to commit to dates that will need re-litigation later. Honest uncertainty beats false precision.
Pick an outcome-driven roadmap when the strategic horizon is the priority. Multi-quarter initiatives tied to revenue, retention, or market position. Boards and leadership who care about impact more than calendar. The format forces you to keep work tied to outcomes, not the other way around.
The pattern we see at Rock is consistent. Agencies running multiple client engagements run the project workspace in Rock for the charter, kickoff actions, file storage, team and client chat. They produce the Gantt-style visual in a separate tool when stakeholders need a polished timeline image. Rock is not a Gantt tool, and pretending otherwise sets the wrong expectation. The split that works: the workspace lives where the work happens; the visual lives where you screenshot it from.
FAQ
What is the difference between a project roadmap and a project plan?
The roadmap is the high-level visual (phases, milestones, owners). The project plan is the detailed work breakdown (tasks, dependencies, hours, owners). Roadmap is for stakeholders. Plan is for the team. Roadmap fits on a screen. Plan can be 50 pages or a full workspace. Use both, in sequence: roadmap first, then plan.
How long should a project roadmap be?
One screen. If it scrolls beyond a single view, it has slipped into project-plan territory. For a 6-month engagement, that is usually 4 to 8 phases on a 12-month grid. For a multi-year strategic initiative, group by quarter rather than month to keep the whole horizon visible.
Who creates the project roadmap?
The project manager creates it, usually after the charter is signed. The sponsor and key stakeholders review and adjust. For client engagements, the client often joins the review even if they do not author. The roadmap is a shared artifact, not a PM solo project.
How often should you update the roadmap?
Monthly at minimum, weekly if the project is fast-moving. Update at every major milestone, every sprint boundary, or whenever a phase shifts by more than 2 weeks. A roadmap that has not been touched in 6 weeks is wallpaper, not a working document.
What is the best tool for a project roadmap?
For a Gantt-style timeline visual, Asana and Monday include Gantt views, and specialized tools like Office Timeline or PowerSlides export polished slides to PowerPoint. The creator at the top of this page is enough for most teams to draft and screenshot. For the project workspace that runs the work alongside the roadmap (charter, kickoff actions, team chat, files), Rock or Basecamp work well. Note that Rock and Basecamp are not Gantt tools. They hold the workspace; you build the Gantt elsewhere.
Should the roadmap include the budget?
Usually no. The roadmap is about phases and dates, not financials. Budget belongs in the project charter (headline number) and the project plan (line-item math). Adding budget to the roadmap clutters it and pulls focus away from the direction-setting job. Exception: outcome-driven roadmaps where each initiative has an attached cost-of-investment, and the budget is part of the strategic story.
The right roadmap is the one your team and clients actually re-read. Rock runs the project workspace alongside the roadmap (charter, kickoff actions, team chat, files). Flat pricing, unlimited users, clients included. Get started for free.
