Customer feedback is an essential part of building a successful software business—or any business for that matter. While feature requests are a common source of customer feedback, they tend to be hit or miss due to the customer’s lack of context. A feature might make sense to them but might be an expensive-to-develop edge case for your business.
Let’s take a look at how to think about feature requests and tactfully say ‘No’ to those that don’t make sense for your product roadmap.
Customer feedback is an essential part of building a successful software business, but feature requests tend to be hit or miss. Here’s how to say “no”. Click To TweetManaging Feature Requests
Feature requests come from a variety of sources, including support tickets, sales conversations and customer emails. These requests are typically recorded on a Trello board or spreadsheet where they are periodically reviewed by product managers using a cost-value matrix. When features make sense, they are pulled into development and eventually launched.
Public Roadmap Portal based on your JSM project – Source: Amoeboids
A growing number of companies use public roadmaps to involve customers in the process. By enabling customers to vote on features and see the long-term vision, public roadmaps provide valuable context to feature requesters and help communicate with customers. Votes also prevent duplicate feature requests and make it easy to see what customers want.
For example, Product Roadmap for Jira Service Desk enables you to collect votes and feedback from customers through Jira Service Desk. Customers can access the product roadmap through their existing JSD accounts while roadmap items are dynamically populated with JQL queries.
Understanding the Requests
The best way to think of feature requests is an early warning system for potential problems. After all, customers make feature requests because they have a problem. Some of these problems may point to a deficiency in onboarding (e.g., it can be solved with an existing feature) while others may point to a much larger issue than a single feature.
Amoeboids-Request-QuestionnaireBefore logging or rejecting a feature request, the sales, support or another point of contact should take the time to understand the problem behind it. What problem does the feature solve? How will the feature request help solve that problem? The answers to these questions can help determine the best way to solve the problem.
By framing feature requests as problems to be solved, you can avoid saying “no” in many cases and instead help the customer achieve what they’re really trying to accomplish. Most feature requests don’t require a new feature, they simply require a little education or workaround to help solve a problem. And, that kind of response can help keep customer churn in check.
Sending the Right Response
There are some feature requests that do require a “no” because they’re not economically feasible and/or out of the scope of your business. For example, an email marketing business may have no interest in adding social media management to its feature set. While you could just say “no” in a short email, empathy goes a long way in keeping customers happy.
A thoughtful “no” reply should include:
- Thanking the customer for taking the time to provide feedback.
- Telling them how you use that feedback and why it matters.
- Telling them that you won’t be working on the feature and the specific reasons why.
- Suggesting a workaround to solve their problem, if possible.
Let’s take a look at an example:
Thank you for sharing your idea for exporting data to a new format. We understand why it would be helpful to include this functionality.
Every month, we review the top 10 feature requests from customers as part of our product development process. We take into account how they fit with our company’s vision, as well as the cost and feasibility to implement them.
We have already committed to three customer feature requests this month, including a separate export request that had more votes (20 votes compared to 5 for this feature request). So, we will not be moving forward with the export option at the current time.
That said, you may want to consider exporting to CSV and converting it to the format that’s right for you. It’s not as simple as a direct export option but you can still access the data you need. You can see a support article on how to accomplish it here: [LINK].
If you’re using a public roadmap, you may want to include these comments in a feature request card to notify users before closing it out. These comments can help everyone feel engaged and encourage them to continue submitting feedback rather than discouraging them. Public roadmaps also help showcase what features are in the pipeline for active development.
Best Practices to Keep in Mind
- Stay Organized: Feature requests should be organized in a single location regardless of the origins (e.g., support, sales, email, social media, etc.). In addition, you should keep them categorized and prioritized to simplify management.
- Make It Public: Public roadmaps are a great way to engage customers and identify promising features to help fill out a roadmap. Feature voting capabilities can also avoid duplicate feature requests and keep things more organized.
- Respond Promptly: Respond personally, promptly and honestly to customers making feature requests. Don’t send generic rejection emails or falsely claim that you will “consider adding” a feature in the future if it’s not in consideration.
- Discuss Ideas: Don’t be afraid to discuss feature requests with customers. If something sounds interesting, create a focus group or interview customers to learn more. There may be more to the idea when it’s fully explored by a group of people.
The Bottom Line
Customer feedback is an essential part of the software development process and feature requests are a common source of feedback. By framing these requests as problems to be solved, you can identify and fix problems that may not require a new feature. When you do say “no” to a request, it’s important to empathize with the customer and tactfully do so.
