Bug vs Feature Request: How to Tell the Difference

A customer submits a report: "The search bar doesn't find results when I use special characters." Is that a bug or a feature request?

If special characters were never supported, it's a feature request. If they used to work and now they don't, it's a bug. If the documentation says they should work but they don't, it's also a bug.

The distinction seems pedantic, but it matters for how you prioritize, assign, and communicate about the issue. Bugs need to be fixed. Feature requests need to be evaluated. Mixing them up creates confusion for your team and frustration for your customers.

This guide defines the line between bugs and feature requests, walks through the grey areas where most teams get confused, and gives you a framework for classifying edge cases.

Clear Definitions

Bug: The product does not behave as expected based on its documentation, stated behavior, or previously working functionality. Something is broken.

Feature Request: The product behaves as designed, but the user wants it to behave differently. They're asking for something new or an enhancement to existing behavior.

The key distinction is expectation vs reality:

Scenario C is where things get interesting.

The Grey Areas

In practice, the line between "broken" and "not built yet" is blurry. Here are the most common grey areas and how to think about each one.

Slow Performance

A user reports: "The dashboard takes 12 seconds to load."

Bug or feature request? It depends.

• If you have a stated SLA or performance standard (e.g., "pages load in under 3 seconds") and you're not meeting it, this is a bug. You promised a level of performance and you're not delivering
• If there's no stated performance target and the page loads "slowly" in the user's opinion, this is a feature request for performance optimization
• If the page used to load in 2 seconds and now takes 12, that's a regression bug regardless of whether you have a formal SLA

Rule of thumb: Regressions are always bugs. Unmet expectations without a prior standard are feature requests.

Missing Validation

A user reports: "I can enter a negative number in the quantity field, and the system accepts it."

Bug or feature request?

• If the quantity field should obviously only accept positive numbers (it's a product quantity in an e-commerce context), most teams would call this a bug. The expected behavior is implicit even if undocumented
• If the field is generic and negative numbers could be valid in some contexts, it's a feature request for input validation

Rule of thumb: If any reasonable person would expect the validation to exist, it's a bug. If it requires domain-specific knowledge to know the validation is missing, it's a feature request.

Works But Not Intuitive

A user reports: "I can't figure out how to export data. It took me 20 minutes to find the button buried in the settings menu."

Bug or feature request?

This is almost always a feature request (specifically, a UX improvement request). The feature works; it's just hard to find or use. However, if the export button was recently moved and the change wasn't communicated, you could argue it's a regression in usability.

Rule of thumb: If the functionality works but the experience is poor, it's a feature request. If a recent change made it significantly worse, treat it with the urgency of a bug.

Works on Desktop, Not on Mobile

A user reports: "The drag-and-drop board works perfectly on desktop but doesn't work at all on my phone."

Bug or feature request?

• If you advertise mobile support or your app is responsive by design, this is a bug. You've set an expectation of mobile compatibility
• If mobile support was never part of the product scope and you've only built for desktop, this is a feature request

Rule of thumb: Check what you've promised. If your marketing, documentation, or app store listing implies mobile support, broken mobile functionality is a bug.

Data Displays Incorrectly Under Specific Conditions

A user reports: "When I filter by date range, the totals at the bottom don't update to reflect the filtered data."

Bug or feature request?

This is almost certainly a bug. If the totals exist and the filter exists, a reasonable user expects the totals to respect the filter. This falls into the "implicit expected behavior" category.

Third-Party Integration Stops Working

A user reports: "The Slack integration stopped sending notifications yesterday."

Bug or feature request?

If the integration used to work and stopped, it's a bug. This is true even if the root cause is on the third party's side. From the user's perspective, your product broke. You need to investigate and fix it.

Why the Classification Matters

Getting the classification right affects three things:

Prioritization

Bugs and feature requests follow different priority tracks:

• Bugs are evaluated by severity: Does it block users? How many are affected? Is there a workaround? Critical bugs jump the queue and get fixed immediately
• Feature requests are evaluated by demand, revenue impact, and strategic fit. They enter a prioritization process (like RICE or ICE) and compete for roadmap space

If you misclassify a bug as a feature request, it sits in a prioritization queue while users suffer. If you misclassify a feature request as a bug, your engineering team drops what they're doing to "fix" something that was never broken.

Team Assignment

Bugs typically go to the engineering team that owns the affected area. Feature requests go through product management for evaluation before any engineering work happens. Misclassification means the wrong team is looking at it.

User Communication

How you respond to the user depends on the classification:

• Bug response: "Thanks for reporting this. We've confirmed the issue and our team is working on a fix. We'll update you when it's resolved."
• Feature request response: "Thanks for the suggestion. We've added this to our feedback board where other users can vote on it. We'll evaluate it during our next planning cycle."

Sending a bug response for a feature request creates false urgency. Sending a feature request response for a real bug makes the user feel dismissed.

A Decision Framework for Edge Cases

When you're unsure whether something is a bug or a feature request, walk through these questions:

Step 1: Has this behavior changed recently?

• Yes, it used to work differently --> Bug (regression)
• No, it has always worked this way --> Continue to Step 2

Step 2: Is there documentation or marketing material that describes the expected behavior?

• Yes, and the product doesn't match --> Bug
• Yes, and the product does match --> Feature Request
• No documentation exists --> Continue to Step 3

Step 3: Would a reasonable person expect this to work?

• Yes, this is an obvious expectation (e.g., positive-only quantity fields, filters affecting totals) --> Bug
• No, this requires a design decision that could go either way --> Feature Request

Step 4: Are you unsure even after Steps 1-3?

• Classify it as a bug and investigate. It's better to investigate something that turns out to be a feature request than to ignore something that turns out to be a real bug

How to Handle Each in Your Feedback Tool

Your feedback tool needs to accommodate both bugs and feature requests. There are two common approaches:

Approach 1: Separate Boards

Create one board for bug reports and another for feature requests. This keeps the two streams cleanly separated and makes it easy to route items to the right team.

Pros: Clean separation. Bug board goes to engineering; feature board goes to product.
Cons: Users have to decide which board to submit to (and they'll often choose wrong). You end up moving items between boards.

Approach 2: Single Board with Tags or Categories

Use one board for all feedback and tag items as "Bug" or "Feature Request" (or "Enhancement," "UX Issue," etc.). Your team handles classification during triage.

Pros: Lower friction for users. They submit in one place and your team sorts it out.
Cons: Requires regular triage to keep things organized.

Our recommendation: Use a single board with categories or tags. It's less friction for users, and your team should be reviewing submissions regularly anyway. During triage, classify items, merge duplicates, and route to the appropriate team.

In ProductLift, you can use categories or tags to separate bugs from feature requests on the same board. Users submit feedback without worrying about classification, and your team applies the right label during review. This keeps the user experience simple while giving your team the structure they need. See our comparison of feature request tools for more options that support this workflow.

What to Tell Users Who Misclassify

Customers will report bugs as feature requests and feature requests as bugs. Here's how to handle both gracefully.

When a "bug report" is actually a feature request

Hi [Name],

Thanks for reporting this. After investigating, we've confirmed that [behavior] is actually working as currently designed. I understand it's not the behavior you expected, and that's valid feedback.

I've converted your report into a feature request on our feedback board so other users can vote on it. If there's enough demand, our product team will evaluate it for a future release.

You can track and vote on it here: [link to feedback item]

When a "feature request" is actually a bug

Hi [Name],

Thanks for submitting this. After looking into it, we've identified that this is actually a bug. [Behavior] should not be happening. Our engineering team has been notified and is working on a fix.

We'll update you once it's resolved. Sorry for the inconvenience, and thanks for catching this.

In both cases, the key is to acknowledge the user's effort, explain the reclassification without being condescending, and tell them what happens next.

Preventing Classification Confusion

You can reduce misclassification by making your feedback submission form slightly smarter:

• Add a dropdown with options like "Something is broken," "I'd like a new feature," and "I'm not sure." This primes users to think about the classification without forcing them to get it right
• Provide examples in your submission form. "Bug example: The save button returns an error. Feature example: I'd like a dark mode option."
• Don't make it mandatory. Some users genuinely don't know, and forcing them to choose leads to random selections. A "Not sure" option lets your team handle classification

FAQ

How do I classify a borderline case between bug and feature?

Walk through a simple checklist: Has the behavior changed recently? Does documentation describe the expected behavior? Would a reasonable person expect it to work? If you're still unsure after these steps, treat it as a bug and investigate. False negatives (ignoring real bugs) are more costly than false positives.

Who should decide whether something is a bug or feature request?

Your triage team (usually product or support) makes the initial call during regular review sessions. For ambiguous cases, loop in engineering to confirm whether the behavior is intentional. The key is to have a consistent process rather than ad-hoc decisions.

Should I track bugs and feature requests in the same tool?

Yes, using a single board with tags or categories reduces friction for users. They submit in one place without worrying about classification. Your team then applies the right label during triage and routes items accordingly.

Do bugs and feature requests have different SLAs?

Yes. Critical bugs that block users need immediate attention, often within hours. Feature requests follow a prioritization process and compete for roadmap space over weeks or months. Medium and low-severity bugs fall somewhere in between.

How do I handle a feature request that reveals a design flaw?

If the current design causes widespread confusion or frustration, treat the UX issue with bug-level urgency even though it's technically a feature request. User expectations matter. If many users hit the same friction point, the design needs fixing.

What if a customer disagrees with my classification?

Listen to their reasoning and ask clarifying questions. They may have context you don't (like a regression you missed). If you still classify it differently, explain your reasoning clearly and tell them what happens next. Transparency reduces frustration even when you disagree.

Wrapping Up

The bug vs feature request distinction is simple in theory and messy in practice. Regressions are bugs. New behaviors are feature requests. Everything in between requires judgment.

The most important thing isn't getting the classification perfect every time. It's having a consistent process for triaging, classifying, and communicating about both types of feedback.

When in doubt, investigate first and classify second. A bug treated as a feature request causes more damage than a feature request treated as a bug.

If you're looking for a tool that handles both bugs and feature requests in one place, ProductLift lets you collect all feedback on a single board with categories and tags to keep things organized. Your users submit naturally, and your team adds structure during triage.