A product roadmap is the ordered account of what a team intends to build and roughly in what sequence. That is the whole definition and it is not the part anybody argues about.
What people argue about is a question the definition hides. There are two documents that both get called a roadmap, they are read by people who want opposite things, and almost every argument about roadmaps is really two people holding different ones.
What is included in a product roadmap, and what are its key elements?
A product roadmap includes six things, on VoteFirst, and none of them is a date.
A card on the public board carries the request, its column, its vote count, its view count, its comment count, and its weighted total when the board is ordered by revenue rather than headcount.
What is not included matters as much. No target date, no owner, no estimate, no dependency, no sprint.
Where do product roadmap ideas come from?
The board underneath it, if the roadmap is doing its job.
The demo board carries twenty requests from two hundred and fifty seven voters. More arrives than any quarter can hold, and the roadmap is the part somebody decided on. Those twenty can be ordered by headcount or by money, and the two orders disagree on almost every board.
What is a roadmap in product management?
A roadmap in product management is the internal one, nearly always, and that is why the phrase causes so much confusion.
Inside product management a roadmap is the planning document. Sequence, dependencies, who is doing what, and dates a team can commit around. It is read by people inside the building and it is the version most articles about roadmaps are describing without saying so.
The one your customers open is a different document with the same name. It answers whether rather than when. Both are real, both are worth keeping, and the mistake that costs the most is publishing the first one because somebody asked for a public roadmap.
What is involved in creating a product roadmap?
Creating a product roadmap involves four steps, and only one of them is drawing anything.
Collect what people have actually asked for, in one place, with the votes attached. Decide what the next quarter is about, which is a judgement nobody can automate.
Order the list inside that theme, by the people waiting rather than by who asked loudest. Then publish the columns and leave the dates on the internal copy.
The fourth step is the one teams skip and it is the cheap one. A roadmap template as a CSV with the effort and priority columns already in it is enough to start, and the ordering is what the five prioritization methods disagree about.
Where does the roadmap in an issue tracker fit?
Beside this one, not instead of it.
An issue tracker roadmap is built from work items, so everything on it has already been decided, sized and assigned. That makes it a plan for the people building and a poor plan for the people waiting, because the question they arrived with, whether the thing they asked for is coming, has nowhere to live on it.
Keeping a product roadmap in Jira, and what a customer never sees on it works through the split.
Is it roadmap to or roadmap for?
Both are correct English, and they mean different things, which is why the question keeps coming up.
A roadmap to something takes a destination. A roadmap to profitability, a roadmap to version two, a roadmap to a sale. The thing after the word is the place you are trying to arrive at, and the sentence is promising you will get there.
A roadmap for something takes an owner or a subject. A roadmap for the mobile app, a roadmap for the platform team, a roadmap for next year. The thing after the word is who or what the plan belongs to, and the sentence promises nothing about where it ends up.
So a roadmap for the product is the document. A roadmap to a hundred thousand customers is a claim. If you are about to write one of these on a slide and you are not sure which, use for, because it is the one that does not accidentally commit you to an outcome.
What are the types of product roadmaps?
Four, and the difference between them is who is allowed to read it.
The internal roadmap carries dates, owners and estimates, and it changes every week without anybody apologising. The public roadmap carries what is coming and roughly in what order, and it carries no dates at all, because a date shown to a customer is a promise however you label it.
The strategy roadmap groups a year of work under a handful of outcomes and is the version a board or an investor sees. The release roadmap is the narrowest, listing what goes into a specific version, and it is the one that becomes the changelog once it ships.
Most arguments about roadmaps are two people holding different ones. Say which type you are looking at before you disagree about what is on it.
Who is the roadmap actually for?
One of two audiences, and it cannot be both.
The internal roadmap answers when. Your team, your board, your account managers. They are planning around it, so they need dates, sequence, dependencies and who is doing what. A roadmap without dates is useless to them, because their whole question is what to plan around.
The public roadmap answers whether. Your customers. They are not planning a sprint, they are deciding whether the thing they need is ever coming and whether it is worth waiting for. Their question is not when will this ship, it is whether you have understood that they need it.
The two documents can be built from the same list. They cannot be the same document, because the moment you put your internal dates in front of customers you have converted a plan into a promise, and you did not mean to.
If the definition is easier to see than to read, the demo board is open with no account and no email.
Should a public roadmap have dates?
Almost never, and the reason is not cowardice.
A date on an internal roadmap is an estimate that everybody reading it knows is an estimate. The same date in front of a customer stops being an estimate the second they read it. They will forward it, plan around it, tell their own boss, and sometimes put it into a renewal conversation.
Then the date moves, because dates move. Now you have not just missed an estimate. You have broken something a person told somebody else, and the damage is not proportional to the size of the slip.
The tempting fix is a vaguer date. A quarter, or later this year, or soon. Those are worse rather than better, because they carry the same commitment with less information.
Soon is a date to the person reading it and it is not a date to you, which is exactly the asymmetry that causes the trouble.
There is one exception. A hard external deadline you cannot move, being a regulatory date, an end of life, a partner's cutoff, belongs in front of customers because the deadline is real and the consequence of missing it is theirs as much as yours.
What goes on a public roadmap instead of dates?
State, and the reason for it.
VoteFirst's roadmap is columns rather than a timeline. A request sits in Suggested, In Review, In Progress or Completed, or in Denied when the answer is no, and moving between them is a decision rather than a schedule. The columns are the whole structure of the page, and there is no date on any card.
That is a deliberate limit rather than a missing feature. A column tells a customer what they actually came for, which is whether you have seen it, whether you agree, and whether anybody is working on it. Those three answers are worth more to them than a quarter they cannot rely on.
Nine things a public roadmap can refuse to show, and what each refusal protects, is the catalogue behind that choice. Order does the rest of the work. If the list is ordered by what your customers asked for, the position of an item is a real answer about priority without being a commitment about time.
A vote can carry the weight of the customer who cast it, which makes the order mean something more than a popularity contest.
One caution about VoteFirst, because it is the kind of thing you would rather find out here.
There are target date and start date fields on a request, they never appear on the public page, and they are readable through the published embed key by anybody who looks at the API. So treat a target date you set as public information even though the roadmap does not print it.
What happens when the plan changes?
It changes, and that is the argument for the whole design.
An internal roadmap that changes is a Tuesday. A public roadmap that changes is a communication event, and how much of one depends entirely on what you promised in the first place.
If you published a column, moving an item between columns is news. If you published a quarter, moving out of it is an apology.
The one thing that must not happen is silence. An item that quietly stops moving reads as abandoned whether it is or not, and a customer will assume the worst answer you left available.
Saying no in public is uncomfortable and it is better than the alternative, which is a board full of requests that are neither refused nor started.
When something does ship, the people who asked for it should hear from you rather than find out. On VoteFirst, publishing a release emails the voters on the requests inside it, though only the ones who were signed in, since an anonymous voter has no address to send to.
The board and the roadmap page are nine dollars a month, both figures are published, and a card is required for the fourteen day trial.
14 days, a card at signup, then $9 or $39 a month.
