Every few months I get a message from a product leader that goes something like this:
“We just moved from RICE to WSJF. We’re hoping this will finally get the team aligned on what to build.”
My response is always the same: it won’t.
Not because WSJF is wrong — it’s a perfectly reasonable framework. But because the framework is being asked to solve a problem it fundamentally cannot solve.
Prioritisation frameworks are decision-making tools. They help you weigh factors consistently, surface trade-offs, and communicate decisions in a structured way. What they cannot do is fix the upstream problems that cause the wrong things to get built in the first place.
In almost every tech team I’ve worked with across 18 years, the problem is upstream.
“Switching prioritisation frameworks is the product equivalent of rearranging deck chairs. The ship is still going in the wrong direction — you’ve just made it tidier on the way there.”
The Four Real Reasons Tech Teams Build the Wrong Things
Before switching to another framework, look at which of these four problems your team actually has. Any one of them will make any framework fail. All four together is a crisis.
1. The Strategy Is Unclear — So Everything Is Equally Important
Prioritisation only works when you have a clear lens to prioritise against.
If your product strategy is:
Grow revenue
Improve retention
Expand internationally
…then you have three potentially competing objectives with no indication of which takes precedence right now.
When everything is a priority, the loudest stakeholder wins.
The framework simply provides language to justify the decision afterwards.
2. The Data Doesn’t Exist — So Scores Are Fiction Dressed as Rigour
RICE asks teams to score Reach, Impact, Confidence, and Effort.
Most teams have reasonable data for Reach.
Impact and Confidence are usually guesses disguised as numbers.
A feature gets an 8/10 Impact score because Sales says a major customer wants it.
A feature gets a 3/10 Confidence score because the engineer looked uncomfortable during planning.
The framework gives an illusion of objectivity while decisions remain subjective.
3. The HiPPO Problem Is Structural, Not Cultural
HiPPO stands for Highest-Paid Person’s Opinion.
Most organisations recognise the problem.
Few solve it.
If the CEO can override prioritisation decisions at any moment, the prioritisation process is theatre.
The team spends weeks scoring initiatives only to watch leadership reorder the roadmap in a single meeting.
The framework didn’t fail.
Governance failed.
4. Discovery Is Disconnected From Delivery
Teams often build the wrong thing because they never validated the problem in the first place.
Discovery and delivery run in separate tracks.
Engineering starts building.
User research happens later.
Research discovers customers don’t actually want the feature.
Engineering is already halfway through implementation.
The prioritisation decision was made before sufficient evidence existed.
No framework can compensate for poor inputs.
What Actually Fixes Each Problem
Fix #1: Write a One-Page Product Strategy Before Touching the Backlog
Your strategy should answer four questions:
Who is our primary customer right now?
What job are we helping them do better than anyone else?
What does success look like in 12 months?
What are we explicitly not doing this year?
The fourth question matters most.
A strategy without constraints is simply a wish list.
Fix #2: Replace Confidence Scores with Assumption Mapping
Instead of asking:
“How confident are we?”
Ask:
“What assumptions are we making, and which ones would kill this initiative if they’re wrong?”
Map assumptions across three areas:
Desirability: Will users actually want it?
Feasibility: Can we build it successfully?
Viability: Will it generate business value?
Before prioritising any feature, ask:
What must be true for users to want this?
What must be true for us to build it successfully?
What must be true for it to create the desired business outcome?
If we’re wrong, what have we wasted?
That final question is your real confidence score.
Fix #3: Define Decision Rights Clearly
The most important prioritisation discussion isn’t about frameworks.
It’s about governance.
Document:
What PMs can decide independently
What requires leadership approval
What requires CEO involvement
What circumstances justify overrides
When overrides happen, record:
The request
The trade-offs
The decision-maker
Transparency creates accountability.
Fix #4: Make Discovery a Prerequisite for Delivery
Before any feature enters sprint planning, the team should have evidence-based answers to:
Do users genuinely have this problem?
Do we have reason to believe this solution will solve it?
If either answer is uncertain, the initiative returns to discovery.
That requires discipline.
And leadership.
Not another framework.
A Four-Week Plan to Fix a Broken Prioritisation Process
Week 1: Audit the Last Six Months
Create a simple table:
Feature
Requestor
Expected outcome
Actual outcome
Patterns emerge quickly.
You’ll discover who is really driving roadmap decisions and whether those decisions work.
Week 2: Create a One-Page Strategy
Answer the four strategy questions.
Get leadership alignment.
If leadership can’t agree, you’ve identified the root cause of your prioritisation challenges.
Week 3: Run Assumption Mapping
Take the top five backlog items and identify:
Desirability assumptions
Feasibility assumptions
Viability assumptions
Features built on untested assumptions return to discovery.
Week 4: Document Decision Rights
Create a one-page governance document.
Clarify:
Who decides what
Who can override decisions
How trade-offs are documented
Publish it and review it quarterly.
The Frameworks Are Fine
This isn’t an argument against RICE, WSJF, Kano, or any other prioritisation method.
Frameworks are useful.
Use them.
But use them for what they’re designed to do:
Organise thinking, not replace it.
The real work happens upstream:
Strategy
Evidence
Governance
Connected discovery
Get those four things right and most frameworks will work reasonably well.
Get them wrong and no framework will save you.
You’ll simply end up with a better-organised backlog full of the wrong things.
The process was never the problem.
The process was simply the easiest thing to change.
