Everything You Should Know About Feature Request Responses

If you are a product manager and you have a pool of feature requests screaming for your attention, you should be thankful. Thankful that users actually care about your product to share feedback.

Feature requests are feedback shared by your users to contribute ideas for product improvement. This request can come either from your internal team who are involved in the product development process or your consumers who are the end-users of your product.

When you get a request, it means that the users value your product. Sometimes it may not be possible to work on every request. But it is important to respond to them. If your users cared enough to share their feedback, you should get back to them with gratitude and apt response.

Common types of  feature requests

Feature requests can flood in from different sources. Some can leave it on your portal, some discuss it among themselves on forums and some reach out to you personally. And these requests can be for different reasons.  Here are the different types of situations you might have.

Request for resolving  a problem with an existing feature

When you are dealing with SaaS products, there are chances that some of the features do not work as smoothly as you want them to be. The interface might lag, the widgets might not work, and there might be glitches with the integrations. 

When the users face such a problem, some will just bad-mouth about it and discard your product. While there are others who will reach out to you and share their experience in the hope of a solution. When you encounter such requests, value them. 

You can easily connect them with your support team to look into the issue. But this is also the best time to dive into deeper conversations about users’ understanding of your product. Ask them specifically what issues they are facing and how they would like you to address them.

Avoid commitments if you are not sure about them. Instead, say that you will look into the matter as soon as possible and get back to them. 

For example, “Hi Aleena, we are extremely sorry that you have to experience such glitches. It must be frustrating. Our technical team is looking into the matter and we are going to update you as soon as that is fixed. Thanks for trusting us.”

Request to improve an existing feature

You cannot expect to launch the perfect product in the market. There will always be criticisms and feedback. Some will happen on public platforms without your knowledge and some requests will come to you hoping for improvements.

If your customers are not fully satisfied with some of the features of your product, they are most likely to reach out and nudge you to improve. While it is important that your customers are satisfied with your product functionality, don’t promise something that is out of your capacity to deliver. It will only make things worse.

Suppose your consumers ask you to integrate some of their favorite applications into your product, which is not feasible for you right now. You have to make the tough call and communicate the situation. 

“Hi Aren, thanks for reaching out to us. We understand how this feature is going to help you in your work. We are actively looking for ways to address your request and will keep you posted if we come up with a suitable solution.”

Request for a new feature

Users may come up with multiple new feature requests. But as said earlier you have to make a careful decision and analyze the feasibility of the feature requests. It is completely okay to say no, provided you say it in the correct way.

When you feel that there is potential in particular feature requests, it is best that your team test it. But if it does not align with your product roadmap, you have to discard it politely.

“Thanks for reaching out to us. We value your feedback. We get a lot of requests in a day and try our best to evaluate all of them, but sometimes it is not possible to address them in the exact way you want us to. Having said that, we will make sure to update you if we work on your request”

How should you respond to feature requests in different types of scenarios?

We have already discussed the common types of feature requests. You may encounter these requests in different types of situations. We have discussed some important scenarios and your appropriate approach toward them. Have a look.

Response to feature requests that have a high potential to improve the product

While some feature requests are farfetched, some show high potential for deployment and product improvement. When you get such requests that seem to fit perfectly with your roadmap, reach out to the prospect and ask more questions about their exact expectations from the product.

If that feature is something you were already working on, then congratulations, the stars are finally aligned. You can reach out to say that the new feature is coming soon. Don’t say when if you can’t give a commitment.

Instead, you can take inspiration from Buffer. Team Buffer is really transparent in user communication. They communicate the different stages of feature development with the users. From the discussion and research to the building or testing stage, they let their users know so that they can have a rough idea about feature delivery.

“Hi Jay, we are so delighted that you took your time to write to us. Our team is already testing the feature you requested for. We will let you know as soon as our team communicates the result with us. Will keep you posted. Have a great day!”

Response to the feature requests done by prospects evaluating the product

While new feature requests have great potential in adding value to your product, some of them may not be feasible for you right now. And you have to know how to evaluate and differentiate between them.

Prospects want the features which will give them the highest value. Their ideas and requests do not come from a place of calculative understanding of your resources and strengths. You know what are your strengths and abilities. So shortlisting and prioritizing features need a lot deeper understanding of customer wants and your strengths to find alignment if any.

Here are the things you should consider while evaluating any feature request-

Human Resources - Do you have the appropriate human capital to develop this feature? Or do you need to hire additional resources?

Actual Capital - Do you have to buy additional elements like software, hardware, cloud services, or licenses?

Opportunity cost -  Do you need to drop any other idea on the roadmap to fit in the feature? What will you lose?

You have to also understand the potential of your prospect in being your long-term client. What are the chances of them discarding or retaining your product? Some of the prospects may even ask you to enhance and develop certain features without even trying the product.

Developing a feature needs a lot of time, effort, and resources, make sure that you are doing it for the right client that promises long-term commitment.  The best thing you can do to ensure this is to carve out an agreement with your prospects that binds them to your product. 

Response to a feature request you are not going to build

While all the feature requests are important for you to review and consider. Unfortunately, you cannot go ahead with all of them. There can be several reasons constricting you to develop a highly requested feature.

Not being able to develop a feature does not mean you discard the user’s request and move on as you have never seen it. Even if you can’t develop a feature right now, you have to let them know. This will keep the relationship with your users intact.

You can start off by thanking the user for taking the time to reach out to you. Also, don’t completely discard their idea of the request. Here is how you can do it-

“Hey, Ashley! Thanks a lot for reaching out. We love your idea. But this is not a functionality we support right now. But we will make sure to add it to our backlog and alert the team.”

Response to feature request your service does not support but may be able to in the future

When you get feature requests that may not be feasible for you right now, but there is a possibility of building them in the future, you should respond to the user accurately about your stand. This is how you can do it.

“Hey Mike, we really appreciate you reaching out. This is a really good suggestion. But unfortunately, currently, we don’t have the resources to build the feature right now. Maybe in the future. Will keep you posted in case of any developments. Have a great day!”

Tips to handle feature requests effectively

Here are some tips on how to address your feature requests with care and perfection-

Honesty is the best policy

The truth may be disappointing and disheartening but it has the power to save relationships. Be open and honest with your communication. If the user request is out of your capacity to develop, communicate it freely with them, like in the above-mentioned examples.

Believe in showing gratitude

You should always respond to a request by thanking them for showing their concern about your product feature development. Most people don’t even care. But to the few you do, make sure to display gratitude.

Stay away from false promises

Nothing will suck out your brand reputation more than false promises. Don’t commit to something you cannot deliver on time. Instead, promise updates. Let them know that you will keep them posted on the imported updates

.

“Hey John, we are super excited to let you know that you are currently working on the feature you requested for. We will keep you posted about the important updates. Stay tuned”

Show your understanding

Understading works best. It shows you are empathetic and concerned about your user’s needs and problems. Here is an example of how you can do it

“Hi Amy, I am so sorry to hear about your inconvenience. I understand it must be frustrating to log in every time you open the app. We are working on the auto-login feature, and hopefully, you will be able to use it soon. Till then, please bear with us a little more. Thank you for your patience.”

Dig deeper into their needs

Before bluntly arriving at a conclusion and dismissing a request, make sure you know the idea and need behind the request. Even if you are not able to work on the feature directly, make an effort to find their real need. It will give you an insight into the problems your users face.

For example,

Customer : “I want to restrict access to my account by some people without blocking them. Is that possible?”

Possible response: ‘“Why and in which cases do you want to use this feature?”

‍

Be honest with your explanation

We have said it before, we are saying it again, being honest is the best way to approach any feature request. Users appreciate honest explanations more than false promises. Here is an example-

“Hey Julia, we are really grateful for your feature requests. However, it is not something that we are working on right now. We will need a little more time to discuss the feasibility of the feature with our resources. We will definitely get back if it aligns with our capabilities. Thanks for understanding.”

Don’t communicate ETA if you are not sure about it

If you are not sure about the product timeline, don’t say it. It is as simple as that. You can instead promise to communicate updates. 

“Hey Irene, we are so excited to inform you that have started working on the feature you requested. Please look forward to it. We will make sure that you are posted with the updates”

How to build your own script to respond to feature requests?

“Great products are engineered when product managers truly understand the desired outcomes by actively listening to people, not users.”

– Michael Fountain, Director of Product at Apptentive

We have already spoken at length about the different ways you can respond to feature requests. Whether it is on a forum or on your portal, you must train your support team to respond efficiently to feature requests. Let’s have a quick checklist for setting the right tone of the response-

• Give honest explanations.
• Be grateful.
• Don’t give the ETA if you are not sure.
• Be understanding and empathetic.
• Invite customers to reach out again.

Feature requests response mail templates

We have crafted some email templates for you to respond to 3 primary situations of feature requests. This will give you an idea of what an ideal response should look like. Have a look.

Saying no

“ Hi (name)

Thank you for reaching out to us. Your messages and feedback keep us going. 

You have raised a great request. I can definitely see how this will help you in your experience of using the product. But unfortunately, this is not something that we can promise right now. I understand and appreciate your point of view and will keep it in our backlog for a team review.

If you want any other insights related to the product, please feel free to ask. We will be more than happy to guide you.

Thank you for bearing with us.

Regards,

(signature)

Saying maybe

“ Hi (name)

We are glad that you reached out to us.

You have asked a great question, I can understand how this feature will add value to your product experience. We are keen to work on this feature, but currently, with resource constraints, we cannot promise you anything soon. But we are definitely keeping this in our backlog for review. Will keep you updated if any development takes place.

In the meantime, do you need help with anything else? Please let us know. We will be more than happy to help.

Have a great day!

Regards,

(signature)”

Saying yes

“ Hi (name)

Thank you for taking the time to contact us. Apologies if you had to wait a while for the reply.

But there is good news :-). We are excited to inform you that we have started working on your requested feature. It will shortly be available in one of our upgrades.

We will make sure to update you when it's live.

Please look forward to it.

Meanwhile, is there anything else that I can help you with? Please feel free to ask.

Have a great day!

Regards,

(signature)”

Final Words

Responding to each and every feature request may not always be possible, especially if they come in huge numbers every day. But make sure that you periodically check and review the requests, and most importantly respond to them. This will contribute to a healthy relationship with the users because they will feel heard and valued.