What is a feature request?
A feature request is a user’s comment, message, or request to include a specific feature in your product. Feature requests can serve as a guide when deciding how to iterate on an existing product.
Users are required to describe a feature request in one of the following ways in addition to locating a method of communication with the developer:
Make it abundantly clear what the feature is, how it might function, and the issue it would address. Give an illustration of how the proposed feature—abstract/users’ emoji—would function. For a comprehensive look at all of the most significant aspects of customer feedback, download our eBook on Customer Feedback: what it is, how to collect it, the kinds of feedback we have, and a lot of helpful tips and mistakes to avoid if you want to work with customer feedback effectively.
How does one submit a feature request?
For requests to be made, your team needs a system for making suggestions that everyone on the team can see. For instance, it is simple to request features that your entire team can see on GitHub.
How do you get a customer to request a feature?
There are numerous ways to solicit feature requests from customers. To start, you need to keep in touch with your customers regularly. Even if the chatbot is automated, having a Contact Us page where customers can make requests is essential.
Second, read other people’s reviews. “Please add form optimization” or “It takes too long to fill out forms” are two examples of requests for new features that customers will make here, either directly or indirectly.
How are feature requests from clients ranked?
The method used to rank feature requests will be influenced by your team’s approach and requirements. However, the most common form of a hierarchy is as follows:
Examples and templates for feature requests Feature request templates are a great way to organize user feedback for your team. You won’t be able to collect and organize feedback from channels like customer support and product reviews if you don’t have one. Major bug and security fixes Minor bug and security fixes Small features and touch-ups that can be implemented in the short term Major features and redesigns that can be implemented over the course of the long term
The vast majority of feature request collection apps provide feedback structure templates.
If you want some ideas for writing effective internal feature requests, you can read this page briefly.
Feature requests are templated, managing them is much more sustainable.
A feature request template makes it easier for product managers to manage feature requests because they arrive as structured, complete data. A template for submitting a feature request should include the following:
The first steps in managing feature requests are standardizing these channels and consolidating feature requests into a single location for evaluation. The classification of the requests is the first step in evaluation. There are three main types of requests:
- Errors and missing features:
- Enhancements to the features The team then places a higher priority on requests for brand-new features. Allowing a user to change the background color is less important than installing a crucial security patch. We’ll go into greater detail about prioritization later.
The appropriate response to the feature request must then be selected by product managers. Is it necessary to include this on the development plan? It’s possible that the feature already exists but requires greater visibility. Is this a duplicate request or a planned feature?
Effective feature request management is required to close the loop.
The person who made the request ought to get a response in which they are sincere thanked and told what happened.
How to respond to a feature request The procedure of responding to a feature request is referred to as “closing the loop.”When closing the loop, it is absolutely necessary to acknowledge the feedback and let the user know if their concerns are being addressed (for example, “We already have a plan to implement this in the next update!”). After that, the exchange should be ended.
Consequently, I occasionally get the chance to submit bug reports and feature requests. In addition, I have discovered a report and request format that is effective in resolving issues and bringing about changes.
Consequently, I present to you today my outline for writing a feature request or bug report with extensive commentary. Even though these guidelines aren’t final, they show the kinds of requests I’ve sent and received that have resulted in few exchanges of information.
Briefly summarize the request.
This ought to be limited to a few words in the ideal scenario. It ought to be simple to incorporate into the subject line of an email or your ticket tracker. Because this summary will likely become someone’s mental shortcut for identifying a unit of work, it is kind to be brief. A straightforward structure, such as “noun verbs the object for a bug” or “should verbs the object for a feature request,” is typical of a concise summary.
If you are unable to complete this step, consider your options before proceeding. You might be dealing with multiple issues at the same time. If you reduce it too much, you run the risk of making the recipient a participant in an unintentional Twenty Questions contest.
Please describe the situation right now.
Give a context in which the proposed change and the current situation can be compared. If the problem is a bug, provide the steps necessary to reproduce it. If you are unable to reliably reproduce the bug, describe the circumstances in as much detail as you can. Please provide a brief explanation of the current operation if it is a feature.
It is easier for writers and readers to comprehend a proposal when there is a contrast between the way things are and how you want them to be.
Describe the outcome you want.
Put another way, insist on the change. Be polite at all times.
Because of this, you probably started this process in the first place. Tell us what you thought would happen if you want a bug fix. If you want a new feature, show how it would actually work in practice.
If you don’t know how the changes will be implemented, you can’t guess how easy, hard, simple, or complicated they will be. You don’t think it’s as useful or persuasive as you think it is.
Describe the benefits of the changes.
back up your request. Give an example of how it will make life better for your employees, clients, or customers. This not only helps the recipient comply with your request but also enables her to make an informed decision about which tasks she should take on first.
Describe the negative effects of the change.
If at all possible, explain how the change will require new efforts or behaviors on the part of your company, users, or customers. You might think it’s counterproductive to talk about the negative aspects of your proposed change; On the other hand, ignoring disadvantages implies ignoring opportunities to mitigate them. You might also occasionally state that there is no disadvantage.
How to Handle Product Feature Requests Properly You might have had bad luck handling product feature requests in the past. Now, allow us to give you some advice on how to respond politely to your customers and effectively handle feature requests for your product.
Paying close attention to what the customer is saying is the first thing a customer service representative needs to do. You should never disregard the feedback of your customers, whether it is positive or negative. To build a stronger relationship with your clients, you need to pay close attention to them. The client ought to feel valued. If you need to know exactly what your customer wants to say, feel free to ask a few questions. This will give your customers the impression that you are paying attention to what they have to say and considering their suggestions.
Be honest and open. Treat your customer relationships as if they were your own.It is a common error for businesses to offer customers nothing but empty promises.
