Prioritize bugs by frequency and severity

Score frequency and severity separately

A bug can be common and trivial, or rare and critical. A typo in a help text is seen by many people, but it blocks nobody. A failed payment is rare, yet every case costs money and trust. Score the two dimensions separately and combine them afterward. A single gut-feel number hides exactly the bugs you need to see.

Build the 2x2 grid

Draw a grid with severity on one axis and frequency on the other. Place each open bug in one cell.

	Rare	Frequent
High severity	Fix soon, and find the root cause	Fix now
Low severity	Backlog, and document the workaround	Schedule with related work

The top right cell goes first. The top left cell still gets a date, because a rare failure that loses data can damage trust in one afternoon. The bottom row can wait, but batch those fixes with other work in the same area so you do not pay the context-switching cost many times.

Escuta Produto does not draw a grid view, so keep this in a shared spreadsheet or document, with one row per bug and a link back to the inbox item.

Estimate frequency from feedback

Frequency is the number of distinct customers who hit the bug in a set period. Feedback gives you a partial count, so be clear about what you are counting.

Start by grouping bug items that describe the same symptom. The widget saves the page URL and the browser automatically, so use those fields together with the words in each message. Then count distinct customers. If items carry an email or an ID, count the unique values. If they are anonymous, count the items and call the total a minimum.

For example, nine bug items mention the invoice page not saving in one browser, and they come from six distinct customers. That is a frequent bug, even though the team heard about it nine times. The gap between messages and people is exactly what this count is meant to expose.

Quiet customers are missing from the count. Someone who leaves without writing still hit the bug. When you have error logs or support tickets, use them to check whether the feedback count understates the problem.

Estimate severity from what the customer lost

Severity is the damage done to someone who hits the bug. Judge it by what the customer lost, not by how upset they sound. Four levels work for most teams:

• Critical: data loss, a login that cannot succeed, a payment that fails, or a security problem.
• High: a core task cannot be finished and there is no workaround.
• Medium: the task takes longer, but a workaround exists.
• Low: visual or wording issues that do not stop work.

Critical and high belong in the top row of the grid. Medium depends on reach: put it in the top row when many customers hit it on a main path.

Two reports show the difference. One says the export button shows an error and no file downloads, which costs the customer a month-end report. The other says a tooltip overlaps the menu on a narrow window. The first is high severity even if it arrives once a week, because it blocks a core task with no workaround. The second is low severity even if many people see it, because nothing is lost.

What goes first

Apply three rules in order:

1. Any critical bug goes to in progress right away, however rare it is.
2. High-severity bugs that many customers hit come next. These are the fix now cell.
3. Batch the low-severity frequent bugs into one release. Close low-severity rare bugs that have a clear workaround, with an internal note that describes the workaround.

A bug that moves from rare to frequent after a release should move up right away, because the rising count is itself the evidence.

Reply to every customer whose bug you schedule. Read how to follow up on a bug report for wording that asks for missing detail without sounding like a support script.

Set up the grid with Escuta Produto

Escuta Produto gives you most of the inputs: a type filter (bug), statuses (new, planned, in progress, done and closed), the page URL and browser saved with each item, the 30-day chart and private internal notes. A weekly routine looks like this:

1. Filter the product inbox to type bug and status new.
2. For each item, read the page URL and browser, then search the inbox for the words customers used to find other reports of the same symptom.
3. Write the severity level and the distinct customer count in an internal note, for example "high, 4 customers, invoice page".
4. Move the bug to planned or in progress, and place it in the grid.
5. Watch the 30-day chart after each release. A rise in bug items means the grid needs a fresh look.

Every new item also posts to Slack or Discord when you have a webhook set up, so critical reports reach the team quickly. Setup steps are in the notifications docs. For the wider triage routine, read what is feedback triage.