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.
What should a feature request template include?
A feature request template should capture a title, the problem, who it affects and how often, the current workaround, a real use case and where the request came from. You can copy these fields into a form, a Jira issue or a support macro.
- Title: one line, in the requester's words.
- Problem: the task they can't complete today.
- Who and how often: role, team size or segment, and how often it happens.
- Workaround: what they do instead right now.
- Use case: one real situation where the feature would have helped.
- Source: the account and the channel, such as a support ticket, a sales call or an in-app form.
Teams forget the source field most often. Without it, nobody can tell the requester when the feature ships.
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 do you create a feature request in Jira?
Most teams log a feature request in Jira as a Story, or as a custom "Feature request" issue type, in the product backlog, with the template fields above in the description. Teams that use Jira Product Discovery log it as an idea instead and attach customer evidence before it becomes delivery work. In both cases, keep one issue per underlying problem and add each new requester to it, so the count stays honest.
How do you respond to a feature request?
Thank the person, restate the problem in your own words, and say whether it's planned, under review or not planned. Then promise to tell them when that changes, and do it. A short reply such as "not in the next quarter, because we're rebuilding reporting first" helps the requester more than a generic thank-you.
Feature requests for enterprise product teams
Enterprise product teams get feature requests from more directions at once: account managers relaying a key customer's ask, support tickets, sales calls, partner teams and in-app forms. The same request arrives through several of them, worded differently, and each channel has its own advocate.
What works at that scale is one record per problem, with every requester, account and source attached. Once a request is tied to named accounts, a roadmap review can weigh it against everything else, and nobody has to rely on one account manager's sense of how many customers asked.
How Usersnap helps with feature requests
Usersnap collects feature requests inside your product and keeps each one linked to the people who asked, from the first submission to the release announcement.
- Collection: in-app widgets and micro-surveys take requests where people use your product, alongside bug reports, so both are sorted in one place.
- Grouping: Sentiment Sensor, included on Professional plans and above (an add-on on Starter and Growth), tags each new request with a topic, so twenty differently worded requests show up as one theme.
- Prioritization: on the Opportunities Board, grouped requests become an opportunity with the feedback attached, scored on value and effort. You can customize the scoring criteria, and the change applies to every opportunity.
- Handover to engineering: opportunities sync both ways with Jira and Asana, so a status change in either tool shows up in the other.
- Closing the loop: Announcements and the Changelog tell requesters what shipped.
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.
How does Usersnap prioritize feature requests?
Grouped requests become opportunities on the Opportunities Board, scored on value and effort with criteria you can customize. Each opportunity syncs both ways with Jira or Asana, where engineering picks it up.
Related terms
See how product teams turn grouped requests into scored opportunities.
.svg)
