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.
Why digging a feature request is important
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.
Building new features without understanding the customer motivations behind them can lead to feature creep and, most importantly, precious time wasted. Time that could be spent adding real value to the product.
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.
Understand the job a customer is trying to do
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.
Ask “why” as many times as it makes sense
What would the new feature help the customer achieve?
Example:
I want a hammer.
Why do you need a hammer?
I’d like to hang a picture on the wall in my living room.
Why would you like to do that?
My daughter will visit me this weekend and I’d like her to see a picture we took together on our last holiday.
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.
Understand how is the customer achieving the same thing without the feature
How are they currently coping without the feature?
Do they have a workaround?
How complex is it, what steps do they take?
Do they interact with any other systems?
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.
How important to the customer is the job they need the feature for
How much time does it take them?
How often do they need to do this job?
What happens if they don’t do the job?
Look for emotional signals. Are they frustrated?
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.
Mining for gold
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.