Every organization eventually invents a way to decide what matters most.
RICE.
ICE.
MoSCoW.
Value-versus-effort matrices.
Weighted scoring.
Quarterly planning.
Backlogs ranked from P0 downward.
The names differ, but the promise is similar: compare competing work, identify what matters most, and focus resources accordingly.
Then reality hits the backlog.
The P0 feature depends on infrastructure ranked P3.
A production incident consumes the engineers assigned to the roadmap.
A customer escalation creates work that didn’t exist during planning.
The top initiative requires a specialist already committed elsewhere.
An architectural assumption turns out to be wrong.
The priority hasn’t necessarily changed.
The conditions required to execute it have.
That distinction explains why prioritization so often fails in practice.
Prioritization frameworks fail when we ask a ranking system to solve an execution problem.
A framework can help decide what appears valuable.
It cannot make capacity appear, remove dependencies, sequence work across teams, resolve competing incentives, or prevent new information from arriving during execution.
A ranked list is useful.
It just isn’t an execution plan.
What Is Prioritization?
Prioritization is the process of deciding which work should receive attention and resources before other work.
That sounds simple until several things matter simultaneously.
A product team may need to choose between:
- a feature expected to increase conversion
- a reliability improvement
- a regulatory requirement
- technical debt slowing future development
- a request from an important customer
Each creates a different kind of value.
Prioritization frameworks provide a structured way to compare them.
RICE
RICE typically considers:
Reach
×
Impact
×
Confidence
÷
EffortIt attempts to favour work that affects more people, creates greater impact, has stronger supporting evidence, and requires less effort.
ICE
ICE uses a simpler combination of:
Impact
Confidence
EaseAgain, the purpose is comparison.
MoSCoW
MoSCoW places requirements into categories:
Must Have
Should Have
Could Have
Won't HaveRather than estimating a universal value score, it forces discussion about necessity.
Value-versus-effort
A value-versus-effort matrix asks a simpler question:
High Value
Low Effort
│
▼
Potentially attractive workNone of these ideas is inherently broken.
They force assumptions into the open.
They make people explain why something matters.
They create a common vocabulary for comparing options.
They can expose a project that consumes enormous effort for very little expected benefit.
The problem begins when the resulting ranking is treated as though the hard part is finished.
It isn’t.
A Priority Is Not an Execution Plan
Suppose a team evaluates five initiatives and concludes that Feature A is clearly the most valuable.
The framework has done its job.
Candidate Work
│
▼
Prioritization Framework
│
▼
1. Feature A
2. Feature B
3. Reliability Work
4. Infrastructure Upgrade
5. Feature CNow the organization tries to execute Feature A.
Design needs another two weeks.
Frontend development depends on the design.
Backend development can start, but one required API depends on the infrastructure upgrade ranked fourth.
The database change requires review from a specialist working on Feature B.
QA capacity is already committed to a release from another team.
Suddenly the actual execution model looks like this:
FEATURE A
│
┌────────┼────────┐
▼ ▼ ▼
Design Backend Frontend
│
▼
Infrastructure
│
▼
Specialist Review
Meanwhile:
QA ───────► Other ReleaseFeature A remains the highest priority.
It still can’t move.
This is where organizations often make the wrong diagnosis.
They conclude that priorities aren’t sufficiently aligned.
So they hold another planning meeting.
The real problem is that importance doesn’t determine executable sequence.
Dependencies do.
Ranking and Sequencing Are Different Problems
Imagine three pieces of work:
A = Highest business value
B = Medium business value
C = Low business valueThe obvious ranking is:
A
↓
B
↓
CBut suppose A depends on B, and B depends on C.
The executable sequence is:
C
↓
B
↓
ANow the lowest-ranked work has to happen first.
That doesn’t mean the prioritization was wrong.
It means ranking answered a different question.
PRIORITIZATION
"What matters most?"
│
▼
Ranking
SEQUENCING
"What must happen first?"
│
▼
Execution orderConfusing those questions creates endless arguments about why lower-priority work is being done while higher-priority work remains blocked.
Sometimes doing the lower-priority work is how the higher-priority work gets delivered.
Dependencies Turn Prioritization Into Coordination
This becomes harder as organizations grow.
A single team with few external dependencies can often prioritize effectively.
The people deciding the work are close to the people executing it.
They share context.
They understand their capacity.
They can change direction quickly.
Now distribute the work across six teams.
The top initiative needs:
Product
│
├── Design
│
├── Application Team
│
├── Platform Team
│
├── Data Team
│
└── SecurityEach team has its own responsibilities.
And its own urgent work.
The application team sees the initiative as P0.
The platform team has a reliability problem it considers P0.
Security has a compliance deadline.
Data has committed to another strategic initiative.
Every team can be correctly following its own priorities while the organization still fails to deliver its highest-priority outcome.
That’s not primarily a ranking failure.
It’s a coordination failure.
The organization has created work whose delivery depends on several independently constrained systems.
No RICE score can remove that dependency.
Local Priorities Don’t Automatically Produce Global Priority
This is one of the hardest scaling problems.
Teams need local autonomy.
They understand their systems better than senior leadership does.
They need enough authority to handle operational issues, maintenance, technical risk and local customer needs without escalating every decision.
But the organization needs outcomes that cross those boundaries.
Those two requirements can conflict.
Consider an infrastructure team.
Its local priority is replacing a fragile deployment system.
The work would reduce incidents and make future releases easier.
A product team needs the same engineers to support a major customer launch.
From the product team’s perspective, the launch is clearly more important.
From the infrastructure team’s perspective, delaying the deployment work increases operational risk and makes every future launch harder.
Which is the higher priority?
A scoring framework can assign numbers.
It cannot decide what the organization values more without somebody making a judgment.
That judgment may involve:
- short-term revenue
- reliability
- future delivery speed
- customer commitments
- regulatory exposure
- opportunity cost
These aren’t naturally expressed in the same unit.
Scores Don’t Remove Judgment
This is where prioritization frameworks can create false precision.
Suppose one initiative receives:
RICE score: 847and another receives:
RICE score: 691The numbers look objective.
But underneath them are assumptions.
How many customers will the feature reach?
How much impact will it have?
How confident are we?
How much effort will implementation require?
Reasonable people can disagree about every variable.
A product manager may estimate high customer impact.
Engineering may expect much greater implementation effort.
Sales may believe the feature is essential for a major account.
Finance may question whether that account is strategically attractive.
The framework hasn’t eliminated judgment.
It has structured judgment.
That’s still valuable.
It becomes dangerous only when the score is treated as a measurement rather than an estimate.
Assumptions
│
▼
Framework
│
▼
Score
│
▼
Decision
Score ≠ objective truthThe score should make the assumptions easier to challenge.
It should not make the decision impossible to challenge.
Different Teams Have Different Definitions of Value
The deeper problem is that organizational value isn’t one-dimensional.
Product may care about:
Adoption
Conversion
RetentionEngineering may care about:
Reliability
Maintainability
Delivery speedSecurity may care about:
Exposure
Compliance
Control effectivenessSales may care about:
Bookings
Pipeline
Deal progressionSupport may care about:
Ticket volume
Resolution time
Customer frictionNow compare:
A feature expected to increase conversion by 8%.
with:
Infrastructure expected to reduce severe incidents by 20%.
Which has more value?
There is no universal conversion formula.
At some point, someone has to decide what matters more under the organization’s current strategy.
That decision is not a mathematical defect.
It’s leadership.
Priorities Are Decisions About Resource Allocation
This is why priority conflicts eventually become political.
Politics doesn’t necessarily mean corruption or dysfunction.
It means people have different interests, responsibilities and interpretations of value while competing for limited resources.
The product leader wants engineering capacity for growth.
The engineering leader wants capacity for reliability.
Sales wants a customer-specific feature.
Security wants remediation work.
All may have legitimate arguments.
A framework can improve the conversation.
It cannot eliminate the conflict.
Eventually, somebody with authority must decide:
Limited Capacity
│
├── Growth?
│
├── Reliability?
│
├── Security?
│
└── Customer Commitment?
│
▼
TRADE-OFFPretending the score made that decision objectively can actually make prioritization worse.
People stop debating the real trade-off and start debating the inputs to the formula.
Impact gets inflated.
Effort gets underestimated.
Strategic alignment becomes whatever wording produces the highest score.
The political argument doesn’t disappear.
It moves into the spreadsheet.
Capacity Is a Constraint, Not a Promise
Even after the organization agrees on what matters, another problem remains.
How much can actually be completed?
Teams estimate capacity using:
- historical throughput
- velocity
- staffing
- sprint capacity
- project estimates
These can all be useful.
None makes future work perfectly predictable.
An engineer becomes unavailable.
A production incident consumes two days.
Implementation reveals hidden complexity.
A vendor delays an integration.
A dependency takes longer than expected.
A seemingly difficult task turns out to be trivial.
Planning should account for uncertainty rather than pretending it doesn’t exist.
The problem isn’t that capacity estimates are imperfect.
The problem is treating an estimate as a commitment to consume 100% of theoretical capacity.
Estimated Capacity
│
▼
100% Allocated
│
▼
Unexpected Work
│
▼
Over Capacity
│
▼
Commitments SlipThe more tightly capacity is allocated, the less room the system has to absorb uncertainty.
Emergent Work Isn’t an Exception
Production bugs are not unusual.
Neither are:
- security vulnerabilities
- customer escalations
- operational failures
- unexpected technical discoveries
- vendor changes
- regulatory requests
Yet planning often treats these as interruptions to the “real” roadmap.
For many teams, they are part of the real workload.
A platform team operating critical infrastructure should expect unplanned operational work.
A mature product should expect defects.
A security team should expect new vulnerabilities.
The exact work isn’t predictable.
The existence of unpredictable work often is.
That changes the planning problem.
Instead of:
Capacity = 100
Plan = 100the organization may need something closer to:
Capacity = 100
Committed Work = 70
Expected Operational / Emergent Capacity = 20
Slack = 10The percentages will vary enormously by team and environment.
The principle is what matters.
Unknown work still consumes known capacity.
If a team repeatedly loses 25% of its time to operational work, planning as though that capacity doesn’t exist isn’t ambition.
It’s bad forecasting.
Not All Work Belongs in the Same Queue
Another mistake is putting everything into one ranked backlog.
Features.
Incidents.
Technical debt.
Security remediation.
Experiments.
Maintenance.
Regulatory obligations.
Then asking a single framework to determine the exact order.
These categories often operate under different rules.
A critical security vulnerability may have a mandatory remediation deadline.
A production incident may require immediate action.
Maintenance may need protected capacity because repeatedly postponing it increases future delivery cost.
A product experiment may be intentionally disposable.
Trying to express all of these as one universal score creates unnecessary complexity.
A better operating model distinguishes types of work.
AVAILABLE CAPACITY
│
┌────────────┼────────────┐
▼ ▼ ▼
COMMITTED EMERGENT PROTECTED
Product Incidents Reliability
Strategy Critical Maintenance
Projects defects ExplorationThe categories don’t have to look exactly like this.
The point is that prioritization becomes easier when every form of work isn’t forced to compete through the same mechanism.
Re-prioritization Can Become More Expensive Than Being Wrong
Once organizations notice that reality keeps invalidating their plans, the natural response is to prioritize more frequently.
Weekly backlog reviews.
Continuous refinement.
Emergency roadmap sessions.
Priority updates.
Leadership reviews.
This keeps the ranking current.
It can also destroy execution.
Suppose a team starts Initiative A on Monday.
On Thursday, Initiative B becomes more important.
The team switches.
The following week, a customer escalation makes Initiative C urgent.
Work switches again.
A ──────┐
│ switch
▼
B ──────┐
│ switch
▼
CThe unfinished work doesn’t disappear.
Context has been loaded.
Design has begun.
Code may exist.
Dependencies may already have been activated.
Switching creates cost.
When priorities change faster than work can complete, the organization accumulates work in progress instead of outcomes.
Reassessment and Interruption Are Different Things
This resolves an apparent contradiction.
Organizations need to reassess priorities frequently enough to respond to new information.
Teams also need enough stability to finish work.
Those requirements can coexist.
REASSESS OFTEN
│
▼
Has something changed enough
to justify interruption?
┌────┴────┐
NO YES
│ │
▼ ▼
Finish work Explicitly
interruptReassessment doesn’t require reshuffling everything.
Most new information should influence the next commitment, not automatically interrupt the current one.
Interruption should have a threshold.
A severe incident may cross it.
A regulatory deadline may cross it.
A major customer event might.
A stakeholder changing their mind probably shouldn’t.
This creates a distinction between being responsive and being chaotic.
Stable Commitments Create Focus
Once work is committed, changing it should carry a visible cost.
That doesn’t mean commitments are sacred.
It means interruption is a decision.
Suppose a team has committed to three outcomes for the next four weeks.
A new request appears.
Instead of simply inserting it as another P0, ask:
What committed work are we willing to stop?
Now the trade-off becomes explicit.
New Priority Enters
│
▼
What Leaves?
│
▼
Explicit Trade-offWithout this rule, organizations don’t really reprioritize.
They accumulate priorities.
The new urgent item enters.
Nothing leaves.
Capacity stays the same.
Deadlines remain.
Then leadership is surprised when delivery slips.
If Everything Is Priority, Nothing Is
This is where the backlog becomes misleading.
A backlog can contain hundreds or thousands of items, all neatly ordered.
Technically, that is prioritization.
Operationally, most of the list is fiction.
If the team completes 100 items per year and the backlog contains 2,000 items, much of that work will never happen.
Yet organizations resist deleting it.
A stakeholder requested it.
A customer might ask again.
Someone spent time documenting it.
Perhaps next quarter will be different.
So the backlog becomes a storage system for decisions nobody wants to make.
Backlog
#1 Likely
#2 Likely
#3 Likely
...
#73 Maybe
...
#481 Probably never
...
#1900 Definitely never
but still "prioritized"Ranking something 1,900th isn’t prioritization in any meaningful sense.
It’s refusal to reject it.
Real Prioritization Requires Saying No
This is the part no framework can automate.
A priority system should not merely determine:
What happens first?
It should also determine:
What are we not going to do?
That means deleting requests.
Closing ideas.
Rejecting projects.
Removing roadmap commitments.
Telling stakeholders that something won’t happen.
The political cost is real.
A framework can provide evidence for the decision.
It cannot absorb the consequences.
If leadership repeatedly overrides rejection whenever someone escalates, teams learn an important lesson:
The official prioritization process isn’t the real resource-allocation system.
Escalation is.
Then rational stakeholders escalate.
The organization creates the behaviour it complains about.
A Backlog Should Be a Filter, Not a Graveyard
A healthier model separates ideas from commitments.
REQUESTS / IDEAS
│
▼
Evaluation
┌──────┼──────┐
▼ ▼ ▼
Reject Later Candidate
│
▼
Commit
│
▼
Execute“Later” should not mean permanent storage.
Items can expire.
Assumptions can be revisited.
Old requests can be deleted.
If an idea remains important, someone can bring it back with current evidence.
The goal is not to preserve every possible future task.
It’s to maintain a decision system people can actually understand.
Prioritization Failure Is Often Coordination Failure
By this point, the pattern becomes clearer.
A priority can be strategically correct and still fail because:
- the necessary capacity doesn’t exist
- another team controls a dependency
- the executable sequence differs from the value ranking
- emergent work consumes capacity
- competing teams optimise for different outcomes
- new priorities are added without removing existing commitments
- work is interrupted faster than it can finish
None of these problems is solved by changing the scoring formula.
The framework may still be useful.
It simply isn’t operating at the layer where the failure occurs.
STRATEGY
│
▼
Candidate Work
│
▼
PRIORITIZATION
"What matters most?"
│
▼
Ranking
│
▼
CONSTRAINTS
Capacity
Dependencies
Sequencing
Skills
Emergent work
│
▼
COMMITMENT
│
▼
EXECUTION
│
▼
OUTCOMEA prioritization framework operates in the middle of that system.
Expecting it to control everything below it is why prioritization appears to fail so often.
The next question is more useful:
What does an organization need around prioritization so that its priorities can actually survive contact with execution?
Strategic Work Needs Protected Capacity
One reason long-term priorities repeatedly lose is that urgent work and strategic work compete for the same people.
The roadmap says:
Migrate the core platform.
Then production breaks.
A large customer escalates.
Security finds a vulnerability.
A commercial deadline moves forward.
The strategic work remains important.
It simply becomes interruptible.
After enough interruptions, the initiative isn’t cancelled.
It just stops progressing.
That is one of the most common ways strategic priorities die.
Nobody formally de-prioritizes them.
Operational reality consumes the capacity first.
A ranking cannot fix that.
If strategic work genuinely matters, some capacity has to be protected from ordinary tactical pressure.
TEAM CAPACITY
┌───────┴───────┐
▼ ▼
Operational Strategic
Work Work
Incidents Migration
Defects Platform
Support CapabilityThe exact split will vary.
The important part is that long-term work cannot depend entirely on whatever capacity remains after everything urgent has been handled.
There may be none.
Tactical Work Isn’t Lower Value
This does not mean strategic work should always outrank tactical work.
A production outage matters.
A security issue matters.
A customer blocked from using the product matters.
The problem is treating every tactical interruption as though it proves the strategic work was less important.
Often the work operates on different time horizons.
A reliability incident needs attention now.
A platform migration may determine whether the same class of incident keeps appearing for another three years.
Both can be important simultaneously.
The real planning question becomes:
How much capacity must remain responsive, and how much must remain protected?
That’s a resource-allocation decision.
Not a scoring problem.
Team Agility Requires Organisational Stability
Prioritization becomes even harder when every team is allowed to change direction independently.
A product team reprioritizes.
That seems agile.
But its new priority depends on the data team.
The data team changed its own priorities yesterday.
The platform team is now committed elsewhere.
Security had planned its review around the previous sequence.
Each team is behaving adaptively.
The combined system becomes chaotic.
Team A changes
│
▼
Dependency on Team B breaks
│
▼
Team B changes
│
▼
Team C gets blockedThis creates an important principle:
Local agility requires some surrounding stability.
A team can change direction quickly when the interfaces around it are dependable.
It cannot move quickly if every dependency is simultaneously renegotiating its own commitments.
That means organisations need stable boundaries even when they want flexible execution.
Stable doesn’t mean fixed forever.
It means teams know:
- who owns what
- which dependencies are reliable
- which interfaces are changing
- who has authority to renegotiate commitments
- how much notice significant changes require
Agility without those constraints becomes churn.
Reduce Dependencies Before Improving Prioritization
If every important initiative requires six teams, prioritization will always be expensive.
Every dependency creates:
- another queue
- another local priority
- another coordination point
- another scheduling constraint
- another chance for interruption
The solution isn’t necessarily better cross-team planning.
Sometimes the architecture or organisational design itself needs changing.
A team that owns an outcome end to end can prioritize much more effectively than a team that owns one step in a chain of seven.
HIGH DEPENDENCY MODEL
Team A → Team B → Team C → Team D
Every priority becomes coordination.
LOWER DEPENDENCY MODEL
Team A
owns larger outcome
Fewer external negotiations.This applies to technical architecture too.
Highly coupled systems make organisational priorities harder to execute because small changes require coordination across many ownership boundaries.
Loose coupling is therefore not only an engineering property.
It reduces prioritization overhead.
Decision Rights Matter More Than Another Framework
Many prioritization problems are really authority problems.
A team identifies its most important work.
A stakeholder disagrees.
The disagreement escalates.
Leadership decides.
Another stakeholder objects.
The decision gets reopened.
Nothing stays decided long enough to execute.
At that point, the issue is not how work was scored.
It’s that nobody knows who can make the final call.
A workable priority system needs clear decision rights.
For example:
Product scope
│
▼
Product owner decides
Technical implementation
│
▼
Engineering decides
Cross-team resource conflict
│
▼
Portfolio leadership decidesThe exact model will differ by organisation.
The principle is simple.
A decision needs an owner.
Input can be broad.
Authority cannot be infinitely distributed.
If every stakeholder effectively has veto power, no framework will create focus.
Escalation Should Resolve Conflicts, Not Restart Them
Escalation is sometimes necessary.
Two important commitments collide.
A regulatory deadline conflicts with a customer launch.
Two teams need the same specialist.
A platform issue creates risk across several roadmaps.
Leadership exists partly to resolve those trade-offs.
The failure happens when escalation becomes a second prioritization system.
A stakeholder dislikes the decision.
They escalate.
Leadership overrides it.
Another stakeholder learns the lesson.
They escalate too.
Eventually, the actual hierarchy becomes:
Framework
│
▼
Team Decision
│
▼
Stakeholder Pressure
│
▼
Executive Escalation
│
▼
Actual PriorityAt that point, the official framework is largely ceremonial.
If escalation is allowed, the organisation needs a clear threshold for when it is appropriate.
Otherwise political persistence becomes more valuable than the prioritization process itself.
Revealed Priorities Matter More Than Published Priorities
A company may publish five strategic priorities.
That tells you what leadership wants people to believe matters.
Resource allocation reveals what actually matters.
Look at:
- where engineering capacity goes
- which deadlines are allowed to move
- which incidents trigger executive attention
- which customer escalations override plans
- which projects retain funding when budgets tighten
- which work gets protected during emergencies
Those are the revealed priorities.
Published Priority
│
▼
"We care about reliability"
Revealed Priority
│
▼
Reliability work is cut
whenever feature delivery slipsIf the two disagree consistently, employees will follow the revealed system.
That is not cynicism.
It’s accurate observation.
Prioritization Frameworks Are Useful When They Make Assumptions Visible
After all this criticism, prioritization frameworks still have a legitimate purpose.
They help people compare uncertain options consistently enough to have a useful conversation.
RICE can expose whether expected reach is actually known.
ICE can reveal that a seemingly attractive initiative depends on very low confidence.
MoSCoW can force a team to distinguish genuinely mandatory requirements from desirable ones.
Value-versus-effort can reveal obviously poor trades.
The frameworks are useful when they produce questions such as:
Why do we believe the impact is high?
What evidence supports that confidence?
Is this actually a must-have?
Why does the team believe the effort is low?
Those conversations improve decisions.
The framework becomes less useful when the organisation expects:
Score = TruthA score is an input to judgment.
Not a replacement for judgment.
Use the Framework to Rank Candidates, Not Govern Everything
A useful operating boundary looks like this:
Candidate Work
│
▼
Prioritization Framework
│
▼
Ranking
│
▼
Human Trade-off Decision
│
▼
Capacity + Dependencies
│
▼
CommitmentThe framework helps organise the decision.
It does not own execution.
That distinction prevents a lot of wasted argument.
If a high-ranked initiative cannot be executed because a dependency is unavailable, the framework has not necessarily failed.
The organisation needs to decide whether to:
- unblock the dependency
- change the sequence
- change the scope
- commit to something else
Those are execution decisions.
Capacity Should Be Committed Conservatively
One of the simplest improvements to prioritization is to stop planning every available hour.
If a team historically loses significant time to:
- incidents
- support
- debugging
- coordination
- reviews
- unexpected complexity
then planning at 100% creates predictable failure.
The organisation may not know what will interrupt the team.
It often knows that something will.
This makes slack a planning variable.
Theoretical Capacity
│
▼
Known Operational Load
│
▼
Expected Uncertainty
│
▼
Commitment CapacityThis doesn’t mean intentionally underutilising teams.
Unused capacity can be applied to:
- maintenance
- quality
- documentation
- small improvements
- learning
The purpose is avoiding a system where every surprise automatically breaks a promise.
Work in Progress Is a Priority Problem Too
Organizations often talk about priority while allowing too much work to start simultaneously.
Five initiatives are all important.
So all five begin.
Each one gets partial attention.
Dependencies remain open.
Context switching increases.
Delivery slows.
Initiative A ──────── 40%
Initiative B ──────── 30%
Initiative C ──────── 25%
Initiative D ──────── 20%
Initiative E ──────── 15%Nothing reaches completion quickly.
The organisation then concludes it has an execution problem.
It may actually have a too-many-starts problem.
A priority system should limit how much work can become active.
Finishing one important thing often creates more value than making small progress on five.
Commitments Need an Interruption Rule
Priorities will change.
The answer is not pretending they won’t.
It’s defining what kind of change is important enough to interrupt committed work.
For example:
Interrupt immediately
- severe production incidents
- active security threats
- immovable regulatory deadlines
Review before interruption
- major customer escalation
- new competitive information
- material dependency failure
Queue for next commitment
- stakeholder preference changes
- ordinary feature requests
- ideas discovered during execution
This prevents every new request from becoming an emergency.
It also gives teams confidence that commitments mean something.
New Information
│
▼
Does it cross the interruption threshold?
┌──────┴──────┐
│ │
No Yes
│ │
▼ ▼
Next cycle Stop / swap
explicitlyThat is much healthier than continuously rearranging the backlog while pretending nothing has been disrupted.
Saying No Should Be an Expected Output
One of the best measures of whether prioritization is real is how much work disappears.
If everything survives the process, the organisation has ranked work.
It hasn’t prioritised it.
A healthy system should regularly produce:
YES
NOT YET
NOThe third category matters.
Rejecting an idea permanently creates clarity.
It frees teams from maintaining stale tickets.
It reduces stakeholder expectations.
It prevents the backlog from becoming an archive of unresolved politics.
A request can always return if circumstances change.
But it should return as a new decision with new evidence.
Not remain immortal because nobody wanted to delete it.
Strategic Clarity Makes Prioritization Easier
Another reason frameworks get overloaded is weak strategy.
Suppose leadership says the company wants:
- growth
- reliability
- international expansion
- profitability
- enterprise customers
- self-service adoption
- platform investment
All are important.
Nothing has been prioritised at the strategic level.
The product organisation is then asked to resolve those contradictions using RICE scores.
It cannot.
Prioritization works better when strategy has already narrowed the field.
Weak Strategy
Everything matters
│
▼
Framework forced to decide strategy
Clearer Strategy
A few outcomes matter most
│
▼
Framework compares work within themA product framework should not be responsible for deciding whether the business values growth over margin this year.
That is leadership’s job.
Execution Capability Changes What Can Be Prioritized
There is another uncomfortable reality.
Sometimes the organisation knows exactly what matters.
It simply cannot deliver it reliably.
A team repeatedly misses commitments because:
- deployments are fragile
- test coverage is weak
- integration work takes too long
- dependencies are poorly understood
- architecture creates excessive coordination
- operational incidents consume capacity
No ranking system fixes this.
The most important work may therefore be improving the ability to execute.
That can look like:
- reducing dependency chains
- improving deployment reliability
- clarifying ownership
- automating testing
- reducing operational load
- simplifying architecture
- improving technical feedback loops
This is why “technical work” versus “business work” can be a false distinction.
Execution capability is business capability when it determines how quickly strategy can become reality.
A Practical Prioritization Operating Model
A healthier system separates several decisions that organisations often collapse into one meeting.
1. Strategy narrows the field
Leadership decides which outcomes matter most.
Not every worthwhile goal receives equal investment.
2. Candidate work is evaluated
Use RICE, ICE, MoSCoW, value-versus-effort, or another method if it helps expose assumptions.
The framework is a decision aid.
3. Constraints are mapped
Before commitment, identify:
- dependencies
- specialist skills
- operational load
- sequencing
- capacity
- mandatory work
4. Work is committed
A small enough set of outcomes becomes active.
Everything else remains candidate work, is delayed deliberately, or is rejected.
5. Interruptions have rules
New information is reviewed continuously.
Committed work changes only when the new information crosses an explicit threshold.
6. Teams execute
The goal is finishing outcomes, not maintaining the freshness of the priority list.
7. Results update the next decision
New evidence changes assumptions.
The next commitment reflects reality.
The Full System
STRATEGY
│
▼
Candidate Work
│
▼
PRIORITIZATION
Compare assumptions
│
▼
CONSTRAINTS
Capacity / Dependencies
Sequencing / Skills
│
▼
COMMITMENT
Small set of active work
│
▼
EXECUTION
│
▼
OUTCOME
│
▼
LEARNING
│
└──────────► Next decisionPrioritization is one component.
Not the operating system.
What Good Prioritization Actually Looks Like
Good prioritization doesn’t mean priorities never change.
It means changes are deliberate.
It doesn’t mean every stakeholder agrees.
It means decision rights are clear enough that disagreement can end.
It doesn’t mean every piece of work has a perfectly comparable score.
It means assumptions are visible and trade-offs are explicit.
It doesn’t mean the backlog is perfectly ranked.
It means the organisation knows what it is actually committing to and what it is willing not to do.
And it doesn’t mean execution becomes predictable.
It means uncertainty has been accounted for rather than hidden inside impossible commitments.
Why Prioritization Always Fails
Prioritization always fails when organisations ask it to do work it was never designed to do.
A score cannot create capacity.
A backlog cannot resolve dependency chains.
A P0 label cannot make another team available.
A framework cannot eliminate politics.
A ranked list cannot protect strategic capacity.
A roadmap cannot prevent emergent work.
And a spreadsheet cannot make an organisation capable of delivering something it does not know how to execute.
That doesn’t make prioritization useless.
It makes its boundary clearer.
Prioritization helps answer:
Given what we know, what appears worth doing?
Execution requires several additional questions:
What can actually be done now?
What has to happen first?
Who owns the decision?
What capacity is genuinely available?
What will we stop doing?
What can interrupt the commitment?
Which dependencies need to be removed?
Those questions turn ranking into delivery.
Related Reading
Internal
- When strategy competes with incentives
- Planning is not execution
- Strategy dies in the handoff
- Why strategy fails in execution
- Accountability without authority creates burnout
External
- Intercom: RICE Prioritization Framework for Product Managers
- Atlassian: Prioritization Matrix
- Atlassian: Work-in-progress limits in Jira boards
- Scrum Guides: Scrum Guide
- Harvard Business Review: How to Prioritize Your Company’s Projects
Final Thoughts
The problem with RICE isn’t RICE.
The problem with MoSCoW isn’t MoSCoW.
The problem with value-versus-effort isn’t the matrix.
All of them can help structure difficult conversations.
They fail when the organisation treats their output as though deciding what matters automatically makes that work executable.
It doesn’t.
Real prioritization sits inside a larger system of:
- strategy
- resource allocation
- dependency management
- capacity
- decision rights
- sequencing
- execution
- learning
If those surrounding systems are weak, the priority list becomes ceremonial.
Teams learn that escalations matter more than scores.
Strategic work gets interrupted indefinitely.
New priorities are added without old commitments being removed.
Backlogs grow because rejection is politically difficult.
And leaders respond by introducing more prioritization process.
The better response is not abandoning frameworks.
It’s using them for the job they can actually do.
Rank candidate work. Make assumptions visible. Force trade-offs into the open.
Then stop pretending the ranking is the plan.
Build commitments around real capacity.
Sequence dependencies.
Protect important long-term work.
Limit work in progress.
Give decisions clear owners.
Define what is allowed to interrupt execution.
And say no often enough that the priority list represents actual choices.
Prioritization doesn’t fail because organisations cannot decide what matters.
It fails because what matters, what can be done, and what people are actually willing to stop doing are three different questions.
Good execution starts when the organisation finally answers all three.
