Feature requests are an everyday occurrence for everyone with a SaaS product. While you may hope that all your customers will have wonderful suggestions that will improve your product, the reality is often different.
Some customers have unrealistic expectations, others have the right suggestions at the wrong time, some requests just take too much time and money to fulfill and sometimes… The feature request is just dumb.
In all of these cases, you have to say no to a feature request. You may think of this as a letdown for your customers, but there are ways to do it elegantly and in a way that retains those customers and encourages them to provide feedback again.
Here is how you can do just that.
Saying no to feature requests
You may get the idea that saying no to a feature request is the end of the line for a certain customer. If you say no, chances are that they won’t stop using your product and switch to a competitor. In fact, in many cases, a stern no is much better than leading the customer into believing that you’ll launch a feature that just makes no sense.
Saying no is an integral part of the feedback loop and many times, you just can’t avoid it. The way you approach the issue will make a huge impact on what the customer does after hearing a “no” from you.
So, instead of saying “We can’t build that feature for you and it won’t be possible in the future”, consider saying “This feature is not on our roadmap now, but there are three different methods you can use to achieve the same results. Here they are…”
Understand the request
You’ll be forced to say no to many feature requests. As mentioned above, there can be a million reasons for a negative answer. However, you should always try to understand why a customer requested a certain feature.
If they made the request, that means that they have a problem to solve and your duty is to see what’s behind it. Your customers are great at figuring out problems but may not always be the best at finding solutions - that’s where you come in.
A lot of times, what the customer is requesting already exists and can be solved in a different way and they’re just barking up the wrong tree. If you can find a way to fix their problem without fulfilling their feature request, then you’re not really saying no - you’re providing a solution to their problem.
So, instead of just saying no, consider saying: “I’m afraid we don’t have that feature planned in the upcoming months. But can you tell me what you’re trying to do that requires it? I’m sure that we can find a workaround solution for you.”
Set the context
When a customer sends in their feature request, they can only think of themselves and their own use case. After all, they can’t possibly know the thousands of others who use your software.
Because of this, they have a false idea of who the product is really for, what the plans are for the future, and what general direction the product is headed in. So, if someone sends in a bad feature request, just tell them that they should do more research?
No, because there’s an easier fix.
To get everyone on the same page, simply use a public roadmap for your product. You can create a public roadmap in FeedBear in as little as 15 minutes and the value that your customers get is immense.
With a public roadmap, your customers can see:
- What features are already in the works (so they don’t request something that’s already in progress)
- What features are planned for the future
- How many people upvoted and requested certain features
- What the general direction of the product is
- How many other customers are out there and what they are requesting
With a public roadmap, you’re giving customers a broader context of your product so even if they hear a no from you, they’ll have a better idea why their request isn’t fulfilled at this time.
Roadmaps can be public or private and with FeedBear, creating both is a breeze. You can share your public roadmap on your website and make it easily accessible for all visitors. When you want to send it as a response to a feature request, you’ll get a branded link too, such as roadmap.markuphero.com.
So, if a customer asks about a feature request that is not planned for the future, you can just say: “We don’t have this feature planned for our upcoming releases. However, you can take a look at our product roadmap to see what we have in store for the upcoming months. Perhaps you’ll find something similar that you like!”
Take your time to explain yourself
Have you ever sent a job application and heard back from the employer that they chose another candidate and that they want to thank you for your time. But the most important thing is missing: why didn’t they hire you?
It’s similar to feature requests. If you take the time to respond to a request and say no, you can take some additional time to explain the specific reason why you said no. The customer will better understand your position and plans for the future and most importantly, they will be encouraged to give you feedback again at some other point.
Show that you care and you’re listening
Being thoughtful, caring and patient are all great ideas until you face reality. If you have a large customer base, you’ll be swamped with feature requests. The worst part is, you’ll have to say “no”, a lot. In fact, you may be tempted to ignore the requests or send a templated answer saying “thank you, but no.”
That’s one way to go about it, and it’s the wrong way.
Make sure to respond to every feature request, especially so if you’re certain that you cannot fulfill it. If you’re rejecting a request, make sure to:
- Thank the customer for submitting the request
- Say that you appreciate their help (and explain specifically with what)
- Give a reason why you can’t fulfill the request
- Offer a solution to their problem
- Thank them for their time and wish a nice day
It sounds like a whole lot of work for each feature request but it’s actually pretty simple. You can create a few templates for each use case and with some copying and pasting and a little bit of creativity, you can say no to feature requests pretty quickly and easily.
Once again, having a product roadmap helps quite a lot.
Collect all requests in a feedback board
You probably have a number of ways for your customers to send a feature request: emails, live chat, phone, social media, you name it. To make this easier for yourself and your customers, use a feedback board instead. In FeedBear, you can create a feedback board within minutes of signing up.
Here’s how the process goes:
- A customer submits their feature request on a feedback board
- Other customers see their request and vote and comment on it
- The best requests are chosen and moved to a product roadmap
This is a structured process that has a lot of benefits for everyone involved. Customers can see what others are requesting so they can easily spot if someone already made a request similar to theirs. PS: this can’t happen in FeedBear, as customers see similar feature requests when they start typing the name of their own - so you avoid doubles.
They can also see the bad requests that never made it, as well as the comments that followed. Numbers don’t lie, and they can see the number of upvotes as well.
This helps you out as it sets the tone from the start: it shows that you’re accepting of all feature requests, that you’re open to discussion, and that you’re actively working on whatever your customers need to be built or fixed.
So, if a customer is asking for a feature that is most likely not going to be built (but you can’t say that with certainty), you can say: “We don’t have this feature on our roadmap now, but you can add it to our feedback board so we can consider it and discuss it - and other customers can vote on it too. You can find our feedback board at this link.”
Don’t mislead or give false hope
Being nice is always a plus, but you should never resort to making promises you can’t fulfill. Rejecting customers isn’t easy and you could be afraid that when they hear no, they’ll just go to a competitor instead.
There’s a slim chance of this happening so do your best not to mislead your customers and give them false hopes that you’re going to build a feature that will never make it to production. You’re only setting yourself up for trouble at a later point when they ask about the same feature request once again.
And of course, they can see from your roadmap whether you’re misleading them or telling the truth. If it’s a no, make sure the customer gets the message, loud and clear.
Close the feedback loop
The only thing that is worse than hearing no to a feature request is not hearing anything at all. When you’re not responding to feature requests, you’re doing yourself a disservice and ignoring your customers, so make sure every request gets a reply, even if it’s a negative one.
Feedback software such as FeedBear lets you take care of this without lifting a finger. As a feature request comes in (through your feedback board), customers get notified every time something happens with it. As it moves through different stages, they get an email with the update.
Another neat aspect of using feedback software is that it lets others join in as well. To be more precise, customers can vote and comment on other people’s feature requests too, besides creating their own. When this feature request progresses, everyone who leaves a comment or an upvote gets notified about this change as well.
Keep everyone informed without sending hundreds of unnecessary emails - with FeedBear.
Dealing with feature requests is a lot simpler than it may seem. Even if you have to say no, this is not the end of the world for your product or customer. In fact, it’s a great opportunity to engage with your audience, hear more about their problems and find new ways to provide value.
The most important part is to automate the tedious parts so you have more time to talk with your customers. If you’re looking for one tool to make it happen - try out FeedBear! You can collect feedback in one place, maintain a beautiful and functional roadmap and communicate everything about your product with ease. Sign up today to get started!