Bug Priority Matrix

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]

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

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: assess bugs in critical launch flows against agreed release criteria.
• 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 affected users, harm, recurrence, and fix time. For example: “This issue affects 0.3% of users once; the P0 affects 18% daily.” Explain severity as well as frequency.

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?

You may accept a low-impact bug when a workaround exists and a rushed fix risks larger regressions. Document the risk, owner, and follow-up date.

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