A roadmap is a short, ordered answer to one question: what are we working on, and roughly when. It is not a plan, a strategy, a specification or a list.
Almost every argument about roadmaps is really an argument about which of those somebody wanted. Somebody asks for a roadmap, gets a Gantt chart, and is annoyed; or asks for a roadmap, gets three themes with no dates, and is annoyed for the opposite reason. The words below are the ones that get swapped.
Product roadmap vs strategy
Strategy is the choice. A roadmap is the consequence of it.
A strategy says who you are building for, what you are betting will matter to them, and what you are deliberately not doing. It is mostly prose, it rarely changes, and it does not have dates on it.
A roadmap takes that and answers the next question down: given that choice, what is happening in the next few months. If you can delete a strategy and the roadmap still makes sense, the roadmap was really a list of requests.
The short test is that a strategy tells you why something is not on the roadmap. If nothing is ever refused on strategic grounds, you have a roadmap and no strategy.
Product roadmap vs vision
Vision is the destination and the roadmap is the next part of the journey.
A vision is a sentence or two about the world once your product has worked. It has no dates at all and it should survive a change of plan. It is the thing you repeat in an all hands until people are bored of hearing it.
A roadmap has a horizon, usually two or three quarters. Anything further out on a roadmap is a vision statement wearing a date, and putting a date on it costs you credibility every time it moves.
Product roadmap vs project plan
A project plan tracks tasks and dependencies. A roadmap tracks outcomes and their rough order.
The difference is granularity and audience. A project plan exists so that the people doing the work know what blocks what: who is waiting for whom, which task cannot start until another finishes, how many days each takes. It is measured in tasks.
A roadmap exists so that people who are not doing the work know what to expect. It is measured in things a customer would notice.
If your roadmap has an item on it that no customer could describe, it is a project plan row that wandered in.
Product roadmap vs delivery plan and delivery roadmap
A delivery roadmap is a roadmap with the engineering sequence on it, and it is usually an internal document.
The reason the two names exist is that two audiences want different things from the same set of facts. A customer wants to know that search is coming this quarter. An engineering manager wants to know that search needs the indexing work first, that the indexing work needs one person for three weeks, and that the person is currently on something else.
Both are true. Publishing the second one to customers is the mistake, because it invites a conversation about staffing that nobody outside the team can usefully have.
Keep one set of facts and two views of it. What belongs on the public one is its own question.
Product roadmap vs release plan
A release plan is about shipping. A roadmap is about intent.
A release plan names versions and the dates they go out, and it belongs to whoever runs the release process. Its readers are the people who need to be ready: support, documentation, whoever writes the announcement.
A roadmap does not name versions, because a version number tells a customer nothing about whether their problem is being solved. The roadmap says the thing, the release plan says when the thing arrives with a number on it, and the changelog says it has arrived.
The teams that conflate these end up with a roadmap full of 2.4 and 2.5, which is a roadmap nobody outside the building can read.
Product roadmap vs backlog
The backlog is everything. The roadmap is the short list you have actually decided on.
A healthy backlog is long and a healthy roadmap is not. The backlog holds every request, bug and idea in whatever state it arrived in; it is an inbox, not a plan, and it is allowed to be enormous.
The roadmap is what survived a decision. If an item is on the roadmap, somebody has said yes to it and accepted that something else is therefore not happening.
The most common failure here is a roadmap that is just the top of the backlog sorted by vote count. Votes tell you what is wanted. They do not tell you what is worth doing, because the loudest request is often the most expensive one and the quiet one is often from the customer paying you the most.
Product roadmap vs Gantt chart
A Gantt chart is a shape, not a document, and it is the wrong shape for a roadmap.
A Gantt chart draws bars across a calendar with dependencies between them. It is excellent for work whose sequence is known and whose duration is knowable: a building, a migration, a conference.
Product work is neither. A bar with a start date and an end date tells everybody who reads it that you know how long something will take, and they will plan around that. When it moves, and it will, you have spent trust you did not need to spend.
That is the whole argument for columns rather than bars. Now, next, later says the same thing with the right amount of confidence in it.
Product roadmap vs story map
A story map is a way of laying out one piece of work. A roadmap is a way of ordering many.
A story map takes a single user journey and spreads it horizontally in the order the user experiences it, then stacks the variations underneath in priority order. Its job is to find the thinnest version of that journey that still works.
So a story map sits below one roadmap item, not beside the roadmap. If you have a story map for the whole product, you have a backlog drawn sideways.
Product roadmap vs PRD and project charter
Both of these describe one thing in detail. A roadmap describes several things in almost no detail.
A product requirements document, or PRD, says what one feature must do, for whom, and how you will know it works. A project charter is its formal cousin: scope, stakeholders, success criteria, signed at the start.
Neither belongs on a roadmap and both are usually linked from one. The roadmap item is a line; the PRD is what opens when somebody asks what the line actually means.
The failure mode is a roadmap where every item has a paragraph under it. That is not a roadmap, it is a table of contents for nine PRDs, and nobody will read the whole of it.
So which one were you asked for?
Answer three questions and the word you needed falls out.
| Who is reading it | What they want to know | The document |
|---|---|---|
| A customer | Is my problem being worked on | A public roadmap |
| An executive | What are we betting on and why | A strategy |
| Your own team | What blocks what, and who is free | A project plan |
| Support and docs | What ships on which date | A release plan |
| An engineer starting the work | What exactly must this do | A PRD |
| Anybody, later | What already shipped | A changelog |
Most teams need three of these and try to make one document be all of them. That is why roadmap arguments feel unresolvable: two people are editing the same page with different readers in mind.
How do you keep the roadmap short enough to stay a roadmap?
By making the decision to drop something visible, rather than letting it happen by neglect.
The practical version: give every item an effort number and a demand number, and order by one divided by the other. Demand is what your customers asked for, weighted by what they are worth to you. Effort is your own estimate, because nobody else can make it.
Then take the top of that list and nothing else. Everything below the line goes back to the backlog with the reason written on it, which is the part that saves you the conversation later.
The spreadsheet that does this arithmetic is free to take, and the board that does it continuously is here. Eight roadmap tools, sorted by who is actually allowed to look at the page they produce, is where that first decision gets made.
What this costs
Lite
$9 /mo
Pro
$39 /mo
Lifetime
$999 once
Fourteen day trial of Pro, card asked for at signup. Nothing here counts the people who vote, so the bill does not move when the board starts working. The long version, with what happens if you stop paying.