A feature request is a comment, message, or ask from a user to implement a specific feature into your product. Feature requests can be used to decide how to iterate on an existing product.
Alongside finding a channel for reaching out to the developer, users must be descriptive about a feature request in these ways:
State clearly what the feature is
Describe how it might work
Explain what problem the feature would solve
Describe a scenario that shows the proposed feature at work
For requests to be raised, your team needs a system in place for making these suggestions in a way that everyone on your team can quickly see. For instance, GitHub makes it easy to request features that your entire team of collaborators can see.
There are several ways to ask your customers for feature requests. First, you must have some form of open communication between you and your customers. Even if it's an automated chatbot, having a Contact Us page where users can submit requests is key.
Second, look through user reviews. Here customers will leave direct ("Please add form optimization") or even indirect ("It takes too long to fill out forms") requests for new features.
The methodology for prioritizing feature requests will vary by your team's approach and requirements. Generally, though, a hierarchy might look like this:
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 long-term
Feature request templates are a great way to structure the feedback your team receives from users.
Without one, you'll find it difficult to collect and structure feedback from customer support and product review channels.
Most feature request collection apps provide templates for structuring the feedback you receive.
If you're looking for inspiration for writing effective internal feature requests, you can skim through this page.
Templating feature requests makes managing feature requests much more sustainable.
Via a feature request template, requests arrive as structured, complete data — making managing feature requests easier for product managers. A feature request template should feed directly into the feature management system and include:
Details about the requester
1.Requested by
2.Request channel
3.Request date
4.Requesters contact details
Details about the feature
5.The product the request is for (a predefined list of products)
6.The function(s) the request relates to (a predefined list of functions)
Details about the request
7.Request name
8.Type of request (a bug, an enhancement, a new feature)
9.A detailed explanation of the request
10. Helpful attachments
Details about the evaluation
11. Request status
12. Request priority
13. Effort required
14. Request outcome
Feature requests can come through various channels and from diverse sources. Emails from sales teams based on feedback from their contacts, messages directly through your product from users, and even comments from colleagues.
Managing feature requests starts with standardizing these channels and collecting feature requests into one place for evaluation. Evaluation starts by categorizing the requests. There are three basic types of requests:
2. Enhanced features
3. New features
The team then prioritizes requests. Letting a user change the background color is less important than a critical security patch. Prioritization is discussed in more detail later.
Product managers then need to decide on the correct response to the feature request. Is this feature already planned, or a duplicate request? Does it need to be incorporated into the development roadmap? Perhaps the feature already exists but needs to be more visible.
Properly managing feature requests means closing the loop. The requester should get a response (personally if possible) thanking them and with the result of their request.
A feature request form is a survey that you can deliver to a customer or user of your product. That survey will ask them if there are any features they would like to see added to your product in the future or in a future version of your product.
If your product is an app, then the new features might come in the form of an app update. If it's a physical product, then the feedback can be used to inform a second or third iteration of the product.
Either way, the purpose of the form is to gather feedback from real-world users who can give unique insights into the usage of your product. You can send out feature request forms via email, have them available on your website, and/or in the help center of your app. You can draw attention to the form, or leave it there for users to discover if you want less feedback.
While there's no reason you can't create your own feature request form, working from a template has the advantage of being faster and ensuring that you don't forget any important details. To help you get started, here are four feature request templates that you can use today.
The first feature request template we're looking at is Feature Requests That Don't Suck. If you don't believe that there are bad feature requests, then this one may not be for you.
But for those that already get too many requests and are looking to weed out everything but the best, this form can help you do that. It's packed with questions that should dissuade bad or casual requests, reducing the overall number of requests you get while also increasing the quality of the requests.
For those who are looking for a feature request template that's a bit simpler, Coda has the answer. It's a basic form that anyone can use and implement without much effort.
It's meant to be a solid baseline, great for teams who haven't worked with a feature request form before. It asks the necessary questions without going too in depth.
The third feature request template we want to bring to your attention is more of a tool than a template. It comes from Reform, a website that allows you to create a professional-looking form and then integrate it into your website.
It's an easy tool to use and a great option for those who aren't sure how to incorporate a feature request form into their website or digital product. You can customize it with your brand's colors and logo, so it'll fit seamlessly into your product.
Lastly, you can use this feature request template to send a feature request via email. This article has several suggestions to choose from, which you can easily modify to fit your company and product.
Responding to a feature request is known as "closing the loop". When closing the loop, it's important to acknowledge the feedback, let the user know if/how their feedback is being addressed ("We already have a plan to implement this in the next update!"), and then end the conversation.
Reach out to airfocus for tools to help you organize, structure, and refine your feature management process.