This was written as part of the rough draft for Deploy Empathy, a practical guide to interviewing customers.
Like it? Order the book:
Most bootstrapped founders talk to customers a lot by default. It’s pretty common for people to handle all customer support and sales themselves for a long time (we still do and have no plans to change!). Lots of phone calls, emails, chats with customers.
So you might think you’re all set when it comes to talking to customers, and wonder why on earth you might need to talk to them more.
I’m going to tell you something that will make you go “agh, really?!:” customer support and sales don’t count as customer research.
Customer support and sales are important. A company can’t exist without them.
… but you also need to set aside time to listen to customers – really listen to them – in a way that isn’t appropriate in customer support and sales settings.
Customer research is a specific activity to unearth customers’ underlying goals, activities, frustrations, and needs, and we use those insights across the many different functions of the business. These things can trickle out in sales and customer support, but I encourage you to set aside time to get these sorts of insights in a concentrated form.
I hope you’ll forgive my pedantry on this. I just want to save you from an accidentally awkward situation. I feel confident you can avoid that once you have a sense for where the lines are.
Let’s dive in a bit, starting with customer support.
Customer support is not customer research
When someone approaches customer support, it’s usually because there is a problem. Something is broken, doesn’t make sense, and is getting in their way. And chances are, they’d rather Do The Thing than talk to someone about how they can’t do the thing.
After all, none of us want to be standing in the returns line at H&M.
(I say this knowing that every organization has its “frequent flyers:” people who tend to call and talk quite a bit because they have limited people to talk to in their daily lives in a B2C setting, or have frequent bug reports in B2B. In my experience answering phones, those people are only a small percentage of customer support inquiries, but garner an outsize amount of attention.)
So, someone comes to you for support. They are approaching you because there is a problem, and this problem stands in the way of accomplishing their task, and they need this problem fixed so they can get on with whatever it was they were trying to do in the first place. We use empathy here to help them resolve it and get back to that task. But the kind of deep curiosity about their underlying tasks is not appropriate in this scenario. They’re trying to get something done, and the product is already in their way, so we shouldn’t get in their way further with more questions.
Note, you can use this as an opportunity to follow-up later – once the problem is solved, the task is done, and their stress of accomplishing the task has evaporated – to set up a dedicated interview another day. This might look like sending them an email a week later like this:
I just wanted to thank you for your understanding last week as we worked through [issue]. Thank you for surfacing this. By speaking up, you’ve allowed us to fix this and ensure that no one else encounters that frustration again.
When we were talking, you briefly mentioned how you were trying to [broader activity that relates to underlying goal]. I was wondering if we might find time sometime this week or next to talk about how you [accomplish underlying goal] to help us understand what you do better.
[Scheduling information – ex calendar link]
And on that note, customer interviews are not customer support. If someone surfaces an issue or complaint, we should jot it down, tell them we’re taking note of it and will communicate it to the appropriate person/team afterwards, and then dive into why that problem presented a problem for the customer. This can be a great launching point into descriptions of processes, but we should not go into customer support mode.
Sales is not customer research
Sales is not customer research as well, but for an entirely different reason. On sales calls, it’s common to get into the problems that someone is solving, the tools they’ve used before or are evaluating, and why they might be looking to switch.
This is GREAT information, but it’s incomplete information.
To fully understand someone’s goals, activities, and needs, we need to be able to dig into the emotion and social context behind the tasks. We need to deeply understand the struggle and pain from the person’s perspective.
But in a sales situation, people have their guard up. For good reason! We should respect that and not try to tear it down.
The kind of empathy that we use to dive to that level and truly understand the human behind the goals is simply not appropriate in a sales setting. In a sales context, we are sympathetic to their goals, and we listen as they describe problems. But it is not appropriate to dive to the emotional level that we would in an interview.
Sales is usually a low-trust setting: someone is trying to figure out whether your product is a fit. It’s a trust-building opportunity for sure, but it’s not by nature a relaxed setting.
In a sales setting, we might also give advice. If a person voices a problem they need solved that our product doesn’t do, we might say that we’re planning to add that in the future, or that another competitor solves it better and recommend they use them instead. We would never provide advice or information like that in an interview.
On the flip side, customer interviews are not sales.
This is probably the biggest mistake I see people making with customer research.
If someone surfaces a problem that they need solved that another product of ours solves and they don’t realize it, do not tell them. Whether it’s an existing feature they already pay for, an add-on product, or a separate product entirely – don’t sell them. These are signs that discoverability of that feature/product is low, and we can dive more into what context they might expect to have that problem solved, the tasks it’s adjacent to, and so forth, so we can learn how to better position that product in terms of process flow.
Selling someone in an interview – or merely saying “oh our product already does that” – will shatter the trust you’ve worked hard to build in the interview. Don’t do it.
Like the customer support example above, we can always email them later. Let’s say they surfaced a task our product solves but they weren’t aware of. We can always email them the next day – perhaps combined with our thank-you – to follow up:
Thank you so much for taking the time to talk to me yesterday! I learned so much from you about [problem/process/etc].
I wanted to touch on something you said in our conversation. You said you were looking for something to do [x]. Our product does this, though it seems the feature is unintentionally a bit hidden.
Would you have 30 minutes sometime in the next few weeks so we can screenshare? It would be helpful for me to see you move through the site to help our team explore how we can bring that feature forward.
We use empathy in customer support, but it isn’t appropriate to use too much curiosity and pepper them with questions. Let’s not get in the person’s way more than we already have.
We use curiosity in sales. But it isn’t appropriate to plunge their emotional depths and use the kind of empathy we would in an interview. We shouldn’t force them to take down the emotional guardrails they have justifiably put up in such a low-trust setting.
We use empathy and curiosity in customer research. When we intentionally interview a person, we dive into their goals, their pain, their process, their emotions.
Customer support, sales, and customer research should work together, and can do so beautifully. But we need to regard them as their own distinct activities, with different ways we conduct them, in order to get the results we want.