A bug is your product failing to do what it was built to do. A feature request asks it to do something new. The distinction sounds obvious until a shared support inbox blurs it, and misfiled items quietly start costing you.
I have spent the last two years building Feeqd, a feature request tracking tool, and the bug vs feature request question comes up most weeks. Rarely because the definitions are hard. Almost always because a misfiled item is expensive: a real defect parked in a voting queue where it goes unseen, or a wishlist item fast-tracked as a "critical bug" it never was.
This guide covers the real difference, the gray area where it genuinely is not obvious, and the part most articles skip: bugs and feature requests need two different triage systems, not one shared list.
What Is a Bug?
A bug is a defect. The product behaves differently from how it was designed or documented to behave. An intended behavior already exists, whether in a spec, a help doc, or a reasonable user expectation, and the product is not delivering it.
A few examples:
- The export button returns a 500 error.
- A saved draft disappears after a page refresh.
- Two buttons overlap on mobile, so neither is tappable.
The defining trait of a bug is a gap between promised and actual. Nobody decided the export button should fail. It is broken, and fixing it returns the product to its intended state. A bug has a correct answer.
What Is a Feature Request?
A feature request is a proposal for new or improved functionality. The product works as designed, and a user wants the design to change. Nothing is broken, so there is no defect to fix. There is a decision to make.
A few examples:
- "Can the export support PDF, not just CSV?"
- "I want to assign a request to a teammate."
- "Add a dark mode."
A feature request does not have a correct answer, it has a trade-off. Building it costs engineering time and adds surface area to maintain. For the fuller picture of what a feature request is and how to write a good one, we have a dedicated guide. The short version: a feature request is a want, not a defect.
Bug vs Feature Request: The Key Differences
In short: a bug is broken behavior to restore, a feature request is new behavior to decide on. The two differ on nearly every axis that matters for how you handle them, as the table below summarizes:
| Dimension | Bug | Feature Request |
|---|---|---|
| Definition | Product fails to do what it was designed to do | Proposal to make the product do something new |
| Baseline | Intended behavior already exists | No intended behavior yet, it is being proposed |
| Decision needed | When to fix, not whether | Whether to build it at all |
| Priority driver | Severity and reach of the breakage | Demand, strategic fit, and effort |
| Who prioritizes | Engineering and support, by impact | Product, with user votes as input |
| Lifecycle ends when | Intended behavior is restored | Feature ships, or is declined |
| Healthy backlog | Trending toward zero | Always full, and that is fine |
That last row matters more than it looks. A growing bug backlog is an alarm. A growing feature request backlog is just a product with engaged users. Apply the same urgency rules to both and you break each of them.
What Happens If You Misclassify a Bug or Feature Request?
Misfiling is not a tidiness problem. It changes what gets built, and when.
A bug filed as a feature request goes quiet. Real breakage lands on a voting board, waits for upvotes it will never get (nobody upvotes "the app is broken," they just leave), and sits there while the team ships shiny things. The user who hit it churns, and you never connect the churn to the cause.
A feature request filed as a bug jumps the line. Label a wishlist item a "critical bug" and it inherits a defect's urgency. It skips prioritization, pulls an engineer off planned work, and quietly bends the roadmap. Do this a few times and every stakeholder learns the trick: the fastest way to get something built is to call it a bug. Now your bug tracker is a lobbying channel, and you have lost the one queue that was supposed to be objective.
Picture a common case. A user writes: "the CSV export is broken, it does not include my custom fields." It sounds like a bug. But the product never exported custom fields, it was never built to. This is a feature request wearing a bug's clothes. File it as a bug and an engineer burns an afternoon "fixing" code that works correctly. File it right and it goes where trade-off decisions belong.
The cost is never just the one mislabeled item. It is the slow erosion of two systems that only work while they stay separate.
The Gray Area: When It Is Genuinely Not Obvious
Most items are easy to classify. A few are not, and pretending otherwise just produces confident misfiles. The hard cases:
- Unspecified behavior. The product does something, but no spec ever said what it should do. With no intended baseline to compare against, "wrong" becomes a judgment call.
- Behavior users depend on. Sometimes a bug becomes load-bearing. Users build workflows on the broken behavior, and "fixing" it breaks them. As Jeff Atwood argued back in 2008, the line between the two is often a matter of intent, not code.
- Bad UX that technically works. A confusing flow is not a defect, the code runs fine. But calling it "working as intended" is a cop-out. It is a feature request to redesign the flow.
- Regressions. Something that used to work and now does not. That is a bug, even if the thing that broke was itself once a feature.
The one-question test
One question cuts through most of it:
Did the product fail to do something it was designed, documented, or reasonably expected to do? If yes, it is a bug. If it is being asked to do something new, it is a feature request.
When the question still does not settle it, default to feature request. Feature requests get a deliberate decision, while bugs get fast-tracked. It is safer to make a borderline item earn its place than to let it skip the queue.
How to Triage Each: Two Systems, Not One
Here is the part most "bug vs feature" articles skip. Once an item is classified, the two types need genuinely different handling. The same inbox cannot serve both well.
Triage bugs by severity
Bugs do not get voted on. Nobody upvotes a crash, and waiting for community demand on a defect is how data loss sits open for a month. Bugs are triaged by severity and reach, quickly, by whoever can assess impact:
- Severity: how badly is the user blocked? Data loss and security issues outrank a cosmetic glitch, every time.
- Reach: one edge-case account, or every user on Safari?
- Reproducibility: a reliable repro is already halfway to a fix; a vague report is not.
The goal is a short path from report to fix, and a backlog that trends down.
Triage feature requests by demand
Feature requests are the opposite. There are always more than you can build, none of them are broken, and the real question is "is this worth it?" That calls for demand plus judgment:
- Let users vote, so real demand is visible instead of guessed. A feature voting board turns "a few people asked" into "fifty-three people want this."
- Score the top of the list with a framework. Our guide to prioritizing feature requests covers RICE and how vote counts feed the Reach input.
- Accept that the backlog stays full. That is a healthy product, not a failure.
Keep them in separate boards
The cleanest way to run two triage systems is to give each its own board. In Feeqd, that is built into the board types: a Bugs & Fixes board and a Feature Requests board, each with its own status workflow. Bugs move fast and quiet toward zero, feature requests collect votes and feed the roadmap. A single shared "feedback" board collapses the distinction the moment it gets busy, which is exactly when you need it most.
Bug vs Feature Request Is a Routing Decision
Whether your team frames it as bug vs feature request or feature request vs bug report, the question is not pedantry, it is a routing decision. Classify it wrong and a real defect goes silent while a wishlist item jumps the queue. Classify it right, send each to its own board, and both systems do their job: the bug queue trends toward zero, and the feature request queue collects the demand signal that builds a roadmap worth shipping.
FAQ
What is the difference between a bug and a feature request?
A bug is a defect: the product fails to do something it was designed or documented to do, so there is a correct state to restore. A feature request is a proposal for new functionality: nothing is broken, the product is being asked to do something it was never built to do. Bugs have a right answer; feature requests have a trade-off.
Is it a bug or a feature request?
Apply one test: did the product fail at something it was designed, documented, or reasonably expected to do? If yes, it is a bug. If the user wants the product to do something new, it is a feature request. When a borderline case will not resolve, default to feature request, so it earns a deliberate decision instead of skipping the queue as a "bug."
When does a bug become a feature request?
A bug becomes a feature request in two situations. First, when a bug report actually describes behavior the product never offered: the user says something is "broken" when they really want something new, so it was a feature request from the start, just mislabeled. Second, when a long-standing bug becomes load-bearing: users build workflows around the broken behavior, so removing it has to be treated as a product decision, not a quiet fix.
What is the difference between a bug and an improvement?
An improvement is a type of feature request: it asks to make existing functionality better, faster, or clearer, rather than adding something brand new. Like any feature request, an improvement carries a trade-off and a priority decision. A bug is not optional, the current behavior is wrong, and fixing it restores the intended state.
Where does "it's not a bug, it's a feature" come from?
The phrase is old developer humor, used sincerely when shipped behavior turns out to be useful, and sarcastically when a team waves away a defect. The widely cited reference is Jeff Atwood's 2008 essay "That's Not a Bug, It's a Feature Request," which argued the line is often about intent rather than code. As a triage rule it is a joke, not a method: classify by whether the product met its intended behavior, not by what is convenient to call it.
Get started with Feeqd for free
Let your users tell you exactly what to build next
Collect feedback, let users vote, and ship what actually matters. All in one simple tool that takes minutes to set up.
Sign up for free