Hello!
We are back, and this month I am making the case that prioritisation is a conversation rather than a scoring exercise, which is my long way of admitting I still do not like RICE. Plus a couple of reads worth your time and a new set of product roles below.
Have a read and tell me if you agree!
š Prioritisation Is a Conversation, Not a Score
I donāt like RICE.
Iāve said as much in conversations with other product people, and itās a view that has not changed over the years Iāve spent watching teams try to make it work.
It has become the default prioritisation model in a lot of product organisations, reached for almost automatically whenever the question of what to build next comes up, and I think that reflexive adoption is the problem more than the model itself.
The appeal is pretty obvious; RICE allows you to simply apply assign numbers to Reach, Impact, Confidence and Effort, and a spreadsheet of numbers feels like objectivity. But each of those inputs is a judgement dressed up as a measurement, and once you accept that, the illusion of accuracy falls apart.
A confident voice in the room can nudge a score just enough to float a preferred idea to the top, and because the maths looks rigorous, nobody has much to push back with.
The subjectivity varies wildly across an organisation too, so the same idea scored by two teams produces two different answers, and neither is more correct than the other. What the model tends to ignore is exactly the context that matters most, situational and market factors, internal dependencies, and the longer arc of customer value, all of which get flattened into short-term thinking.
In practice Iāve watched RICE exercises resolve into one of two outcomes.
Either the ordered list comes out roughly matching what the team already believed, which makes the whole exercise redundant, or it throws up something unexpected that then gets quietly reshuffled to suit stakeholder preference, with little evidence to defend the original ordering.
Both are a waste of time and energy, and both leave the team with a rearranged spreadsheet rather than the shared understanding they actually needed.
A few years ago I spoke with one of the people involved in creating RICE, and he told me they never really used it themselves because it had too many limitations in practice. That stuck with me because, much like the Spotify model, RICE has become something teams use because they feel theyāre supposed to, not because it helps them make better decisions.
The distinction Iād draw is between having a framework and having a conversation.
Prioritisation is not really a scoring problem, itās a storytelling problem, and the value lies in the quality of the ongoing conversation rather than in the final ordered list.
What you want is the ability to defend a decision across the dimensions that matter, customer value, business impact, technical effort and time to value, and to keep moving between those as context shifts.
A number gives you a snapshot in time. It doesnāt give you the detail to have a proper discussion about how long something takes to build, how long it takes to reach the market, and therefore how long before it returns any value at all.
This is where the model fails us. You can have an experiment that is designed and built inside a single sprint but takes six months to deliver value, and another that takes two or three sprints to build but delivers value within a week.
RICE has no real way of surfacing that trade-off, and it certainly doesnāt help a group collaborate on the decision.
Iāve come to prefer working through value and impact, then effort, then time to value as separate layered conversations, because it forces the team to negotiate together rather than defer to a formula.
Iād add one nuance from a recent coaching conversation, because it reframed something for me personally.
A coachee had been told by a senior leader that speed mattered most, and had led with ātime savedā as their headline. The leader then corrected the emphasis, saying that decision quality was actually more important because time is a byproduct of it. I think thatās exactly right. When you make good decisions, they are both effective and efficient, and the time element takes care of itself. That is a more honest thing to optimise for than raw speed, and itās a better argument to take to leadership than a prioritised list nobody quite trusts.
None of this means teams have to prioritise in the same way. What matters is whether they can roll their decisions up into a shared view that leadership can read, so the reasoning behind a call is visible even when the method underneath differs.
If a team canāt defend or negotiate their choices, thatās the real gap, not the absence of a particular framework.
How are you handling strategic prioritisation on your teams at the moment, and where has your current approach let you down?
Article by Chris Compston
š From the Reading List
This doesnāt seem like the best ideaā¦ growing human neurons on a chip to play Doom is wild. Iām wonder what the real medical use might be for this research.
The argument that feels right to me is āsit with the complexity instead of rushing to fix itā, and it helps to deal with the usual diversity-training clichĆ©s. My one worry is that āstay with uncertaintyā can become an excuse for leaders to never actually decide anything. Worth reading though.
š©š½āš Product Careers
New roles at Kraken, Compare the Market, GitLab and more ā¦
Chief Operating Officer / Product Operations Lead / Product Ops Lead / Senior Manager - Product Operations / Product Director, Service Operations / Chief Operating Officer / Director - Product Management / AI Transformation Owner / Strategy & Operations Manager / Product Operations Manager