How should we score bugs fairly across teams?

Use a shared matrix with clear definitions: Severity (user/system harm), Impact (business/customer fallout), and Frequency (how often) on 1–4 scales. Multiply, then apply business multipliers for critical flows (checkout, onboarding, SLAs).

What makes a bug a P0 vs. P1?

P0 stops shipping or breaks critical journeys for a meaningful % of users with no workaround. P1 hurts a key flow but has a workaround or lower blast radius. Decide with data: affected users, revenue risk, and time-to-fix.

How do we estimate frequency if data is spotty?

Triangulate logs, analytics paths, and support volumes. Use ranges and update scores as evidence improves. A rough, transparent estimate beats ignoring frequency.

How should upcoming launches change prioritization?

Add a launch multiplier to signup, payment, or migration flows. A bug that risks day‑one trust gets elevated temporarily. Make the multiplier explicit and time‑boxed.

How do we include QA and engineering reality in prioritization?

Add engineering time and QA scope to the triage sheet. Prioritize clusters of related fixes to reduce context switches and retest cost. Reserve capacity for hotfixes.

How do we stop recurring bug classes?

Tag bugs by class (e.g., null handling, auth race). When a class crosses a threshold, open a prevention ticket (tests, observability, refactor) and allocate platform/quality capacity each sprint.

What belongs in the bug triage sheet?

ID, Severity, Impact, Frequency, Score, Affected Users, Proposed Action, Priority, Est. Engineering Time, QA Scope, and Customer Communication. Owners and dates for accountability.

How do we explain not fixing a noisy bug first?

Use the matrix to show blast radius and risk. Compare affected users and harm vs. the current top items. Offer a timeline and communication plan to reduce noise while the real fires are handled.

How do we keep triage from derailing sprints?

Reserve a buffer for urgent bugs (e.g., 10–20%). Batch fixes where possible, and enforce a clear definition for P0 hotfixes vs. P1/P2 that can wait for the next sprint.

Bug Priority Matrix

Q: Should we ever ship with known bugs?

Yes, when impact is low, a workaround exists, and fixing it risks bigger regressions. Document owner, risk, mitigation, and a follow‑up date. Trade‑offs are fine; surprises are not.

Triage and prioritize bugs with clear scoring methodology

daily-essentialsbeginnerRisk MatrixPriority ScoringResource Planning400-600 words

Customize Your Prompt

Fill in the variables to generate your personalized prompt

Bug List/Description

Total User Base Size

Upcoming Milestone

Additional Context (Optional)

Preview

See how your prompt will look with the current variables

You are triaging bugs for a product with [Total User Base Size] users approaching [Upcoming Milestone].

Role: Senior Product Manager with expertise in risk assessment and quality management.

Instructions:
1. Score each bug using Severity (1-4) × Impact (1-4) × Frequency (1-4)
2. Apply business context multipliers for critical features
3. Consider technical debt implications
4. Factor in upcoming milestone timeline
5. Recommend fix order based on resources

Specifics:
| Bug ID | Severity | Impact | Frequency | Score | Affected Users | Action | Priority |
|--------|----------|---------|-----------|-------|----------------|--------|----------|
| [ID]   | [1-4]    | [1-4]   | [1-4]     | [X]   | [Estimate]     | [Fix/Defer] | [P0-P3] |

## Priority Buckets
**P0 (Ship Stopper):** [List with justification]
**P1 (This Sprint):** [List with sprint capacity check]
**P2 (Next Sprint):** [List with dependencies]
**P3 (Backlog):** [List with revisit timeline]

## Resource Impact
- Engineering hours needed: [Estimate]
- QA requirements: [Scope]
- Customer communication: [If needed]

Purpose: Sprint planning and resource allocation decisions.

Bug Data:
[Bug List/Description]

## Important Guidelines

### Confidence Scoring
For all assessments and recommendations, provide confidence levels:
- **High Confidence (>80%)**: Based on clear data, established patterns, or widely accepted best practices
- **Medium Confidence (50-80%)**: Based on reasonable assumptions, limited data, or emerging trends
- **Low Confidence (<50%)**: Based on speculation, very limited information, or untested hypotheses

### Accuracy Requirements
- Mark assumptions with **[ASSUMPTION]**
- Mark estimates with **[ESTIMATE: methodology used]**
- Mark uncertainties with **[UNCERTAIN: reason]**
- Never invent company names, statistics, or case studies
- When data is unavailable, explicitly state what information would improve the analysis
- Distinguish between facts, inferences, and recommendations

### Source Attribution
- General knowledge: "Based on industry standards..."
- Inferences: "This suggests that..."
- Speculation: "One possibility is..."
- Best practices: "Common approaches include..."

What Makes a Good Bug Triage

• A shared scoring model: severity × impact × frequency, with clear definitions.
• Business multipliers for critical flows (checkout, onboarding, SLAs) documented upfront.
• Realistic fix ordering: engineering time, QA scope, and customer comms included.
• Milestone awareness: launch blockers float to the top automatically.
• Debt tracking: recurring classes of bugs generate a follow‑up investment ticket.

Common Bug Triage Mistakes

• Fixing the loudest bug first (the CEO’s DM) instead of the biggest blast radius.
• Vague severity definitions—everything becomes a P0, which means nothing is.
• Ignoring frequency because it’s “hard to estimate”—estimate anyway, then update.
• No QA time in the plan; bugs boomerang back and burn sprints.
• Treating symptoms—never opening a root‑cause ticket for recurring classes.

Questions PMs Actually Ask (Bug Prioritization)

How do I explain why a noisy bug isn’t P0?

Show the matrix. Blast radius (affected users), revenue/user harm, recurrence, and time‑to‑fix. “This one hits 0.3% of users once; the P0 hits 18% daily.” Most people respect math.

We’re about to launch—how does that change prioritization?

Add a launch multiplier to flows that can tank the launch (signup, payment, migration). A P1 yesterday could be a P0 today if it risks day‑one trust.

What if we can’t estimate frequency?

Triangulate: logs, support tickets, analytics paths. Use a range and update as you learn. A rough estimate beats pretending frequency doesn’t matter.

Should we ever ship with known bugs?

Yes—when impact is low, there’s a workaround, and fixing it risks bigger regressions. Document the risk, owner, and follow‑up date. Adults make trade‑offs; write them down.

How do we stop fixing the same bug family every sprint?

Track bug classes and open a prevention ticket (tests, observability, refactor). Dedicate capacity (e.g., 20%) to platform/quality so you actually get ahead.

How to Use This Prompt