Time to read: 5 minutes
So, you decided to build your product on user feedback. You want your users to determine the direction you'll be taking. You receive feature suggestions on Twitter, via email or even solicit feedback publicly with UserVoice polls…
It's great when you hear the same request over and over again. Clearly, you have to consider it. But then there are the requests that will take ages to implement, the ones that complicate the user interface and aren't worth the hassle.
How do you say “No” to users without pissing them off? Do you say it outright? How do you explain why? Do you even have to explain?
I used to be very stressed about saying “No”, overthinking and rewriting my emails. But I got better over time. Following these simple rules helped me:
1. Set customer expectations beforehand
Note: I'm using “customer” and “user” interchangeably throughout the article. I'm talking about paying users.
customer expectations ≠ reality => disappointment
customer expectations << reality => excitement
Set the expectations to a reasonable level, so that you can exceed them. For example:
You're not going to implement every feature suggested on your community forum? State this clearly when posting a poll or a feedback thread.
You're not necessarily adding the top voted feature in a poll? Say it.
You'll start working on a feature, but not sure if it's going to be in the next release? Don't commit to deadlines.
You can continue the list.
If users don't expect you to implement their feature suggestions, they won't be disappointed when you say “No” or “Not now”.
2. Be honest, but don't be rude
A bootstrapper told me he liked being honest about features they were not going to implement. He declined feature requests like this:
Sorry that feature sounds nice but with our limited resources we can't be bothered to implement it right now, maybe next year.
I'm really bothered by the above sentence.
How would you feel if somebody said this to you? Probably like you're some kind of nuisance preventing SuperStartup from following their vision. I'm also not sure that most users know what resources are and why they would be limited.
It's alright to say to customers that you don't have the time and your team is small. I've admitted it many times. But saying the customer is bothering you is not a right thing to do.
3. Tell the user why you have to say “No”
In principle, you don't have to justify anything. In reality, customers usually ask “Why?” or say something like: “This can't be too hard to do. It's just one button.” That's why I take the time to explain why I have to say “No” and save myself the distraction of future emails.
But developers and customers usually speak in different languages.
You have to point out a reason that the customer will understand.
Here’s what your reasons might be and how users would react to them:
✗ “It's going to take ages to implement and it isn't really worth it.” A customer doesn't care about the time it will take or about your priorities.
✗ “We've got more important tasks.” You risk insulting them by saying their problem isn't as important as your other tasks.
✗ “It's going to complicate the user interface.” User… what?
✓ “It's not going to benefit many users”. This sounds most understandable from a customer standpoint. It's what I say.
Saying “No” to users
Hi <customer_name> ,
[Set a positive tone. Remind the customer of their positive experience with your product.]
(For example, If they said “I bought it and it's really great”, you can say “Thank you for your purchase. I’m glad that you like <product_name> so far”.)
[Empathize. Show your understanding.]
I understand that it would be very handy to <perform_action_that_new_feature_will_allow>.
[Say that you like their idea, but don't be excited about it]
This sounds like a nice thing to have (not “great”, not “awesome”). I added it to our list of ideas (not “list of feature requests”, not “list of future improvements”, not “list of bugs”). Thank you for taking the time to share this with me!
[Time to say “No”. Explain why.]
When choosing new features to add from the list of ideas, we have to pick the ones which will bring most value to as many customers as possible. We're a really small team with a long list of ideas. ("We have to" = the circumstances force you to do this. It's not that you don't want to help.) Since you're the first person to mention <feature>, I have to say that we'll consider adding this feature to <product_name> only after we receive a number of similar requests. (Saying: “I'm really sorry that I have to turn you down right now, but I can't promise you anything.” without the negative words: “sorry”, “can't”.)
[Mention other cool relevant feature you have added recently.]
By the way, there is another cool thing you can do with <product_name>: <new_feature>! If you haven't tried it out yet, go ahead and download the new update. Here's an article which covers <new_feature> in more detail. (You're shifting the focus to the great things your software already does. Trying to offer the customer a new positive experience with your product.)
[Don't forget to be nice]
Have a fantastic <day_of_the_week>!
For more templates like this, be sure to check my free ebook here: http://sansmagic.com/5-template-responses-to-crazy-customer-letters/
Note that, in this email, there is no time-frame and there is no promise that we will add the feature. We will consider adding it after we receive a number of similar requests. That's me being honest. It's exactly how we prioritize feature requests. You might have a different policy.
Saying “No” on Twitter
IMO, email is much better than Twitter for handling customer support, but if you have limited characters to say No to a customer, here's roughly the above email condensed in a tweet:
@username Thank you for sharing your idea with me. We'll consider it in the future. Btw, we're currently working on featureX. Stay tuned!
Here featureX is the next big thing you're rolling out. Trying to remind the customer that you're always working on improving your software for them.
Don't forget to analyze each feature request
This is how you gain insight about the problems that your customers are trying to solve with your software.
Is the request really one-off?
What is the core problem that this customer is facing? It doesn't have to be solved with the exact feature they suggested.
Are there other customers who have the same problem?
If you're asking for feedback publicly, make sure that customers know what they should expect. I also find it a good practice to explain why I have to decline a request, because users usually ask that question. Be honest with your customers, but don't be rude.
Do you find it hard to reject feature requests? How do you do it? Share your thoughts and strategies in the comments below.