When a feature request is actually a bug report
5 min read
“Can you add a setting to increase the export limit?” reads like a feature request, and most triage systems label it one on the spot. Sometimes it is. Sometimes the export is failing at a number lower than the documented limit because of a bug, and the customer, unable to see the code, has invented the most plausible fix they can describe: give me a bigger number and maybe it will work. What labels are worth using covers the type label that splits a backlog into feature requests and bugs; this is the case where a customer’s own words point the label the wrong way, and the cost of getting it wrong is a slow drift toward a backlog full of asks nobody actually wants once you look underneath.
What does a feature request that is really a bug report look like?
It names a workaround instead of the problem. A genuine feature request usually describes an outcome the product does not support at all: “let me schedule this for later,” “add a dark mode.” A miscategorized bug report describes a specific number, threshold or behavior that sounds like a missing setting but is actually a symptom: “increase the timeout,” “add a retry option,” “let me export more rows at once.” The tell is that the requester is proposing an implementation, a setting, a toggle, an override, rather than describing a goal, because they have already tried the feature as documented and it did not do what the documentation says it should.
| Signal | Feature request | Bug report wearing a feature request’s label |
|---|---|---|
| What the requester describes | An outcome the product cannot do | A parameter they want to change |
| Whether the documented behavior already covers this | No, genuinely missing | Yes, but it is not working as documented |
| Whether increasing effort makes the ask disappear | No | Sometimes, if the bug happens to be threshold-related |
| Where it should route | Product backlog | Bug queue |
Why does this matter more than it sounds like it should?
Because the two queues have different owners, different timelines and different success criteria, and a bug filed as a feature request gets prioritized against feature requests, competing for attention with genuine product gaps instead of getting fixed on the schedule a bug deserves. How to track feature requests covers why mixing bugs and features in one queue lets the loudest complaints crowd out real asks; a feature request that is secretly a bug does the opposite kind of damage, sitting in the product backlog accumulating votes for a “feature” that would vanish the moment the underlying bug got fixed, which wastes the prioritization signal for everyone reading that backlog.
How do you tell the difference when the customer’s own words point the wrong way?
Ask what they expected to happen, not what they want you to add. “The export capped at 500 rows and I need 2,000, can you raise the limit” sounds like a limit-increase feature request until the follow-up question, “is 500 the documented limit,” reveals the documented number was 5,000 and the export is failing early. That single question, what did you expect versus what happened, does most of the sorting work, because a genuine feature request has no documented behavior to fall short of; there is nothing to expect because the capability does not exist yet.
Should support agents or engineers make this call?
Support agents make the first pass, because they see the ticket first, but the label should be easy to change and cheap to get wrong, not a one-time decision that locks the item into the wrong queue forever. A lightweight second check, an engineer skimming new “feature request” labels weekly for anything that smells like a bug in disguise, catches the ones a support agent without codebase context could not have known to flag. This does not need to be formal; it is closer to a five-minute scan than a review process.
Does closing the loop change once you have found the real bug?
Yes, and it improves the message you get to send. Closing the customer feedback loop covers telling a requester when their ask ships; a recategorized bug gets a better version of that message, because “we found and fixed the bug behind this” reads as competence, where “we built the feature you asked for” would have been true only by accident, since the real feature request, a genuinely higher export limit, may never get built at all once the bug is gone and the original 5,000-row limit is enough.
What happens if you never catch the miscategorization?
The backlog fills with asks that look like real demand and are not, and prioritization decisions made against that backlog inherit the distortion. A “feature” with forty votes might really be forty people hitting the same bug, and building the literal ask, a setting to raise a limit that was never actually the constraint, ships complexity that fixes nothing, while the underlying bug continues to generate new “feature requests” from customers who have not yet found this thread.
FAQ
Is it worth adding a formal step to check every feature request against known bugs? Not a formal step, a habit: whoever triages a new feature request should ask “does the documented behavior already claim to do this” before applying the label, since that one question catches most of the miscategorized ones without adding process overhead.
What if the customer insists it is a feature request even after the bug is found? Explain what you found and why the setting they proposed would not actually be needed once the bug is fixed. Most customers are asking for a workaround because they assumed the real fix was unavailable, not because they specifically wanted the setting.
Does a recategorized item lose the votes or comments it collected as a feature request? It should keep them, visibly, because those votes are the evidence that led to finding the bug in the first place, and hiding that trail makes the same miscategorization harder to catch next time it happens on a different ticket.
Can this happen in reverse, a bug report that is really a feature request? Less often, but yes: “this is broken” sometimes means “this does not do what I assumed it should,” which is a missing capability, not a defect. The same question, what did you expect versus what is documented, sorts this direction too.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.