Every product management framework ever created is an attempt to make an inherently political decision look rational. RICE. MoSCoW. ICE. Kano. Value vs. Effort matrices. Impact/Effort grids. They’re all trying to answer the same unanswerable question: What should we work on next? And they’re all trying to answer it in a way that feels objective and defensible, rather than “I think this one matters more.”
The frameworks aren’t wrong to exist. But they’re easy to misuse, and most teams use them wrong.
Here’s the honest truth: Prioritisation is a judgment call. You’re weighing inputs that don’t have clean numerical values. You’re making a call about what the business needs, what the user needs, what the team can execute, and what will actually move the needle. There’s no formula for that. There’s just thinking clearly about the inputs and being willing to make a judgment.
The frameworks are useful for one thing: making the implicit explicit. If you just say “I think we should build this,” nobody knows what you’re actually weighing. But if you say “here are the options, here’s the impact each one would have, here’s the complexity, here’s the strategic value,” then people can understand your thinking and either agree with you or tell you you’re wrong about the facts.
Let me walk through the frameworks and when they’re actually useful.
RICE (Reach, Impact, Confidence, Effort) is useful when you want to force a conversation about what you actually know. What percentage of our users would this affect? How much would it change their experience — a little bit or a lot? How confident are we about that number? How much work would it be? If you apply this honestly, you notice that some features you thought were important don’t actually reach many people, or their impact is small. Some features that sound simple are actually uncertain. That’s valuable information.
The mistake people make with RICE is treating it like a scoring algorithm. They calculate RICE scores like it’s math, and then they build in numerical order. That’s missing the point. The point is to talk through the factors and notice what you actually believe about them.
MoSCoW (Must have, Should have, Could have, Won’t have) works when you need to have a conversation about what’s actually critical and what’s nice to have. It’s not a scoring system; it’s a categorisation. And the power of it is the “Won’t have” category. If you force yourself to write down what you’re deliberately not doing, you clarify your actual priorities. If everything is “Must have” or “Should have,” you haven’t prioritised anything.
Kano analysis — which puts features into categories of basic needs, performance needs, and delighters — is useful for understanding what you’re solving. A fitness app’s basic need is “it has workouts.” A performance need is “the workouts are well-designed and appropriate to my level.” A delighter is “there’s a coach who knows my history and gives me feedback.” Mixing these up is where you get products that are beautiful but don’t work, or that work but feel joyless.
Impact/Effort grids are useful for a specific conversation: “What could we do that would have high impact and be relatively easy?” This is helpful for finding quick wins, things that improve the product without eating up months of time. But treating them as the primary decision-making tool is a mistake, because easy things aren’t always important, and important things aren’t always easy.
The real conversation is about what moves the needle. Not what’s urgent, not what’s flashy, not what the CEO’s friend asked for. What actually moves the needle for the user and the business right now?
For a fitness app, that might be: “New users give up in the first week because they don’t know how to actually use the app.” That’s a needle-mover. If you fix that, you change retention, which changes everything. It might not be the most fun feature to build. It might be unglamorous — better onboarding, clearer instructions, one-on-one support for the first week. But it moves the needle.
Or it might be: “Users can’t find workouts appropriate to their level.” If you fix that, you fix the person who signs up for advanced yoga and gets frustrated, or the person who signs up for beginner and feels bored. That moves the needle.
Or it might be: “Coaches can’t see who’s doing the workouts they prescribe.” If you fix that, coaches can actually support their clients better, which builds loyalty and word-of-mouth. That moves the needle.
What doesn’t move the needle:
- Cosmetic changes nobody asked for
- Features that serve a small number of users very well while confusing everyone else
- Compliance or security requirements that don’t prevent actual harm
- Features that were on the roadmap six months ago but the world has changed
- Things you’re building because someone influential keeps asking about them
Here’s how I actually think about prioritisation:
First, I check: What are the constraints? Is there something we absolutely have to do — a security vulnerability, a compliance requirement, something that makes the product literally unusable? Do that first. You don’t get to choose to ignore genuine constraints.
Second, I look at the user problem. What are users actually struggling with? Not what they ask for, but what do our support tickets say? What do our user interviews reveal? What are the tasks that are taking people longer than they should, or are confusing, or are causing them to leave? Of those, what would help the most people?
Third, I look at the business problem. What’s blocking growth? What would unlock a new market? What’s keeping churn high? What would make us more defensible? Of the things that would help users, which ones also help the business?
Fourth, I look at the execution burden. Of the things that would help users and the business, which ones can we actually pull off? Some things are impossible because the architecture is wrong. Some are possible but would require rearchitecting. Some are straightforward. That’s not a reason to ignore the hard ones, but it’s real information about time investment.
And finally, I make a judgment call. Based on all of that, what moves the needle most? Usually the answer is obvious. Once in a while it’s genuinely unclear and I get to admit that and make a call I could defend multiple ways.
The frameworks are scaffolding. They help you think. They help you communicate. They help you make sure you’re not just going by vibes. But at the end of the day, somebody has to make a call. The best product teams I’ve worked with don’t treat frameworks like they’re laws. They use them like tools. They pick the one that’s useful for the conversation they need to have. They’re clear about what they’re assuming and what they’re uncertain about. And then they make the call and move forward.
If you can explain why you prioritised something, and you were considering the right factors, then even the people who disagree with your choice can usually live with it. What kills teams is prioritisation that’s unexplained or that seems arbitrary. What kills products is prioritisation that loses sight of what actually matters.
So yes, use a framework. But use it to think, not to avoid thinking. And at the end, be willing to say: “I think this matters most, and here’s why.”