//

“The Customer Is Not Always Right”: Cindy Alvarez with Lean Customer Development (Video + Transcript)

July 30, 2018
VIDEO

At Girl Geek X Elevate 2018, “Lean Customer Development” author Cindy Alvarez encourages asking questions to explore customers’ and co-workers’ true pain points, and offers poignant leadership advice aimed to help you improve your working relationships — while positioning yourself as a helpful and empathetic resource to your colleagues, managers, and customers.


WATCH ON YOUTUBE
Share this

Transcript

Cindy Alvarez: I’m Cindy Alvarez, and right now I’m on a flight heading back from Johannesburg, so you get a pre-recorded talk from me. I’m going to talk today about why the customer is not always right. First of all, I want to start off by saying where did this thing even come from? Where did we start with the phrase, “The customer’s always right?” What does that mean? Why is that important to us?

It primarily comes down to the fact that we want our customers to come back and buy more things from us. We want them to like us, and that makes me realize that customers are not just external people who buy our products, they’re also people that we work with every day. There’s a lot of things you can do to make those relationships better, whether they’re talking to customers who are external to you, or the people who are next to you every day. Let’s dive right in.

First of all, let’s think about what’s our desired outcome. I think when we say things like this, we tend to think of things like units sold, or increasing usage, but fundamentally, we want to understand the underlying problems that customers have — whether that’s the one buying our product, or our coworkers because understanding is the only way we can hope to solve their problems.

We really, let’s be honest, want our customers to like us, we want our coworkers to like us, and we want to find the best possible solution for the problems that we’re facing.

That best possible solution isn’t always obvious. What do we do with that?

Most of us have been through the scenario where a customer came to us, they asked for something, we built it, we delivered it, and then it didn’t actually solve their problem. We’ve wasted time on something, and we have to support something that didn’t really meet their needs.

When people ask for solutions, they’re asking for their assumption of what the solution to their problem is. A lot of times, they haven’t really thought about the problem they’re really trying to solve, and honestly that’s not their job.

It’s our job as product people to think about how we’re going to come up with solutions.

For example, let’s say we had a customer who came to us and said, “I need to rent a car.” Now, on the face of it the best possible customer service would be to rush right out, and get that person into a car rental agency, and put them in a car as quickly as possible.

If we’re bound by things like SLA metrics and we have to respond to customers within a certain number of hours, or we have to respond to every single user voice, or every single email query, then we tend to game-ify ourselves into these non-optimal solutions.

Let’s think about why that person asked for a car. It could be that they’re about to go shopping, they don’t own a car, they’re going to buy a lot of groceries, and they don’t want to take them home on the bus. It could be that they’re having a vacation, and they want to drive along PCH and take in the scenery. It could be that they have a lot of relatives in town, and they won’t all fit into their tiny Prius.

For each of those scenarios, there are different solutions that may make more sense.

In one case, it may make more sense for someone to grab a Lyft, in some cases maybe you need to actually rent a van, and in some cases maybe you can borrow a car from a friend. If you’re actually out on a vacation and you want to take that drive along the coast, then sure, you do need to rent a car… but in that situation, you probably want to rent a fun to drive car. You don’t want to rent a beater or an SUV.

If we just rush someone straight to the car rental agency, we’d end up with that subpar solution.

As customer-oriented product people, we have to take a step back and ask “why?”

This is something that we also need to do internally, and I find this happens even less often internally because we assume that we understand the why’s.

As soon as we’re working in an office with someone, in a team with someone, we assume a shared context that doesn’t usually exist. There are people that I have literally sat across from for weeks on end, and yet we’ll still have underlying assumptions that are different from each other.

The “why” is always more interesting, it’s more useful, it’s more actionable, and it’s more trust building than the “what.”

That last one’s a little bit interesting because people think that asking “why?” sounds almost a little accusatory. If you have a small child, you know it can actually get pretty annoying when people keep asking why.

We need to add a little padding around it, but fundamentally when people ask why, what they’re actually saying is, “I want to know more about this. I am interested in you, I care about what you have to say.” As opposed to what, which has this whiff of, “how quickly can I get you out of my hair?” That’s not how we want to build these relationships.

Let’s think about it: someone comes to you, they have a request. It could be the customer who says, “I need to rent a car,” or, “You need to build this feature,” “You need to support this use case.” It could be your boss who has given you a task, “You need to do this thing. You need to manually sort through this data. You need to write this spec.”

The first question we really have is: “What’s the problem you’re trying to solve?” That can be pretty tricky to ask because if your boss says, “Do this,” and you ask, “Well, what’s the problem you’re trying to solve?” your boss might just say, you know, “Get on it. Let’s do it.”

Again, we need some padding, and so we want to say, “Okay, just to make sure I understand it seems like the outcome you’re looking for is X, is that correct?”

If your boss says, “Manually sort this data,” what they probably want is clean data. If someone says, “Get me a drill, “ they probably want quarter inch holes, but you need to validate that.

The best way to do it is give that, “Just to be sure I’m clear, this is the outcome you’re looking for, is that correct? Am I missing anything?”

This gives people the opportunity to step in and say, “Actually, this is the thing I needed,” or, “Actually, here’s some more information that I assumed that you knew, but you probably didn’t.” Or, “I’m sure I’ve told you this a billion times.”

Having been someone who’s managed teams, I have always had things that I’m pretty sure I said a billion times, and yet either I didn’t, or people didn’t hear me. It doesn’t really matter because the outcome was the same, and they weren’t privy to that information, and that meant they weren’t going to do as good a job as if they had the information they needed.

We want to ask why. Why do you need that done? What’s the outcome you’re hoping for?

A lot of us, when we’re interacting with customers, what we hear is basically a demand for features, and it’s hard to ask why because what they really want to get to is when. When are you going to build this thing?

It’s useful to take that step back. I like to announce it as such, and say, “You know what? Let’s talk about delivery deadlines sometime in the future, in a few minutes, right? But just a second. I want to be sure I understand something. It sounds like you’re asking for this feature. Just to be sure I understand, if we had already built it, what would it allow you to do? Essentially, how would it make your life better if you had this thing?”

The thing that I found surprising is that when you ask people some polite version of “how would it make your life better?” a lot of times you get a non-answer.

You’ll get an answer like, “Well, it would just be nice to have.”

We don’t have time for building things that are nice to have.

How would it make your life better? What would it allow you to do? When someone really needs something, they’ll have a story for you.

“Uh, you know, it would take me half the time to sort my data. Oh, I wouldn’t have to waste head count on this position. We could start coding tomorrow.” When people have a story, that’s something worth doing.

When a customer comes to you and you say, “What would it allow you to,” sometimes you get the non-answer of, “But your competitor has it.” That’s actually just pushing the can down the road a bit, and what you say to that is to say, “Okay, I understand. You’re right, our competitor does have that feature. I’m curious if you were using that feature with Google, Facebook, et cetera, what would it allow you to do?”

I can’t count the number of times I’ve had customers who say, “Well, it would just be nice to have.”

If the reason that you’re going to lose a feature sale is because of a checkbox feature that someone’s not even going to use if they go to your competitor, that’s not something we should be trying to win on.

You may lose a sale in the short-term, but you’re going to have someone who isn’t really having their needs met, and they’re ripe to be plucked back in a year or two.

We ask, “How would it make your life better?” Maybe we hear that it really wouldn’t, and then we proceed.

Sometimes you’ll hear a variation like, “It might be useful in the future,” and, again, kicking the can down the road a little bit, and you got to ask one more question which is, “Okay, I’m curious how do you see your organization changing in the future?”

“What?”

“Well, you said it might be useful in the future. I’m curious how are things going to change such that this might be useful in the future?”

You want to be very polite and smiley, you’re very nice about this, but the point is if you don’t know how the future’s going to change, and I don’t mean the next five years because no one knows that. I mean the next six months.

If someone can’t give you an answer, then it’s not a real need.

It’s a wish, or maybe it’s leverage to try and get a deal. Or maybe it’s just someone who’s trying to look smart in a meeting, and I think we all know the people who are in meetings trying to look smart, being loud, man-splaining you, et cetera. “How will it make your life better? What do you anticipate changing in the future?”

The other thing is that when we jump in trying to understand problems, or provide solutions, a lot of times it’s useful to know what people are already doing, and how they feel about it. That sounds so incredibly simple as to be obvious and dumb, and yet I have been surprised by the number of times I’m in meetings where we really don’t know. Sometimes it’s, “Hey, could you take a step back? I’m just curious, could you walk me through what you’re doing today? I mean, I know high level, but I’d love to see the details.”

When someone walks through a process for something, you might see exactly where their pain point is. Maybe they asked for this feature that’s a widget, but you can see that actually they’re having a hard time with this other area, and the widget might be one solution, but as a product person you can see it’s actually a poor solution. Or it’s something that will be applicable to this customer and no others.

In a meeting, a lot of times, where there’s a debate between people who think that one side’s doing it right, and the other side’s doing it wrong, a lot of times that comes down to an assumption about what each side is actually trying to do.

“Could you walk me through what you’re trying to do,” is a good way to defuse that, and let people say, “Look, this is just what I want,” because that’s, at the end of the day, what we’re trying to do.

We’re trying to help people get what they want done.

If we do that, we will seem amazingly smart, and helpful, and kind, and everything else. It’s a really good hack.

“Could you walk me through what we’re doing today?”

This is also really great advice when you get put into a new role. Let’s say you got promoted to manager. Congratulations! You can’t just step in, of course, and say, “This is how we do things now.” You can try, but you’re going to get a mutiny.

If you join a new company, a new role, people have established practices. Some of them are good, some of them are bad, and if you don’t know the history of why people are doing one of them, you don’t have a lot of position to say, “Let’s do things differently.”

If you can go into a new organization, or a new customer, and say, “You know, walk me through what you’re doing today. Okay, that’s interesting. Okay, you know, how did that happen in the past? Do you have a sense for how that decision was made ? How’s that going? You know, if you could change anything about it what would it be?” This kind of conversational approach gets people to trust you, and it gets you a lot more insights than you would ordinarily have.

Now, I’ll note one thing here, is that taking that step back and asking supposedly “dumb” questions can be particularly tough if you’re a woman, and if you’re in a meeting where you think people are just a little too quick to think that you are asking dumb questions. This is where it’s useful to borrow a new person. This might genuinely be someone who’s new on your team, or you could literally just grab one of your coworkers and ask them to come into a meeting, this doesn’t work internally but it works well with customers, “Come into this meeting pretend to be the new guy, new gal.”

The new person has a lot more freedom to say, “Hey, I bet everyone in the room already knows this,” — hint: they don’t — “But could you walk me through what you’re doing today?”

You will get a ton of insight out of that, and the customer won’t actually mind getting to repeat history, and probably halfway through their diatribe they’ll be like, “You know what? We didn’t even tell you that our entire back end system changed in the last year, did we? (haha).” Yeah, that’s probably something that you should’ve known.

“What are you doing today? How is that going?”

Once they’ve finished talking about that, then you’re going to reiterate. This is active listening. This is the thing that makes you feel a little bit like a kindergarten teacher, but trust me, it works. I wouldn’t tell you this if it didn’t.

“It sounds like you need to do X, and Y, and Z. It sounds to me, like you’d be happier if magically these things were fixed. Is that accurate? Am I missing something?”

Give them that option to correct you, or to add things.

Now, there’s a magic thing that happens once you’ve reiterated back, which is that you have absorbed like 80% to 90% of people’s anger at this point, even if you don’t actually solve their problem. They’re amazingly happier that you took the time to understand it in the first place. There are studies to back this up. Stanford has been doing some research with doctors and malpractice, and they found with a control and experiment group, that surgeons who made a mistake, and apologized were much more likely to not have suits brought against them, or if there were, they settled for much less money. Essentially, if someone sewed a sponge in you by mistake… you really want to hear that person say sorry. If they don’t, you’re going to take them to court for all they’re worth, so we can do that.

That leads to my next point, which is — apologies are free.

Any woman who’s ever worked for me knows that I always tell them, don’t apologize. For your ideas, don’t apologize. Don’t say I’m sorry about this idea, or I’m sorry that I want to do something a new way.

But when it comes to a customer who is feeling wronged, who is feeling like, I’m already upset, go ahead and apologize because that de-fangs even the angriest customer.

If someone comes in and they’re furious, “I can’t believe that you’ve lost my data. I’m going to quit your account right now, this is ridiculous,” and you say, “I’m really sorry. We did that, we lost your data. That’s really awful, and I don’t want that to ever happen again. Let’s see what we can do about it.” Those are magic words.

It’s very hard for someone to hear something that is humble and accepting of responsibility, and keep yelling at you. They trail off, “Well, you better see what you can do.”

Give them out, apologies are free.

It doesn’t matter if it’s not your fault, if someone lost their data through something that was user error, it doesn’t matter. You’re not going to talk them into that. Telling people that’s the way the feature was designed has never made anyone happy ever, so apologize. You can do that.

Apologies are free. They’re also rare, especially good ones.

Follow-ups are also rare.

Even if you didn’t provide the answer someone wants, just the fact that you reach back out to a customer, or a coworker a couple weeks later to give them an update, “Hey, I looked into that solution. It turns out we’re not going to be able to address it. I’m really sorry, I just wanted to let you know,” people are amazingly happy about that because they never hear it.

The traditional vendor/buyer relationship is, “We’ll put it on the roadmap,” and then it’s on the roadmap, and it’s on the roadmap, and they never actually get the feature.

Internally, when people have suggestions, “Oh, we’ll consider it. Oh, put it in the suggestion box,” and there’s never any closure.

That’s the final thing I have to talk about: people like closure.

As humans, closure makes us feel satisfied. We like to know that something is going to happen even if it’s not the thing that we expect.

Customers and teammates don’t have to agree with your decisions, but they need to know why you made them. They don’t even need to understand why. It’s just that they need to know that you didn’t have malicious, or stupid reasons for making your choice.

“Based on these reasons, I am making the decision to do X.”

Someone may disagree, but they’ll grumble, “Well, I guess I understand why you’re doing it. I still don’t agree with you, though.”

That’s okay, customers in that scenario are going to be a lot happier.

In this case, someone’s come to us, they’ve demanded a feature, we basically talked them out of it, we’ve explained why, and yet they’re still not furious at the end. In fact, a lot of these customers end up being incredibly loyal because even though they’re not getting what they want, they know that you understand what they need. This works both internally and externally, and it’s been tremendously useful in my career.

The bar is really low for honest communication, and for digging in to find out what the underlying problem is.

We can do better, and it’s an amazing hack that most of the people around us don’t know about, so we should take advantage.

The customer is not always right, to be honest, no one is always right, but you can, and should control your own narrative. That means taking in what you’re hearing, and reflecting on it, and asking questions, and redirecting it to something that is more positive, and something that you can control.

I’m sorry am not able to take questions live, but I really do answer them.

I’m @cindyalvarez on Twitter or cindy@cindyalvarez.com. If you have questions, feel free to shoot them over to me. And that’s my last piece of advice: when people say it’s okay to ask questions, they mean it — take advantage. Enjoy the rest of your conference everyone!