Bug vs. Feature Request: How to Tell Them Apart in Triage

A bug is a gap between what your product promised and what it actually does — the promise coming from a spec, documentation, prior behavior, or a reasonable user expectation. A feature request asks the product to do something it never promised in the first place. The quickest way to tell them apart: if the behavior worked before, was documented to work, or any reasonable user would expect it to work, it's a bug; if it's a new capability nobody ever committed to, it's a feature request.

What is the difference between a bug and a feature request?

The distinction is about expectation, not effort or severity. A one-line typo fix and a month-long rebuild can both be bugs; a trivial toggle and a major integration can both be feature requests. What decides the category is whether the reported behavior breaks a commitment the product already made.

• Bug: The product has an expected behavior — stated or implied — and does something else. Examples: a checkout button that returns a 500, a saved draft that disappears on refresh, a filter that returns the wrong rows.
• Feature request: The product behaves exactly as built, and someone wants it to do more or differently. Examples: "add dark mode," "let me export to CSV," "support bulk edit."

Two reports can describe the same screen and land in opposite categories. "Export is broken" is a bug if an export button exists and fails; "we need an export" is a feature request if export was never built. Getting the category right starts with knowing what was actually promised.

How to tell a bug from a feature request in under a minute

Run each incoming report through the same short check so classification comes from facts, not from whoever argues loudest in triage.

1. Check the expectation. Is there a spec, acceptance criterion, or doc that says what should happen? If the behavior contradicts it, it's a bug.
2. Check prior behavior. Did this work in an earlier release? A regression is always a bug — no spec required, because the working version was the spec.
3. Reproduce it. Confirm the behavior is real and consistent before you argue about its label. A report you can't reproduce isn't ready to classify.
4. Ask: broken or absent? Broken existing behavior is a bug. An entirely absent capability is a feature request. This single question resolves most disputes.
5. Route accordingly. Send bugs to the fix queue with a severity and an SLA; send feature requests to the roadmap backlog where they compete on business value.

The gray areas that cause triage arguments

Most disagreements cluster in a handful of edge cases. Handle them with a default rule so the team stops relitigating each one.

"It works as designed, but the design is wrong"

This is a design defect. The code matches the spec, but the spec produces a bad outcome users hit today — a confusing empty state, a destructive action with no confirmation, a form that accepts invalid input. Triage it as a bug with a note that the fix needs a design decision, and route it to whoever owns that surface. Filing it as a feature request tends to bury it in the roadmap, where a live problem waits behind net-new work.

Missing validation or error handling

If the product accepts input it should reject, or fails without telling the user why, that's usually a bug: the implied contract of any input is that it validates and reports failure. "Add a nicer error message" on a path that already handles the error is closer to an enhancement.

Undocumented behavior someone relied on

When a change breaks a workflow that was never officially supported, reasonable people disagree. Decide it by impact and reach: if many users depended on it and had no warning, treat it as a bug (or at least a breaking change that needs a migration path), not a feature request to "bring it back."

Performance and UX complaints

"It's slow" or "this is confusing" is a bug when it violates a stated target or a clear expectation (a page that used to load in a second now takes ten), and a feature request when it asks for a better-than-promised experience. Anchor the call to a measurable expectation wherever one exists.

Why the distinction actually matters

Getting the label right isn't pedantry — it changes three concrete things:

1. Routing and SLA. Bugs typically carry response and resolution targets by severity; feature requests enter the roadmap and are scheduled by value. Misfiling a bug as a feature strips it of its deadline.
2. Quality metrics. Bugs count toward escaped-defect rate, reopen rate, and mean time to resolution. A bug hidden in the feature backlog quietly makes your quality numbers look better than they are.
3. Ownership and accounting. Fixing a broken promise is maintenance the team already owes; building a new capability is a prioritization choice. Teams that blur the two end up shipping features while known breakage lingers.

Classify from evidence, not opinions

Every rule above depends on knowing what actually happened, and most triage fights are really disputes about the facts. The fix is to capture the evidence at report time — exact steps, the environment, and the console and network state — so a triager can see whether behavior is broken or merely absent instead of guessing. In-app capture like Klavity Snap attaches that context to every report, which turns "is this a bug?" from an argument into a lookup. Once reports arrive with evidence, you can triage the backlog quickly and route each item to the right queue with confidence.