The short version
- Seven decisions, each with a default that happens when nobody decides.
- The default for order is recency, which is how a roadmap ends up reflecting the last three conversations.
- The default for updates is when somebody remembers, which is never after the second month.
- Starting with the roadmap is the mistake. The roadmap is an output.
Roadmap development is usually described as a process with phases. It's more useful as a sequence of seven decisions, because the phases are where the calendar goes and the decisions are where the roadmap actually comes from.
Each decision below has a default. The default is what happens if nobody decides, and the default is wrong about half the time, which is the whole reason to write them down.
What is roadmap development?
The work of turning what people have asked for into an ordered, published list, and keeping it current.
Two thirds of that is the turning. The publishing is a text file. The keeping current is a habit. The hard part is the middle, and the middle is seven decisions.
There's a board that has been through all seven 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 decisions
| # | The decision | The default if nobody decides |
|---|---|---|
| 1 | Where input comes from | Whoever emails you |
| 2 | What counts as one item | Whatever the sender wrote |
| 3 | How duplicates are merged | They are not, and the count splits |
| 4 | How size is estimated | Guessed in the meeting, by the loudest estimate |
| 5 | How order is decided | By who asked most recently |
| 6 | What is published and what is not | Everything, or nothing |
| 7 | When it is updated | When somebody remembers |
1. where input comes from
The default is whoever emails you, and the default is a sampling problem. The people who email are the confident ones, which isn't the same set as the people who matter.
The decision is whether there's a place anybody can reach without being invited. If there is, the input includes the people who would never have written to you directly, and those are the ones whose leaving you wouldn't have seen coming.
2. what counts as one item
The default is that the item is whatever the sender wrote, which means your list is shaped by their vocabulary rather than by your product.
The decision is to rewrite each request as one situation with one cost. "Add filters" isn't an item. "The list can't be narrowed to one account, so checking a client's requests means reading all of them" is, because two people can now agree or disagree with it.
This is the most under rated step in the entire sequence. It's also the one that makes step three possible, because you can't merge duplicates you can't recognise.
3. how duplicates are merged
The default is that nothing is merged, four requests for the same thing sit separately, and each looks small.
The decision is what happens to the votes when you merge. If merging adds two counts together, somebody who asked twice counts twice.
The version that stays honest deletes the duplicate voter's second vote before the move and recounts from the rows, so a merged item's count is the number of distinct people, not the number of clicks.
4. how size is estimated
The default is a number said aloud in a meeting by whoever speaks first, and everyone anchoring to it.
The decision is what the size is for. It's so that ordering means something, not so that a schedule exists, because ordering by demand alone puts the largest request first every time. A rough size on every item, from the same scale, is enough. Precision here buys nothing.
5. how order is decided
The default is recency, which is how a roadmap ends up reflecting the last three conversations.
The two inputs worth having are demand and size, and the useful ordering is the one that puts the most demand for the least effort first. That ranking is mechanical, which is its advantage. It produces an order nobody has to defend socially, and then you override it deliberately where you've a reason.
The overriding is the point, not a failure. A mechanical order gives you something to argue against, which is better than arguing in the abstract.
6. what is published and what is not
The default is either everything, which makes the roadmap a backlog nobody can read, or nothing, which makes it a rumour.
The decision worth making is that declines are published too. A request that won't be built, with one sentence saying why, is more useful to the person who asked than silence, and it's the cheapest credibility a roadmap can buy.
7. when it is updated
The default is when somebody remembers, which is never after the second month.
The decision is to attach the update to something that already happens. If moving an item to done is how the release note gets written, the roadmap updates itself as a side effect of shipping, which is the only version that survives a busy quarter.
The mistakes
Starting with the roadmap. The roadmap is an output. Starting there means the items come from the room rather than from the input.
Estimating in days. Days turn into dates, and dates on a public page are a commitment made before the work is understood.
One person holding the merge knowledge. If only one person can tell that two requests are the same thing, the count is only right while they're there.
Publishing without declines. Then the roadmap is a list of successes and readers discount it accordingly.
How do you do this without a tool?
Seven decisions and one document of four columns, being the request as written, the rewritten situation, a rough size, and a state. Merge by hand and write the decline reasons in the same file.
It works. What it can't do is the counting, because the people who would agree with a request can't see it. Every number in your document is your own estimate of demand.
How does this product do it?
Requests arrive on a public board and nothing a visitor writes appears publicly until somebody approves it. Merging deletes the duplicate voter's second vote before the move and recounts from the rows, so a merged count is distinct people.
Each card carries an effort estimate and a demand score, and the board can be ordered by the priority the two produce.
Denied is one of the five default columns, not a deletion, so declines are published with their reason. Completing an item can write the changelog entry for the release it belongs to.
The public roadmap page covers the board, and how to develop a roadmap for a project runs the same seven decisions on a single project, not a product.
What makes a roadmap good covers the tests the finished page has to pass.
14 days, a card at signup, then $9 or $39 a month.
