In most product teams, the backlog is a place where urgency goes to die. Everything that enters it was urgent when it was added — a customer complaint, a sales request, a competitor feature, an internal idea. Six months later, it's all still there, and it all still feels urgent, and nobody quite knows which thing to do next.
The problem is not a lack of tools. There are dozens of prioritisation frameworks: RICE, MoSCoW, Kano, ICE, weighted scoring. The problem is that most frameworks require a kind of false precision — assigning numbers to unknowns — that makes them feel rigorous while actually just laundering gut feel through a spreadsheet.
What actually works is simpler: two dimensions, honestly assessed, and the discipline to act on the result.
Prioritisation collapses to two questions. First: how much does this improve the outcome we care about? (Impact.) Second: how much will it cost us to deliver it? (Effort.) Everything else is either a refinement of these two or a distraction from them.
Confidence is sometimes added as a third dimension — "how certain are we about impact?" — and it's worth keeping in mind. But in practice, most teams know when they're guessing. The discipline is to label the guess honestly, not to score it on a 1–5 scale and add it to a formula.
The hard part is not understanding the grid — it's being honest when filling it in. Every team has features they want to build that belong in "Time Sinks" but keep getting reclassified as "Big Bets." The framework only works if the team can be honest about impact.
Impact is the dimension teams find hardest to assess, because it often requires predicting the future. The temptation is to score it numerically and feel scientific about it. A better approach is qualitative but structured.
Ask three questions for each feature under consideration:
Teams systematically underestimate effort. This is well documented — it's related to the planning fallacy and optimism bias — and it's particularly pronounced for features that touch multiple systems, require coordination across teams, or involve capabilities the team hasn't built before.
Two practices help. First, always ask engineering before scoring effort, not after. PMs who score effort unilaterally almost always underestimate. Second, use the concept of "unknown unknowns" as an explicit effort multiplier. Any feature that touches a new codebase area, a third-party API, or a user flow that hasn't been tested recently deserves an effort score 1.5x higher than the obvious work suggests.
Most of the urgency in a product backlog is not real urgency — it's recency. A customer complained last week, so their request feels pressing. A competitor launched something last month, so matching it feels critical. But recency is not the same as importance, and reacting to recency is one of the most reliable ways to let genuinely important work slip.
A practical test: ask yourself whether you'd still consider this urgent if you'd heard about it six months ago instead of last week. If the answer is no, it's recency bias at work, not strategic priority. Log it, evaluate it calmly against the grid, and resist the pull to fast-track it just because it's fresh.
The grid doesn't always produce a clean answer. Two items land in the same quadrant with similar scores, and you still have to choose one. In these cases, two tiebreakers are useful: strategic alignment (which one moves you closer to where you want to be in 18 months?) and reversibility (which one is harder to undo if it's wrong?). Prefer the item that's more strategically aligned and more reversible.