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 are the key elements of a product roadmap, and what is included in one?
Six things, on ours, 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?
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?
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 prioritisation methods disagree about.
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 honest 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.
Ours 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 our own product, 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 ours, 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.
