On this page
Most roadmap work is deciding what to leave off. A roadmap that lists every feature anyone has asked for is a wish list. A useful one shows the few bets the team will make next, why, and how you will know they worked. This guide shows how to build a product roadmap: what it is, the formats that suit startups, a seven-step method and how to prioritize. It also gives you a product roadmap template to copy, examples for three stages and ways to keep the plan honest as it changes.
What is a product roadmap?
A product roadmap is a shared plan that shows the problems a team will work on, in what order, and the outcomes it expects. It covers months, not weeks. It sits between strategy and delivery. Strategy says who the product serves and how it will win. The roadmap turns that into a sequence of bets. The backlog and sprint plans then break the nearest bets into tasks. The UK government's service manual makes the same split. Its guidance on developing a roadmap says roadmaps are not the same as backlogs, which teams use to manage the delivery of features and tasks. A good product roadmap is readable by investors, sales and engineers alike, and every item on it traces back to a goal. If an item cannot, it does not belong there yet.
A roadmap is only as good as the strategy behind it. If the team cannot agree on the customer and the goal, no format will fix that. It is a job for product strategy and consulting, not a prettier chart.
Roadmap formats and when each fits
Most product roadmap examples you will see use one of four formats. Pick the one that matches how certain your plans are.
| Format | What it shows | Fits | Risk |
|---|---|---|---|
| Now, next, later | Three columns of problems ordered by urgency, with no dates | Early teams whose plans change every month | Reads as vague to investors unless each item names its goal |
| Outcome roadmap | Goals and the measures that show progress, with bets under each | Teams with a clear strategy and data they can track | Hard to start without baseline numbers |
| Timeline roadmap | Items placed on months or quarters | Fixed dates such as a launch, a contract or a compliance deadline | Every date looks like a promise, even the guesses |
| Theme roadmap | Broad areas of investment, such as onboarding or reliability | Sharing direction across a wider company | Themes too broad to guide what the team builds this month |
Many teams blend them: now, next, later for the product team, with dates only on the items tied to a real external deadline.
How to build a product roadmap in seven steps
This is how to create a product roadmap from a blank page. Each step produces something you can show.
- Write the goal. Start with a one-line vision and a few objectives for the next year, each with measures you can track. The UK service manual's planning guidance suggests three to five main objectives with three or four measurable results each, which is a sensible size for a startup too.
- Gather the evidence. Pull together customer interviews, usage data, sales notes, support tickets and the engineering team's list of risks. If the evidence is thin, run discovery first; our list of product discovery questions is a good place to begin.
- Frame problems, not features. Write each candidate item as a customer problem with the outcome you expect. "Admins cannot see who changed a setting" leaves room for better answers than "build an audit log page".
- Size and score. Estimate the effort with engineering and score each item against your goals. The next section covers a simple scoring method.
- Sequence by dependency and risk. Put the riskiest assumptions early, while they are cheap to test, and respect technical dependencies so later work does not stall.
- Choose the format and horizon. Show the next few months in detail and later work at a high level.
- Share it and set a review rhythm. Walk the team, investors and customer-facing staff through it, and book the next review before the meeting ends.
How to prioritize what goes on the roadmap
Scoring does not make the decision for you, but it makes the argument visible. RICE, a method Sean McBride described on the Intercom blog in 2018, scores each item on four factors:
- Reach: how many customers or events the item affects in a set period, such as a quarter.
- Impact: how much it moves the goal for each of them, on a scale of 3 (massive), 2 (high), 1 (medium), 0.5 (low) and 0.25 (minimal).
- Confidence: how sure you are of the estimates, at 100% for high, 80% for medium and 50% for low.
- Effort: the work required, in person-months.
The score is reach times impact times confidence, divided by effort. Use it to compare items, not as a verdict. Some work skips the queue: a security fix, a runtime reaching end of life, a contract commitment or a legal deadline. Mark those as commitments so they do not compete on a score they will never win.
A product roadmap template you can copy
A product roadmap template only needs a few columns, and a spreadsheet is enough. The same service manual recommends keeping the roadmap online in a spreadsheet or other software. Tools such as GitHub's roadmap layout can show the same items on a timeline by month, quarter or year. These are the columns we use, filled in with a hypothetical example:
| Horizon | Goal | Problem to solve | Evidence | Measure of success | Owner | Confidence |
|---|---|---|---|---|---|---|
| Now | Raise trial-to-paid conversion | New admins stall before inviting their team | Trial interviews and onboarding funnel data | More trials with a second active user in week one | Product lead | High |
| Next | Reduce cancellations in small accounts | Small teams cannot export their reports | Support tickets and cancellation survey answers | Fewer cancellations that cite reporting | Product and engineering leads | Medium |
| Later | Open a second segment | Agencies want to manage several clients in one account | Inbound requests from agencies | Pilot agencies pay for multi-client access | Founder | Low |
The confidence column is the one many templates leave out, and it does the most work. It tells readers which items are commitments and which are bets, so a later change does not look like a broken promise.
Product roadmap examples for three startup stages
The right roadmap changes with the stage of the company. These examples are hypothetical, written to show the shape rather than any real company.
Pre-seed: a search roadmap
A two-founder team with a prototype and a handful of early users does not need dates. Its product development roadmap is a now, next, later list of questions. Which segment gets value fastest? Which single workflow will they pay for? What stops them using it every week? Every item is a test, and the roadmap's job is finding product-market fit before the money runs out.
Seed: an outcome roadmap
A team with paying customers and a small engineering group sets two or three outcomes for the next two quarters. Examples are faster onboarding and fewer cancellations in small accounts. Under each outcome sit the bets the team will try, in order, with the next quarter in detail and the one after in outline.
Series A: themes with dated commitments
A company with several teams and larger customers needs themes for the wider company and an outcome roadmap per team. It also keeps a short list of dated commitments, such as a single sign-on release a customer has contracted for. The product roadmap is now a coordination tool, so ownership and review rhythm matter as much as content.
The agile product roadmap
An agile product roadmap is built to change. The Manifesto for Agile Software Development values responding to change over following a plan, and that applies to roadmaps as much as to code. In practice, an agile roadmap shows goals and problems rather than fixed feature lists. It keeps dates only where a real deadline exists, and the team reviews it on a regular rhythm as each release teaches them something.
Scrum, a common agile framework, does not define a roadmap at all. The 2020 Scrum Guide describes a Product Goal: a future state of the product that the team plans toward. It also describes a Product Backlog, an ordered list of the work needed to improve the product, delivered in Sprints of one month or less. A roadmap sits above both: it lays out the sequence of Product Goals, while the backlog holds the detail for the current one.
Keep the roadmap honest as plans change
A roadmap loses trust when it changes quietly. It keeps trust when changes are visible and explained. These habits help:
- Review on a fixed rhythm. Monthly for an early team, quarterly for a wider company, and after any major lesson. The UK service manual says roadmaps are developed iteratively, and that the Government Digital Service revisits its own at least once a quarter.
- Plan near work in detail and far work loosely. The same guidance notes that the further ahead an item sits, the more uncertain it is.
- Keep a change log. One line per change: what moved, why, and what evidence caused it.
- Say what you dropped. Removing an item is a decision worth announcing, especially to the customer or salesperson who asked for it.
- Separate commitments from bets. Use the confidence column, and never put a date on a guess.
The rhythm only holds if someone owns it. In many startups that is a founder with too many other jobs, and the roadmap drifts. Some teams hire SaaS product managers part time to run this cadence, while others give one founder protected time for it each week.
Frequently asked questions
What is a product roadmap?
A product roadmap is a shared plan showing the problems a team will tackle, in what order, and the outcomes it expects over the coming months. It connects strategy to delivery: strategy sets the goal, the roadmap sequences the bets, and the backlog breaks the nearest bets into tasks. It should change as the team learns.
What should a product roadmap template include?
A useful template includes a time horizon (now, next or later), the goal each item serves and the customer problem. Add the evidence behind it, a measure of success, an owner and a confidence level. Confidence matters most, because it shows readers which items are firm commitments and which are bets that may change.
What is an agile product roadmap?
An agile product roadmap is a plan built to change as the team learns. It shows goals and problems rather than a fixed list of features, keeps dates only for real deadlines, and is reviewed on a regular rhythm. In Scrum terms, it sequences Product Goals, while the Product Backlog holds the detailed work for the current one.
How far ahead should a startup roadmap plan?
Plan the next few months in detail and up to about a year at a high level. Early-stage teams often keep only now, next and later columns, because their plans change monthly. Later-stage teams can plan further ahead, but the further away an item sits, the less certain it is, so keep distant items loose.
What is the difference between a roadmap and a release plan?
A roadmap shows which problems the team will work on and why, over months. A release plan shows what will ship, when, and in which version, over weeks. The roadmap guides priorities and is shared widely, while the release plan coordinates the delivery, testing and launch of work that has already been chosen.
Sources and update history
- GOV.UK Service Manual: Planning in agile
- GOV.UK Service Manual: Developing a roadmap
- The 2020 Scrum Guide
- Manifesto for Agile Software Development
- Intercom blog: RICE, simple prioritization for product managers (Sean McBride, 2018)
- GitHub Docs: Customizing the roadmap layout
Update history
- First published.
