How much feedback is enough to act on?

Is one report enough to act on?

Sometimes, yes. One report is enough when it describes a severe failure you can reproduce, such as a payment that charges twice or data that disappears after saving. Waiting for a second report in that case means waiting for a second customer to get hurt.

For most feature requests, one report is not enough. One person asking for a feature tells you what that person wants. It does not tell you how many people share the need, how often it comes up, or what it would be worth to them. The right response is to note it, ask one clarifying question, and watch for the next matching report.

The honest answer depends on the kind of feedback, so judge bugs and ideas separately.

Why should severity beat volume for bugs?

Volume measures how often people complain. Severity measures how much a failure hurts when it happens. For bugs, severity is the better first sort. A crash on the only page where customers can pay is more urgent than fifty reports about a misaligned footer, even though the footer gets more mentions.

Frequency still matters, because it tells you how many customers are affected. The two work together. Use severity to decide whether a bug is urgent at all, and frequency to decide how many customers it touches. The frequency and severity guide sets out a grid for this.

A quick test for severity: if this bug happened to one customer today, would they lose money, lose data or stop using the product? If yes, act on one report.

When does a request deserve a second look?

A request earns a closer look when it arrives from several distinct customers, in similar words, about the same job. Count customers, not messages. Three messages from one account are one data point.

Look for these signs before you spend engineering time:

• The request names the same situation in different words.
• Customers who ask are paying, active or in a segment you care about.
• The request blocks a step that other customers also reach.
• Someone has worked around the gap, for example with a spreadsheet or a manual export.

A workaround is especially useful evidence. People only build a workaround for a need that matters to them.

Ask what the workaround costs. If customers export to a spreadsheet, retype data between tools, or keep their own list of requests, the cost is visible, and you can estimate it in hours a week. A request that saves several customers an hour a week is easier to justify than one that saves a few minutes once a quarter.

How do you tell a signal from an anecdote?

An anecdote is one vivid story. A signal is a pattern that survives a second look. Use three checks on each claim:

1. Repetition: has a second distinct customer described the same thing?
2. Reproduction: for bugs, can you make it happen on purpose?
3. Context: does the request fit the product's direction, or only one customer's unusual setup?

A single report that passes all three is worth acting on. A dozen reports that fail the second check are a guess until someone reproduces them.

A worked example with three cases

Take three situations from the same week. The numbers are invented for illustration.

Case	What arrived	Decision
A	One bug report: export file is empty for a customer with no data in the last month	Reproduce now. If confirmed, act on one report, because it affects data.
B	Four idea reports for a dark mode, from four different customers	Note it, ask one follow-up, and add it to the canonical request list.
C	Twelve messages about the search being slow, from three customers	Check the page URL and reproduce the slow query. Volume is high, but the customers are few, so treat it as one bug with a wider impact.

Case A acts on one report because the severity is high and the failure is concrete. Case B waits because the signal is real but not yet urgent. Case C shows why counting messages misleads: twelve messages from three customers is a smaller population than it looks.

What should you write down before you decide?

For each item you choose to act on or set aside, write one line of reasoning in an internal note. Include the number of distinct customers, the severity or the job behind the request, and the date you decided. When someone asks in a month why a request was declined, the note answers the question without a debate. The guide to saying no to feature requests has wording you can reuse.

Revisit those notes at the weekly review. The weekly feedback review template includes a step for this.

Checking the signal inside Escuta Produto

Escuta Produto gives you the raw inputs for this decision. Filter the inbox by type to separate bugs from ideas, then sort the bug list by the severity you judge from the message. Use the rating and the page URL in each item to see how serious and how local a bug is. Count distinct customers from the email field and from your notes, since the product has no voting or merge feature.

For the rest of the workflow, the widget docs explain how feedback reaches the inbox with the page URL attached, and the notifications docs show how to route urgent reports to Slack or Discord so a severe bug is seen the same day.