Bug Report vs Feature Request: What's the Difference?
Your issue tracker is full of tickets, and half of them are mislabeled. Someone filed a “bug” because the app doesn’t support dark mode. Another person submitted a “feature request” because the payment form silently drops their credit card number. Neither label is correct, and the mislabeling creates real problems downstream.
The distinction between a bug report and a feature request seems obvious in theory but gets murky in practice. Getting it right matters because the two follow completely different workflows, involve different stakeholders, and compete for different budgets.
What Is a Bug Report?
A bug report documents something that is broken — the software doesn’t behave as specified, as designed, or as a reasonable user would expect. The key word is defect. Something was supposed to work a certain way, and it doesn’t.
Examples of bugs:
- Clicking “Submit” on the registration form returns a 500 error
- The total in the shopping cart doesn’t include tax, even though the design spec says it should
- The app crashes when a user uploads a HEIC image on Android
- Email notifications stop arriving after a user changes their timezone
In each case, there is an existing expectation — explicit or implied — that isn’t being met. The software is failing to do what it’s supposed to do.
What Is a Feature Request?
A feature request proposes something new — a capability, behavior, or improvement that doesn’t currently exist. The software isn’t broken; someone wants it to do more than it does today.
Examples of feature requests:
- “Add dark mode support”
- “Allow users to export reports as PDF”
- “Support login via Apple ID”
- “Show a progress bar during file uploads”
None of these describe defects. They describe desired enhancements. The software works as built — it just doesn’t do everything the requester wants.
The Gray Area
The tricky cases live in the space between “it’s broken” and “I want something new.” Here are the most common gray areas and how to classify them.
Performance issues. The page loads, but it takes 15 seconds. If there’s a documented performance target and the software misses it, that’s a bug. If no target exists and the page has always been slow, it’s an improvement request.
Missing validation. The form accepts an email without an ”@” symbol. If the spec says “validate email format,” it’s a bug. If validation was never specified, it’s a feature request.
Design inconsistency. A button is blue on one page and green on another. If the design system specifies button colors, it’s a bug. If there’s no design system, it’s an improvement request.
Unintuitive behavior. The app logs users out after 5 minutes with no warning. Users hate it. But if that’s the intended behavior per the spec, it’s a feature request to change the policy.
The guiding question is always: Does a specification, design, or reasonable expectation exist that the software is failing to meet? If yes, it’s a bug. If no, it’s a feature request.
Why Correct Classification Matters
Mislabeling creates tangible problems.
Bugs labeled as feature requests get deprioritized. They enter a product backlog and wait for roadmap planning, while users continue experiencing a broken workflow. A payment processing error sitting in the feature request queue could cost real money every day it goes unaddressed.
Feature requests labeled as bugs create false urgency. The development team drops what they’re doing to investigate a “critical bug” that turns out to be someone wanting a new export format. Time and focus are wasted, and actual bugs get displaced.
Metrics become unreliable. If your team tracks bug count, resolution time, or defect density, mislabeled tickets pollute those numbers. You can’t improve what you can’t accurately measure.
How to Handle Each in Your Tracker
For bugs: Use a structured format with environment details, steps to reproduce, expected vs. actual behavior, and severity. Route to engineering. See our guide to writing bug reports for the full framework.
For feature requests: Capture the user need, not just the proposed solution. Route to product management for prioritization.
For gray areas: When in doubt, file it as a bug. It’s better to investigate a potential defect and reclassify it than to let a real bug languish in the feature request backlog.
A clean tracker with correctly classified tickets ensures that broken things get fixed, new ideas get proper evaluation, and nobody wastes time working from wrong assumptions.