As companies grow, feature requests become one of the most important forms of communication with your customers.
They have the power to shape how your product evolves over time — something that can impact positioning, product-market fit, and the company’s direction.
But without the right processes, systems, and best practices in place, everything can turn to chaos.
Companies quickly start to experience far more feature requests than they can handle.
Some ideas never get captured.
Others get ignored.
Some features get built but don’t get advertised so customers don’t even know they were listened to.
This guide will teach you everything you need to know about feature requests — how to process them, manage them, respond to them, prioritize them — so you don’t face these challenges as your company grows.
We’ve even created a free feature request template for you — just make sure to read all the way through to get it!
Let’s start by looking at what types of feature requests you might receive.
What are the different types of feature requests?
The best way to categorize feature requests is by considering how they change the functionality of the product. A feature request either fixes an existing functionality, enhances existing functionality, or introduces an entirely new functionality.
- Bug reports
Bug fixes are usually the most critical type of feature request as they may prevent a customer from using your product as promised. Left unfixed, bug fixes are the most likely to cause user frustration and churn (for businesses using a SaaS model).
- New feature requests
Introducing new features is often the most common type of feature request, yet the most time-consuming for product and development teams. Constant innovation is essential for the long-term growth of your product. When executed in line with your users’ needs, it can have a positive impact on retention.
- Improved functionality
Users may suggest product improvements that are aimed to get more value out of existing features. For example, adding a new filter option, updating the UI/UX, improving the user workflow, or similar.
What makes a good feature request?
Common mistakes
Duplicate feature suggestions
Duplicates are the death (by a thousand cuts) of product management when it comes to feature requests and product prioritization. If you want to consider your client’s requests to inform your roadmap, you need to make sure the demands are unique and not counted multiple times.
Taking every request without a filter
Not identifying who asked what, and why is the most common mistake for product managers who have just started collecting features proposals.
To leverage feedback and feature requests, don’t forget to record who is asking for this feature and why.
Not looking at feature suggestions with a critical eye
You should always keep your product strategy and vision in mind.
Dive deeper to understand why your customer wants something or thinks they require something.
Don’t just take an ask and record it. You should always consider the “why” behind a request. Make sure to take the extra step and ask the right questions during your customer interviews.
Not following a sustainable process
It’s tempting to do too much with not enough, so don’t try fixing problems you don’t have.
Don’t build a very complex and detailed process if you have doubts it is realistic to preserve it in the long run.
Use simplicity to drive adoption, especially in your first iteration, before you add some bells and whistles to it.
Best practices
Structured and comparable data set.
You need a feature request template because you need the data you get from your users to be comparable.
And the best way to structure it is to use a tool that helps you frame the way you want to record the proposal to analyze and act upon it — even if that’s just a spreadsheet.
Make sure your feature request template is easy to replicate and complete.
This is the best way to make sure everyone involved will follow the process and the template you want to use.
Use categories and tags
You need to know if the feature suggestions you are receiving are related to UX, Quality, Innovation, etc
It will help you make sure what you decide to prioritize fits in your strategy and that your focus goes to the right place.
You will also start to pick up on trends. Suddenly receiving dozens of feedback related to UX after your last update?
Maybe it’s a sign that something didn’t go as planned!
Identify the impact
How and how much will it impact everything?
The client, other clients?
Will it affect the company from an operational standpoint?
Will it generate revenue or other benefits? And if so, what benefits?
You need to ask and have some idea of the answer for each feature you are considering building.
Whichever process, tool, or template you want to use, make sure it is shared widely.
And use it to bring your team around and gauge the impact it will have.
How to collect a feature request — with feature request template examples
Before you learn how to build a feature request template, let’s provide some inspiration on how and where you can collect feature requests:
In-App
Gathering in-app feedback allows users to instantly share their thoughts when they’re ‘in the moment’ — often leading to well-thought-out feature requests. Another key benefit is that in-app widgets reduce the friction for users to leave feedback, so you’re likely to receive more of it. You can either develop your own widget or section within your product, or easier, embed feedback management software like ProdCamp.
The example above: ProdCamp — via an in-app feedback widget
Internally
Customers may mention feature requests to customer-facing teams like the customer support or sales support team, instead of submitting ideas themselves through other feedback channels. Therefore you should ensure you have a system in place for team members to capture feature requests directly from customers.
The example above: ProdCamp — via our Intercom integration
Product Roadmap
With a public roadmap, you can share progress on new features in development, and let users submit feature requests for others to vote on. One benefit of accepting feature requests through this channel is that it’s easy for interested users to leave comments about specific functionality they’d like to see or requirements they have.
The example above: Wizishop — via their product roadmap
How to build a feature request template
There are many ways to build a feature request template, but you should normally aim to collect the below information:
- FEATURE REQUEST NAME
- FEATURE REQUEST STATUS
- DETAILED DESCRIPTION
- CATEGORIES (UX, QA, INTEGRATION, ETC.)
- PRIORITY (HIGH, LOW, MEDIUM)
- EFFORT ESTIMATION (Based on “t-shirt size” or the days of development effort required)
- ATTACHMENTS (this can help to understand more about the proposed new features)
- CREATED BY
- REQUESTED BY
If you use a feedback management tool like ProdCamp or have a public roadmap, it will be easier to implement. But even if you don’t, it’s possible to use a Google Form or Google Doc to create a basic feature request template as you’ll see next.
Grab our free feature request template!
Using the fields above, we’ve created a free Google Doc Feature request template.
To save it for yourself, click the link above, then go file > make a copy and save it to your Google Drive.
How to prioritize product feature requests
Prioritization Frameworks
There are literally more than half a dozen ways to weigh and prioritize client requests:
If you want to learn more, check out our article describing how to prioritize product features and plan ahead.
How to say “no”
When you’re making your final product decisions, you will often need to reject some of the new feature requests you’ve received.
Here are 6 principles you should follow when saying “no” to your user base:
- Make the customer feel heard — always respond and follow-up with them
- Explain your feature request and prioritization process
- Understand the “why?” behind their request
- Be honest
- Say not now
- Offer workarounds and potential solutions (perhaps with existing features or functionality)
By following these principles, the user experience becomes far more positive because their expectations are actively managed.
How to respond to a feature request
Follow the ProdCamp Product Growth Flywheel
Sometimes team members can forget how the feedback process and product development process are cyclical.
This is why we created the Product Growth Flywheel.
It reminds everyone there’s no way to capture feedback without keeping people informed, and that no actions should be taken that aren’t backed by data.
Maintain an active feedback loop
Maintaining customer engagement means maintaining an active product feedback loop. Needless to say, this isn’t always easy if you have lots of users and various products.
Here are the key principles you can follow to make sure you do it right:
- Acknowledge: Notify when you receive and record user feedback
- Engage: Ask questions to understand your users’ underlying pain points and use cases, but never over-promise.
- Act: Act on what you hear! It doesn’t have to mean adding the product improvement to your product roadmap. You might offer a workaround, or direct users to your knowledge base.
- Inform: Keep your team and customers posted about what is going on to ensure smooth feature request management.
Explore further to learn how you can create a real feedback loop.
Systemize the entire process
Trying to use a mixture of spreadsheets, documents, and Trello boards to manage the feature request process at scale is likely to lead to chaos.
You need a feedback management system that can:
- Centrally store all your feature requests
- Allow feature voting so you can gauge user demand
- Capture feature requests from multiple channels
- Automatically keep users in the loop about their feature requests
- Prioritize requests based on customer value, demand, and effort
ProdCamp can do all of this, and much more.
