A payment fails for a small group of customers, an order status occasionally stays out of date, and a banner looks wrong in one browser. All three reports can arrive labelled “urgent”. For a Product Owner, ordering that work requires enough information to explain what happens if each defect remains unresolved and what other work would be displaced by fixing it now.
The following examples use Mercato, a hypothetical online shop. They show how the same evidence can lead to different decisions as the affected audience, available workaround or time remaining before a campaign changes. The priorities are proposed decisions for these cases, not a universal classification that every team should adopt.
Severity describes the failure; priority orders the response
Severity describes how seriously the defect affects the system or the person trying to use it. Priority expresses how soon the team should address it relative to other work. A crash in an obsolete internal tool may be severe for its remaining users yet require a different response from a smaller failure affecting today's checkout campaign. The distinction only helps if the team records who is affected and under which conditions.
Labels such as critical, major, P1 or P2 vary between organizations. Microsoft Azure Boards, for example, maintains separate severity and priority fields and illustrates why their values need not match. Product, Engineering, QA and Support should agree the meaning of their own labels, including the route for an active incident. A label copied from another company does not establish a response time.
Establish the impact before arguing about the order
“Some customers cannot pay” is enough to start investigating, but it does not yet describe the scope. The team needs the affected payment method, the conditions in which the failure occurs, when it started and whether customers can recover without paying twice. A low number of reports can reflect limited exposure or a problem that customers abandon without reporting. Uncertainty about reach should remain visible.
A useful bug report gives the team a shared basis for that discussion. The following information can be gathered progressively; investigation of a serious incident should not wait for a perfectly completed form.
- The observed and expected behaviour, affected journey and known reproduction conditions.
- The audience exposed to the failure, with evidence and any gaps in that evidence.
- The consequences for customers, transactions or data, including whether the effect can be reversed.
- The available workaround, who can use it and its cost or limitations.
- The timing constraint, available containment and an initial engineering assessment of the fix.
The guide to product observability develops how to investigate production signals. For prioritization, the useful output is a short account of the impact and its confidence level. A trace full of errors does not, on its own, establish how many customers failed to complete a purchase.
Three bugs and the decisions behind their priority
A failed confirmation after payment
Mercato receives reports that a payment has been charged but no order appears. The scope is initially unknown. Because customers may retry and incur another charge, the team follows its incident procedure and considers containment, such as disabling the affected payment path, while Engineering investigates. Support needs a way to identify affected customers and explain what will happen to their money and order.
An immediate response does not necessarily mean shipping the first code change proposed. The team must compare containment and recovery options, assess the fix and check transactions already affected. Product brings the customer and business consequences to that decision; Engineering determines the technical options and risks. Waiting for the next routine backlog meeting would leave an active harm unaddressed.
A delivery status that stops updating
A carrier integration leaves some orders marked as preparing even though they have shipped. The parcels keep moving, and customers can use the carrier's tracking page, but that link is only available in an email that some customers cannot find. The bug may initially sit behind the payment incident while still receiving a named owner, a planned review and a temporary support measure.
The workaround has to be evaluated as customers experience it. If most affected people cannot find the email, the existence of a tracking page offers little relief. A rise in support contacts or evidence that delivery failures are being hidden would change the priority. Recording those conditions gives the team a reason to revisit the decision.
A visual error just before a campaign
A banner clips a line of text in one browser. If the missing text is decorative and the offer remains clear, the team may schedule the correction after higher-impact work. If the clipped line contains the minimum spend required for tomorrow's promotion, the same rendering defect changes what customers understand about the offer. Correcting or replacing the banner may now need to happen before the campaign starts.
“Visual” is therefore an insufficient reason to assign a low priority. The decision depends on the information lost, the people affected and the time available to act. A corrected image or temporarily paused campaign may offer a safer response than a rushed layout change with consequences elsewhere.
A decision table to use with the team
The table captures the reasoning in the examples. It is an aid for discussion, not an automatic scoring system. Each row needs evidence, and an unknown impact may justify investigation or containment before the team can rank the permanent fix confidently.
| Situation | Initial response | Reason to review |
|---|---|---|
| Payment charged, order missing | Activate the incident response; assess containment and reconcile affected transactions. | New evidence on reach, duplicate charges or recovery options. |
| Delivery status stale | Plan the correction and provide an accessible tracking alternative. | The workaround fails, support demand rises or delivery failures become hidden. |
| Campaign condition clipped | Correct or replace the banner before exposing customers to the offer. | The campaign is postponed, the content is replaced or exposure changes. |
Make the cost of changing the plan explicit
A bug does not become free because it is labelled urgent. Fixing it can interrupt other work, require a specialist and introduce regression risk, meaning previously working behaviour may break. Engineering's assessment should include verification and rollout as well as the code change. The Product Owner can then explain which planned outcome is being delayed and why that trade-off is justified.
In Scrum, the Product Owner is accountable for ordering the Product Backlog, while Developers manage the Sprint Backlog. When new work emerges during a Sprint, the Product Owner and Developers discuss scope without endangering the Sprint Goal. An active incident also follows the organization's operational responsibilities; a Product Owner should not become the sole gatekeeper for containment. Work that fails the Definition of Done cannot be treated as a completed Increment simply because the remaining defect has been given a low priority.
Record why a bug can wait and when to reconsider it
A deferred bug needs a decision that can be revisited. Record the known impact, the temporary measure, who will review it and the date or event that triggers that review. “After the release” needs a specific owner and a place in planning; otherwise it can turn into an indefinite delay. Customer reports, a larger rollout or a change in the workaround can invalidate the earlier assessment.
Closing the report also needs evidence that the original failure has been addressed and affected users or transactions have been considered. Where the expected behaviour was unclear, the article on acceptance criteria for Product Owners helps turn that agreement into cases the team can verify. The book Testing, Bugs, and QA for Product Managers develops test results, bug triage and release decisions in more detail for Product Managers and Product Owners.
References
- Microsoft Learn: managing bugs and distinguishing severity from priority.
- The Scrum Guide: Product Owner, Sprint Backlog, Sprint Goal and Definition of Done.