Many customers don’t appreciate a direct “no” to their feature requests.
Even a polite way of saying no, such as “thanks for your request, but it doesn’t fit our plans” can annoy — and possibly infuriate — customers.
Better is a non-committal answer, such as:
“Thanks for the suggestion. We’ll consider it for the future.”
However, this response is still not perfect. Customers interpret it in one of three ways:
- They are satisfied that you’ve responded
- They see through this as a brush-off
- They consider it a promise. They’ll write to you after your next release asking why you haven’t added the feature you “promised” to include.
Some other problems with this approach:
- The customer may feel like their request has gone into a black hole
- They have no way of seeing if the request is likely to be implemented
- You can’t tell how popular the suggestion is, or whether many customers have already made a similar request
If you do go with this approach, make an effort to record each request in a spreadsheet. It is tempting for your time-pressed support team (or you, in the case of a single-person business) to send a stock response and then ignore the request. However this is valuable data that you should use to shape your product’s ongoing development.
By recording requests you might find that the requests you’ve been declining are way more popular than you realised.
There’s also another way to manage feature requests. This is the one we like so much we even invented a product to make it easier: Feature Upvote.
Feature Upvote is an online product ideas board that lets your customers (and team) add and vote on feedback.
So if you use Feature Upvote to track feature requests, you have another way of saying no. You can simply write:
“Thanks for the suggestion. You should add it to our Feature Upvote page so that other customers can comment and vote on it.”
Now the customer can see if their feature request has already been requested. They’ll see its relative popularity compared to other outstanding feature requests. If it is not popular, they’ll understand why your answer is probably “no”.
And because the customer isn’t always wrong (in fact, you might be wrong – yes, it does happen!), you’ll also be able to discover if you’ve been saying “no” to the wrong feature requests.
When individual customer support staff are fielding feature requests, you – the product manager – don’t always get a sense of the frequency of specific feature requests. However, when you have a place to gather all feature requests and where customers can upvote the ones they want, you’ll discover which requests are popular, and should be given high priority by your product development team.
To recap, avoid a direct ‘no’ because it can annoy customers. They woudn’t be making a feature request if they didn’t feel strongly about the subject. They’ll already invested time in letting you know they’re unhappy. So they deserve a bit of consideration.
So at least say ‘no’ in a tactful way. Then record the request so that you can find out if you’ve been saying ‘no’ when you should be saying ‘yes’. If this is the case, then rethink your product roadmap. Talk to your team. Send a notification to those customers saying ‘Your suggestion is now in progress’. Happy days!
If you like the sound of an online product ideas board then please consider us, Feature Upvote.