A product team agrees that a new customer feature is its highest priority. Before development can proceed, the platform team needs to upgrade a database. The engineer best placed to help is already committed to reliability work, and a production incident consumes part of the following week.
The feature may still be the most valuable outcome under consideration. The team now needs a workable sequence and a decision about where the required capacity will come from. Repeating its position at the top of the backlog does little to resolve either question.
Prioritisation helps an organisation compare competing work. Its value depends on how those comparisons reach the people, dependencies, and commitments involved in delivery. A ranked list becomes useful for execution when the organisation can explain what can happen next and what will change to make it possible.
Using Scores to Examine Assumptions
Intercom’s RICE framework compares work through estimates of reach, impact, confidence, and effort. It provides a consistent structure for examining why an initiative appears worthwhile. The original guidance also acknowledges that dependencies and other considerations can justify doing lower-scoring work first.
The estimates remain judgments informed by evidence. A feature might reach many customers but have a small effect on their behaviour. An apparently inexpensive change may require more work once its dependencies are understood. The discussion around those assumptions can be more useful than the final numerical difference.
For the customer feature, the team should be able to explain what improvement it expects, which evidence supports that expectation, and what remains uncertain. If the infrastructure work was missing from the estimate, the comparison needs to be updated.
A score can help make that revision visible. Leadership still needs to decide how the expected benefit compares with other demands, particularly when those demands concern different outcomes such as reliability, customer growth, or operational risk.
Separating Importance From Sequence
The customer feature depends on a platform change, which depends on the database upgrade. The upgrade therefore belongs earlier in the execution sequence even if it has little independent customer value.
The plan needs to show how that enabling work contributes to the desired outcome. Otherwise engineers can appear to be working on an unrelated technical task while stakeholders wait for the feature they were told mattered most.
Dependencies also need owners and readiness conditions. The application team should know what the upgraded database must provide, how it will confirm readiness, and when it needs to participate in testing. A date without those agreements may conceal an unresolved handover.
This distinction gives planning a more practical scope. Comparing candidate outcomes establishes where effort may be justified. Sequencing establishes the steps required to achieve the selected outcome under current conditions.
Resolving Priorities Across Teams
The platform team’s reliability work may also be important. It could address a failure affecting several services, while the feature serves a particular customer group. Both teams can have reasonable priorities and still need the same specialist at the same time.
The conflict requires a decision at a level with authority over the competing commitments. Relevant options might include delaying the feature, reducing its scope, postponing part of the reliability work, or arranging another qualified person to help. Each option has consequences that should be made visible.
Clear decision rights help the teams obtain a resolution. Specialists contribute evidence about risk and feasibility; the authorised owner decides which trade-off the organisation will accept within applicable constraints.
The resulting commitment should reach everyone affected. Changing the engineer’s allocation without changing the reliability team’s expectations leaves the conflict in place, with the cost appearing later as a missed commitment.
Planning With the Capacity Available
Capacity needs to account for the work a team already performs. Production support, maintenance, reviews, and existing commitments consume time alongside new delivery. Historical experience can help identify the likely demand, even when the exact incidents or requests cannot be predicted.
For this team, planning should examine how much specialist time is realistically available for the database upgrade. If that person regularly handles incidents, the forecast should reflect the uncertainty and provide a route for responding when support demand rises.
An estimate expressed in person-days also needs a calendar interpretation. Several days of specialist effort may be spread across weeks because the work has prerequisites or competes with other responsibilities. Adding developers does not necessarily remove that constraint.
The organisation can respond by reducing concurrent work, changing scope, or protecting a specific allocation. These choices make the commitment more credible because they change the conditions on which delivery depends.
Deciding When Work Should Be Interrupted
New information should influence priorities. It does not follow that every important request should immediately interrupt work already underway. The decision needs to consider what would be gained and what stopping would cost.
A serious production incident may justify redirecting the database specialist. A new feature request may be better considered when the current upgrade reaches a safe stopping point. The distinction depends on consequences, urgency, and the state of the work in progress.
The team should record enough context to resume interrupted work: what changed, what remains incomplete, and which assumptions require checking. Other teams may also need to revise arrangements they made around the original plan.
A useful interruption policy establishes who can redirect work and which circumstances require escalation. It gives people a way to respond to genuine urgency while making the effect on existing commitments explicit.
Making Room for a New Commitment
Suppose a customer escalation introduces another urgent feature. Leadership should identify which work loses capacity if the new request proceeds. That may mean moving the original feature, narrowing one of the initiatives, or declining the new commitment.
An additional priority label does not resolve the allocation. The revised plan needs to explain what is being done, which expectations have changed, and who will communicate the decision to affected stakeholders.
Backlog management should support that clarity. Candidate ideas can remain available for later consideration without being presented as promised work. Items with no credible delivery horizon may need rejection, archiving, or a condition under which they would be reconsidered.
The decision process becomes more useful when it preserves those reasons. Stakeholders can then understand what evidence would justify reopening a request, rather than relying on repeated escalation to obtain attention.
Learning From What Reaches Completion
The organisation can assess prioritisation through the outcomes it completes and the decisions that shaped them. For the customer feature, useful questions include whether the expected benefit appeared, whether dependency estimates were realistic, and what caused any changes to the commitment.
A delay caused by previously unknown database work suggests a need for better discovery. Repeated interruptions may indicate unrealistic capacity assumptions or unclear escalation rules. If many initiatives require the same teams, reducing those dependencies may improve delivery more than changing the scoring formula.
These findings should inform the next planning decision. The roadmap can become more credible as teams learn which conditions permit work to progress and which commitments they can sustain.
For the product team, the useful result is an agreed sequence backed by available capacity and authority to resolve conflicts. The feature’s priority remains part of the reasoning, alongside the practical choices that allow it to reach customers.
