Building an agile product roadmap in Asana

Why build your roadmap in Asana

A roadmap does three things: it shows the direction, explains the priorities, and connects day-to-day work to goals. A slide deck handles the first well. It often fails at the other two, because it is out of date three weeks after it was presented.

Asana’s main advantage is that it avoids this drift: every roadmap item is a task, with an owner, subtasks, comments and a status. The roadmap updates along with the work. At SipScience, we used it for the overall roadmap view, for sprints and for retrospectives.

If you are starting from scratch, read how to write a product roadmap first: the tool does not replace the thinking.

Setting up the roadmap, step by step

1. Create a “Product roadmap” project, from Asana’s roadmap template or a blank project, and attach it to a team so it is visible across the organisation.
2. Create the sections (list view) or columns (board view) to match the time axis you choose, plus a “Backlog” section.
3. Create one task per roadmap item: an epic, a feature, a technical workstream. Not one task per user story, or the roadmap turns into a backlog.
4. Fill in each item with a goal, a summary of the problem to solve, the hypothesis it must validate and the expected result.
5. Assign each item to the product manager, who consults stakeholders and places it in time.

A useful order of magnitude: a readable roadmap holds a few dozen items, not several hundred. If you are well beyond that, you have probably mixed up roadmap and backlog.

Choosing the time axis

This is the first real decision. Every team works differently: choose an axis that fits your strategy and constraints, not the one in the default template.

Conceptual: now, next, later

Sections “Backlog”, “In progress”, “Next”, “Later”, “Never”. Very agile, ideal when resources and pivots are uncertain. The “Never” section is underrated: it documents what you have decided not to do, and saves you reopening the debate every month.

By quarter

Sections “Backlog”, “Q1”, “Q2”, “Q3”, “Q4”. A good balance between the big picture and sprint preparation. This is the format I recommend most often for a team that reports to senior management.

By month

Almost sprint-level planning. Very readable day to day, but it reduces agility and encourages overestimating the team’s capacity. If you choose it, reassess priorities at the end of each month, or you will be managing a cascade of slippages.

You can also combine them: a conceptual axis for the view shared with the whole company, and a “Quarter” field filled in only for committed items. The view stays honest about uncertainty, and management sees what is actually promised.

An agile product roadmap template

Here is the template I reuse most often. The custom fields make the difference between a wish list and a decision tool.

• Goal (drop-down): the three to five goals for the year. Every item must serve one.
• Hypothesis (text or drop-down): what the item must prove. This is the link to the hypothesis roadmap.
• Priority reason (drop-down): customer request, growth, monetisation, technical debt, compliance.
• Status (drop-down): to scope, ready, in progress, shipped, measured. “Measured” is the step everyone forgets.
• Sprint (drop-down or text): useful with a quarterly axis.
• Metric (text): the number that will tell you whether the item worked.

Then sort by goal or by priority reason: imbalances become visible immediately.

A well-filled roadmap item

A fictional example, for booking software aimed at physiotherapy practices:

The “Out of scope” line is not a field in the template, but I add it to the description. It heads off half the discussions when the item is broken down.

Asana and Scrum: linking the roadmap to sprints

The roadmap and the sprint backlog should not be the same project. Keep a “Roadmap” project at epic level, and one project per team for sprints, with one section per sprint. Asana lets you add the same task to several projects: a user story can live in the sprint while staying linked to its roadmap epic.

In this setup, the grooming session is where roadmap items are broken down into backlog items ready to be committed. I cover the common mistakes in product backlog: mistakes to avoid.

Views complete the setup: the timeline to visualise dependencies, the calendar for deadlines, the board for daily tracking. Depending on your plan, goals and portfolios let you consolidate several roadmaps.

The rituals that keep it alive

1. Every week (15 minutes): the product manager updates statuses and flags blocked items. No meeting needed.
2. At the end of each sprint: check that shipped items have a tracked metric, and move to “Measured” those whose effect you know.
3. Every month: review the “Next” and “Later” sections with the team leads. An item that has not moved for three months must be justified or moved to “Never”.
4. Every quarter: a formal review with management, based on the hypotheses validated or invalidated, not on the list of releases.

Typical mistakes, and how to spot them

• The roadmap that has become a backlog. Sign: hundreds of tasks, with user stories and bugs mixed in with the epics. Fix: one level per project, and a filter that shows only roadmap-level items.
• Empty fields. Sign: sort by “Hypothesis” or “Metric” and half the rows are blank. Fix: an item with no hypothesis and no metric stays in “To scope”.
• Nobody moves anything to “Measured”. Sign: the “Shipped” column keeps growing, the “Measured” column stays empty. It is the symptom of a team that ships without learning.
• False dates. Sign: deadlines pushed back every month on the timeline. Fix: remove dates from uncommitted items.
• Too many contributors. Sign: everyone creates items, and the roadmap reflects who has the most time to write. Fix: a request form that feeds the backlog, and a single owner for the roadmap.

Asana for which teams?

In a startup, starting early helps build good habits, and the basic plan covers the essentials. With a single team, one project is often enough: sections for the roadmap, a “Sprint” field for work in progress, and a weekly review. Don’t build the architecture of a thousand-person company for five developers.

In a larger organisation, with several teams and many stakeholders, the challenge becomes keeping everyone in sync: shared custom fields, followers on tasks, common naming conventions. Write those conventions on one page, with examples, and decide who can create or change the shared fields. Without that, every team invents its own statuses and consolidation becomes impossible.

Either way, the rule is the same: if teams call you to find out where something stands instead of checking the roadmap, the tool is no longer the source of truth.

Where does AI fit in?

Project management tools, Asana included, now ship AI features: progress summaries, drafting descriptions, suggestions for breaking work down. They save time on formatting. They do not decide priorities, and an automatic summary of a badly kept roadmap is still a badly kept roadmap.

The most useful application I see: asking an assistant to review a roadmap item and check that it contains a goal, a hypothesis and a metric. It is a discipline AI helps you keep, not a judgement it replaces. If your teams want to make this a habit, it is the kind of exercise we work on in AI training.

If the roadmap itself contains AI projects, treat them with the same fields. An “AI assistant for support” item with no metric and no business owner is unlikely to get past the demo. The guide to choosing a team’s first AI use cases helps frame them.

In hindsight

In 2022, this article was mostly an Asana how-to. I would keep the structure: a roadmap level separate from the backlog, fields that force you to write down the hypothesis and the metric, and a “Measured” status nobody is allowed to forget. These three choices work in any tool, and that is what matters.

I would tone down the importance I gave to the tool. Since then I have run several roadmaps in parallel, notably as CPO at Dotworld, and the problem was never the software. It was in the decisions: who arbitrates between two products, when, with what information. A good tool makes those decisions visible. It does not make them. It is the same idea as the thesis I defend today on AI projects: 70% organisation, 30% technology.

AI assistants have changed two things in this practice. Writing an item description, summarising a comment thread or preparing a quarterly review takes far less time. The flip side is that producing text now costs nothing: tasks grow longer, descriptions start to look alike, and a roadmap can appear well kept without being so. So I ask teams to check every generated summary before sharing it, and to keep the fields short. A metric fits on one line. If it takes a paragraph to explain, it is not defined yet.

Finally, I would measure the time saved rather than assume it. If an assistant saves the product manager an hour a week on roadmap updates, that can be verified: measuring the time saved by an AI tool explains how. And for the AI projects on the roadmap, the real question remains whether they reach production: from AI POC to production.