When a feature request is really a bug in disguise

The test: was this already supposed to work?

Customers often describe a bug as a missing feature. "Please add a way to export all my projects" can mean the export button exists but skips archived projects, which is a bug. It can also mean there is no export at all, which is a real request. The words are the same, and the difference is in what the product already promises.

The test that cuts through this is simple: was this already supposed to work? If the product has a page, a button, a setting or a line in the docs that promises the behavior, and the customer is not getting it, the request is a bug. If the behavior is new, with no promise behind it, the request is a feature. Most triage mistakes come from skipping this question and reacting to the wording.

Compare the expected behavior with the new behavior

Write two short sentences for every ambiguous item. The first says what the customer expected to happen, based on what the product shows or documents. The second says what happened, based on the message and the page URL. If the first sentence describes behavior the product already has, the request is probably a bug. If the first sentence describes something the product has never done, it is a feature.

Here is an example. A customer writes, "The invoice filter does not show drafts, please add it." Your expected behavior sentence reads: the filter should list drafts, because the filter list has a drafts option. Your observed behavior sentence reads: the drafts option is there, but selecting it shows nothing. That is a bug dressed up as a request.

Common disguises

Some patterns show up again and again. Learn to recognize them, because they are quicker to spot in a batch of messages than one at a time:

• A setting that does nothing. The customer turned it on and nothing changed.
• A limit that is wrong. The product says five items and stops at four, or never stops.
• A missing row or file. An export, list or report skips some records.
• A broken repeat. A feature works the first time and fails on the second try.
• A text problem. A label is cut off, a translation is missing, or a date is shown in the wrong format.
• A confused flow. The customer expected to go back and the button did something else.

If the message describes any of these, the feedback is a bug report, even if the customer used the words "please add".

Reclassify during triage

Reclassify deliberately, not by accident. A short routine helps:

1. Read the message and write the expected behavior and the observed behavior in one note each.
2. Check the page URL and the metadata to see where the problem happened.
3. Search the inbox for two or three distinctive words to find other items that describe the same gap.
4. If the gap is a broken promise, record "reclassified as bug" in an internal note, with the expected and observed sentences.
5. Set the status to in progress or planned, depending on whether you will fix it now or later.

The note matters because the type in the inbox is the one the customer picked. In Escuta Produto, the type cannot be changed from the dashboard, and only the status can be updated. So the reclassification lives in the note and the status, and anyone who reads the item sees the real classification. Keep this in mind when you count requests: a feature count that includes reclassified bugs is not an honest count of new work.

Reply the way you would to a bug

Once you know it is a bug, the reply should sound like a bug reply. Confirm the problem in the customer's terms, say what you found, and say what you will do next. Do not defend the wording of the request, and do not tell the customer they asked for the wrong thing.

Hi Ben, thanks for asking about the drafts in the invoice filter. The drafts option is supposed to list every draft, and when I select it the list comes back empty. That is a bug on our side, not a missing feature. I am fixing the filter now and will write again when it is live, so you can check it on your own drafts.

Notice that the reply names the broken promise. That is what makes the customer trust the fix instead of feeling handled.

When the customer insists it is a feature

Sometimes a customer knows the product does not promise the behavior, and they still want it. In that case the item is a feature request, and the honest answer is the same as for any request: thank them, record it, and set the status. Do not argue the classification. If you reclassify a request as a bug, check that the product really does promise the behavior, because a reply that calls a feature a bug will be found out.

Be careful with the middle ground, where the behavior is inconsistent across pages or plans. Write the inconsistency in the note and treat the fix as a bug, even if the cleanest fix is a new behavior. Then the customer hears that you agree something is wrong, which is the part they care about.

Triage and reclassification in Escuta Produto

In the Escuta Produto inbox, filter by type and status to find the feature requests that might be bugs in disguise. Read the message, then the page URL and the metadata, since a bug usually points to a specific page. Use the internal notes for the expected and observed sentences and for the reclassification, and set the status so the item shows its real state.

Write the reply from your own email to the address on the item. Escuta Produto does not send automatic emails, so the reply is yours to write. For the weekly routine that groups these items, see how to triage customer feedback. The bug follow-up steps, including confirming the fix with the reporter, are in how to follow up on bug reports, and the status meanings are described in how to design a feedback status workflow. For how the widget captures page URLs with each item, see the widget docs.