Product roadmap: how to write one (with an example)

What is a product roadmap?

A product roadmap describes the vision, direction, priorities and planned progress of a product over time. It is an action plan that connects the organisation’s goals to the teams' work.

It shows what you are going to do, but above all why. Every item must tie back to a goal or to a hypothesis to validate. Without that link, the roadmap becomes a list of requests, and prioritisation comes down to whoever shouts loudest.

It is not set in stone. It evolves with what you learn: an invalidated hypothesis, a shifting market, a pivot. A roadmap that never changes is either perfect or ignored. In my experience, it is rarely the former.

Roadmap, backlog, release plan

These three documents are often confused. They differ in level and in audience.

Who is it for?

Maintaining four different roadmaps is not realistic: they would never stay consistent. But one roadmap can be presented from several angles.

The development team

Focused on goals and context: expected value, milestones, definition of done. It prepares the sprints without replacing them.

Senior management

Focused on strategic goals and their progress, often by quarter, with little technical detail. Involve management early: their trade-offs belong in the roadmap, not discovered in a steering committee.

Sales teams

Focused on what helps sell: stability, compatibility, answers to objections. Avoid precise dates: a dated commitment reduces agility and is rarely worth much to the customer.

Customers

An external view, simple and readable, of the main directions. It is a marketing tool: build it with marketing, and put nothing in it you are not prepared to deliver.

How to create a product roadmap, in six steps

1. Go back to the fundamentals. What is the goal? Have you found your market fit? If not, the roadmap exists to find it. If so, it exists to move specific metrics.
2. List the hypotheses to validate and rank them by risk. That is the hypothesis roadmap, the DNA of the product roadmap.
3. Translate each hypothesis into initiatives: what needs to be built, tested or measured to validate it.
4. Choose a suitable time axis: now, next, later, or by quarter.
5. Check it against the teams' real capacity, with them. An unrealistic roadmap demotivates more than it guides.
6. Share, gather objections, adjust. Then publish it in the tool the team already works in.

The right level of detail is the one your audience understands without explanation. Too detailed, and nobody reads it. Too vague, and nobody can use it.

Prioritising without false precision

At step 3, you will have more initiatives than capacity. Frameworks such as RICE (reach, impact, confidence, effort) help structure the discussion. Use them to compare, not to calculate: a score of 7.4 against 7.1 settles nothing, it hides fragile estimates.

Three simple questions are often enough:

1. Which goal does this initiative move, and by how much, based on what we actually know?
2. Which risk does it reduce: a critical hypothesis, a dependency, an obligation?
3. What happens if we don’t do it this quarter?

The third question is the most useful. Many initiatives deemed urgent have no consequence at all if they wait three months.

A product roadmap example

A fictional example: work-order management software for residential property managers, which has found its first customers and wants to reduce churn.

Note the “Why” column: it matters more than the “Initiative” column. And note that automatic qualification is framed as a hypothesis to measure, not as an AI feature to ship.

Three months later

Let’s continue the example. During the quarter, the team measures the time actually spent triaging requests at five customers. It is much lower than expected: the real time sink is chasing contractors. The roadmap changes accordingly:

• Automatic qualification moves down to “Later”, with the measurement that invalidated it noted in a comment.
• A new initiative appears under “Next”: automatic reminders to contractors, with the time to close a work order as its metric.
• The tracking redesign has shipped; it stays visible until 90-day churn can be measured.

This is exactly the expected behaviour. A roadmap that absorbs an invalidated hypothesis within a few weeks is worth more than one that hits its dates on useless initiatives.

Involving the teams

Presenting the roadmap is the best moment to share the strategic goals. But involvement starts earlier: developers should be consulted during design, not informed at the end. They see technical risks and shortcuts that you don’t. I have written a separate piece on this: agile roadmap: how to involve your teams.

Using and updating the roadmap

Update it as often as needed, and at least at the end of every quarter, checking it against the hypotheses that have been validated or invalidated. Use it during backlog grooming and sprint planning. To keep it in a project management tool, see building an agile product roadmap in Asana.

A warning sign to watch for: if teams call you to find out what is planned instead of checking the roadmap, they no longer trust it.

The rules I apply

• Every item has an explicit reason to exist.
• The teams take part in designing it.
• It is linked to hypotheses and metrics.
• It contains only the level of detail its audience needs.
• It is reviewed regularly and reflects pivots.
• It is accessible to everyone, in the everyday work tool.

Typical mistakes, and how to spot them

1. The dated feature list. Sign: no “why” column, only feature names and months. Ask, for each line, which goal it serves. The silences are your candidates for removal.
2. The roadmap of whoever spoke last. Sign: priorities change after every customer meeting or committee. Set a review rhythm and a single place for requests.
3. The roadmap with no capacity. Sign: everything is under “Now”. If the team cannot do it all this quarter, the roadmap is lying, and everyone knows it.
4. Hidden commitments. Sign: dates promised to a customer or to management that appear nowhere. Make them visible, with their origin.
5. Shipped, never measured. Sign: initiatives disappear on release. Keep them until their metric has been read.

Small team or large organisation

With a single product team, one page is enough: the quarter’s goals, three horizons, a “why” column. The product manager owns it, reviews it monthly with the team and the founders, and shares it where the team works. Don’t create audience-specific views as long as everyone can read the same one.

In an organisation with several teams, you need two levels: a portfolio roadmap, showing the goals and the trade-offs between products, and one roadmap per product, detailing the initiatives. Dependencies between teams become the first topic of every review. Decide who arbitrates when two teams claim the same capacity, or the decision will be made in the corridors.

Where does AI fit in?

In 2026, almost every roadmap has an “AI” line. It is often the vaguest one: “integrate AI into the customer journey”, with no metric and no owner. Apply exactly the same rules to it as to everything else: a hypothesis, a metric, a business owner, a bounded scope.

AI assistants help draft initiative descriptions or synthesise customer interviews. They don’t make the calls for you. And an AI initiative on the roadmap only has value if it reaches production: that is the subject of from AI proof of concept (POC) to production.

Some AI lines also carry a real deadline that justifies a precise date: the AI Act obligations for high-risk systems, for instance. If your product touches recruitment, credit or education, check its classification under Annex III before setting the timeline.

In hindsight

The 2022 version of this article is still right on the essentials, and I would keep it: a roadmap is judged by its “why” column, it is built with the teams, and it changes when a hypothesis falls. Nothing I have seen since contradicts these rules.

I would nuance the idea of a single roadmap adapted for each audience. As CPO at Dotworld, I ran the roadmaps of several products in parallel. The difficulty was not presenting one roadmap from several angles, but arbitrating between products competing for the same people. That is why I now insist on the portfolio level and on the question “who arbitrates?”. I argue that a successful AI project is 70% organisation and 30% technology; a roadmap often follows the same proportion.

AI assistants have changed how I prepare a roadmap. Synthesising twenty interviews, grouping customer requests, drafting a first version of the initiative briefs: what used to take days takes hours. This has two consequences. Experiments cost less, so the roadmap can hold more hypotheses tested quickly. And more checking is needed: a generated synthesis can invent a consensus that did not exist in the interviews, or ignore the customer who said the opposite. I always go back to the sources behind any claim that shifts a priority.

Finally, I would add a rule I had not written down in 2022: an AI initiative only leaves the roadmap once it has been measured in production, on metrics defined in advance. At Home Partners of America, the results of the customer service assistant were tracked on precise metrics: 46% of tickets deflected, 97% intent accuracy, a 60% reduction in average resolution time. Figures like these cannot be reconstructed after the fact: they require knowing, before launch, what you will measure and how. The method is detailed in measuring an AI assistant.

Frequently asked questions

What is the difference between a roadmap and a backlog?

The roadmap says where the product is going and why, at the level of goals and initiatives. The backlog lists the concrete work to be done, at the level of user stories, bugs and technical tasks. The roadmap feeds the backlog, not the other way round.

Should a product roadmap include dates?

Horizons, yes; precise dates only for real commitments, such as a regulatory or contractual deadline. Fine-grained dates on uncertain items create false promises and reduce agility.

How often should the roadmap be updated?

Whenever a hypothesis is validated or invalidated, and at least once a quarter in a formal review with the teams and senior management.

Which tool should you use for a product roadmap?

The one the team already works in: a project management tool, a shared spreadsheet or dedicated software. The criterion is not how rich the features are but whether it gets updated: a roadmap checked every week in a simple tool beats a sophisticated view nobody opens.

How do you put an AI project on the roadmap?

Like any other initiative: a problem, a hypothesis, a measurable metric, a business owner and a bounded scope. Add a step for measurement in production and, if the system touches a sensitive area, a check of the AI Act obligations.