Understanding Your Customer

Tobias Jensen at UXDX Community: New York. Video: https://youtu.be/rRqvH3rYJog

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Design thinking for real-world problems

[00:00:07] My name is Tobias. Actually, it's "To-be-us," because I am from Denmark. Any fellow Scandinavians here, please yell "whoo." Okay. I work at Blackboard Insurance. I'll quickly go over what Blackboard Insurance does, but what I wanted to say here is that I'm a person who's obsessed with trying to figure out how we can use design thinking to solve real-world problems. Not because I want to offend anyone in e-commerce, but I think being in e-commerce can sometimes be a little too focused on conversion. I'm very focused on how we take a very real problem, which for example is insurance, where we have people who want to protect their stuff and they're basically anxious all the time. How do we create an experience that's good for them and just improve that overall experience for them as well?

[00:01:10] I am from Blackboard Insurance, and what Blackboard does is try to take this really bad experience of insurance and ask how we can make it a lot better by making it, first of all, customer centric, but also super value driven and also data centric. All this data is out there, it's all available to us through a lot of different vendors, but how can we use it in a way where we can optimize our own workflows but also the customers' as well? We work with commercial insurance, meaning we give insurance to businesses. So we're not one of Lemonade or the other personal lines, but we try to do the same thing in the commercial space.

Needs versus wants

[00:01:59] Today I'll be talking about understanding your customer, and specifically needs. I think it's an important subject to talk about. We typically get into this phase where we think we know what the customer needs, but we don't really know how to prioritize them, categorize them, operationalize them, all this stuff. So that's what I want to go over, and see if we can get to a point where people know how to include needs in their work. I'll be going over the why, the what and the how: why is it important to look at needs, what are needs, specifically emotional and functional needs, and how you can hopefully leave this room and implement it in your own organization.

[00:02:48] Before we get started, let's talk about needs versus wants. I think most of you, because you are in the product world, know that if you only focus on what the customer wants, you probably won't get to a point where you actually deliver the most value. The challenge for us is to figure out what it is that the customer needs, and what we can do to identify that need, design for that need and develop for that need, and not just listen to whatever they want and build whatever that feature is. I think we've all been in a situation where you're told to build a button, or put something here, or put some piece of content there, but you don't really know why it is important. Does it even stem from a need? That's why this talk is going to be about how you identify that need instead of just listening to the want.

[00:03:39] Another point I want to make is that when we focus on needs, it can get complicated to figure out what is actually a good need to focus on. Because needs are very contextual, first of all. There will always be a different need for a different thing, depending on what time of day it is, what context you're in. I'll probably drink a beer when I am off work, but I won't drink a beer when I wake up in the morning. So I have a different need depending on context. I still want a beer eventually, but I don't want a beer in the morning. So needs are very fluctuating and contextual. They're also very individual and hard to generalize as well. Hopefully we'll get a little more clarity on that.

[00:04:22] Oh, that's great. The idea is for these lines to be up there, just FYI. When we look at a user story like this one, we have this "so that" over here in the corner. Basically what this user story allows us to do is say we are building features because of a need out there. I'm not sure if I'm the only one, but sometimes you can get to a point where it's really hard to identify that "so that," or why this is super important to implement. So you just end up spinning out something that's maybe not even a real need, just something you think would be a good need for the customer. So hopefully by today I'll also have more of a tool to put in that statement, so you actually have a better idea of why you're building the features you're building.

Functional and emotional needs

[00:05:12] Generally, we need better tools to be able to actually design our products around needs, and I think I've reiterated that point many times. Who here knows about Maslow's hierarchy of needs? Okay, I'm not going to bore you with that. What is an important point about it is that, basically, what he finds is that human beings have needs at different places in the hierarchy, meaning you have more foundational needs and you have more, what can you say, icing-on-the-cake needs, if that makes sense. The basic needs of the human being are in the triangle: at the bottom you have sleep and whatever else you need, and at the top you have more like self-esteem and control, which are love and more soft values. The very important thing about this is that needs are very hierarchical and they're very, again, contextual, and that's why this becomes really relevant for product development.

[00:06:22] Let me show you. In product development we're talking about two different categories of needs: emotional and functional needs. What that means is that you need the functional needs to be there, to take precedence, or to be taken care of in the product, before you can start focusing on the emotional needs. However, if you only focus on the functional needs, you'll get to a place where it's hard to differentiate yourself from other competitors as well. So why is it that Lyft outperforms Uber? Well, the functional is taken care of for both of them, but maybe Lyft or Uber are focusing on different emotional values, which is what actually makes the difference in how they are perceived by the customers.

[00:07:11] If we look at values in the insurance domain, you see up here trust, aesthetics, reduces anxiety, it's reputable, meaning that the company is actually a good company that you want to buy from. You have cost-effective, efficient, informative or reliable. But once you actually start looking at them, you have a very distinct categorization of emotional and functional needs. I think it's very important to keep in mind that people would not want to buy insurance if we didn't have these foundational elements, but up here is where we can actually differentiate an insurance product for the customers. I just wanted to give that high-level overview of why needs are important to focus on. I'm just going to take a sip of water.

Needs across the double diamond

[00:08:05] The challenge that I'm putting out here today is: how do we identify, operationalize and measure these customer needs? If we look at a design process, and David and I were talking about how visualizing design processes can be done in many different ways, the general idea is that you want to make sure that you have a phase where you're doing your research, you're defining whatever you got from that research into some kind of problem statement, you're taking that and ideating on it, opening up the space for that, and then you're going down and saying what is it that is eventually going to be the prototype delivering the value. So this double diamond approach. What I want to say is that customer needs should be in each and every phase of this. And by the way, each phase in this process fits each thing that I want to talk about. You have identifying the needs here, you have operationalizing them once you've defined them, and then you have measuring them at the end. So that's what I'm going to be talking about more specifically today.

Identifying needs with customer outcome statements

[00:09:04] How do we identify the customer needs? Identifying customer needs should obviously be done in research, because this is where you get a chance to ask the customers questions about their experiences with your product or service. This is where you get to send out surveys. This is where maybe some of you out there use consultants or whatever to gather these research insights. However, what is important in this process is that you keep it outcome focused, and I'll go over what outcome focused means. The idea is that you want to gather information to the extent that you know what the need is from the customer, that you can try to deal with and develop products around. And then I'm going to go over how you define this need in a statement that you can use for the later process.

[00:09:58] I'm going to be talking about customer outcome statements today. If people know about Jobs to be Done, or other theories trying to frame what the job is that the customer wants to get done, you'll see some familiarity in this. The idea is that we have a customer outcome statement that is a very concise, precise way of describing what we need to deliver to the customer for them to actually get the right value, and then we use that in the process.

[00:10:32] The way we do that, let's see, that turned out to be a little ugly as well. Basically, the idea is, and we've modified the Jobs to be Done statement a little bit as well, that we go down and say what is the context that the customer is in whenever they're experiencing something. I'll give a very concrete example from claims in insurance. We have a specific context where the customer wants to do something. They have some kind of action to get to some kind of objective. In this case, before a loss happens, the customer wants to maximize their ability to protect their assets. Makes sense, right? Whatever they can do in their specific situation to maximize their ability to protect their assets will make sure that they don't get a claim, which means that they won't have a loss, and that's the best for everyone.

[00:11:31] This is an example of saying: instead of saying customers want to have an easy way to understand how not to get losses, we actually want to step back and say, really, what they want to achieve is to maximize their ability to protect their assets. After you've started synthesizing all your research insights, you can get to a point where at the top we have the journey: before loss, loss occurs, claim is processed, claim is settled, and you go back to normal as a customer. And in each of these contexts or stages in the process you have the statement. Maximize ability to protect assets is at the before loss stage up there. When you go back to normal, you want to maximize future loss prevention. Or when the claim is being processed, you want to maximize knowing where the claim is.

[00:12:32] Hopefully what's clear here is that these are all specific needs that are not necessarily describing a want or a feature, but more what it is that the customer wants in this given context. And looking at it from a functional and emotional need perspective, you suddenly see, oh, some of them are actually more functional. Minimize number of steps to complete is very functional, whereas minimize anxiety and uncertainty of outcome is more emotional. That one is about anxiety, and making sure that we as a company can make sure the customer is not anxious, whereas the other is more about making the process more efficient, making sure that whatever claim is being processed is actually processed with the fewest steps. When you start mapping it out, you'll see that some of them are functional and some of them are emotional. What this hopefully allows you to do is prioritize and say, you know what, we have to make sure that at least these functional needs are taken care of, and then we will focus on the more emotional needs after.

Operationalizing needs in ideation

[00:13:47] How do we then operationalize these? Now we're at a point where we've done the research, we've defined the outcome statements, the outcomes that we want to achieve for the customer, and now we're going into the ideation phase of saying: how do we carry that through and make sure that whatever design activities we're doing stick to the need that we observed? We also want to make sure that when we start prototyping and picking our solutions, whatever we're deciding on is going to be the most valuable to the customer.

[00:14:19] This is great, so imagine that line is up on top. I found it very useful, once you have the customer outcome statements. I'm not sure how many of you have used "how might we" for a design ideation session before. What you'll find is that these customer outcome statements are actually perfect for "how might we." Take the example we had before: how might we help the customer maximize their ability to protect their assets? It's a very specific problem without being focused on the solution. So this actually allows for brainstorming on how we can make sure that the customer knows how to protect their assets. Again, we're not talking about an app, we're not talking about notifications, we're not talking about a website. We're talking about the need that we know the customer has, and how we can design solutions for it.

[00:15:17] This looks a little better, actually. Eventually you can get to a point where you have the entire customer journey mapped out, and as you'll see, at the top you can have a guiding customer outcome statement that defines whatever solutions you end up with. Down here you can see: maximize ability to protect assets. Okay, that ended up being claims prevention notifications that are contextual for the customer. Well, now we know, at least, for whatever feature we ended up delivering, which need we hope we're going to satisfy. It's the same thing for the rest of the process: we're not going to have a random feature release, we're not going to randomly deploy something and hope that it's going to deliver value. You need to have a specific objective or outcome in mind whenever you ship, so you can see the value and measure the value.

Measuring needs in surveys

[00:16:10] Speaking of measurement: obviously measuring can be done in many different ways, both qualitatively and quantitatively. I want to show you the way that I found customer outcome statements can be used quantitatively in surveys. So that's what I'm going to go through. Now we're at the point in the process where we're still trying to focus on the needs. The prototype has been made, or maybe even the product has been shipped, and we're now ready to measure whether we actually achieved the outcome that we wanted to achieve.

[00:16:52] In this one, you'll see that here we have "the solution helps," and then we have the customer outcome statement. Let me show what that could look like: the claims prevention notification helps maximize my ability to protect my assets. What this does is basically describe the value you want to deliver, for the need that the customer has, with the solution you've developed. If you put that into a survey, and let's say you use a Likert scale like this one, you can ask them, "To what extent do you agree with the following statement?" And you can see whether the customer actually agrees that you've met the need they had. Let's say in the beginning, when you first ship the product, or maybe even before you ship the newest product, you get a very strong disagree. That's fine. But then, to measure the success of whatever need you wanted to design for, you would hopefully see a better score down there.

Key takeaways

[00:17:56] What I wanted to talk about today was that customer needs are, first of all, emotional and functional, and I hope you see that as a clear distinction. It's something you can also read about online. Ideally, whenever you get a sense of a customer need, think about whether it's actually functional or actually emotional. Functional being the more basic need that you have to solve for first, but that doesn't really provide any differentiating value in itself, and then you have the more emotional need after, which is probably going to differentiate you from the competitors.

[00:18:38] The key takeaways are: we need better tools for identifying needs, so that we don't just listen to wants. And maybe the point that's right to make here as well is to remember that it is important that you focus on the needs and not just on the wants that you're constantly getting from people who have requirements for you. Also, customer needs are hierarchical, and they're both functional and emotional in character. We can organize and operationalize the customer needs in what we call customer outcome statements. And ideally this method allows for finding solutions and measuring success grounded in the customer needs. Hopefully it should be clear by now that whenever you can distill the customer need into a sentence and use it throughout the entire process, you have a much more grounded solution that's not just pulled out of thin air but actually specified in a specific customer need. So that's it. Time for questions.