Solving Customer Problems, Not Feature Requests
So often, as product managers, it can feel as though customer complaints are thrown over the wall to us in the form of unvetted feature requests and other prescriptive solutions. It’s annoying. And it’s also our job to help the customer support team understand how to pass on user feedback in a helpful way.
In this post, we’ll cover why support and product should work together, how to train support to collect and evaluate user feedback, and finally how to set up a solid feedback process between the two teams.
Why support and product must work together to solve customer problems
Customer support people are problem solvers, no doubt about it. Their job is to field complaints or difficulties, user mistakes and software malfunctions. And they’re incentivized to solve the problems as quickly as possible, usually under a certain time period: two hours, 24 hours, etc. Closing tickets and customer satisfaction are critical to customer support’s performance metrics.
But what about the customer problems that can’t be solved on the spot? Then product management gets involved.
Indeed, these problems might require a longer term (i.e. more comprehensive or more foundational) solution, perhaps something built by the development team. Once a solution is in place, the support team doesn’t need to field complaints about it anymore.
So, reporting and/or handing over such customer problems from support to product is clearly an important link. A strong feedback loop between these teams can better the product, improve user satisfaction, and increase support efficiency – impacting all the juicy company KPIs that are attached to those.
The key is to get this hand-off right!
How to train customer support to collect feedback for product
To be fair, it’s not the support team’s day job to collect and interpret feedback so much. And we’re not trying to put more on their plate. Quite the opposite. We’re trying to get to the root of issues, so their job is easier! (It just so happens this makes our job easier, too.)
We can get there by reframing questions and using new techniques. The tenets of this training are to help the customer support team to:
- Understand “the why”: how to see customer problems holistically
- Focus on problems, not features: how to define core issues and needs
- Use good feedback channels: how to communicate it to product
Understand “the why”: how to see customer problems holistically
When it comes to understanding customer feedback, product teams love the 5 Whys method. (In fact, I’ve even used it with my own dad!) It’s a simple one to pass on to the support team.
The method approaches feedback and requests with an iterative round of questioning – and that question is always simply, “Why?” With each answer you receive, follow up by asking “Why?” again, and you’ll peel back the layers of what the customer actually needs.
By digging to the root of the problem like this, three great things happen:
- The solution can end up loads easier than whatever request or idea the customer originally had. That means faster, simpler, more elegant fixes.
- The product team doesn’t need to doubleback to the customer for more information and repeat the conversation.
- The customer ends up feeling really listened to, because you’ve engaged them about their problem and they’re involved in the discussion.
Focus on problems, not features: how to define core issues
Once we’ve reached the core problem, let’s stay there! Let’s not wander into solution territory or hypothesize how some features could be tweaked to do this or that. We don’t need feature requests, we need well-defined problems.
One way to help non-product people understand this concept is to give real life examples. Specifically, give them examples of when a product feature request has led to something being built that wasn’t the requested feature, but that did solve the underlying problem and in a better way.
Some well-known quotes out there demonstrate this well. And although the quotes might be historically incorrect, their messages still ring true!
“If I had asked people what they wanted, they would have said faster horses.”Henry Ford (There’s no evidence he actually said this, but it’s a product management maxim at this point.)
“The electric light did not come from the continuous improvement of candles.”Oren Harari
Once the support or success teams get the importance of staying problem-focused, you can give them convenient ways to transfer this customer feedback to the product team.
Use good feedback channels: how to communicate it to product
The final step is to make this collaboration as easy and seamless as possible.
Product people know that the best practice for collecting customer feedback is to offer loads of ways for those customers to actually submit it. There should be an option in the app, on your website, via email, through Slack or social media, etc. If your team is new or just getting started with collecting feedback, have a look at how to set up a customer feedback process.
The same applies to getting feedback from customer support to the product team. Set up several feedback channels for non-product folks to send over the information. The easier it is to share, the more feedback you’ll get. And chances are it will be better quality!
You can use a special email address, a Slack channel, a Typeform, an old-school shoebox with written notes inside. Provide a short template for a “problem-focused” report, so the support rep only needs to fill in the blanks.
Of course, it’s best to automate this step as much as possible. That’s exactly what we’ve done with ProdPad.
Within the tool, we have a Chrome extension, which means that people from Success can quickly write some feedback from their browser. There’s also a customer feedback portal where the support or success teams could add feedback on behalf of a customer.
Essentially, ProdPad is a tool that helps automate the feedback collection process, and then helps product teams manage the feedback through well-designed backlogs and roadmaps. To check it out, you can sign up for a free trial.