The default, and why it fails
With no method, priority goes to whatever was mentioned most recently, most loudly, or by the largest customer. Each of those is a real signal and none of them is a good ordering, because they measure who is talking rather than what matters.
- Recency — the last conversation dominates, which makes the roadmap a function of your calendar
- Volume — one insistent customer outweighs twelve quiet ones with the same need
- Account size — reasonable, and it slowly turns a product into one customer's custom software
- Interest — you build what's fun, which is usually not what's blocking anyone
Frameworks, and what they hide
Scoring frameworks are useful for structuring a conversation and dangerous when treated as arithmetic. Every one of them turns estimates into a number, and the number then looks more objective than the estimates were.
| Framework | Structure | What it hides |
|---|---|---|
| RICE | Reach × Impact × Confidence ÷ Effort | Impact is a guess; multiplying guesses compounds them |
| Value vs effort | Two axes, four quadrants | Ignores strategy — some low-value work is required |
| MoSCoW | Must / Should / Could / Won't | Everything becomes a Must under pressure |
| Cost of delay | What waiting costs per week | Hard to estimate honestly for anything non-obvious |
Five questions that do most of the work
- How many people asked for this unprompted?Unprompted is the key word. Anything you asked about will be endorsed.
- What happens if we don't build it?Churn, lost deals, or mild disappointment. These are very different answers.
- Does it serve the users we're keeping, or the ones we're chasing?Before product-market fit, serve the ones who stayed.
- What does it cost after it ships?Support, maintenance, and the constraint it places on future changes.
- What does it prevent us from building?The real cost of any decision is the alternative, and this is the question most often skipped.
The cost after it ships
Prioritisation usually estimates build effort and stops there. Build effort is a one-time cost; everything after is permanent.
- Every feature is a surface to support, document, and explain
- Every feature is a constraint on future changes — someone depends on it now
- Every feature makes the product slightly harder to learn, for everyone, forever
- Features are far harder to remove than to add, because removal is visible and addition isn't
Keep a public list of what you're not building
A roadmap says what's coming. The more useful document says what isn't, and why. It stops people waiting for something that will never arrive, and it stops the same request being re-litigated every quarter.
- Write the reason, not just the decision — "not now, because it serves prospects rather than current users"
- Include the condition that would change the answer, if there is one
- Share it with customers who ask. Most people accept a clear no far better than a vague maybe
- Review it twice a year — some entries will have become obvious yeses
Common mistakes
- Letting the most recent conversation set the order
- Treating a framework's output number as objective
- Estimating build cost and ignoring permanent maintenance cost
- Building for prospects while current users churn
- Answering every request with "maybe later", so nothing is ever really declined
Key takeaways
- Recency, volume, account size, and interest are the defaults, and all four are poor orderings
- Frameworks structure the argument; they don't produce the answer
- Unprompted demand and the cost of not building are the two highest-signal questions
- The cost of a feature is mostly what it costs after it ships
Try it yourself
Take your current backlog and add one column: what this prevents us from building. Fill it in for the top five. The ordering usually changes, and the reason becomes explainable to anyone who asks.