Swipe these tidbits to craft a “no” response to a feature request….politely of course.
It’s always great when a customer comes to you with a really great feature request, fully supported by a logical explanation of how this feature will help them and other customers like them use your product better.
We can dream, right?!
Most of the time, feature requests won’t fit into the roadmap, conflict with the product vision, or not be worth the development effort for the benefit it would provide.
For all those types of requests, you’ll have to say “no” to the person who requested it — politely, of course. It’s a skill all product managers have to develop.
Just to note, we’ve phrased the below options so that you’re not saying “no, that will NEVER happen”. After all, things change! We’ll try not to pigeon hole ourselves here.
So here are the seven components of a feature request response…
- Thank them for reaching out
- Empathize with them
- If needed, ask for clarification
- Say no without saying no
- Present a workaround or existing feature, if possible
- Thank them for their request
- Sign off
Here’s examples of each of the steps you can copy + paste into your own emails and chats. Just replace the items in brackets before you send them out!
1.) Thank them for reaching out and giving feedback
- Thanks for reaching out!
- First of all, we really appreciate the you reaching out to us!
- I appreciate your interest in making [product X] an awesome product.
2.) Empathize with why they’re asking for it if you can
- I can see why you’d want to [do x/integrate x/add x] with our product.
- I agree, [the person’s problem] is definitely super frustrating! I can see why you’d want to change that.
- Being able to do [the person’s request rephrased] would be super helpful.
3.) If you really don’t understand their request, ask for clarification on what they’re asking for. Find out the core problem.
- Could you help me out with learning more about what you’d like in a feature like this?
- How would you see something like this working?
- Could you explain your current workflow and how this may be able to improve it?
- How would this feature help you out in your day-to-day work?
4.) Say no without saying no
- Right now we’re working on [feature X]. We think that it will improve our customer’s experience when [what your feature hopes to help]
- Our next 3 months of development work has already been planned, so we won’t be able to fit this into our schedule in the immediate future.
- If we have a few more customers who also suggest this feature, we will definitely try to work it into our future plans.
- This is not the direction we’re looking to take our product at the moment.
5.) If there’s a workaround or feature that exists that could provide the same outcome they’re looking for
- I’m not sure if you’re aware of it, but we do have [X feature] that may be able to help you do [what they’re looking to get out of feature request]
- If you’re looking to do [thing the customer wants], you may be able to use [other possible features/actions] as a workaround in the meantime.
- We’ve found that a lot of customers who want to do [X] have had success with [feature X].
6.) Thank them for reaching out (you don’t want to miss the actual good feature requests)!
- Thanks for reaching out!
- Keep the feature requests coming!
- Your feedback really helps us to keep improving [product X].
- Have a great [Monday].
7.) Sign off
I hope this structure helps you build your next feature request response! If you have any additions or any tips you use when responding to your feature requests, leave it in the comments.