The short version
- The roadmap sits between the backlog and the release, and touches both.
- Four things have to be true before a request moves from backlog to roadmap.
- Three audiences at once is the granularity problem, and it has no clean answer.
- The roadmap owes the backlog an honest no.
In software development the roadmap is the layer between the pile of things people have asked for and the thing that actually ships. It's the narrowest artefact in the process, and it's the only one written for somebody outside the team.
This post is about where it sits rather than what it is. What a software roadmap is covers the definition.
Where does the roadmap sit?
Between the backlog and the release, and it touches both.
| The layer | What it holds | Who reads it | How often it changes |
|---|---|---|---|
| Requests | Everything anybody asked for | Whoever triages | Daily |
| Backlog | Everything you might do | The team | Weekly |
| Roadmap | The small ordered part you committed to | Customers, sales, the team | Monthly, and visibly |
| Sprint or iteration | What is being built right now | The team | Every cycle |
| Changelog | What actually shipped | Customers | Every release |
The roadmap is the only row in that table whose audience includes people who don't work for you, and that single fact explains most of its properties. Why it's short, why it uses recognisable words, and why dates on it cost so much.
There's a stack doing all five layers if you want to see them side by side, 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.
How does something get from the backlog onto the roadmap?
Four things have to be true, and a request that fails any one of them stays in the backlog.
It's one thing. A backlog item can be a vague area. A roadmap item has to be something a reader can tell happened.
It's wanted by more than the person who asked. This is where a request list with counts earns its keep, because it's the only cheap way to find out.
Somebody has estimated it, roughly. Not a date. A size, so that ordering it against the others means something.
You're actually willing to do it. A roadmap item you would drop the moment anything else came up is a backlog item with a promotion.
The three audiences, and the granularity problem
A roadmap usually serves customers, sales and the team at once. They want different things and the conflict is real, not a matter of writing better.
| Audience | What they want | What they do with it |
|---|---|---|
| Customers | Is my thing coming, and roughly when | Decide whether to wait or to leave |
| Sales | Something to show in a deal | Answer an objection in a call |
| The team | What is next after this | Plan the next cycle |
Sales pressure pushes toward dates and certainty. Team needs push toward detail. Customers need neither. They need recognisable words and a visible order.
Write it for the customer. The other two get the same page and a conversation, because a conversation can carry a caveat and a page can't. A roadmap written for sales becomes a set of commitments nobody in engineering agreed to, and that's the single most common way the artefact goes wrong.
What the roadmap owes the release
One thing, which is that when something ships the reader can see it was the thing on the roadmap.
That sounds obvious and it's where most of the credibility is lost. An item called "better exports" ships as three separate improvements over two months, none of them announced, and the roadmap quietly moves it to done. From outside, nothing happened.
The fix is mechanical, not editorial. Tie the item to the release, and let shipping the item write the entry.
What the roadmap owes the backlog
An honest no.
Every roadmap decision is a decision against everything else, and the backlog is where everything else lives. If items never leave the backlog and never get declined, the backlog becomes a place requests go to be forgotten politely, and the people who filed them learn not to file again.
A declined item with a reason on it's worth more to the person who asked than an item that sits untouched for two years.
The theatre to leave out
The quarterly deck. A roadmap that exists as a slide reviewed in a meeting is a performance rather than an artefact. If the current version isn't the one the audience can reach, there's no roadmap.
Confidence percentages. A number attached to a guess to make it look measured.
Swimlanes for internal teams. The audience doesn't know which team is which and should not have to.
Anything labelled strategic. If the item can't be described in the words a customer would use, it's not ready to be on a page they read.
How do you do this without a tool?
A page with the ordered items, edited when something moves, and a changelog under it saying what shipped. The two together are the whole artefact.
The part you can't do with a document is the promotion decision, whether the thing is wanted by more than the person who asked. Without counts, that judgement is made by whoever was most recently in the room.
How does this product do it?
The five layers above are one board. Requests arrive in Suggested, get declined into Denied with the reason visible, or move through In Review and In Progress into Completed.
Each card carries its vote count, an effort estimate and a progress percentage, and can be tied to a named release so the changelog entry is written from the thing that shipped, not typed again.
The counts come from the people waiting, so the promotion decision has something behind it other than the loudest voice in the meeting.
The public roadmap page covers the board, and roadmap development covers the decisions in order.
14 days, a card at signup, then $9 or $39 a month.