How To Use Customer Feedback: Problem vs Pain

It’s no mystery how customer feedback fits into business.

Des Traynor, the co-founder of Intercom, thinks of customer feedback as business-oxygen.

Drift refers to it as the ‘battery that powers customer-driven companies.’

No surprise, then, that much has been said about how to ask for it, collect it, and implement it in the right ways, from keeping your own biases out, to weighing its different sources and inspiring honesty.

There’s a thorny customer feedback problem, though, that we’re mostly tiptoeing around: you can collect the most descriptive, insightful feedback possible and have it result in something underwhelming, for both your company and your customers.

‘Most companies devote a lot of energy to listening to the “voice of the customer,” but few of them are very happy with the outcome of the effort,’ writes Rob Markey et al. at the Harvard Business Review, in an effort to advise companies on how to close the customer feedback loop.

‘Feedback loops often suffer from a lack of commitment,’ writes Sarah Chambers at Kayako, in an article outlining how difficult it is to balance customer requests with available resources.

There seems to be a gap we haven’t bridged as yet, between feedback and the value you can extract from it. And I think it’s a result of failing to recognize two things: that feedback is symptom-centric and that value is job-centric.

A caveat is in order, however, before we begin. While this post is focused on using customer feedback to solve for the right customer problems, there is more to be said about whether a solution might be right for your business. Only a solution that’s right on both counts is worth implementing.

Feedback is symptom-centric

All a patient can do, when he’s trying to figure out what’s wrong with him, is talk to a doctor about everything he is feeling – the ache here, the rash there, and the tightness in his lower jaw before the doctor ties each symptom to the others so they all make sense as a whole.

Customer feedback works in the same way. All your customers have is their experience of your product and this means that even at its most descriptive, any feedback they give you is inherently subjective.

Without an objective understanding of why and how you’ve put your product together, feedback is a subjective account of what it is like to have a problem; it can’t be taken as a description of the problem in itself.

This is the primary reason it makes sense to treat customer feedback as you would a hypothesis – there are metrics to consider, weighed against what works for your product and the resources you have at your disposal, before you execute a solution or start building a feature that a customer has asked for (this is the right-for-your-product thing I’m glossing over for now).

Wherever (whoever) the feedback is coming from, it needs to be deconstructed, and tied back to the underlying problem, if it is going to feed value back into your product.

Value is job-centric

Value, on the other hand, isn’t built around a person. It’s built around a job.

It shouldn’t matter to the Hammer Co. whether the person using one of their hammers fits into a blue-collar or a white-collar persona.

Personas, for all the information they bring with them (hypothetical and not), can’t tell you (or the executives at Hammer Co.) what it takes to make a better hammer.

The ends to which a hammer is used, however, just might.

Intercom has covered this idea of job stories vs user stories extensively.

In essence, they argue that user stories (typically built around personas) have too many assumptions that don’t acknowledge why someone does something.

This means that the value you can extract from a user story is limited. Like the example of Hammer Co.’s personas.

Job stories, on the other hand, are all about the why – they’re incredibly focused on causality; the because that’s lying hidden within the story of a product (I used the hammer because I wanted too…).

Job stories lend themselves to value in a way that user stories do not.

The bridge between symptom-centric and job-centric

By themselves, our two ideas lend themselves to old conclusions. First, that feedback can be a great aid towards knowing your customer but it isn’t the be-all and end-all. And second, that creating value is tied to the why hidden in a customer story.

Tying these two ideas together, though, delivers a little insight into what might be causing that pesky gap between feedback and value: a failure to address the why that’s driving it. Customer pain is the result of a product or feature that isn’t quite doing the job that it’s been hired to do.

Bridging the gap, then, means figuring out how to use customer feedback to shed light on underlying problems (as opposed to the obvious superficial ones). Bridging the gap, in other words, means tying customer feedback back to the job that your customer has hired your product to achieve.

Understanding that the gap exists and bridging it is the difference between a quick-fix that acts as a band-aid and a lasting solution that puts a broken bone back together; the difference between treating the symptoms and treating the disease.

‘We could use feedback to offer quick fixes, we don’t. We use it, instead, to ask more ‘why’ questions, to dig deeper into the journeys and goals of our customers, and figure out what their problems really are.’ – Rajaraman, co-founder, Chargebee.

Here’s how Chargebee did it.

Talk to the user, solve for the job

I found the doctor-patient metaphor to be so appealing because it’s the only way that I can describe Chargebee’s attitude to customer problems: understand the symptoms, look at the data, diagnose the disease.

Ask why, ask why, and when you’re tired of asking why, do it one last time.

The process hasn’t always been linear and unblemished (because this means that you don’t give your customers what they’re asking for, in some cases) but the solutions that have come from tying feedback to jobhave fed back into the product in extremely valuable ways.

These illustrative case studies are an amalgamation of real examples that Chargebee has learned from over the years.

Case Study 1

When RT wrote in, frantic, that their exports of customer information were failing, solving for the pain they were (very clearly) facing would have been easy – all a matter of figuring out why they were failing (because they were trying to export an unsupported field) and working around it (download the unsupported field information separately and merge the two .csv files in Excel later).

But we wanted to dig a little deeper.

We knew that RT was using Chargebee to organize shipping information (in addition to billing). When a shipment was due for the next month, they would filter out the customer they had to ship to (the active ones who had cleared all past due amounts) and export their details to Excel where they would sort through the information before shipping began.

What we learned was how their rapid growth was affecting the job they’d hired Chargebee to do. With thousands of customers asking for t-shirts every day, their shipping deadlines doubled…and then tripled. It got to a point where they had to ship at multiple times every day.

This was why they had the unsupported fields to begin with – they were trying to make their shipping process simpler by collecting all the information they could from their customers up front (so there was less sorting in Excel).

Peering past the pain took conversation and patience (on both sides, definitely). Solving for the pain was to fix the exports. Solving for the problem, though, was to offer a workaround so that Chargebee could sort customer information so shipping became smoother as a whole.

Tying the feedback (things within Chargebee are going wrong, help) to the job they were expecting Chargebee to perform (we want to start shipping every day), helped us figure out how to solve their shipping problem for them in a way that worked well with RT’s growth over the next few years. And made sure they never had Excel problems again.

Case Study 2

When QA wrote in with a request for a support desk integration, something that was already on our roadmap, their pain stood out. There was too much of a load on their support team.

But we wanted to know why.

We knew that QA has a very customizable product on their hands, which meant there were myriad ways a user could tailor their product to their liking.

What we learned was that their support team was collecting, sorting, and applying these customizations themselves. All the customer requests were coming through to QA’s small support team creating a bottleneck. An integration with the support desk QA was using would have eased the pain, but it wouldn’t have solved the problem.

Tying the feedback (our support team needs help) to the job they were expecting Chargebee to perform (record changes to subscriptions as they come in), helped us prioritize our self-service customer portal over a support desk integration (which came to the fore only late 2016).

What’s next?

There is a lot left to address. Just because you’ve identified the problem doesn’t mean you build the feature (that’s how this idea of solving for the problem ties into the vision you have for your company and the data you have on the problem).

How you validate solving for a problem now vs later is a product call that must balance your vision, goals, and resources, because, make no mistake, every customer solution is a change to your product. I’ll leave an analysis of that for Part II.

This is a solid first step towards figuring out the right customer problems to solve for, though: asking why to tie it back to a job.

It’s helped us bridge the gap and create lasting value for our customers and their businesses.