# Product roadmap

A product roadmap is a short, shared plan of what a product team intends to work on and why, usually grouped by time horizon or goal, that helps everyone agree on priorities without promising exact features on exact dates.

Also called: Roadmap, Now, next, later roadmap, Outcome roadmap, Feature 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.

## 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.

| Document | What it holds | Time span |
| --- | --- | --- |
| Roadmap | Goals and themes in priority order | Months |
| Release plan | What ships in the next releases, with dates | Weeks |
| Backlog | Every task, bug, and idea | No fixed span |

## 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.

**Diagram: A now, next, later roadmap.**

1. Now (In progress, specific, committed)
2. Next (Likely, shaped, open to change)
3. Later (Problems worth solving, not designed)

_Detail falls off with distance. Items move left as they are understood, and some never leave Later._

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](https://www.choie.co/glossary/user-research), support, and [product analytics](https://www.choie.co/glossary/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.

> **Say what you are not doing.** A short list of things deliberately left out is one of the most useful parts of a roadmap. It ends debates before they start. Choie's [prototype week](https://www.choie.co/services/coded-prototype) opens the same way: day one picks the one critical workflow and decides what is out.

## Roadmaps for early products

Before launch, the roadmap is mostly the [MVP](https://www.choie.co/glossary/mvp) scope and a list of what comes after. The first release should be fixed in a written [scope of work](https://www.choie.co/glossary/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

### What should a product roadmap include?

The product goal, the main problems or themes in priority order, a rough time horizon for each, and what is deliberately out of scope. Detailed tasks belong in the backlog instead.

### Should a roadmap have dates?

Near-term items can have target dates when the work is well understood. Further out, time horizons such as now, next, and later are more honest than specific dates.

### How often should a roadmap be updated?

Whenever you learn something that changes priorities, and at least on a regular rhythm such as monthly for an early product. A stale roadmap misleads the people relying on it. During a Choie build, the founder gets a new live link to use every Friday, which makes a natural weekly check on whether the next item still makes sense.

### Should I share my roadmap with customers?

A high-level version can build trust, especially for B2B products. Share themes and problems rather than feature promises with dates, so you keep room to change course.

Related: [Minimum viable product (MVP)](https://www.choie.co/glossary/mvp), [Product discovery](https://www.choie.co/glossary/product-discovery), [Scope of work](https://www.choie.co/glossary/scope-of-work), [Product-market fit](https://www.choie.co/glossary/product-market-fit), [Product development retainer](https://www.choie.co/glossary/product-development-retainer).

HTML: https://www.choie.co/glossary/product-roadmap