Every organization eventually invents a way to decide what matters most. Some use RICE or ICE, others use MoSCoW, value-versus-effort matrices, quarterly planning, or a backlog ranked from P0 downward.
The names differ, but the promise is similar. Compare competing work, identify what matters most, and direct limited resources toward it.
Then reality hits the backlog.
The P0 feature depends on infrastructure ranked P3. The engineer who understands that infrastructure is committed elsewhere, a production incident consumes two days of the team’s week, and a customer escalation introduces work that did not exist when the priorities were agreed.
The P0 feature may still be the most important thing on the roadmap. What changed was not necessarily its priority, but the conditions required to execute it.
That distinction explains why prioritization fails so often in practice. Organizations ask a ranking system to solve an execution problem.
A framework can help decide what appears worth doing. It cannot create capacity, remove dependencies, determine executable sequence, make scarce specialists available, or prevent new information from arriving after work begins.
A ranked list can be useful. It just is not an execution plan.
The Highest Priority Cannot Always Happen First
Suppose an organization evaluates several initiatives and concludes that Feature A has substantially more business value than anything else under consideration.
The prioritization process has done its job. Feature A belongs at the top of the list.
Now suppose Feature A requires an infrastructure change before development can proceed, and that infrastructure change requires a database upgrade. The ranking might therefore say:
BUSINESS PRIORITY
1. Feature A
2. Infrastructure change
3. Database upgrade
EXECUTABLE SEQUENCE
Database upgrade
↓
Infrastructure change
↓
Feature AThe lowest-ranked work has to happen first.
That does not mean the prioritization was wrong. It means importance and sequence are different properties of work.
Prioritization asks what matters most. Sequencing asks what must happen first for the important thing to become possible.
Confusing those questions creates a familiar organizational argument. Someone sees engineers working on lower-ranked infrastructure while the P0 feature remains incomplete and concludes that the team has lost focus.
In reality, doing the lower-priority work may be exactly how the organization delivers its highest priority.
This becomes more difficult when the sequence crosses team boundaries. Feature A may require product, design, an application team, a platform team, data engineering, security review, and a specialist who supports several other projects.
At that point, the problem is no longer primarily ranking. It is coordination.
Dependencies Turn Priorities Into Coordination Problems
A single team with relatively few external dependencies can often prioritize effectively. The people deciding what matters are close to the people doing the work, they understand their own capacity, and they can adjust the sequence when circumstances change.
Now distribute one outcome across six independently constrained teams.
The product team considers the initiative P0, but the platform team has a reliability problem it considers P0. Security has a regulatory deadline, while the data team has already committed its capacity to another strategic initiative.
Every team can be following a perfectly reasonable priority order while the organization’s supposedly highest priority remains blocked.
No scoring framework can remove that contradiction.
This is the difference between local and organizational priority. Teams need enough autonomy to protect their systems, handle incidents, manage technical risk, and make decisions using information that central leadership does not have.
The organization simultaneously needs outcomes that cross those boundaries.
Those two requirements collide whenever several teams need the same scarce capacity at the same time. A product launch can be genuinely important while a platform migration is also genuinely important, and neither team has to be wrong for the conflict to exist.
Eventually someone has to decide where the constrained resource goes.
A framework can improve that conversation by making assumptions visible. It cannot eliminate the trade-off that created the conversation.
A Score Structures Judgment. It Does Not Replace It
This is where prioritization frameworks can create a misleading sense of precision.
Suppose one initiative receives a RICE score of 847 and another scores 691. The numbers make the difference look measured.
Underneath them are estimates.
Reach depends on assumptions about how many people will encounter the change. Impact requires a judgment about how much those people will benefit, confidence describes how strongly the organization believes its own estimates, and effort depends on work that has not yet been completed.
Reasonable people can disagree about every variable.
That does not make RICE useless. Its value is that the framework forces those assumptions into a form that other people can inspect and challenge.
ICE, MoSCoW, and value-versus-effort perform similar functions in different ways. They create a shared structure for discussing uncertain choices.
Problems begin when the score stops being treated as structured judgment and starts being treated as objective truth.
This is especially dangerous when different functions are comparing different forms of value. Product may care about conversion, engineering about reliability, security about exposure, sales about bookings, and support about customer friction.
There is no natural formula that tells an organization whether an eight percent conversion improvement is worth more than a twenty percent reduction in severe incidents. At some point, the business has to decide which outcome matters more under its current circumstances.
That decision is not evidence that the prioritization framework failed. It is evidence that prioritization eventually becomes resource allocation, and resource allocation requires judgment.
Hiding the judgment inside a score does not make it disappear. It simply moves the argument into the spreadsheet.
Capacity Does Not Expand Because Something Became P0
Even after the organization agrees about what matters, execution still has to fit inside available capacity.
Planning often starts with a theoretical number. A team has a certain number of engineers, a historical velocity, or an estimated amount of work it can complete during the quarter.
Then reality consumes part of that capacity.
A production incident requires attention, an engineer becomes unavailable, implementation reveals hidden complexity, a vendor misses a date, or a customer escalation requires immediate investigation.
Organizations often describe these events as interruptions to the roadmap. For many teams, however, some amount of unplanned work is part of the normal operating environment.
A platform team will have incidents. A mature product will produce defects, while security teams will discover new vulnerabilities and customer-facing teams will encounter escalations that could not have been named three months earlier.
The exact work may be unknown. The fact that unknown work will consume capacity often is not.
That gives planning a useful principle: unknown work still consumes known capacity.
If a team historically spends a significant portion of its time handling production work, planning as though one hundred percent of its theoretical capacity is available for roadmap commitments does not make the organization ambitious. It creates commitments based on capacity that was never likely to exist.
This is another reason a P0 label has limited power. Calling something critical does not make an engineer appear, shorten a dependency, or recover the week lost to an incident.
The priority can remain perfectly correct while the original delivery assumption becomes impossible.
Constant Reprioritization Can Make Execution Worse
Once organizations notice that reality keeps invalidating their plans, the natural response is to prioritize more frequently.
The backlog is reviewed again, scores are updated, leadership meets, and the roadmap changes to reflect the latest information. In principle, this makes the organization more responsive.
In practice, changing priorities has a cost.
A team can begin Initiative A, spend several days understanding the problem and activating its dependencies, then switch to Initiative B when new information arrives. A week later, a customer escalation makes Initiative C urgent.
The team has responded quickly three times and completed very little.
Work that was interrupted does not return to its original state. Engineers have loaded context, design work has begun, code may already exist, other teams may have reserved capacity, and assumptions may need to be reconstructed when the work resumes.
This creates an important distinction between reassessment and interruption.
Priorities should be reassessed as new information arrives. That does not mean every new piece of information should interrupt work already in progress.
A severe production incident may justify interruption. A regulatory deadline or a material change in business conditions may justify it as well.
Most new requests should influence the next commitment rather than automatically displacing the current one.
Without that distinction, an organization can become extremely responsive at the decision level and extremely slow at the delivery level. Every team changes direction quickly, but nothing remains important long enough to finish.
A New Priority Is Not Free
The most revealing moment in prioritization occurs when something new becomes urgent.
A major customer needs a feature, a security issue appears, or leadership identifies an unexpected opportunity. The organization labels the new work P0 and adds it to the plan.
The crucial question is what happens next.
New priority enters
↓
What loses capacity?
↓
What stops or moves?
↓
Explicit trade-offIf nothing leaves, the organization has not reprioritized. It has increased demand while leaving capacity unchanged.
This is how companies accumulate ten “top priorities” and still describe themselves as focused. Each new item is genuinely important, but nobody is willing to name the existing commitment that should lose resources because of it.
The same problem appears in enormous backlogs.
A team might have 2,000 items carefully ordered from most to least important while completing only 100 items a year. Most of that backlog is not a realistic execution queue.
Ranking an item 1,900th is effectively saying that it will not happen while avoiding the discomfort of actually rejecting it.
Real prioritization therefore requires more than deciding what happens first. It requires deciding what will not happen.
That is where frameworks reach their political limit. A scoring model can provide evidence for rejecting a request, but it cannot absorb the consequences of telling a stakeholder no.
Organizations that refuse to make that decision usually create a different priority system accidentally. Stakeholders learn that the official backlog can be overridden through escalation, executive sponsorship, customer pressure, or persistence.
Once that happens, the framework is no longer the resource-allocation system. Escalation is.
People respond rationally by escalating more often.
Commitment Is Where Prioritization Becomes Real
A priority list describes preference. A commitment describes where the organization is actually willing to put scarce resources.
That distinction matters because published priorities and revealed priorities can be very different.
A company may say reliability is strategically important while repeatedly removing engineers from reliability work whenever feature delivery slips. It may describe a platform migration as critical while allowing every customer escalation to interrupt it.
Employees eventually learn which signal to trust.
The real priority is revealed by what keeps its capacity when priorities collide.
This is also why decision rights matter. When product, engineering, security, and sales disagree about how a scarce resource should be used, broad input is valuable, but the decision cannot remain indefinitely distributed.
Someone needs enough authority to end the trade-off.
Otherwise decisions are repeatedly reopened. A team commits, a stakeholder objects, leadership intervenes, another stakeholder escalates, and the priority changes again before execution has enough time to produce an outcome.
Clear authority does not make the decision objectively correct. It makes the organization capable of acting on a decision long enough to learn whether it was correct.
Commitment therefore creates a useful boundary around prioritization. Before commitment, candidate work can be scored, challenged, reordered, combined, or rejected.
After commitment, the threshold for interruption should rise.
New information still matters, but the question changes from “is this new thing important?” to “is it important enough that we are willing to stop something already underway?”
That second question forces the trade-off back into view.
Prioritization Is Only One Part of the System
RICE does not fail because Feature A depends on infrastructure. MoSCoW does not fail because a production incident consumes half the team’s week, and a backlog does not fail because the specialist needed by its highest-ranked item is unavailable.
Those are failures at different layers of execution.
A useful operating model is therefore simpler than endlessly refining the ranking formula.
Strategy determines which kinds of outcomes matter. Prioritization compares candidate work and exposes assumptions about its value.
Capacity and dependencies determine what is actually executable. Commitment decides which subset receives resources, while execution produces new information that changes the next decision.
The relationship looks roughly like this:
strategy → candidate work → prioritization → constraints → commitment → execution → evidence → next decision
Prioritization matters, but it occupies only one position in that chain.
Expecting it to control everything downstream is why organizations keep replacing one framework with another. When RICE fails to make execution orderly, they adjust the formula, introduce another planning process, add more priority labels, or hold more frequent backlog reviews.
None of those changes creates missing capacity or removes a dependency.
Sometimes the better intervention is architectural. If every important initiative requires six teams, reducing coupling may improve execution more than improving the scoring system.
Sometimes it is organizational. A team that owns a larger outcome end to end needs fewer negotiations to move important work forward.
Sometimes the answer is simply to commit to less. Finishing two important outcomes can create more value than starting six and continuously moving people among them.
The framework is useful when it helps the organization make better choices about candidate work. It becomes ceremonial when everyone knows that the actual order will be determined later by dependencies, escalations, and whichever crisis arrives first.
What Matters, What Can Happen, and What Stops Are Different Questions
Prioritization frameworks are not broken because they cannot solve all of this.
RICE can help expose an optimistic impact estimate. MoSCoW can force a useful conversation about whether something really is mandatory, while value-versus-effort can reveal work whose likely return does not justify its cost.
Those are valuable functions.
The mistake is believing that deciding what matters most automatically determines what the organization should be doing at this moment.
The highest-value outcome may depend on lower-value enabling work. The people needed to deliver it may be occupied by another legitimate priority, while operational work may consume capacity that looked available during planning.
New information may also make another opportunity more valuable tomorrow than anything on today’s list.
A functioning organization needs to deal with all of those conditions without pretending that the ranking itself caused them.
That means priorities need real capacity behind them, dependencies need to influence sequence, interruptions need a meaningful threshold, and decision rights need to be clear enough that trade-offs eventually end.
Most importantly, adding something to the top of the list has to change something elsewhere. If every new priority enters while every old commitment survives, the organization is not prioritizing more aggressively.
It is overcommitting more explicitly.
The useful questions are therefore different.
What matters most? What can actually happen next? What are we willing to stop doing so that it can happen?
A prioritization framework can help answer the first question. Execution begins when the organization answers all three.
