The short version
- Seven steps, starting with everything anybody has already asked for, in their own words.
- Four requests for the same thing look small apart and significant together.
- Order by demand divided by effort, then override it deliberately and say so.
- A spreadsheet with five columns does all seven steps.
Most instructions for how to develop a roadmap for a project start with the timeline. Start with the input instead. You almost certainly already have more requests than you can build, and the roadmap is what comes out of sorting them rather than something you design first and fill in afterwards.
Seven steps below, in order, with the thing that goes wrong at each one.
Where do you start?
With everything anybody has already asked for, in one place, in their own words.
Not a workshop. Not a template. A single list, gathered from wherever the requests currently live, which is usually four places, an inbox, a support queue, a chat channel and somebody's notes from calls.
There's a board that has been through this if you want to see the output, 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.
The seven steps
| # | Step | What goes wrong |
|---|---|---|
| 1 | Gather every request into one list | Half of them live in one person's head and never arrive |
| 2 | Rewrite each as a situation with a cost | Skipped, and the list stays shaped by the senders' vocabulary |
| 3 | Merge the duplicates | Done badly, and the counts either split or double |
| 4 | Size each one roughly | Done precisely, which wastes a day and changes nothing |
| 5 | Order by demand against effort | Done by argument, and the loudest person wins |
| 6 | Decide the cut line, and decline what is below it | Skipped, so nothing is ever refused |
| 7 | Publish, with states and a last changed date | Published once and never updated |
1. gather
Go to each place requests currently arrive and copy everything out, in the sender's words, with who sent it and when.
The step that's actually hard here's the fourth place, the notes from calls. Those requests are the ones from your largest accounts, and they're the ones most likely to be missing entirely because nobody wrote them down at the time.
2. rewrite
Each request becomes one sentence naming who, in what situation, at what cost.
"Add filters" becomes "checking one client's requests means reading the whole list, which is why the weekly review takes an hour". Now two people can agree or disagree with it, and step three becomes possible.
This is the step most often skipped and the one that decides whether any of the later steps work.
3. merge
Four requests for the same thing look small separately and significant together.
The mechanical question is what happens to the counts. Adding them together double counts anybody who asked twice. The version that stays honest removes the duplicate person's second vote and recounts from the underlying rows, so a merged item's count is distinct people.
4. size
Rough, from one scale, applied to everything. Small, medium, large is enough.
Don't estimate in days. Days become dates, dates reach the public page, and a public date is a commitment made before the work is understood. The size exists only so that step five means something.
5. order
Demand divided by effort, then override it deliberately.
The mechanical ranking isn't the answer. It's a starting position that nobody has to defend socially, which turns the conversation from "what should we do" into "what should we move, and why". That's a much shorter meeting and it leaves a record.
6. decide the cut line
Draw a line. Everything above it's the roadmap. Everything below it's either the queue or a decline.
The decline is the step that gets skipped, and skipping it's why backlogs grow forever. A request that won't be built should be said to have been refused, with one sentence of reason, where the person who asked can see it.
7. publish
States, order, the declined section, and the date it was last changed.
Then make the update a side effect of something that already happens. If moving an item to done is how the release note gets written, the roadmap stays current without anybody remembering to maintain it.
What to do when the requests disagree with the plan
They will. You had a plan before you sorted the input, and the input will rank something else first.
Three cases, and they need different answers.
The requests are right and the plan was a guess. Change the plan. This is the common case and it's the reason to do the sorting at all.
The plan is right and the requests are a sampling artefact. Check who is asking before concluding this. If the loud requests come from small accounts and the quiet ones from large accounts, the count is measuring availability rather than value, and reading it by revenue rather than headcount changes the answer.
The plan is right for a reason the requests can't see. A contractual obligation, a dependency, a thing that has to exist before three other things. Do it, and say on the roadmap that it's next, without pretending it came from demand.
What not to do is run the sorting and then quietly ignore it. The exercise is only worth the day it takes if the result can change the plan.
How do you do this without a tool?
A spreadsheet with five columns, being the request as written, the rewritten situation, who asked, a size, and a state. Merge by hand. Publish the top dozen to a page.
Every step works except the counts, which stay your own estimate of demand, because the people who would agree with a request can't see it.
How does this product do it?
Requests arrive on a board, with the people who asked attached to them. Merging removes the duplicate voter's second vote and recounts from the rows.
Each card carries an effort estimate and a demand score, and the board can be ordered by the priority the two produce. The weighted count reads the revenue behind the voters, so the sampling question in the second case above is answerable, not arguable.
Denied is one of the five default columns, so the cut line produces published refusals with their reasons, not silent deletions.
The public roadmap page covers the board, and roadmap development covers the same ground as a set of decisions rather than as steps.
What a roadmap should include covers what belongs on the page once it exists.
14 days, a card at signup, then $9 or $39 a month.
