Product roadmap examples: types and how to build one
Product roadmap examples for 4 types (timeline, now-next-later, outcome-based, theme-based), a hypothetical table and the steps to build one.
A product roadmap is a shared plan that shows the vision, direction, priorities and progress of a product over time. Atlassian defines it as a source of truth that explains why work is planned as well as what. The four common types are timeline, now-next-later, outcome-based and theme-based, and they differ mainly in how much they promise about dates.
What is a product roadmap?
A product roadmap is a high-level plan that links short-term work to long-term goals. Atlassian says items on it should be tied to product strategy and goals, and that it should respond to customer feedback and the competitive picture. It is a different document from the delivery plan: Atlassian advises development teams to keep a separate delivery plan that maps back to the roadmap, with committed ideas broken into epics, requirements and user stories.
Product managers usually own the roadmap and build it with engineering, design, marketing and other stakeholders. The Scrum Guide gives the same idea a narrower name, the Product Goal: a future state of the product that the team plans against, which the team fulfils or abandons before taking on the next.
What are the main types of product roadmap?
Roadmap types differ in what they are organised around: dates, time horizons, results or problem areas. The table summarises the four common types plus the goal-oriented format from Roman Pichler. ProdPad, which sells roadmap software and favours now-next-later, supplies several of the definitions, so its judgements are attributed to it.
| Type | Organised around | How it treats dates | Main risk |
|---|---|---|---|
| Timeline | Planned work plotted against calendar dates, usually as bars | Fixed dates | Dates are read as commitments before solutions are validated |
| Now-next-later | Three horizons: being built, likely next, still unsettled | No dates | Horizons with no shared definition become a vague timeline |
| Outcome-based | Problems to solve and the measurable result expected | No feature-date pairs | Outcomes written too loosely to measure |
| Theme-based | Problem areas or themes that group several initiatives | Often none | Themes so broad that everything fits |
| Goal-oriented (GO) | A goal per period, with features and metrics beneath it | A date or quarter per goal | Too many features listed under each goal |
ProdPad defines a timeline roadmap as planned work plotted against calendar dates, and says it answers scheduling questions well and strategic questions poorly because it commits to solutions and dates before either has been validated. It also notes that the swimlanes and dependency markers in a timeline carry real information, for example when two teams will touch the same system in the same window.
What is a now-next-later roadmap?
A now-next-later roadmap organises initiatives into three horizons instead of fixed delivery dates. Janna Bastow of ProdPad, who says she invented the format, describes Now as clearly defined work being built, Next as items broken down less finely, and Later as hazy problems the team is not ready to commit to.
Her advice is to write down what each horizon means for the team: what has to be true for something to sit in Now, what earns a place in Next and what keeps an item parked in Later. She also says the commitment lives in objectives and key results, and the roadmap shows the plan. The format suits teams that learn as they build, and a manager who needs a firm launch date for a partner will still need a separate dated plan.
What does a product roadmap example look like?
The example below is hypothetical: a product team in Pune running a food-ordering app writes an outcome-based roadmap in now-next-later form. Each row names a problem and the measure that would show it is solved, and no row names a release date.
| Horizon | Problem to solve | How success is measured | Confidence |
|---|---|---|---|
| Now | Repeat customers retype the same order every week | Share of repeat orders placed through a reorder button | Scoped and in build |
| Next | Checkout asks for the address on every order | Fewer abandoned checkouts at the address step | Needs customer interviews |
| Later | Payments on a recurring order fail or are forgotten | Fewer failed payments and late reorders | Problem not yet sized |
The confidence column is the part many roadmaps leave out. It tells a reader that Now is a plan, Next is an intention and Later is a direction, which is the difference ProdPad's format is built to show. The same list could be redrawn as a timeline by adding bars, and the information lost would be exactly that column.
How do you build a product roadmap step by step?
Start from the goal and work outward to the work, since a roadmap built from a list of requests becomes a feature list.
- Write the product goal or strategy in one or two sentences, including the user and business results it should produce.
- Collect inputs: customer feedback, discovery findings, company goals, market changes and effort constraints. Atlassian lists these as the criteria for evaluating ideas.
- Prioritise the opportunities with an agreed method. The prioritisation frameworks guide compares RICE, MoSCoW, Kano and ICE.
- Choose the format for the audience: horizons or outcomes for the product team, quarters for executives, benefit-led views for customers.
- Attach a measure to each goal or problem, so the roadmap states how the team will know it worked.
- Share it, collect questions, and set a review rhythm.
Teresa Torres of Product Talk says a date-based roadmap holds solutions that have already been matched to opportunities and vetted by assumption tests, while an outcome-oriented roadmap may include opportunities and outcomes still to be explored. The opportunities themselves come from discovery work such as customer interviews and assumption tests.
Who should see the roadmap, and in what form?
Atlassian describes four audiences. Development teams need the link between strategy, goals and priorities, and executives need the work tied to company goals, organised by month or quarter with less detail. Sales teams need features and customer benefits, and Atlassian advises avoiding hard dates there. Customers see an external roadmap with a high-level view of prioritised problem areas.
The practical rule is one source of truth with several views, not several roadmaps that drift apart. Atlassian also warns that too much or too little detail makes a roadmap easy to ignore.
What mistakes turn a roadmap into a feature promise list?
Roman Pichler describes the common pattern: too many features, features that are too fine-grained, a roadmap that overlaps and competes with the product backlog, and features that are read as a commitment instead of part of a high-level plan likely to change. His GO roadmap limits each goal to three features and never more than five.
Other mistakes follow from the same cause. Dates appear on items that have not been scoped, goals have no metric, and one roadmap is sent to every audience unchanged. The roadmap also goes out of date, which Atlassian calls counter-productive, and stakeholders start asking for updates instead of reading it.
Marty Cagan of Silicon Valley Product Group states the underlying point: strong teams focus on solving problems, and in his words the work is about delivering results, not about features or a roadmap.
When does a timeline roadmap still make sense?
A timeline roadmap still makes sense where a date is real. Pichler gives the example of a game that has to be ready for the Christmas sales, where meeting the deadline is part of the value, and he keeps a date or time frame row in his goal-oriented template for that reason. Atlassian's executive view is organised by month or quarter, and ProdPad itself accepts a timeline for release planning and immediate work while advising against one for the long-term roadmap.
The trade-off runs the other way for now-next-later. It gives stakeholders less certainty, and ProdPad notes that the hard part is persuading leaders to trade dates for horizons. A team without objectives and key results, or something equivalent, may find that dropping dates also drops accountability.
No single format is correct; the choice depends on the audience and on how much of the plan is known. For a wider list of planning and prioritisation tools, see the top product management tools and frameworks guide.
Where does roadmapping fit in a product management programme?
Product Management with AI is an online certification from BITS School of Management (BITSoM), offered in partnership with Masai, taught in live online classes with an optional campus workshop. It covers product discovery, design and MVPs, building with agentic AI, Agile execution, go-to-market and product metrics, and its topics include roadmaps and backlog management, Jira and stakeholder alignment.
Frequently asked questions
What is a product roadmap?
A product roadmap is a shared plan that outlines the vision, direction, priorities and progress of a product over time. Atlassian describes it as a source of truth that aligns an organisation around short and long-term goals and shows why work is planned, with items linked to strategy.
What is a now-next-later roadmap?
A now-next-later roadmap has three columns, Now, Next and Later, instead of delivery dates. Now holds work being built, Next holds work expected afterwards, and Later holds problems not yet ready for commitment. ProdPad's Janna Bastow describes it as a way to communicate priorities without false certainty.
How often should a roadmap be updated?
Atlassian says as often as necessary, which could be every week or fortnightly, and calls an out-of-date roadmap counter-productive. Stakeholders asking for updates instead of reading the roadmap is a sign it has gone stale, while spending more time updating it than executing is a sign the cadence is too frequent.
What is the difference between a roadmap and a backlog?
A roadmap shows direction and priorities at a high level, while a backlog is the ordered list of work the team will do. The Scrum Guide calls the Product Backlog an emergent, ordered list of what is needed to improve the product. Pichler warns against letting a roadmap compete with the backlog.
What is an outcome-based roadmap?
An outcome-based roadmap is organised around problems and measurable results instead of a list of features. ProdPad defines each item as a problem to solve plus the result expected, such as a higher activation rate. The team then chooses the solution, and can change it, while the outcome stays fixed.
Next step
A roadmap is only as good as the priorities and discovery behind it. To practise building and presenting one on real product cases, see the Product Management with AI programme page, and read the guide to product manager interview questions for how roadmap questions are asked.