Feature Requests vs Bug Reports: How to Tell the Difference
Most feedback isn't clearly a bug or a feature request. Here's how to classify the gray areas reliably and why getting it wrong slows down your whole team.
Triagly Team
"The export button doesn't work." That's a bug. "I wish you had dark mode." That's a feature request. Easy.
Except most feedback isn't that clean. "It used to work differently." "I expected this to do X." "This should exist." These sit in a gray zone, and getting the classification wrong has real consequences. Bugs treated as features take longer to fix. Features treated as bugs get rushed through without proper design.
Here's how to tell the difference reliably.
The Core Distinction
A bug is when something that should work doesn't. The product has defined behavior, and it's failing to meet it.
A feature request is when something doesn't exist yet. There's no current behavior to fail. It's an absence, not a failure.
Simple framework. Messy in practice.
The Gray Areas
"It's Not Working Like It Used To"
This looks like a bug. Something changed. But was the change intentional?
If you deliberately changed a behavior, that's not a bug. If you broke something by accident, it is. The question isn't "did it change?" but "was the change intended?"
"I Expected It To Work This Way"
If your docs or marketing promised certain behavior and the product doesn't deliver, that's a bug. The customer had a reasonable expectation you set.
If they assumed how it would work with no basis, that's a feature request for better defaults or clearer UX.
"This Should Exist"
Is it a missing feature, or a missing piece of something that exists?
"Dark mode should exist" is a feature request. "The export function should allow CSV, not just PDF" depends on context. If the original export was designed to be flexible, CSV support might be closer to a bug. If PDF was always the spec, CSV is a new feature.
Ask: does this build on something that exists, or does it create something entirely new?
"It Crashed"
A crash is a bug. But intermittent crashes under specific conditions need investigation before classification. Reproducible code failures are bugs. Environmental mysteries might be something else entirely.
How to Classify
Check the Spec
What is the product supposed to do? Deviation from that is a bug. Addition to it is a feature. If your docs say "exports to PDF" and it doesn't, that's a bug. If it exports to PDF but customers want CSV, that's a feature.
Look for Broken Promises
Anything you explicitly committed to in marketing, sales, onboarding, or docs that doesn't work is a bug. No promise? Harder to call it a bug. A missed expectation isn't the same as a broken contract.
Apply the "New Project" Test
If you were building this from scratch, would you include this? If yes, it's a feature request. If it's just fixing something that should already work, it's a bug.
Why This Matters
Priority and Speed
Bugs should usually get faster attention. A broken experience is more urgent than a missing one. Misclassifying a bug as a feature delays the fix. Misclassifying a feature as a bug rushes it without proper design. If you're already struggling with prioritization, wrong classification makes it worse.
Team Routing
Different people handle bugs and features. Support triages bugs. Product owns features. Engineering allocates time differently for each. Wrong classification sends work to the wrong team.
Customer Communication
"We're fixing this bug" creates different expectations than "We've added this to our roadmap." Customers deserve accurate information about what's happening with their feedback.
Building a System
Create a Classification Guide
Document clear examples of bugs, features, and gray areas. Share it with your team. When different people classify the same feedback differently, you have a consistency problem.
Use a Taxonomy
Add categories to your feedback at capture: bug, feature, improvement, question. This makes analysis easier and decisions clearer.
Triagly handles this automatically. AI reads incoming feedback and classifies it as a bug report, feature request, improvement suggestion, or question. No manual tagging needed, and the classification stays consistent regardless of who submitted the feedback or which channel it came through.
Review Gray Areas Together
When ambiguous cases come up, discuss them as a team. Build shared understanding of where your lines are. Over time, classification gets faster and more consistent.
The Practical Takeaway
Most feedback isn't perfectly clear. That's okay. What matters is having a reliable process: check the spec, look for broken promises, and apply the new-project test. Build classification into your workflow instead of deciding ad hoc every time.
The cost of getting this wrong isn't catastrophic for any single item. But across hundreds of pieces of feedback, consistent misclassification compounds. It slows bug fixes, delays features, and confuses your team about where to focus. When you're dealing with feedback at scale, getting the basics right matters even more.