product roadmap
Also called: roadmap, product road map
A strategic communication tool that shows how a product will move towards its vision: which customer problems and business objectives the team will tackle, in roughly what order, and why. It states intent and direction, not a delivery contract.
A product roadmap answers three questions for everyone who works on or around a product: where are we going, why, and roughly in what order will we get there. It sits between the company's vision and the team's detailed plans. Above it are the mission, the product vision and business objectives. Below it are release plans, backlogs and sprint boards that say exactly what ships when.
A useful roadmap usually has five primary parts:
- Product vision: the future the product is working towards.
- Business objectives: the measurable results the company expects.
- Themes: the customer needs or problems the team will tackle.
- Timeframes: broad buckets such as quarters or Now / Next / Later.
- Disclaimer: a clear note that the plan will change as the team learns.
Secondary details (likely features, stage of development, confidence, target customers, product areas) are added only when a particular audience needs them.
The roadmap's main job is communication. Engineering uses it to understand why the work matters, sales and marketing to prepare for what's coming, executives to see how investment turns into results, and customers to see that their problems are heard. That is why it should be short enough to read in a few minutes, and why it is a statement of intent rather than a list of promises. Once it turns into a dated feature list, it stops doing its job and becomes a project plan that is out of date a week after it's shared.
Example
Sofia, a junior PM at CatChow, receives a spreadsheet of 40 feature requests and a request from the CEO for "a roadmap for next year". Instead of putting dates on all 40, she drafts a one-page roadmap:
- Vision: cat owners never run out of the right food, and never have to think about it.
- Objectives: grow the subscription share of revenue from 18% to 30%; cut delivery-related support tickets by a third.
- Now: Make reordering effortless for regular buyers (objective 1).
- Next: Help owners choose the right food for their cat's age and health (objectives 1 and 2).
- Later: Reliable delivery windows outside big cities (objective 2).
- Disclaimer: "Plans as of March; they will change as we learn."
Most of the 40 requests now sit under one of the three themes as candidate solutions. The rest wait, each with a written reason.
Common mistakes
- Treating it as a delivery schedule. Exact dates for everything turn every change into a broken promise. Keep dates for the release plan.
- Listing features without the why. A column of feature names invites "why is X there and not Y?". Lead with themes and objectives.
- Showing every detail to every audience. Engineers, sales and customers need different depth. Keep one core (vision, objectives, themes, timeframes) and add layers per audience.
- Building it alone. A roadmap nobody helped shape gets little support. Involve stakeholders early.
- Never updating it. A roadmap that isn't reviewed on a regular cadence quietly becomes fiction.
Learn it in the course
- What a roadmap is (and isn't) · Why a feature list with dates fails as a roadmap, what a product roadmap is actually for, and how it differs from a release plan, a backlog and a Gantt chart.
- Anatomy of a roadmap: the five primary components · The five parts every useful roadmap needs (product vision, business objectives, themes, timeframes and a disclaimer), what each one does, and Sofia's first one-page roadmap for CatChow.
- Outcomes over outputs · The difference between what a team ships and what changes because of it, how to climb from a feature request to a measurable outcome, and the traps that make an outcome useless.