The short version
- A roadmap is a short public statement of what is coming and in what order, kept current.
- It's not a schedule, and treating it as one is what causes most of the damage.
- Three audiences read it at once, which is why most of them read badly.
- Credibility comes down to two things a reader checks without noticing.
A software roadmap is a statement of order. It says what you intend to work on and roughly in what sequence, to an audience that's not in your planning meetings.
It's not a schedule, not a specification and not a backlog. Those three confusions account for most of the arguments anybody has about a roadmap, so the rest of this post is about the boundaries, not about the definition.
What is a software roadmap, exactly?
A short, public statement of what's coming and in what order, kept current.
Four words in that sentence are load bearing. Short, because a roadmap that takes ten minutes to read is a document, not a signal. Public in the sense of being visible to the people affected, whether that's customers or another team. Order, which is the only thing it can promise and keep.
And current, because a roadmap that's out of date is worse than no roadmap. It actively misleads.
There's one running, not a description of one, and the demo is open without an account.
Picking the tool this lives in? Eight roadmap tools, sorted by who is allowed to look. On one of them every viewer needs a paid seat.
What belongs on it, what belongs in a ticket, and what belongs nowhere
| The thing | Where it goes | Why |
|---|---|---|
| A capability a customer would recognise | The roadmap | It is the unit the audience thinks in |
| A rewrite with no visible effect | Nowhere public | Nobody outside can evaluate it and it will be read as a delay |
| A bug | The bug queue | A roadmap of bugs is a list of apologies |
| The fifth sub task of a feature | A ticket | Sub tasks are how the work is done, not what is coming |
| A date | Nowhere, usually | A date is a commitment made before the work is understood |
| A thing you might do if somebody asks | Nowhere yet | If it is not ordered it is not on a roadmap |
| A theme for the quarter | The roadmap, above the items | It is how you decline six requests with one sentence |
| An outcome with its current number | The roadmap, if you will measure it | Without the number it is a wish |
The test for any single item is this. Would a customer recognise the words, and would they be able to tell afterwards whether it happened. If the answer to either is no, it belongs somewhere else.
What a roadmap is not a plan for
It's not a schedule. A schedule has dates and dependencies and is used to coordinate people. A roadmap has order and is used to set expectations. Publishing a schedule as a roadmap is how a team ends up defending a March date in April.
It's not a specification. The roadmap says the export is coming. It doesn't say which columns, and it should not, because the columns are decided by the people who look at it when the work starts.
It's not a backlog. A backlog is everything anybody has ever asked for. A roadmap is the small ordered part of it you've actually committed to. The moment the roadmap becomes the backlog it stops being a signal, because the reader can no longer tell what's real.
It's not a promise of completeness. Things will ship that were never on it. That's normal and it should be said on the page.
Who is it for?
Usually three audiences at once, which is the reason most roadmaps read badly.
Customers want to know whether their thing is coming. Sales want something to show. Engineers want to know what's next. Those three want different granularity, and a roadmap trying to satisfy all three ends up too detailed for the first and too vague for the third.
The workable answer is that the public roadmap is for the first audience, and the other two get the same page plus a conversation. Writing one document for the least informed reader is the only version that stays honest, because it forces the words to be recognisable, not internal.
What makes one credible
A reader deciding whether to believe a roadmap checks two things, usually without noticing.
Has it changed since last time. A page that looks identical on two visits reads as abandoned, whatever it says.
Did anything that was on it actually ship. One item moving from a planned column to a shipped one, with a date on the shipped one, does more for credibility than any amount of writing.
That second one is why a roadmap and a changelog belong next to each other. The changelog is the evidence for the roadmap's claims.
The mistakes
Publishing a roadmap with dates. Covered above, and it's the one that causes the most damage.
Putting everything on it. A roadmap with forty items is a backlog, and a reader can't tell which four matter.
Never removing anything. Items that quietly became never should be said to have become never. A denied column is more credible than a silent deletion.
Writing it in internal language. If the item says "migrate the ingestion pipeline", the audience it was written for can't use it.
Letting it go stale. A roadmap is a claim about the present. It expires.
How do you do this without a tool?
Three headings on a page, five items each at most, edited whenever something moves, with a line at the top saying when it was last changed.
That's a real roadmap. What it can't do is tell you whether the order is right, because it only carries your own view of what people want.
How does this product do it?
The board is a roadmap with five columns by default, being Suggested, Denied, In Review, In Progress and Completed. Denied is a column, not a deletion, so a declined request stays visible with the reason on it.
Each card carries an effort estimate and a progress percentage, and can be tied to a named release so that shipping it writes the changelog entry. Requests arrive from the people waiting, not only from inside, and nothing a visitor writes appears publicly until somebody approves it.
The public roadmap page covers the board, and software roadmap examples covers the shapes one can take.
What makes a roadmap good covers the tests a finished one has to pass.
14 days, a card at signup, then $9 or $39 a month.
