8 - How and Why You Need to be Talking to Customers episode artwork

EPISODE · Jan 25, 2022 · 28 MIN

8 - How and Why You Need to be Talking to Customers

from Stacking Growth | The B2B Marketing Podcast · host Refine Labs

This episode contains a recording from a Customer Research session MJ Peters (VP of Growth, Refine Labs) hosted internally. She shared how to seek out opportunities to do customer listening, a step-by-step framework for customer research that you can implement in your business, and a handful of use cases for customer listening. If you find yourself needing to conduct market research for any reason (which every marketer should be doing), you'll find value in this episode.

Episode metadata supplied by the publisher feed · Published Jan 25, 2022

Embed this episode

NOW PLAYING

8 - How and Why You Need to be Talking to Customers

0:00 28:39
of MATCHES

TRANSCRIPT · AUTO-GENERATED

The marketing movement by ReFine Labs. Welcome back to the marketing movement. In this episode, MJ Peters, the VP of Growth at ReFine Labs, breaks down everything you need to know about customer research, spotting opportunities to coach your clients to do customer listening, and giving your clients a process for getting customer insights that will help them be confident and take action. Enjoy.

I'm going to talk about customer research. My background is a lot of product management and product marketing. And so customer research is something we do a lot to apply to a ton of different contexts, which I'll talk about a little bit later. So just wanted to share some of my experience and how I approach that.

So in terms of what I'm hoping people will get out of this session, obviously we don't do customer research on behalf of clients that ReFine Labs. However, I think a lot of our clients could benefit from doing it in-house. So the two things that I hope you'll be able to take away are, first of all, spotting opportunities to coach your clients on where they might use customer listening. And also, if they want to do customer listening, giving them a process, they've never done it before, that would help them be confident and take action on it.

I think it's especially important to do customer listening for companies that are not marketing to other marketers, because you just don't have built-in empathy for what your customers experience. So you have to be pretty methodical in order to get to messages and products that are going to resonate with them. So a couple of use cases for customer listening, there are more use cases than this, but these are ones where customer listening has been very impactful for me in the past. One would be defining a more specific ideal customer profile.

So if you're finding your customers feel like they're not reaching the right people or the stats you're getting back are maybe a little weaker than some of the other accounts you run on, it might be worth having your customers think about defining a more specific ideal customer profile, because it could be that their value proposition for their product resonates more strongly with a specific set of customers, and they're casting too wide of a net, and talking to some of their best customers to find out what sets them apart from the rest is a great way to make your ideal customer profile a little bit more effective. In that same vein, creating a more effective go-to-market strategy. So I did notice when I was sitting in client calls during my first couple of weeks, a bunch of our clients have multiple segments that they market to in their business. And the last two companies I was at had multiple segments in our business.

And the more I learned about the customers we were selling to, the more it became very clear that one or two of those segments were far more profitable, where the customers resonated with our product, a lot more saw a lot more value in it. And so it made a lot of sense for the company to focus more on those one or two segments, versus spreading themselves too thin. So that could be going on inside of some of the companies that you're working with. And then, of course, I think this is going to be one of the biggest use cases for us in our clients that we're finding out is delivering messaging and creative that resonates more strongly.

So if you find that you have clients where it feels to you, like their messaging is a little generic, or you want to come up with new things to experiment with, customer listening can be a great source of ideas, and in fact, you can use the customer's own language to create messaging, which tends to go over pretty well with them. Same thing with creative, like the images that you select. I think I might have posted about this on LinkedIn today, actually. The images you can select can resonate with them, or they can be totally off base.

And the more you know about them, the better in terms of being able to select the best creative. I used to do this primarily for generating new product ideas. So product marketing and product management, working closely together to identify what should be on the roadmap. And then finally, generating better content.

So customer listening is one of the first places I go when I don't have content ideas to populate that content calendar with stuff I know that my customers are going to be interested in. So with those use cases in mind, I want to transition over and talk about a framework that I use for customer listening that can break it down into some discreet steps that people can follow to make the most of the conversations they set up with their customers. The framework looks like this. There's basically four steps.

You start with a hypothesis, and then you do your customer listening. So you set up conversations with people and you can document the interviews. Then after each interview, you're going to document what you find. And then after you have all of your interviews documented, you'll come back to that original hypothesis and validate pieces of it and quite possibly invalidate other pieces of it.

Throughout that process, there's a number of documents and preparation that I recommend doing, especially if you don't have a ton of experience with this. So those include a discussion prep, a discussion guide for each conversation you're going to have, and then a call reports in order to document every conversation you've had. And I'll go over some kind of like best practice with regard to each of those things as we get more into it. So the first thing I like to start with is a hypothesis, which is, I think it's very useful because I don't need to tell you that everybody has opinions about marketing.

And it's kind of hard to decide with something like marketing, what's the best message that we should be using or which customers should we be marketing to, what's our strategy be. And so one answer that I found a lot of companies come up with to those questions is called the HIPAA, which stands for Highest Paid Persons Opinion, which while a lot of companies do that, it's not always the best answer to the question. So I find that the best antidote to the HIPAA method of decision making and marketing is the scientific method, basically approaching these marketing decisions in an evidence-based manner with the customer conversations being the inputs. And so you start with the hypothesis and the scientific method because as a team, you are assuming that you're smart, but you're guessing.

In terms of what the hypothesis actually looks like, the purpose of it is to document as a team what you think is going on. And so you can use any format you want. I'll give a couple examples of formats that I have used that might be a good starting point on the next slide. But no matter what format you use for your hypothesis, you should write it down.

I think a lot of teams probably skip the writing it down part. It's actually kind of hard to force yourself to write it down. But more than likely when you create a hypothesis, you're going to have a bunch of team members that are coming at it from different angles. Maybe you've got people from product marketing and demand-gen and content and brand, or maybe you have people from sales and product management in there too.

Everybody has different information. Writing it down is a forcing function for the group to be very clear on what everyone thinks and be on the same page about what it is you're going to test. Because again, we're smart but we're guessing. So the reason you document the hypothesis is because you're going to use the customer conversations to test that hypothesis.

So two hypothesis formats that I have used in the past. The first is customer problem solution. And so this is, as a group, you want to write down in as much detail as possible, who is your customer? What problem does the customer have?

And how does your solution solve their problem? And there can be multiple bullet points under each of those. Who is the customer? It might be job title, geographic area.

Maybe you might segment by certain beliefs that people hold or what kind of technology they use, et cetera. So like capture everything you think defines an ideal customer. Same thing with the problem. Your customer might have like 10 different problems and maybe two or three of them are super important.

Maybe two or three of them are solved by your product versus not solved by your product. And then, of course, how do your features and benefits map to those problems that they have? Jobs, pains, and gains is the second format that I've used. So jobs is what does your customer need to do, whether it's related or unrelated to your product.

Pains is in the course of doing that job, what gets in the way of your customer achieving what they need to do, what frustrates them, what keeps them up at night. And gains is like any sources of delight. And I could probably do an entire session on just jobs, pains, and gains and how you should do that and how you can come up with jobs, pains, and gains, but I'm not going to do that here because we're just going to go over this context of this wider process. But either of those formats can work well for a starting point for hypothesis.

So what do you think the answers to these questions are? How would you answer these before customer research? And then your customer research is going to validate what the customers think are the answers to each of these. So I'm going to pause here and tell a story because I think maybe some of you are thinking like customer problem solution is like a very stupid thing to write down.

It's everyone should know who our customer is, what problem they have and what the solution is. And I'm actually going to tell you a story about one time in a previous role where we actually had no idea what the answers to those questions were. So at FireChase, we were trying to enter a new segment, which was airport ground support equipment. So in the top left, you have this picture of a plane and the airport ground support equipment is like all the stuff and the vehicles that, you know, move the plane around the airport and refuel it and like put baggage on there, all the support equipment that planes interface with when they're on the ground at an airport.

And we were trying to of course sell them our fire suppression system, which looks kind of like that when it's inside an engine compartment to prevent the scenario that you see playing out here on the right where the ground support equipment caught fire and the plane is on fire as well. So we were trying to figure out how to reach that market and say, hey, you should protect your stuff with our stuff. And we started with customer listening. And so we documented our hypothesis, we used the customer problem solution methodology.

And we thought that the customer for our product, like who would be buying this, were somebody that works in it, therefore it. And probably somebody that was in operations or maybe their title was like risk management. We thought we'd go after the decision maker. So we said VP of operations or VP of risk management at an airport, which sounds like a pretty reasonable assumption.

We figured the problems were, first of all, if your airport ground support equipment catches on fire, then probably it's going to end up in the repair shop for a while. And you probably don't have that many of those pieces of equipment. So like these people need to keep the planes running on time. So if they don't have enough equipment, then they're going to have downtime and you're going to cancel flights.

That's probably an issue for them. And then also the cost of repairing that equipment is probably a pain point. And we thought that our solution was our fabulous fire suppression technology. After talking to customers, both existing customers and prospects like potential customers who we thought were in our ideal customer profile, we actually found out that the customer didn't work for the airport.

They worked for the airline. So we didn't actually know this, but the airline owned the ground support equipment, not to the airport. And they had a specific job function inside of the airline called fleet management, which was about managing all these vehicles and their lifecycle. So we were working in the wrong people.

And we were talking about the wrong problems in our messaging and our sales conversations in our content. Because even though it wasn't super likely that the ground support equipment was going to catch the plane on fire, like what usually happened if there was a fire in the engine of these things was like it was only a problem for that little vehicle and they repaired it and then it was fine. They didn't actually care about those fires, even though they happen more often. They only cared about the catastrophic fires where like the ground support equipment was catching the plane on fire.

So rather than talking about downtime and cost of repairing the equipment, the conversation, the sales conversation that resonated with them was like, you don't want to see your logo on the side of the plane that's on fire because that's not good for your brand. That's going to cause reputation damage. And it could even put passengers in crew in danger if it's a really bad situation. Those were, they were not interested in talking about the minor incidents, even though they happened way more often, they were only concerned about these major incidents.

And then finally, in talking to our existing customers that were already buying from us, we thought that they were buying from us because they thought our technology was better and they didn't. They were buying from us, they thought the technology was basically all the same. They didn't really know. They were buying from us because we were less annoying to work with than the other vendor that they were previously buying from.

So that was kind of interesting because we ended up making organizational decisions based on that. We created a new kind of team that had an engineer and a sales rep and a customer service person that only catered to these customers and was able to like really deeply understand their needs, which was leaning into that point of differentiation of us knowing the customers better and being more responsive versus the competition. So we were able to win more customers that way. So basically everything we thought was wrong.

And so while customer problem and solution seems like a really silly thing to not know about, it's always good to test your assumptions, especially when you use a rigorous framework like a scientific method. So the takeaway is nobody is above the scientific method. So now that we have gone over hypotheses, once you have one with your team, the next step is to do discussion prep. So quick note on this, you're going to complete one hypothesis for your whole customer listening project.

You only have to do that once at the beginning. But with discussion prep, you're going to do a separate discussion prep for each customer conversation. So usually when I do a customer listening project, I'll do like six to 10 conversations, which doesn't seem like a lot. But after six or 10 conversations, you will probably spot trends and you'll have enough information to validate your original hypothesis.

So it's like one hypothesis and six to 10 discussion for each conversation you're going to have. And the discussion prep consists of, again, writing down, force yourself to write down, who am I going to talk to? What do I want to learn from them? What am I going to do with that information?

And how will I go about learning the information? And the reason it's really good to do this is so that you have a clear objective and like a game plan going into each conversation. It helps you validate things more quickly and ask the right questions. When you force yourself to write down the first three questions, who am I talking to?

What am I going to learn? What am I going to do with the information? It's super easy to then immediately come up with the right questions to ask them. So here's an example of discussion prep.

For example, I might be talking to Andy Paul. He's the director of systems engineering at whatever place, whatever company. Two examples of what you might want to learn from your conversation. One would be what are his biggest frustrations with the products he's using today?

If that's what you want to learn, then maybe a way you're going to use that information is creating new content that addresses his top frustrations using the language that he uses to describe them. So you might want to sometimes flip the two questions. What do I want to learn and how many use the information? Because how you're going to use the information may inform what you want to learn.

Another example of that is maybe Andy is one of your best customers and you want to know what makes him different from the other customers so that you can then go back and incorporate that to create a narrow or ICP and do better targeting. I did an ICP exercise with customer listening at FireTrace where we were selling two machine shops and I interviewed 10 of our biggest customers that were in that segment. Most of them said that they were running an oil-based coolant in their machine and that wasn't part of our ICP. It was the only reason that they were buying it.

Anyone who was running a water-based coolant wasn't buying our product. This water doesn't catch on fire. We didn't know that before the customer listening showed us so we were able to create much more narrow targeting. We were able to come up with some cool partnership ideas with companies that were selling products to the same type of customers.

So creating a narrow ICP can be a really good use case. And then you move into the how I go about it. So how will I go about learning what I want to learn? It's prepared a list of six to 10 questions based on your discussion prep.

So now you know what you're going to learn and how you're going to use that information. What questions do you need to ask to achieve that outcome? With the questions themselves, you want to make them as open-ended as possible because you don't want to lead the witness. You want to hear what the customer has to say.

And in fact, if they say something contradicts your opinion, that's great because that means you learn something from this exercise. So always make them open-ended. Air on the side of more open-ended and less specific. Sometimes they're going to not understand the question.

If it's too open-ended, you might have to provide more context but air on the side of open-ended for sure. I also like to start broad and then zoom in. So some of the questions I like to ask at the very beginning of a customer conversation are like, what does a day in the life look like for you? Like just understanding what it is they do even if that is totally unrelated to our product because it gives you a sense of what their priorities are.

And I put this quote, which I'm sure everybody has already heard before, which is from Henry Ford. If I asked my customers what they wanted, they would have set a faster horse. So if you zoom right in to your product and asking about what your customers want from your product, they're going to tell you they want a faster horse, not a car. So if you start broad and then zoom in, you can understand the context that your customers are living in and it gives you an opportunity to add value later on where you might be able to spot product opportunities or messaging opportunities or use case opportunities that they are not coming up with themselves because they don't spend their whole day thinking about your product or use them and your whole day thinking about your product.

So if you understand them like contextually in a broad sense and understand how they feel about your product, you're more likely to come up with ideas of how you can serve them better. General tips for when you conduct a customer listening call. At the beginning of the call, it's really good to give the customer a sense of what to expect. So hey, I'm thankful for your time.

I'm just going to ask you some questions. We're going to be using the information that we get from this interview to come up with new product ideas to serve you better or create some new content. All of your answers are just going to be used internally for my team and it's totally anonymous, it's not going to be shared anywhere. But just what to expect is a bunch of questions.

I would love to know what you think and I'm not trying to sell you anything. So two things there. It's very disarming when you say I'm not trying to sell you anything because they're very, very honest when they know you're not going to try to sell them anything. You can learn awesome information.

And then the second one is like people sometimes are taken off guard, even if they know the purpose of the conversation by email, they're taken off guard when you just are peppering them with questions. So if you set the expectation early, like I'm about to ask you a ton of questions, I might sound a little nosy, but this is how we're going to use the information. I really appreciate your answers. It helps the discussion kind of flow more easily as you start to get into it.

The second tip is to really keep track of your time. So this kind of plays back into trying to set up the conversations in the first place. It can be sometimes hard to get people to give you their time because everybody's busy, especially when you're trying to get customer feedback from your existing customers as well as people who are not your customers because then you're doing some cold outreach. So when I'm doing cold outreach, like set up customer calls, I mean, I think it's great to interview your competitors' customers if they'll interview.

I only ever ask for 20 minutes of their time because 20 minutes just doesn't feel like a huge time commitment. So if you've only asked for 20 minutes of their time, you should only take up 20 minutes of their time. So once you approach that 20, 30 minute mark, you should check in and say, hey, I don't want to take up more time than I ask for. And usually people are very appreciative of that.

And a lot of them will let you keep asking them questions even if you're approaching the end of the time, if the conversation went well. Another tip that I think is really interesting is sometimes you should ask the same question multiple different ways. And I think this is especially true when you're digging for pain points. So an example of what I might do is I might ask the customer what is something that you find frustrating or what is something that is challenging for you in your role right now?

I would let them answer the question. And like sometimes you're not getting anything you can use out of that. And so follow up with something like what's less than ideal. You literally just ask the same question two different ways and you're probably going to get a different answer the second time.

And you can do that like three times in a row and it might seem really weird to you but they're not going to notice. And sometimes like the third answer they give you is gold. So don't be afraid to ask the same question several times in a row. Record the call if you can, just take the pressure off from taking notes.

Obviously be grateful for their time. It's a huge help to you and people are always busy. And then at the end of the call, if everything went well, I always ask who else I should be talking to or doing research with. And if the call went well, you can sometimes get a warm introduction to someone outside your network that can give you insight you would otherwise get.

It's a lot easier than doing cold outreach. So after you've had your conversation, I like to produce a call report to document the findings. Sometimes I just take open-ended notes but it's sometimes useful to create a template. I think also creating a template helps build momentum.

So it's really easy to let yourself off the hook for not doing customer research. So if you as a team do this whole process and you create your hypothesis together and everybody feels it templates, it feels formalized. There's milestones that you can work toward and you're just more likely to do it. So if I were to create a template that people would fill out, I'm going to do five call reports this quarter to complete my customer or a student quota or whatever.

And our template had, you can put anything you want on the template, ours had an executive summary. It had a section about what surprised you. I always find that really interesting. Suggested follow-up actions.

And the one thing we had on our template is this table of pain points. So pain points are really useful in understanding what your messaging should be as well as what should be on your product roadmap. So we would have pain points and then we would also try to force people to quantify the pain points, which requires you to ask very specific questions in the customer interview. But if you can prioritize one of the most painful pain points, then you can lead with those and your messaging.

You can develop features around those. So when we were trying to quantify how painful is a fire for our customers, we asked what the consequences of a fire were for anyone that had experienced them that we found out in a customer interview. So one guy in particular had experienced a fire in the middle of the night when I was in the facility. And I followed up and I was like, would you mind sharing with me what was the outcome for that?

What did it cost to recover from that? And he said, $190,000? Part of it was equipment damage. He said, $45k, equipment damage, but it was $145k business interruption.

And it was all covered by insurance. But I thought it was fascinating that they were working with machines that cost a couple hundred thousand dollars each. But the real quantifiable impact was not the machine. It was business interruption.

And so I started talking more and more about that. And he got into this whole train of thought, like, hey, if I have a machine down, I'm going to have to pay to recover the machine. But I might lose a customer if my machine is down for too long. So I'm going to miss being on a revenue.

My customer might get angry. They might switch suppliers. This is a competitive industry. And I can't afford to be down or else I'm going to lose a customer.

So now all of our messaging on the website says, you know, uptime is everything. If you have a losing of it a day of productivity, you could lose a contract or customer. And that's what resonates with the shop owner who is the person making the purchasing decision here. So by quantifying that the equipment repair cost was only 25% of the pain point.

And actually, business interruption was 75%. We were able to make our messaging a lot more effective. All right. So now you'll have a call report for each of the six to 10 calls that you did.

Once you have all of those call reports, you can get back with your original group and look at your original hypothesis and decide what we're right about what we were wrong about. So in my ground support equipment example, we were wrong about everything. And other examples, we've been right about some of the pain points, wrong about some of the pain points. Some things never came up.

Like clearly we thought they were important customers thought they were less important. So with your hypothesis that's written down, go through, put a check mark next to anything that a customer confirmed, put an X next to anything that they directly contradicted. And then there's going to be a bunch of stuff that's still left over. You can put questions and question marks next to those.

And maybe you want to go out and try to specifically validate or invalidate those points and you set up additional conversations with that objective. Or maybe you just say, all right, we're only going to use the validated stuff in our messaging and you go from there. You can consolidate all of the items that you marked as valid in a spreadsheet, which then becomes an awesome reference for discussions, for messaging, for content calendar. Here's like an example of a spreadsheet that we would use.

So if you use the Jobs Pains Games framework, you can also have a hypothesis of what your products pain relievers are, so what part of our solution directly addresses the customer pain point. And so you can put in all the validated pain relievers that you're saying, oh yeah, I love your feature because this is such a nightmare and your product helps me get around this. So you would say, all right, our automatic invoicing system is the pain reliever. It was validated by Valerie Smith and she said, we used to be using this system and our AR clerks were working around the clock to collect payment.

Now we have this and it saves us so much time. So you can actually see what words she used to validate what you thought was true about your product and those become words that you can use in your messaging. It becomes ideas of maybe we should build some content around this and maybe we should promote it to more people like Valerie so that they can see the benefits of our solution. So that kind of brings me to the end of the presentation format here but I hope that that process overview is helpful and hopefully some of the stories give people some ideas and if anyone has any questions, I'm happy to take them.

No similar episodes found.

No similar podcasts found.

Frequently Asked Questions

How long is this episode of Stacking Growth | The B2B Marketing Podcast?

This episode is 28 minutes long.

When was this Stacking Growth | The B2B Marketing Podcast episode published?

This episode was published on January 25, 2022.

Is there a transcript available for this episode?

Yes, a full transcript is available for this episode. You can read the complete transcript on the episode page.

Can I download this Stacking Growth | The B2B Marketing Podcast episode?

Yes. Use the download control on the episode player to save the publisher-provided media file.
URL copied to clipboard!