How to mine a feature request for better product decisions | Support Hacks

No matter how great your product is, there will be gaps between what the customer needs and what the product offers. So if you work in Customer Support, most likely you are dealing with users asking for features that the product doesn’t have.

The usual approach taken by most Support teams is to tag the conversations where customers are asking for a new feature and send weekly or monthly reports to the product team with the most requested features.

What you don’t know is that, from the product perspective, you are sitting on a gold mine. And it’s up to the folks working in Customer Support to dig and extract the gold, or completely ignore it. Furthermore, the data you send to the product team, although accurate, can lead to poor product decisions if taken for granted.

In this issue, I will describe a different approach to handling feature requests. It will take your team a bit more time to do right, but I believe the benefits greatly outweigh the extra time put into it.

Let’s start with an example. You are supporting a SaaS product that helps gym and club owners manage their memberships. At some stage, you start getting new feature requests from customers asking for an analytics & reporting feature. The support team tags rigorously each ticket and, at the end of the month, you send a report to the product team highlighting the new feature request.

After discussing the new idea in their weekly meeting, the product team concludes it is a reasonable request and decides to implement it during the next release cycle. Two months and a few thousand dollars later, a new dashboard feature with shiny charts and filtering capability is proudly announced to customers. However, despite the effort put into it, the customers are not using much the new dashboard. They start asking for another feature, a PDF export.

When one of the product managers finally asked a few customers why they need the PDF export, he found an astounding fact. The gym owners wanted to add the export to the brochure they send to professional trainers to promote themselves. They only needed a one-page doc with new nice-looking numbers there to impress the trainers.

Customers asked for analytics. The product team jumped to the conclusion that they wanted to better understand their memberships data. But what they really wanted was to impress people. If the product team had correctly understood this from the beginning, they would have built a totally different and much simpler feature.

Customers hire products to make progress in their lives, to help them with a job they’re doing. Any feature request should be mapped to that particular job, to what the customer is trying to achieve.

Simply tagging and tracking the requests would produce very little valuable data to help the product team. The gold is in the follow-up questions and the responses to those questions.

What would the new feature help the customer achieve?

Example:

What is the job of a hammer in this example? Hitting nails or preserving precious memories? The end goal of a feature is not always as it looks like in the first question. Asking “why” a few times as appropriate will help your product team understand the customer motivations at the deepest level.

Look for facts, not opinions. Avoid asking customers their opinion of what they’re doing, you only want to know what they’re literally doing.

The answers to these questions will help the product team understand the current workflow that customers are using, including the complexity of the job and any dependencies.

The answers will help the product team prioritize the feature request if they decide to pursue it. When customers are spending a significant amount of time and resources on a workaround, that means the goal they are trying to achieve is very important to them. If that’s the case, you want your product to be part of the solution that helps them achieve their goal.

There is a lot of emphasis on quantitative data in Customer Support and for a good reason. Metrics and KPIs are important. What is often ignored though is the qualitative data.

Having open conversations with customers can teach you many things from the product perspective. You can learn about their struggles, motivations and emotions. Things that you can’t get from a dashboard.

The customer stories and motivations are hidden in those conversations we call tickets or chats. They are not apparent at the first glance, one needs to dig them out, mine them for gold by asking thoughtful questions. The answers to those questions hold the key to a customer-centric product roadmap.