If you’re in the SaaS business, odds are you get feature requests from your users all the time. Receiving this feedback is a great sign, it means your users use and value your product enough to try and make it better (rather than the other side of the coin where you’re building a product that no one wants, nor cares about). Show your users you similarly value their input by responding to their inquiries, challenges, and requests, and you’ll keep their trust, foster long-lasting relationships, AND motivate them to continue sharing their ideas with you.
So...this begs the question, how do you respond to a feature request?
Don’t give your users a chance to feel like their feedback has gone into a black hole! It’s important to acknowledge the feedback you receive, so your users know you are actively listening and have received their valuable feedback. As Kristen Smaby explains, “When customers share their story, they’re not just sharing pain points. They’re actually teaching you how to make your product, service, and business better.”
So be sure to acknowledge them for this help and guidance. When people feel that their feedback is heard and valued, they are more likely to continue sharing it. Here’s where things can get tricky. How exactly should you go about responding to each and every feature request you receive? In the early days, sending personalized email responses to every request you get is feasible, but as your userbase grows, the volume of feedback you get will follow suit.
How can you ensure users don’t feel like their ideas and suggestions are being lost in the feedback black hole? (Wink, wink, nudge, nudge, UserVoice can help you do more than just capture and aggregate user feedback, we help you eliminate the feedback black hole too!) Here’s how to take it a step further than simply sending an automated email that says “Thanks for your feedback, <YOUR NAME HERE>! We appreciate it!”
We all know what they say about assumptions...so let’s not make assumptions when it comes to feature requests, ok? As Henry Ford once claimed, “If I’d asked customers what they wanted, they would have asked for a faster horse.” Rather than taking every feature request you receive at face value, dig into the background and uncover specifically what your users are trying to solve or optimize for...rather than assuming the faster horse they’ve requested is the best solution.
There are a ton of resources to help dig into the meat of feature requests, Jared Spool encourages product managers to pry for users’ desired outcomes. Questions like “If we act on that request, what will the outcome be for you?” followed by “what is preventing you from doing that today?” will get you a long way. Another easy framework for getting to the root of any problem is the famous “Five Whys.”
Essentially, each level of “why” helps your team get deeper and deeper into the root of the issue at hand. Only once you’ve uncovered the problem can you begin to articulate and test possible solutions.
Don’t just respond to feature requests, dig into them. The better you understand the problem and take the time to validate that your solutions are the correct ones, the better you can serve your end-users.
I can’t emphasize enough how important it is to be honest in all your responses. In an ideal world, all of the received feature requests would be a perfect fit and could feasibly be built out and delivered. However, this is not the case. As product managers, we must be picky when determining which features to build, which also means saying “no” quite frequently.
If you’re not used to saying no, the first few times you tell a user “no, we’re not going to build that” can be uncomfortable. Here are a few suggestions to help as you build up this very important product management “muscle” and start feeling more comfortable telling folks “no”.
Time and time again we preach about the importance of closing the feedback loop. Product teams that get into the habit of acknowledging, digging deeper into, and when necessary saying “no” to feature requests will get more value out of their customer feedback programs than those who don’t prioritize closing the customer feedback loop.
Furthermore, a closed-loop customer feedback program is table stakes when it comes to providing a positive customer experience to users. As recent research on B2B customer experience found, customer experience is expected to pass both price and product as key distinguishers for SaaS products in increasingly competitive spaces. So, as you’re benefiting from all the valuable input your users share with your team, don’t forget about one of the most important parts of a healthy product feedback program: following up, and following through.
If you need a system to help your team better understand what your users want, check out UserVoice today.