Skip to content
Product Lifecycle Templates

Product Roadmap

beta  ·  Family strategy-docs  ·  Phase undefined  ·  Sizes lean, full  ·  Formats now-next-later, go, themes  ·  ~2,550 tokens

The document that says in what order this product intends to solve the problems its strategy chose, and how certain it is at each horizon. It is judged by whether the uncertainty in it is visible: a roadmap that looks equally confident about next month and next year is claiming knowledge nobody has.

How to pick a format and a size, how to tell whether the draft is any good, and when to stop.

Before you start: is this the right document at all?

Section titled “Before you start: is this the right document at all?”

Write a roadmap when people outside the team need to know what is coming and in what order, and when the honest answer varies by how far out you look. Do not write one because a planning cycle asked for one.

Write something else if:

You actually need Because
a product strategy you are still arguing about which problems are worth solving. The roadmap orders choices; it does not make them
a product backlog you need the specific work items. The roadmap scopes the backlog, it is not a higher-resolution version of it
a release plan you are planning one release in detail. That is a project plan, by the account of the person who named both artifacts
OKRs you need the measurable commitment for this period. “The roadmap shows the plan. The OKRs carry the commitment”
a Plan of Record you have a genuine date commitment. Track it separately and deliberately, so it stays scarce

Write nothing at all if nobody outside the team reads it and the team already knows what it is doing. A roadmap maintained for an audience that does not exist is a recurring cost with no reader.

Two warnings worth taking seriously. First, no study links any roadmap format, cadence or confidence device to product or business outcomes. What exists is a strong convergence of practitioner prescription, which is worth following and is not proof. Second, the word “roadmap” appears nowhere in the Scrum Guide. Whatever process you run, having one is a choice you are making, not a requirement you are meeting.

Picking a format and a size

Section titled “Picking a format and a size”

Format is the organising principle, and it is a real choice:

  • now-next-later (product-roadmap_template-lean.md, product-roadmap_template-full.md) sorts by confidence. Use it when the honest answer to “when” is “it depends”. This is the default, and the only one showable to a customer without implying a schedule.
  • go (product-roadmap_template-go-full.md) sorts by release, with a measurable goal per release. Use it when releases are real events in your world and each needs to answer what it was for.
  • themes (product-roadmap_template-themes-full.md) carries vision and objectives inside the document. Use it when the roadmap has to travel and argue for itself.

If nobody can name your next release, you do not want the GO format. If the reader already knows the strategy, you do not need the themes format.

Size is how much context the reader lacks: lean for a team that shares it, full for anyone outside the room.

The one test that outranks the rest

Section titled “The one test that outranks the rest”

Could a reader build a Gantt chart from this? Then it stopped being a roadmap. A project plan details how work gets done; a roadmap communicates why it is worth doing.

The second test is about honesty rather than form: does this document look equally certain about next month and next year? If so, it is claiming knowledge nobody has.

The rubric

Section titled “The rubric”

Score each 0, 1 or 2. Under 12 out of 18, and a now-next-later full roadmap will be read as a commitment you did not make. The other variants score against fewer rows; see the scope table below. That is the failure that costs trust, and it is not recoverable by explaining afterwards that it was only ever indicative.

# Criterion 0 1 2
1 Serves a stated outcome No parent named Names a goal, but no item ladders to it Names the parent document, and you can say which item serves which outcome
2 Problems, not features Named features throughout A mix, with features dominant Someone could solve an item a completely different way and the entry would still be satisfied
3 Confidence decays Equal precision at every horizon Later items vaguer, but not deliberately The furthest items are visibly coarser, and the document says so in words
4 Exclusions with a cost Nothing excluded Excludes things nobody asked for Excludes a named request someone wanted, with a reason, and they have been told
5 Not a Gantt chart Bars, dependencies, dated features Some dated deliverables leak in No delivery commitment could be lifted from it, or the ones that exist are marked as commitments
6 Not a backlog Assembled from accumulated requests Mostly top-down, some drift Every item traces to the outcome above, and you can name something in the backlog that is deliberately absent here
7 Dependencies named (full, now-next-later only) None Categories listed (“engineering capacity”) Named dependencies, each with the reordering it would trigger
8 Owned and triggered (full, now-next-later only) No review, no owner “Reviewed quarterly” An event that triggers review, a backstop date, and a named person
9 Audience-honest (full) Same document for everyone Vaguely aware it may be shared States who reads it, and if external, has been stripped and coarsened deliberately

Which rows apply to what. Every threshold is two thirds of the available points, rounded down.

Document Rows Maximum Score against
now-next-later, full all 9 18 12
now-next-later, lean 1-6 12 8
go, full 1-6 and 9 (row 5 judged on whether dates are marked as commitments, not on their presence) 14 9
themes, full 1-6 and 9 14 9

Rows 7 and 8 are scored only against now-next-later. Neither the GO format nor the themes format ships a Dependencies section or a Review Trigger section, so grading either on those rows would penalise the choice of format rather than the quality of the document. Row 9 does apply to all three, because every format’s frontmatter carries an audience field.

Format-specific checks

Section titled “Format-specific checks”

now-next-later. Read only the Later lane. Does it read like a plan? If someone could build a budget from it, the lanes have collapsed and you have a timeline roadmap in three columns.

go. Read the goal and metric columns alone, ignoring features. Could a stranger decide, three months after each release, whether it worked? If not, the metrics are decoration and the features are doing the work, which is backwards.

themes. Read the objectives and themes alone. Does every theme serve a stated objective, and is there an objective no theme serves? Both mismatches matter, and the second is the one authors miss.

Failure signals to look for in the draft

Section titled “Failure signals to look for in the draft”
  • The feature list. Named features pinned to dates.
  • The Gantt in disguise. It started as themes and drifted into bars.
  • Lane collapse. Stakeholders quote your Next lane back as a commitment.
  • The backlog reformatted. Assembled from what accumulated rather than from the outcome.
  • False precision. Q1, Q2, Q3, Q4, all equally confident.
  • Later as a graveyard. Requests you did not want to refuse, parked where they will quietly rot.
  • The sales leak. An internal roadmap that will end up in a prospect’s inbox, because internal roadmaps do.
  • Nothing excluded. Which means it cannot be used to say no to anything.

When it is good enough

Section titled “When it is good enough”

When someone can use it to refuse a request, when the person whose request it refuses has been told, and when a reader can tell from the document alone which parts they may plan around. A roadmap that has never been cited in a decision is not finished, however tidy it looks.

Then delete every HTML comment, put the review trigger in a calendar with a name attached, and decide deliberately whether anyone outside the company should see it.

The artifacts

Section titled “The artifacts”

product-roadmap_template-lean.md · ~2,550 tokens

---
title: "{{product_name}} Product Roadmap"
product: "{{product_name}}"
owner: "{{who_owns_this_roadmap}}"
horizon: "{{period_this_covers}}"
audience: "{{internal_or_customer_facing}}"
status: "{{draft_or_agreed}}"
last_updated: "{{date}}"
doc_type: product-roadmap
size: lean
format: now-next-later
source_template: product-roadmap
source_template_version: 0.1.0
---


<!--
LEAN PRODUCT ROADMAP (now-next-later format). Three confidence lanes and the two things that stop them being
a wish list: the outcome they serve, and what is deliberately not on here. To grow it into a roadmap that has
to survive people who were not in the room (see product-roadmap_template-full.md), ADD sections; never rename
or reorder the ones below, because the full variant is a strict superset of this one.


WHAT NOW / NEXT / LATER ACTUALLY MEANS. The lanes are levels of CONFIDENCE, not dates in disguise. Now is
work in progress, shaped and understood. Next is being sharpened and is expected to change. Later is a
problem area nobody has shaped yet. Its creators are explicit that the point is varying certainty: "No one is
100% sure all the time." If your Later lane reads like a dated plan, you have rebuilt the thing this format
exists to replace.


THE ONE SENTENCE TO REACH FOR WHEN THIS IS MISTAKEN FOR A COMMITMENT, from the same source: "The roadmap shows
the plan. The OKRs carry the commitment." When someone asks this roadmap for a delivery guarantee, they are
asking the wrong artifact.


THE TEST THIS DOCUMENT HAS TO PASS. Could a reader build a Gantt chart from it? Then it stopped being a
roadmap. The distinction that survives even when a roadmap carries dates is that a project plan details how
work gets done, while a roadmap communicates why it is worth doing.


WHAT THE EVIDENCE ACTUALLY SAYS, SO YOU ARE NOT MISLED. No study links any roadmap format, cadence or
confidence device to product or business outcomes. What exists is a strong convergence of PRESCRIPTION: three
named practitioners, arguing independently, all arrive at "express less certainty, further out". That is
worth following and it is not proof. See product-roadmap_companion.md section 1.


A NOTE ON WHOSE PROCESS THIS IS. The word "roadmap" does not appear anywhere in the Scrum Guide. Whatever
framework you run, this artifact sits outside it and you are choosing to have one.


THIS IS ONE OF THREE FORMATS, AND THE CHOICE IS REAL.
- This one sorts by confidence. Reach for it when the honest answer to "when" is "it depends".
- product-roadmap_template-go-full.md is a goal-and-metric grid tied to named releases. Reach for it when
  releases are real and each one needs a measurable goal.
- product-roadmap_template-themes-full.md carries vision and business objectives alongside the themes.
  Reach for it when the roadmap has to argue for itself, not just list.
See product-roadmap_companion.md section 4.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   product-roadmap_companion.md), guiding questions to ASK, a GOOD and a WEAK example, and the TRAP to
   avoid.
2. Replace each {{placeholder}} with your content.
3. Fill "The Outcome This Serves" FIRST. A roadmap whose items do not ladder to a stated outcome is a
   backlog someone reformatted.
4. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
5. Before you share it: self-grade against product-roadmap_guide.md, then DELETE every HTML comment. They
   are guidance, not content.
-->


# {{product_name}} Product Roadmap


## The Outcome This Serves


<!-- WHAT  The measurable change this roadmap exists to produce, and the strategy or goal it descends from.
           Two or three sentences. Name the document above this one.
     WHY   This is what makes the lanes below judgeable. Without it a reader cannot tell whether an item
           belongs, and the roadmap drifts into a list of whatever accumulated. The failure has a name and a
           mechanism: when work is assembled bottom-up, "the intent behind the work has been quietly
           replaced by the gravity of the backlog itself." Deep dive: product-roadmap_companion.md section 3
           (The Outcome This Serves).
     ASK   What does the strategy above this say we are trying to change? How would we know this roadmap
           worked? If someone proposed an item that served no outcome, what would we point at to refuse it?
     GOOD  "Serves the FY26 goal of cutting emergency-job response time by a third. The dispatch strategy
           diagnosed the obstacle as urgency living in free-text notes, so everything below is aimed at
           getting priority out of prose and into the schedule."
           (names the parent, the measure, and the diagnosed obstacle)
     WEAK  "Improve the dispatch experience and deliver customer value."
           (nothing here could exclude any item)
     TRAP  Naming a goal nobody above you agreed to. If the strategy document does not say this, you are
           writing strategy in a roadmap, which is how a roadmap ends up being negotiated by people who
           never read it. -->


{{the_outcome_this_serves}}


## Now


<!-- WHAT  Work actually in progress, shaped and understood. Three to six items. Say what problem each one
           solves, not which feature ships.
     WHY   Now is the only lane where certainty is high enough to be worth stating, and even here the
           honest framing is a problem being solved rather than a feature being delivered. Themes exist for
           exactly this: "Instead of promising to build a specific feature, the team commits to solving a
           specific customer problem." Deep dive: product-roadmap_companion.md section 3 (Now).
     ASK   Is someone working on this today? Do we know what "done" looks like well enough to recognise it?
           Is this a problem or a solution, and if it is a solution, do we know it is the right one?
     GOOD  "Urgency inference at intake. Dispatchers should not have to read notes to find the emergency.
           In progress, first cohort of 20 accounts."
           (a problem, its current state, and a scope)
     WEAK  "Ship v2.4 of the scheduler." (a release, not a problem, and nobody outside the team can judge it)
     TRAP  Putting everything here because it all feels urgent. If Now has twelve items, it is a backlog. -->


{{now}}


## Next


<!-- WHAT  Problems being sharpened, expected to change. Two to five. Less detail than Now, deliberately.
     WHY   Next is the lane where dishonesty creeps in, because it is close enough that people
           want dates and far enough that estimates do not hold. The whole reason to sort by confidence is
           that "the further away something is, the more uncertain it is. Your roadmap should reflect
           that." Deep dive: product-roadmap_companion.md section 3 (Next).
     ASK   What would we have to learn before this could move to Now? Is this shaped, or just agreed to be
           important? Would we bet a quarter's capacity on it today?
     GOOD  "Override transparency. Dispatchers who disagree with an inferred priority currently have no way
           to say why, so we cannot learn from the disagreement. Shape after the first cohort reports."
           (says what has to happen before it becomes Now)
     WEAK  "Q3: Reporting improvements." (a date and a category, which is a timeline roadmap wearing a
           three-lane costume)
     TRAP  Letting Next become a promise. If a stakeholder can quote this lane back to you as a
           commitment, the lanes have collapsed and the format has stopped working. -->


{{next}}


## Later


<!-- WHAT  Problem areas nobody has shaped yet. Two to five, deliberately coarse. One line each.
     WHY   Later exists to show direction without implying a plan, and it is the lane readers are quickest to
           delete for being too vague. That vagueness is the honest content: a roadmap that
           looks equally certain at every horizon is claiming knowledge it does not have. Deep dive:
           product-roadmap_companion.md section 3 (Later).
     ASK   Is this a direction or a decision? Would we be embarrassed if this never happened? Is it here
           because we believe in it, or because someone senior mentioned it?
     GOOD  "Multi-day scheduling for planned maintenance work. We do not know whether this is the same
           product or a different one."
           (a direction with the open question stated)
     WEAK  "AI-powered predictive dispatch platform (Q4 2027)." (a date on a thing nobody has shaped is
           the exact false precision this lane exists to avoid)
     TRAP  Using Later as a graveyard for requests you do not want to refuse. Say no in the section below
           instead; a Later item nobody intends to do is a lie with a longer fuse. -->


{{later}}


## What Is Not On Here


<!-- WHAT  Things asked for, considered, and deliberately excluded this horizon, with one line each on why.
           Two to five. Name real requests.
     WHY   This is the section that makes the lanes usable, and the one easiest to leave out. A roadmap
           without exclusions cannot be used to refuse anything, which means it settles no arguments and
           changes no behaviour. It is also what stops Later becoming a graveyard. Deep dive:
           product-roadmap_companion.md section 3 (What Is Not On Here) and section 7.
     ASK   What has been asked for repeatedly that we are not doing? Who will be unhappy, and have they
           been told? Is anything in Later actually a refusal we have not made yet?
     GOOD  "Customer-facing arrival windows. The most requested item we have, and it depends on scheduling
           accuracy we do not yet have. Revisit when the override rate is under 20 percent. Sales knows."
           (a real request, a reason, a condition for revisiting, and who was told)
     WEAK  "We are not doing anything that does not align with our strategy." (refuses nothing specific)
     TRAP  Listing only things nobody wanted. If every exclusion is uncontroversial, the hard refusals are
           still hiding in Later. -->


{{what_is_not_on_here}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 17 sections across 3 format(s), methodology methodology-agnostic, typically owned by Product Manager.