Agile roadmap: how product managers build one

What is an agile roadmap?

It is an action plan, owned by the product manager, that describes how a product will evolve over time. It differs from a traditional roadmap in three ways:

• It is organized around goals and hypotheses, not a list of dated deliverables.
• It is revised continuously, at the pace of what the team learns.
• It provides context for sprints: product owners use it to prepare planning, and several agile teams can share the same roadmap.

It has to respond to pivots. But responsive does not mean unstable: every change needs a reason.

In practice, an agile roadmap answers three questions every team asks: what are we working on now, what comes next, and why in that order? If your roadmap cannot answer them in a minute, it is not yet helping anyone plan.

How the product manager designs it

The starting point is not the list of requests you have received. It is a more fundamental question: what is the shortest path to market fit or, once that is reached, to the metrics that matter?

To answer it, the product manager formulates hypotheses by combining three sources: the strategic vision, market feedback and technical constraints. Those hypotheses become initiatives, placed on a timeline. I recommend keeping the product roadmap and the hypothesis roadmap side by side: the second explains the first.

Small team or large organization

In a team of five to ten people, the roadmap fits on one page. The product manager builds it almost alone, talking things through with the developers and the founder as they go. The risk is not heaviness, it is what goes unsaid: everyone believes they share the same priority until the day two people realize they were talking about different things. Write it down, even briefly.

In an organization with several teams, the roadmap becomes a coordination tool. You need a shared level (goals, major initiatives, dependencies) and a more detailed level per team. The risk flips: too many levels, too many reviews, and a roadmap that describes the org chart rather than the product. The rule I apply: every initiative at the shared level has exactly one team that owns it, even if others contribute.

Questions to ask for every initiative

Before adding an initiative, put it through its paces:

1. What is its priority relative to the strategic goals and the hypotheses to validate?
2. When do we plan to tackle it?
3. Are there deadlines the team needs to know about: regulatory, contractual, commercial?
4. What are its dependencies, internal or on other teams?
5. Which team owns it, and does that team have the capacity?
6. Can we keep teams stable, or do we need to reorganize them?
7. If we reorganize, have we allowed time for people to get up to speed?

The last question is almost always forgotten. It explains a good share of delays.

What an agile roadmap is made of

A suitable time axis

Items must follow on from one another logically. The axis can be precise (quarters) or deliberately loose: “now”, “next”, “later”. The now, next, later format has become common because it embraces uncertainty: the further out the horizon, the less detail. Choose the axis that fits your context, and remember that it will be used in sprint planning meetings.

Fully described items

A roadmap contains epics (features that span several sprints), features, technical workstreams and sometimes actions coming out of retrospectives. Epics and features are described with their context, their goal, a representative user story and a definition of done.

This level of description lets developers understand the intent and work autonomously without jeopardizing what comes next. If your tool lets you link each item to a hypothesis, with a tag or a field, do it: that is what I describe in building an agile roadmap in Asana.

A worked quarter-planning example

A fictional example, to make the method concrete. A B2B software vendor that manages field technician jobs. Two teams of five developers, one product manager, one designer. Goal for the year: reduce churn among mid-sized customers. Top hypothesis for the quarter: these customers leave because scheduling technicians takes them too long.

1. Work out real capacity

A quarter is six two-week sprints. On paper, two teams of five developers give you sixty person-sprints. In this example, the team sets aside 30% for maintenance, bugs, support and leave, based on what it actually consumed in previous quarters. That leaves forty-two person-sprints for the roadmap. That figure, not the first one, is what you plan with.

2. Place the initiatives

Total committed: thirty-eight person-sprints out of forty-two. The remaining margin is not a comfort blanket; it is what absorbs the unexpected without blowing up the roadmap.

3. Plan the mid-quarter decision

The automatic suggestions are only committed if measurement confirms the time saving at the end of sprint 3. The threshold is written down before starting: for example, at least a one-third drop in scheduling time among pilot customers. Otherwise, the fourteen person-sprints go to another hypothesis. This planned decision is what makes the roadmap both committed and flexible.

4. Communicate to each audience

One page for leadership: goal, hypothesis, mid-quarter decision. The detail for the teams. Only the “now” for sales, who should not be selling the “later”.

The planning cycle

An agile roadmap follows a simple cycle:

1. Draft by the product manager, based on hypotheses and goals.
2. Review with the teams: objections, technical risks, rough estimates. Adjustments are made without betraying the fundamentals: every item keeps a reason to exist.
3. Publication in the team’s working tool, notifying the people concerned.
4. Breakdown of near-term items into backlog items during grooming.
5. Quarterly review: test the roadmap against the hypotheses that have been validated or invalidated, and adjust it.

This rhythm works whatever the size of the organization. When a roadmap spans several teams, the quarterly review becomes the moment to inspect, adapt and communicate together. Involving teams at every step is the subject of agile roadmap: how to get your teams on board.

Involving teams without creating a committee

Consulting everyone does not mean deciding as a group of twenty. Four rules keep the review useful:

• One decision-maker per roadmap, known to all. The RASCI matrix exists precisely to write that down.
• Written comments before the meeting: the draft circulates a few days ahead, and the meeting only deals with objections.
• Precise questions rather than “what do you think?”: what technical risk do you see, which dependency is missing, what will your customers misunderstand?
• A decision log: what was decided, by whom, and why. It stops the same debates from reopening every quarter.

Developers bring risks and estimates; business teams bring field knowledge and deadlines. Neither group votes on priority: they inform it.

Mistakes to avoid, and how to spot them

Each of these mistakes leaves visible traces well before it becomes expensive.

In hindsight

I wrote the first version of this article in 2022, after several years in product, mostly at startups. Since then, I have owned roadmaps in very different settings: the AI transformation of a contact center at Home Partners of America, then leading product at Dotworld, where we shipped four SaaS products in six months. Here is what I would keep, what I would nuance, and what has changed.

What I would keep

A roadmap organized around goals and hypotheses, revised at a known rhythm. I have never seen a roadmap of dated deliverables survive a quarter without being quietly rewritten. I would also keep the question about getting people up to speed: it still explains a good share of the delays I come across.

What I would nuance

I wrote that the now, next, later format embraces uncertainty. That is true for the team. To leadership or a customer, it can look like a refusal to commit. In larger organizations, I therefore add a few dated commitments, presented as such, the ones driven by an external constraint, and I set them apart visually from the rest. A roadmap can contain dates; it should not be made of them.

I would also nuance the idea of a product manager drafting alone. In a small team, it is efficient. In an organization of several hundred people, the draft is better co-written with the engineering lead and a business lead; otherwise the review turns into a negotiation.

What AI assistants have changed

The writing has become fast: epic descriptions, user stories, summaries of dozens of customer interviews. A clickable prototype that used to take a week often takes a day. That changes the economics of the roadmap: testing a hypothesis costs less, so you can test more of them before committing a team for a quarter.

The underlying difficulty has not moved: you still have to choose. An assistant produces twenty plausible initiatives in a minute, and nothing tells you which ones rest on a real problem. Summaries have to be checked against the sources: a customer quote distorted in a summary can steer a whole quarter. Review, compare against the sources, spot what was made up: that is the rule I apply and the one I teach.

The rest comes down to organization. The 70% organizational share I talk about for AI projects applies to the roadmap too: who decides, who is consulted, how often you revise. The tool speeds up the writing; it does not make the call.

Where does AI fit in?

AI initiatives themselves need different planning. Their outcome is uncertain: you cannot know in advance what quality the system will reach on your data. Plan them as hypotheses, with a quality threshold to hit and a decision agreed in advance if it is not reached. That is the difference between a roadmap that piles up POCs and a roadmap that puts systems into production, as I explain in from AI POC to production.

In the quarterly example above, model-based assignment suggestions would follow exactly the same pattern: a quality threshold measured on real cases, a decision date, and a fallback plan. To choose where to start, see choosing a team’s first AI use cases; to check the real gain afterwards, review time included, measuring the time AI actually saves.