What is a feature request?
A feature request is a customer, colleague or stakeholder asking for something the product does not do yet. It might be a new capability, a change to something that already exists, or a connection to another tool they use.
Almost every request arrives as a solution. Someone hit friction, pictured a fix, and sent you the fix. The friction is the part worth having, because the fix they imagined is rarely the one you would build.
What a good feature request contains
Four things, and most requests are missing at least two of them.
- What they want. One sentence, in their words.
- What they cannot do today. The task that is blocked, not the feature that is missing.
- Who it affects and how often. One person once a quarter is a different request from twelve people every morning.
- What they do instead right now. The workaround. This is the one everybody leaves out and the one that tells you the most.
If a request only has the first item, you have an idea. You need the other three before you can weigh it against anything else.
Feature request vs bug
A bug is the product failing to do something it already promises. A feature request is the product not promising it yet.
The line blurs more often than people expect. “Export is broken” can mean the export button throws an error, which is a bug, or that export exists but only produces PDF when the customer needs CSV, which is a request. Sorting the two correctly matters because they go to different queues, get different urgency and get judged by different standards. A bug has to be fixed. A request has to earn its place.
Types of feature request
- New capability. Something the product has never done.
- Improvement. Something it does, made faster, clearer or less manual.
- Integration. A connection to a tool the customer already works in.
Improvements and integrations get underrated. They tend to be cheaper to build and they come from people already using the product, which makes them better evidence than a request from someone who has not committed yet.
Feature request examples
“Can you add tagging?” The workaround was a naming convention in the title field that nobody on the team followed consistently. What they needed was a way to find things again, and search filters solved it without building tags.
“We need a Jira integration.” Already existed. They could not find it. That is a request that turns into a documentation and onboarding fix.
“Add bulk export.” Twenty accounts asked. Most were pasting the file into a weekly status document, so a shared view solved it for the majority and export stayed on the list for the few who genuinely needed the file.
How to handle feature requests
Collect them in one place. Requests arrive in support tickets, sales calls, in-app messages and Slack. Spread across four places, you cannot see that eleven people asked for the same thing.
Group before you count. The same request gets worded a dozen ways. Grouping by topic is what turns a list of comments into a number you can act on.
Score against something. How many people, how often, which segment, how much it costs to build. Any consistent scoring beats deciding in the meeting where the loudest person is present.
Tell people what happened. Including no. A customer who hears “not this quarter, and here is why” keeps sending you requests. A customer who hears nothing stops.
How Usersnap helps with feature requests
Requests come in through in-app widgets and micro-surveys, alongside bug reports, so the sorting happens in one place rather than across two tools. AI-powered automations group similar requests by topic and sentiment, which is the counting step most teams do by hand. The public board lets customers see and upvote what has already been asked, and the Opportunities Board is where a grouped request gets scored and turned into something on the roadmap. Jira, Jira Product Discovery and Linear integrations push it to the people who build it.
Feature request FAQ
What is the difference between a feature request and a change request?
A feature request asks for functionality that does not exist. A change request modifies something already built or already specified, often mid-project, and usually carries a narrower scope.
How do you write a good feature request?
State what you want in one sentence, describe the task you cannot complete today, say who it affects and how often, and explain what you do instead right now. The last one is the most useful and the most often missing.
How do you prioritize feature requests?
Group duplicates first so you are counting people rather than comments, then score on reach, frequency, segment value and build cost. What matters most is that the criteria are written down, so the decision does not change with whoever is in the room.
Should you build every requested feature?
No. Most requests are a customer proposing a fix for friction they hit. Build against the friction, and you will often solve the problem for more people than the original request would have.
Collect feature requests and bug reports in one place with Usersnap. Your first 20 feedback items are free, no card needed.
.svg)
