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 prioritisation frameworks like WSJF are 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. If your organization struggles here, establishing a robust product strategy consulting framework is often the missing foundational step.
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. To see how aligning executive vision transforms your roadmap, explore our approach to AI-ready execution and SaaS consulting.
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 it, for you to build it successfully, and 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, and 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 whether users genuinely have this problem and if there is reason to believe the solution will solve it. If either answer is uncertain, the initiative returns to discovery. That requires discipline, leadership, and not another framework.
A Four-Week Plan to Fix a Broken Prioritisation Process
Week 1: Audit the Last Six Months — Create a simple table tracking Feature, Requestor, Expected outcome, and Actual outcome. Patterns emerge quickly to show who is really driving roadmap decisions.
Week 2: Create a One-Page Strategy — Answer the four strategy questions and 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, Feasibility, and Viability assumptions. Features built on untested assumptions return to discovery.
Week 4: Document Decision Rights — Create a one-page governance document clarifying who decides what, who can override decisions, and 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.
