In short
Prioritisation works when items are compared against each other rather than scored in isolation. Frameworks assigning numeric values to value and effort mostly launder opinion into arithmetic. The more useful discipline is a short ordered list, a much larger unordered pool, and a willingness to delete — because an item nobody will do this year is noise, not a plan.
Why the frameworks disappoint
Most scoring frameworks ask you to rate value, effort, reach and confidence, then multiply.
The arithmetic is sound. The inputs are guesses. Multiplying four estimates produces a precise-looking number carrying all the uncertainty of its worst input, and the precision is persuasive in a way it has not earned.
They are useful for one thing: forcing a conversation about why people disagree. When two people score the same item very differently, the discussion that follows is the actual value — not the number.
So use them as a prompt, not as an oracle.
Compare, do not score
People are unreliable at assigning absolute values and much better at comparing two things.
"Is this more important than that?" produces more consistent answers than "rate this out of ten." Building an order through pairwise comparison is slower but the result holds up, because each decision was made against a real alternative rather than an abstraction.
The practical version: take the top ten candidates and sort them by repeatedly asking which of two you would do first. You will find the order faster than expected, and the disagreements surface where they matter.
Separate the ordered list from the pool
A backlog with two hundred items in priority order is fiction. Nobody has genuinely compared item 140 with item 141.
What works is two things:
A short ordered list — the next five to fifteen items, genuinely sequenced, that you intend to do.
An unordered pool — everything else, unsorted, unestimated, uncommitted.
Items move from the pool into the list when they become relevant. The pool never needs sorting, which removes a large recurring cost that produced nothing.
Ask what happens if you never do it
The most clarifying question available.
For most backlog items, the honest answer is nothing much. Someone asked for it once, it seemed reasonable, and it entered the list without anyone deciding it mattered.
Items where the answer is nothing should be deleted, not deprioritised. Keeping them costs attention every time anyone reviews the backlog, and it makes the list feel like an obligation rather than a plan.
Deleting is a decision. A backlog nobody deletes from becomes a graveyard, and a graveyard is where genuinely important items go to be lost among the rest.
What actually deserves to be near the top
Things that are breaking. Correctness and reliability problems compound and erode trust.
Things blocking other things. An item unblocking three others is worth more than its own value.
Things that get harder later. Schema decisions, URL structures, anything that accumulates data shaped by it. These are cheap now and expensive after.
Things with a real deadline — a legal requirement, a contractual commitment, an external date.
Things you will learn from. When you are uncertain, doing the small version of something teaches you more than more discussion.
What rarely deserves the top: the loudest request, the newest idea, and the thing that is easiest to build. Ease is a tiebreaker between comparable items, not a reason on its own.
Handle requests honestly
Backlogs bloat because "we'll add it to the backlog" is a comfortable way to avoid saying no.
It is not kinder. The person believes it is coming, waits, and eventually concludes you were not straight with them. A clear no, with a reason, preserves the relationship better than an indefinite maybe.
When you do add something, be honest about where it sits. "This is in the pool, and realistically we will not get to it this year" is information someone can act on — they can escalate, find another route, or drop it.
Review it rarely, but properly
Monthly is enough for most teams. More often and you spend more time discussing work than doing it.
At each review: confirm the ordered list still reflects reality, promote anything that has become urgent, and delete aggressively. Anything deferred three times should be removed rather than moved again — three deferrals is the list telling you something.
And record why items were rejected, briefly. Otherwise the same idea returns every few months and gets discussed from scratch, which is one of the more avoidable recurring costs in a product team.
The measure
A backlog is working when you can answer "what are we doing next and why" in one sentence, and when nothing important is buried.
If the answer requires opening a tool and scrolling, the list is doing you no good — however carefully everything in it was scored.
If you are running a product with more requests than capacity and want an outside view on the order, book a call.
Common questions
What is the best way to prioritise a backlog?
Compare items against each other rather than scoring them in isolation, since people are far more reliable at saying which of two things matters more than at rating something out of ten. Keep a short genuinely ordered list of the next several items and leave everything else in an unsorted pool.
Are prioritisation frameworks like RICE useful?
Mainly as a prompt for discussion. Multiplying several estimates produces a precise-looking number that carries all the uncertainty of its worst input, so the arithmetic launders opinion. The genuine value appears when two people score the same item very differently and have to explain why.
How big should a backlog be?
The ordered part should be five to fifteen items you actually intend to do. Everything else belongs in an unordered pool — a two-hundred-item list in priority order is fiction, because nobody has genuinely compared item 140 with item 141.
When should you delete something from the backlog?
When the honest answer to 'what happens if we never do this' is 'nothing much', and whenever an item has been deferred three times. Keeping such items costs attention at every review and buries the things that matter. Deleting is a decision, not a failure.
How should I respond to requests I won't build?
Say so clearly, with a reason. 'We'll add it to the backlog' is a comfortable way of avoiding no, but it leaves the person waiting for something that is not coming — which damages the relationship more than a straight answer would. If you do add it, say honestly where it sits.
