Practice 01.03 · Product quality
Prioritize bugs by user impact
You do not need to be a technical expert to bring order to a bug backlog. For each bug, answer four questions: what is broken, who is affected, how often it happens, and whether a safe workaround exists.
60 minutes for the first analysis
In plain language
Priority is harm to the user, not how loud the discussion is
What you will need
01
When to use it
The backlog keeps growing, the team argues about urgency, and the latest loud request gets picked up instead of the most dangerous problem.
In plain language
Where to look for evidence
One screenshot does not show the scale. Combine the technical signal, a user report, and the impact on a key action.
Crash and ANR reports
Look at the number of affected users, the app version, device, stack trace, and repeatability.
If there are no reports, ask a developer to reproduce the problem and save the video, logs, and conditions.Support and reviews
Group requests by a single cause: login, status, payment, data loss, blank screen, or a confusing message.
If tags are not set up, manually go through the 30 most recent requests and create five simple categories.Key journey
Compare the action's success rate before and after the error appeared: login, registration, saving, verification, or a transaction.
Without analytics, run the journey ten times on the affected version and record the failure rate.02
Sort out the bug list in five steps
Collect everything into one table
Merge duplicates from crash reports, QA, support, and reviews. One user problem should be one row.
- Where to do it
- Jira, Linear, or a shared table with links to the original signals.
- What the result looks like
- Three tickets — “endless status,” “transaction stuck,” and “I can't see the result” — are merged into one problem.
Describe the harm in plain words
Write down what the user cannot do and what they risk losing. Do not leave only an error code in the title.
- Where to do it
- In the “user impact” field of each task.
- What the result looks like
- Not “API 504,” but “after confirming, the user does not see the final status and repeats the action.”
Confirm the scale
State the number of people affected, the platform, version, frequency, and period. If there is no number, honestly note your confidence level.
- Where to do it
- Next to the technical trail and a link to the support requests.
- What the result looks like
- 84 users in 7 days; Android 12 only; confirmed by 12 support requests and one error cluster.
Assign a priority and a workaround
Security, money, data, and a blocked key action come first. While the fix is in progress, support must know how to help the user safely.
- Where to do it
- In the P0–P3 columns: owner, deadline, and workaround.
- What the result looks like
- P0; owner — the backend team; deadline — today 18:00; support checks the status by ID.
Close on data, not on release
After the fix, repeat the scenario and make sure both the technical signal and the user complaints are gone.
- Where to do it
- In the task, 24–72 hours after the fix ships.
- What the result looks like
- The error cluster is gone, 20 test runs pass, and no new requests on the topic for two days.
03
Practical examples
P0: transaction status stuck
The problem hit 84 users in a week: the result is invisible, so people repeat the action. There is a financial and trust risk — an owner and a safe support reply are needed today.
P1: empty history on Android 12
The scale is smaller, but key data is unavailable. The task records the version, a repro video, the temporary restart workaround, and a support-request check 48 hours after the hotfix.
A priority table the whole team understands
Five rows are enough for the first decision. Do not hide the impact behind a technical bug name.
| Problem | Impact and scale | Workaround | Decision |
|---|---|---|---|
| Transaction status stuck | Money/trust · 84 users | Support checks manually | P0 · fix today |
| Login code not delivered | Blocks login · Android 12 | Resend after 60 seconds | P0 · Android developer |
| Empty history | Data not visible · version 4.2 | Restart the app | P1 · urgent fix |
| Push opens the home screen | Extra step · 11% of taps | Open the section manually | P2 · next release |
| Misaligned icon | Appearance only | Not needed | P3 · design debt |
Rule: P0 blocks or corrupts money, data, security, or the main journey. Every P0 has an owner, a deadline, a message for support, and a way to verify the fix.
04
Prioritization checklist
A critical task should read the same to product, support, and development.
05
How to know the fix worked
Technical signal
The specific crash cluster, ANR, or error code disappeared on the affected version.
User journey
The success rate of logins, saves, transactions, or the other broken action recovered.
Support and trust
New requests on the topic stopped, and users who hit the problem received a clear answer.
A bug is closed not when the code ships, but when users complete the journey again and the data confirms it.