How to Build a Product Roadmap in 7 Steps
By Sebastiaan Jansen · · 9 min read
How to build a product roadmap comes down to seven decisions: who it is for, which outcome it serves, what evidence you trust, which work belongs, how you sequence it, how you show time, and how you review it. A roadmap is a sequenced bet on outcomes. A feature list with dates is something else. If a reader cannot see the outcome, the audience, and the next review date, what they are looking at is a backlog with headings.
Work through the steps in order. You can get the first version out of one workshop, but most of the value comes from the review afterwards.
How to build a product roadmap in 7 steps
Most roadmaps turn into a wishlist by week three because someone skipped the audience or the outcome.
1. Name the audience and the decision
A roadmap exists so someone can make a decision. Write that decision down before you add a single item.
| Reader | Decision they need | What to show | What to leave off |
|---|---|---|---|
| Executives | Fund, pause, or redirect a bet | Outcomes, themes, rough horizon | Ticket-level tasks |
| Product and engineering | What to start, and what to refuse | Themes, dependencies, capacity | Dates with no owner |
| Customers or sales | What is committed vs. exploratory | Now, and a short next | Internal experiments |
One page rarely works for all three. A public note and an internal plan can share the same themes and still differ in detail. If sales wants a month you do not have, say "next quarter" or "not scheduled."
2. Set one outcome per theme
An outcome is a change you can observe. "Ship the new billing page" is an output. "Reduce failed renewals" is an outcome. Outputs only belong on the roadmap as the work you believe will move the outcome.
Write each theme in three lines:
- Outcome: the change you want, and how you will know it happened.
- Bet: the work you will try first.
- Non-goal: what you will not do in this horizon, even if someone asks.
Three to seven themes is enough for a quarter. Go past that and nobody can tell what matters. Company goals sit on a strategic roadmap, while the product roadmap stays closer to delivery and points up at those goals.
3. Gather evidence before you rank
Rank with the evidence you already have, and make sure it is specific: support themes with a count of accounts, a sales note that names the deal and the blocker, a drop-off in the current flow, or an engineering constraint that blocks other work.
Put each candidate on one line: the problem, who has it, the evidence, and the smallest slice you could ship. If the evidence cell is empty, the item stays in the parking lot. Creating a roadmap from opinions feels faster, and you pay for it in the next planning meeting, when every item looks equally urgent.
4. Choose the work, and cut
A roadmap that includes everything is a backlog. Filter in this order:
- Does it move an outcome you already named?
- Can a named team start it inside the horizon?
- What do you stop or delay to make room?
If your answer to the third question is "nothing," you have not actually chosen anything. Use last quarter as the ceiling. Count how many items of a similar size this team finished, and plan no more than that.
Requests still come in as problems, and they only become tickets after a person accepts them. A pile of unreviewed notes is not a commitment.
5. Sequence by dependency and learning
Priority alone does not set the order. Some work cannot start until other work exists, and some is only worth doing after a smaller release.
- Now: staffed, defined well enough to start, reviewed on a short cycle.
- Next: shaped but not staffed, with dependencies named.
- Later: a problem you intend to solve, without a solution you are ready to defend.
Dates help when there is a real customer commitment or legal deadline. They hurt when the date is a guess you will miss in public. The now-next-later roadmap covers when to drop dates. Put a date on Now only after the work is sliced, and use a horizon for Next and Later.
Write dependencies as a sentence, such as "Blocked by the billing migration." That is more honest than a bar that starts on a Monday nobody believes in.
6. Pick a format people can read in five minutes
The format follows from the audience you named in step 1.
- Timeline: use it when the dates are real and the dependencies are the story.
- Now, next, later: use it when a false schedule would do more harm than a missing date.
- Themes by outcome: use it when the reader funds bets rather than tickets.
- Columns the team already uses: use them when the roadmap and the board should be the same object.
A product roadmap that people actually open is one of these, kept short, with a link to the tickets under each theme. 10 product roadmap examples puts the shapes side by side. Hand-drawn plans drift away from the work. Jira timelines are common and drift the same way when the roadmap is a second copy; Jira roadmaps explained covers those limits. Falrow draws its roadmap timeline from tickets, so the bars match the board. A spreadsheet works too, as long as one person checks that match every week.
The published view should answer three questions without anyone calling a meeting: What are we doing now? What comes next if Now lands? What did we postpone on purpose?
7. Review on a cadence, and decide the leftovers
Set the cadence at the moment you publish.
- Weekly, inside the team: what moved, what is stuck, and what evidence changed.
- Monthly, with stakeholders: outcomes rather than ticket trivia, plus a check on what is still Now.
- Quarterly: kill, keep, or reframe each theme.
Unfinished work should not roll forward by default. Each item gets a decision to continue, slice smaller, or stop. Silent rollover hides a team that has taken on too much. Cycle schedules in Falrow require that review before leftover work moves, and the roadmap stays counted from the tickets. The same rule works in a spreadsheet. Put the next review date on the page, because readers trust a plan that says when it will be corrected.
A worked example: reducing failed renewals
This example is illustrative. The company and the counts are not a case study. They walk through the seven steps on a single theme.
Audience. The head of product has to pick one growth bet for the quarter. Sales wants a public date. Engineering can staff one pair.
Outcome. Fewer failed renewals than last quarter, counted from failed renewal invoices.
Evidence. Support tagged 40 renewal threads. Fourteen of them failed because the card update errors out after a plan change, and finance confirmed those accounts. Every other idea, annual plans included, has fewer than five accounts behind it.
Cut. Fix the card update after a plan change. The new pricing page stays parked.
Sequence. Now: reproduce the error, ship the fix, and confirm with those accounts. Next: a clearer message when the card network declines. Later: annual plans, but only if failed renewals stay high after the fix.
Format. An internal now-next-later view. Sales gets one sentence: "We are fixing renewal payments this quarter. No date on annual plans."
Review. A two-week cycle. If the fix is not in review by the end of cycle two, the scope drops to the plan-change path only. The item does not slide forward on its own.
A full roadmap is four to seven entries written the same way, and you stop adding when capacity is full. Creating a product roadmap is that card repeated, followed by saying no to an eighth theme.
What stays on the page
| On the roadmap | In the backlog or parking lot |
|---|---|
| Outcome, owner, and horizon | Raw feature requests |
| The current bet and its next slice | Tasks, bugs, and subtasks |
| A real dependency or a real date | A guessed month with no commitment |
| The review date | Every idea from the last offsite |
The roadmap holds the small set of bets. The backlog holds everything else, ordered for the people doing the work. Executives do not need story points on this page, and engineers do not need a vision paragraph where the sequence should be. Link the two layers, and build a product roadmap at the altitude of the decision you named in step 1.
How the plan stays honest
A bad template causes fewer problems than these three failures.
The roadmap and the tickets disagree. Someone updated a slide while the board moved on. You can fix this by generating the view from the tickets, or by checking every week that each Now item has a live ticket. The problem is the second copy nobody maintains. Falrow's ticket-counted roadmap is one way to get rid of that copy. A named owner doing a weekly check is another.
Dates nobody can defend. A date is either a commitment to someone outside the team or a forecast, so label which one it is. A forecast should be a range based on your own throughput, for example: "We finished four items this size last quarter, and this theme is three." A single date with no range reads as a promise.
Nobody owns the no. Write the non-goal on the theme. When the postponed item comes back, point to that line and to the review date. You are saying no until the next review, unless new evidence earns it a place sooner.
Quarter labels need the same honesty. "Q3" is a bucket, not a delivery promise, and the legend should say so. The Scrum Guide makes a related point at the sprint level: a goal is a coherent objective, and unfinished work is inspected rather than assumed to continue. A roadmap theme deserves the same treatment over a longer horizon.
A two-hour workshop
Use this agenda when the team needs to produce the first version together.
- 15 minutes: name the audience and the one decision this page supports.
- 20 minutes: list outcomes, merge duplicates, and stop at seven.
- 30 minutes: for each outcome, write down the evidence and the smallest bet. Park anything without evidence.
- 20 minutes: mark now, next, and later against last quarter's throughput.
- 15 minutes: pick the format and name one owner for the published view.
- 20 minutes: read it as the audience would, and cut any line that needs a speech to explain.
You should leave with a page, a review date, and a parked list. That agenda is the practical answer to how to build a product roadmap: seven decisions, one owner, and a date when you will find out in public what you got wrong.
FAQ
How long does it take to build a product roadmap?
A first version takes about two hours if the evidence is already in your tools. The ongoing work is the review, which means a short weekly check inside the team and a monthly pass with stakeholders. Teams that redraw the roadmap as a quarterly slide spend longer on it and trust it less. The hours that count are the ones you spend cutting.
What is the difference between a roadmap and a backlog?
A roadmap is a small set of outcomes, sequenced for a named audience, with a review date. A backlog is the ordered list of work a team might pull next. The roadmap should link to backlog items without listing every ticket. Ticket detail belongs on the board, and the bet belongs on the roadmap.
Should a product roadmap have dates?
Use a date when an external commitment or a real dependency makes it true, and when the work is sliced enough to staff. Use now, next, and later when the date would be a guess. If you publish a date, also say what would move it. Readers can handle a range, but they stop believing a plan that silently misses its deadlines.
How often should you update a product roadmap?
Update Now items as the work moves, which for most teams means weekly. Reconfirm themes with stakeholders every month. Reset the theme list each quarter, or sooner if the evidence changes. Moving every unfinished item into the next period without a decision does not count as an update. Each rollover should say continue, slice, or stop.