Ask a product team how they prioritise, and you’ll often hear about a scoring framework with weighted columns for impact, effort, confidence, and reach — a spreadsheet elaborate enough to feel rigorous, and just complicated enough that everyone quietly overrides it whenever the numbers disagree with what they already wanted to build.
Complexity isn’t the same as rigor
A prioritisation framework’s job is to force an honest comparison between competing ideas. Once it gets complicated enough, it stops doing that — it becomes a way to justify a decision that’s already been made, dressed up in numbers that feel more objective than they are. That’s not a failure of the specific framework. It’s what happens to almost any scoring system once enough inputs get added to it.
A shorter version that still works
A simpler method holds up surprisingly well in practice: for each candidate feature, answer two questions honestly.
- What specifically breaks if we don’t build this? Not “it would be nice to have” — a concrete cost, complaint, or lost opportunity that’s actually happening right now.
- What’s the smallest version that addresses it? Not the fully-realised feature from the roadmap deck — the narrowest version that would genuinely fix the specific problem in question one.
Features where the answer to the first question is vague — “it would improve engagement,” “competitors have it” — usually don’t survive this filter, and that’s the point. Features tied to something concrete and currently happening tend to rise to the top without needing a spreadsheet to prove it.
Where this still needs judgment
This method won’t resolve genuine trade-offs between two well-justified features competing for the same engineering quarter — that still requires a judgment call, ideally made by someone accountable for the outcome. What it’s good for is clearing out the larger number of features that sound reasonable but aren’t actually solving a problem anyone currently has.
A shorter list, built from two honest questions, tends to produce a roadmap a team can actually defend — including to themselves, months later, when they’re asked why a particular feature made the cut.
