Let's assume that you are a product manager in an online bank called n18 and one of your users called Marc asks you for a new feature "Hey n18, is it possible to add invoice editing in the mobile application?"
Your brain tells you "Noooo Marc, please... 😰 we already have an overloaded roadmap, we don't have time for this feature. Our roadmap is already full of fresh new features for the further development of our product. You can’t ask me to build this new feature...”
So you have to answer "No" to Marc to develop this feature and anyway it's the first time you've been asked for this feature so why answer positively when you can simply answer no?
How to answer no to Marc asking for a new feature request in the best possible way without offending him and that he goes to one of your competitors right after your answer?
In fact it's not so easy to answer “No” to a feature request and we will see why, then you will discover 5 great examples of how to answer well to deny a feature request to your customer.
Make sure you understand your user's real needs.
Before answering yes or no to your user, make sure you really understand their needs. Does your user have this need on a recurring basis or is it just a request for a single use? Does your user see this feature as a hook to your service? Has your user already used this feature in a competing service?
Understanding your user's needs is essential. If you need to develop the feature, the user who asked you the question first will be the greatest person to give you honest feedback.
Is the feature-request interesting?
Is the feature-request you received from Marc interesting, but you don't have the time to develop it right away?
Today most companies use a feedback board to prioritize the features to be developed. It's a simple and scalable feedback hub for your product. It allows you to centralize everything in one place.
For example, Google has built its own feedback board to collect the feedback of their users.
If you are a SaaS, an online bank or a more traditional company, you can use Upfeed, it allows you to collect the feedback of your users and create a roadmap to prioritize your functionalities. You will no longer have to answer "Yes" or "No" to your users asking for a feature. Your users can submit new feedback on your board and vote on existing feedback.
How can I avoid answering No to feature-requests?
The example of Github making its roadmap public allows its users to directly consult the next features that will be developed in order to avoid the questions like "is this feature going to be developed soon?" "is this feature going to arrive on the product?"
Building a public roadmap can save you from all those questions that a normal user may ask when registering or subscribing to a service. It's human, he needs to be reassured about the sustainability of the product development.
5 examples of how to say “No” to feature-requests
Your user needs to know the truth if the functionality he is asking for will actually be developed or not. Find out how to answer no in the best possible way.
1. Answer no, for the moment
If you don't plan to develop this feature at the moment, don't tell him "yes" out of pure pleasure, but answer him the truth. That you are going to develop this feature, but later.
Thank you for taking the time to suggest this feature. We will take it into account in our roadmap and you will be notified when the development of this feature begins. We are adding it to our roadmap for Q2 2021".
2. Explain why it’s not the direction you want to go
The feature-request requested by your user does not go in the direction of your product development? Feel free to be clear in the message your product conveys to your users. If the feature-request doesn't fit in your line, tell him/her and explain the reason. I also invite you not to close the door to your user. If, for example, his need is a need common to several of your users, you could open it later. Always leave a possibility and provoke empathy in your user.
Thank you for taking the time to suggest this feature. The feature-request you have requested is very interesting, however it does not fit in the guideline of our product. We are adding it to our feedback board, if it arouses the curiosity of many users then we could potentially develop it in the future."
3. Say ‘no’ to the request, clearly and honestly
How to say "no" definitively and in the best way while not offending your user. Get their feedback and explain to them why their feature will never be developed.
We sincerely believe that your feedback is good, however, we won’t be able to look at your idea for now. We want to make sure we remain focused on our current goals.”
4. Explain why it’s not the solution for them
Sometimes your user will have seen an existing feature from one of your competitors and will want to get the same one on your product. Ok it doesn't necessarily start from a bad attention, except that you don't intend to develop this feature to differentiate yourself and not to spread yourself too thin.
Thanks for the time you take to write this feedback. We believe that the feature you just mentioned will not be developed for our product at this time.
However I invite you to add it on our feedback board, if this feature gets more than 10 votes, we will take it into account in the future”
5. Make sure you’re on the same page with a customer
Make sure you understand their needs and that your product matches their real needs. Identify the user you are talking to. Is it a recurring customer with a large MRO on your product or a small customer thinking less than 1% of sales on your product?
Answer according to the typology of your user. Be close to them in order to build a relationship with them and develop feedback as your product develops.
Tips to remember for saying “No” for feature-requests
- Welcome your user's feedback in a positive way
- Thank him for the time he takes to write his feedback and allow you to improve your product.
- Tell him clearly why you are not going to develop his feature-request at the moment.
- Add it in the loop if this feature will be developed one day and enter it in the beta users group.
- Offer him a solution
Your user always needs an answer and we suggest that you answer positively even if your primary intention is to answer "No". A recently published book by William Hurry entitled "The Power of a Positive No: How to Say No and Still Get to Yes" summarizes very well the examples seen above.
The best way to get feedback and avoid incessant requests to build functionality are "feedback boards".
Following Google's example, we have developed a tool that allows you to build your public roadmap and receive feature requests in a public way. So your users can consult the features you are developing and vote for those that are already present. Are you currently using Trello or Jira to build your roadmap and get feedback?
We invite you to test Upfeed for free for 7 days and start receiving feedback. Don't leave your users in doubt.