It is Friday afternoon. Checkout is failing, a feature review is booked for Monday, and someone has marked a small visual issue “urgent.” Which one gets the team’s attention?
This is a fictional situation, but it captures the prioritization problem well: the labels are less useful than the consequences. A bug should interrupt feature work when the harm or risk cannot reasonably wait. That does not make every bug an emergency.
Separate two decisions: do we need to respond to an incident now, and what should we build once the product is stable? Mixing them into one backlog conversation can hide both the immediate risk and the longer-term trade-off.
First, find out what is actually broken
Before deciding, collect enough information to describe the situation:
- What user action is failing?
- How many people are affected, and which people?
- Is there a security, privacy, data-loss, or payment-integrity risk?
- Is there a safe workaround?
- Is the harm continuing or getting worse?
- Can the team roll back, disable the affected path, or contain the issue?
- Who owns the response, and who needs updates?
Use your organisation's incident and escalation policies. The questions above are a decision aid, not a substitute for those policies or specialist security advice.
GitLab's public prioritization guidance is a useful example of treating bugs, features, and maintenance together while also considering severity, response expectations, and cross-functional ownership. Its specific targets belong to GitLab; they are not universal rules. 1
Three illustrative decisions
The following examples are fictional, not reports from Aniket's employers.
| Situation | Initial decision | What to verify |
|---|---|---|
| Payments fail for every customer | Escalate for immediate incident response | Scope, ongoing harm, rollback options, and payment reconciliation needs |
| A display label is misaligned but the task works | Usually schedule after assessing impact | Accessibility, comprehension, and whether particular users are blocked |
| An executive requests a new feature before Monday | Clarify the deadline before interrupting delivery | Business consequence, commitment, evidence, and what must be displaced |
Notice that “cosmetic” is not a conclusion until you understand the impact. A small visual defect can matter a great deal if it makes a critical task inaccessible.
Likewise, “needed by Monday” describes a date. It does not explain why that date matters.
Once immediate risk is contained, compare the options
A temporary fix and a permanent fix solve different problems. A workaround might restore service quickly while leaving recurring maintenance costs. A rebuild might address the underlying issue but delay a valuable launch.
Compare:
- User harm: What happens if this waits?
- Cost of delay: What value is lost by postponing the feature?
- Recurrence: Will the same issue keep interrupting the team?
- Effort and dependencies: What is required to ship a safe change?
- Uncertainty: Which assumptions could reverse the choice?
For comparable planned work, a framework such as RICE can help expose assumptions. It should not be used to avoid a required incident response or pretend a security risk is just another ordinary feature request.
Explain the decision in six lines
A useful update might look like this:
Problem: Customers cannot complete payment.
Known impact: The affected checkout path is failing; scope is still being checked.
Immediate action: The incident owner is coordinating containment and recovery.
Delivery impact: Work on the new feature is paused while the response needs that team.
Unknowns: Recovery time and the permanent fix are not yet confirmed.
Next update: The owner will share progress at the agreed checkpoint.
This is a hypothetical communication template. It deliberately avoids promising a recovery time before the team has evidence.
Practise the trade-off in two games
Friday 5PM presents tickets to sort into do now, schedule, delegate, or drop. Its short timer makes the difference between urgency and importance tangible. Its answers are fixed for the fictional scenarios; a real team's context can change the right action.
The War Room asks players to make stakeholder choices while balancing stability, growth, and morale. It makes the idea of competing consequences visible. Its meters are game mechanics, not forecasts of business outcomes.
Both are part of Aniket Mishra's playable portfolio, not incident-management software or validated professional assessments.
Before reopening the roadmap debate, I would make sure somebody owns the incident and somebody owns the update. Then I would write down what is being delayed. “We are fixing a bug” is not enough information for a team that has just lost its feature deadline.