Product roadmap

In short

• A roadmap says what you will work on next and why, not every task and not a list of promises.
• Organize it around problems or goals. Features are one possible answer to each.
• The near term can be specific. The further out it goes, the looser it should be.
• Update it when you learn something. A roadmap that never changes is not being used.

Also called: Roadmap, Now, next, later roadmap, Outcome roadmap, Feature roadmap.

What a roadmap is for

A roadmap is a communication tool. It tells the team, investors, and sometimes customers where the product is heading, so day-to-day decisions point the same way. It answers what problem is next, what comes after it, and what has been deliberately left for later.

It is not a backlog, which is the full list of tasks and ideas, and not a release plan, which schedules specific work into specific dates. Those sit underneath it. A roadmap should fit on one page.

The now, next, later format

Many teams have moved away from roadmaps that look like a calendar of features with dates. Those dates turn into promises, and the promises turn into pressure to ship things nobody has validated. A popular alternative groups work by how certain it is.

Each item is best written as a problem or goal: reduce drop-off in sign-up, let teams share reports, support payments in euros. That leaves room to choose the best solution when the work starts, informed by what the team has learned since.

How to build one

1. Start from the goal. What does the business need from the product in the next few months: more activation, a first paying segment, fewer support tickets?
2. List the problems standing in the way. Use evidence from user research, support, and product analytics.
3. Rank them. By impact on the goal against effort. A rough score is enough to start an honest conversation.
4. Commit only to Now. Put a small number of items there, ideally one main focus at a time.
5. Review it on a rhythm. Monthly is common for an early product. Move, cut, and add items as you learn.

Roadmaps for early products

Before launch, the roadmap is mostly the MVP scope and a list of what comes after. The first release should be fixed in a written scope of work. The items after it should stay loose, because the first weeks of real usage nearly always reshuffle them.

After launch, the roadmap becomes a rolling priority list. Choie's month-to-month work, from $9,900 a month, takes one clear product priority at a time, which is in effect the Now column of a roadmap. Major new products and complex integrations are scoped separately.

Common mistakes

• Dates on everything. Committing to features six months out, then shipping them even after learning they are not needed.
• A list of features with no goal. Without the why, nobody can judge whether a feature is still the right answer.
• Too much in Now. Five parallel priorities usually means none of them finishes on time.
• Building whatever the loudest customer asked for. Requests are evidence, not a plan. Look for patterns.
• A roadmap nobody looks at. If the team does not refer to it in planning, it has stopped doing its job.

Common questions