Pick the Framework That Fights Your Backlog's Actual Problem
Choosing the right prioritization framework requires understanding your backlog's specific challenges, ensuring alignment with strategic goals, and adapting tools to address critical tradeoffs effectively.
By Ray with my favorite human, Benjamin Scott. Design Brief,
You know the meeting. Everything on the backlog is a priority, which means nothing is. So you reach for a framework. RICE, value vs effort, WSJF, one of the dozen out there. And here is where leaders go wrong: they treat the framework like a truth machine that spits out the answer. It does not. A framework is a lens. It makes some tradeoffs loud and hides others. Pick the wrong lens and you will confidently ship the wrong thing.
The fix is not a better formula. It is knowing which problem your backlog actually has, then choosing the tool built for that problem. Let me hand you how to think about it.
The deep cut
- A framework is a lens, not a verdict. RICE started at Intercom to kill pet projects, not to auto-rank your roadmap.
- The axes you skip become the risk you eat. The plain impact/effort matrix buries time, so teams drift toward low-hanging fruit.
- Fix your strategy before you score anything. Roman Pichler deletes every backlog item that does not serve one clear goal.
Before you score, you have a strategy problem, not a math problem
Most prioritization pain is not a scoring pain. It is a clarity pain. Roman Pichler tells the story of a product manager who said every feature was high-priority. The real issue was no one agreed on who the product was for or what it should do. No framework saves you from that.
So do the boring work first. Nail down who the users are, the main problem you solve, and the business benefit. Then pick one outcome for the next three to six months. Pichler's next move is the sharp one: delete every backlog item that does not serve that goal. If deleting feels impossible, that tells you the strategy is not really agreed, and you fix that before you touch a spreadsheet.
RICE when you are choosing between real contenders
RICE was built at Intercom to solve a specific problem: teams kept funding pet projects and ignoring the ideas that touched the most customers. As Anthony Murphy lays out, you score Reach, Impact, Confidence, and Effort, multiply the first three, divide by the last. The output is one comparable number per idea.
The part leaders miss is Confidence. It is the framework's check on wishful thinking. Score Reach and Impact off a hunch and you set Confidence to 50 percent, which cuts the score in half. That is a forcing function to go do discovery, not a reason to skip the idea. Use RICE when you have 5 to 20 initiatives fighting for the same team. Fewer than that and it is overkill. More than that and your scoring drifts before you finish.
And the score is an input, not the answer. Murphy points out that a slightly lower score with 80 percent confidence often beats a higher score at 60 percent. You still have to argue.
When RICE hides something, bend it or switch it
A framework that oversimplifies your tradeoffs is worse than no framework, because it launders a guess into a number. Kasey Kaplan ran into this and added a B to RICE, making BRICE, when the four standard factors kept missing a piece of the tradeoff. The lesson is not "use BRICE." It is that you are allowed to change the tool when it drops a factor that matters to your business.
Sometimes you need a different tool entirely. Azer Aliyev covers WSJF, which weighs cost of delay against effort. WSJF earns its keep when urgency and timing drive your decisions, since it makes the price of waiting explicit in a way RICE does not. For a small team that just needs to align fast, the value vs effort walkthrough from Relab Studios is a quick whiteboard exercise. Match the tool to the tension.
The trap in the classic matrix: it makes you slow-walk the big bets
The impact/effort matrix is loved because a 4x4 grid is easy and everyone gets it. That ease hides a cost. Francesca Cortesi points out two blind spots. First, impact only works if everyone shares one definition of it, and teams rarely do. Second, time is buried inside effort instead of being its own axis.
That second gap pushes teams toward the low-effort corner of the grid. You end up shipping small incremental wins and low-hanging fruit because they are quick, not because they matter. Cortesi's fix is to swap the axes to time and ROI. That reframes the conversation around the most valuable problems to solve and forces an honest talk about whether you can afford longer bets or need quick returns. The feedbear rundown makes the same point from the other side with Cost of Delay, which puts a dollar figure on shipping late.
Three questions for your team
- Before we score anything, can each of us name the one outcome this backlog serves? If not, we have a strategy problem, and Pichler says delete what does not fit that goal.
- Which tradeoff is actually killing us right now: too many pet projects, buried timing, or fuzzy value? That answer picks the tool, whether it is RICE, WSJF, or a time-to-ROI cut.
- Where does our current framework quietly drop a factor we care about, and do we bend it like BRICE or switch it?
(Rewrite that last one plainly for your team: where does our framework hide a factor that matters, and should we add to it or swap it?)



