UX FTW – Customer-Centric Value Creation with a Jobs-To-Be-Done Mindset

Wolfram Nagel at UXDX Community: Customer Centric Creation and Breaking UX myths. Video: https://youtu.be/h-KBidoJfg4

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.

Creating value with a customer-centric mindset

[00:00:00] Welcome everyone. I'm going to talk today about how we use Jobs to Be Done to create value with a customer-centric mindset in our company. And a pretty short introduction: I'm co-founder of designmethodsfinder.com. I work at TeamViewer, since six years now. I wrote a book, and if you want to know more, please reach out to wolframnagel.com.

[00:00:25] The general and the core idea, I guess for many of us, for all of us, is we want to create value for our users and for our customers, and if we don't do this completely wrong, we also will create value for the company. In order to achieve this, we developed in the past years a customer-centric value creation framework. That's how we call it. I'm going to introduce this briefly at the end of the talk. Now I will introduce you to how we apply this, why we do this, the mindset behind, and some tools.

Too much information, and the challenge of prioritizing

[00:01:04] I guess many of you can agree that normally, nearly no company out there has not enough information. It's rather always too much. We get a lot of customer feedback. We have new product ideas, many feature requests, for example. We know how people use the product from usage tracking. We have other insights. We know about pain points, problems.

[00:01:31] We have a lot of ideas, and basically the backlog grows faster than you can work on the items. It's always a lot of information. The main challenge generally is, how do we prioritize? Is this feedback representative? Is it objective? Is it relevant now? Is this important, or is this just one customer? What should we put on the roadmap? What should be done first? What next? And in general, how do we prioritize? That's the main challenge, to organize all this information we get.

Flippers, mermaids and the job

[00:02:03] I have some examples and stories to explain the mindset behind our approach. The first one is from Sarah Conklin[?], who's a product manager and product designer. Her daughter came to her and told her, "Mom, I want a pair of flippers for my birthday, but I'm actually not into flippers." Which is weird. So what Sarah did, let's call it research: she talked to her daughter to find out why, and she found out that her daughter wants to feel like a mermaid. She's basically using these flippers to play mermaid, but maybe these flippers would be even better for Sarah's daughter.

[00:02:40] What I want to say with that example is, it's about the job. Flippers aren't obviously always used to improve at swimming. Some people obviously also use flippers to feel like a mermaid. And if Sarah knows now what the job of her daughter is, she's able to provide the best possible gift for her daughter's birthday. And that's also the message for you, and for us basically in the company. We need to know our customers' job. What do they want to get done?

[00:03:10] There's a phrase that says, "People hire a product to get a job done." And in that sense, this little girl hires the flippers to feel like a mermaid. Maybe her mother could also buy a mermaid costume, and that would also serve the job. And to serve our customers in the best possible way, we need to talk to them. We need to understand them, like Sarah did with her daughter.

Listening to music: from needs to a prioritization map

[00:03:34] Another example is from the listen-to-music area. It doesn't matter when you lived or when you listen to music, like 50 or 40 years ago or now. It doesn't matter if you use cassettes, or listen to CDs, MP3 players, iPod or streaming services. The importance, if you like music, does not change. The technology can change, but the job, listen to music, is stable over time.

[00:03:58] And when you are working in that business, let's say your main job in that case is listen to music, you will do qualitative research, and you might find out a lot of needs that your users and customers have. Like listen to favorite music when on the go, when running, when having a shower, that's a huge difference. Or maybe they want to share their favorite songs with others. And the list grows and grows. There's a lot of needs, it can be more than 100 needs, and then you have the same challenge as I mentioned at the beginning: how do we prioritize? Shall we go for the listen-when-running feature, or should we improve the playlist feature? I have no idea, because they all sound reasonable.

[00:04:40] What you can do is ask your customers two questions related to the same need. How important is it for you that you can listen to your favorite music when you're on the go, and how satisfied are you right now regarding this? And then they can answer. They have five options, from not important at all or not satisfied at all, to this is extremely important, or I'm extremely satisfied.

[00:05:07] There's a pretty easy formula behind it, taken from outcome-driven innovation, from ODI and Strategyn. And when you apply this, you get something like this, which is a map. All these little dots represent one of the needs I just told you about before, and this can help you to prioritize. You have two axes, importance and satisfaction, and all these needs are phrased in a solution-agnostic way. There's no app behind it, or button, or any feature. It's just listen to favorite music when I'm on the go.

[00:05:40] The items on the bottom right are pretty interesting, because they are underserved. These needs are very important for the customers, but the satisfaction is currently rather low. So if you get these needs addressed better than the market or the competition, users might choose your product over others. This can help you to prioritize. Maybe let's go for these needs first, compared to all the other needs that also sound reasonable.

[00:06:09] The dots, the needs in the top left are also interesting. Maybe if you want to reduce maintenance costs. I don't want to go too deep here today. It depends always on what you want to find out, but this can help you to prioritize what should be done next, creating the roadmap and so on.

Crossing the river instead of building a bridge

[00:06:27] The last example: imagine you're standing in front of a river with a bunch of people. You can just tell your crew, "Guys, we need to build a bridge." Everyone will start building a bridge. Okay, fine. But that's actually not the real goal, like with the mermaid before. Actually you want to cross the river. And if you tell the crew, "Guys, we need to cross the river, what can we do?" then everyone can think about what could be a solution. Of course you can build a bridge, but you can also build a raft, or you can swim across the river, or maybe there's a narrower point somewhere along the river. This is also a solution to cross the river.

[00:07:03] What I want to say with that example again is that it's about understanding the job, and not talking about a potential solution too early, because often we are approached, just as a metaphor, we often use this metaphor in discussions: "Please build a bridge for me. You have this amount of time." Then I always ask why, to understand the circumstances.

[00:07:28] And to make the switch to software development, imagine the next release is in two weeks, and you want to improve the product for your customers and users. Maybe this bridge takes two or three months to build, so that's too long. You will not ship an improvement with the next release. But if the whole team knows not just about the bridge to build, but about, oh, we need to cross the river, we want to allow our customers to cross the river with our product with the next release.

[00:08:00] And maybe there's a developer in your team who understood the user, the use case, and the job to be done, and all the needs. Maybe they can come up with, oh, with my framework it's pretty easy to create a raft, it takes only one week, and we have even one week left to test. So let's try this out. You can ship this feature that addresses the need, cross river, with the next release in two weeks. And then you can check if the need is addressed well enough, or if you need to improve, or maybe you still need to build the bridge.

[00:08:35] Just to quote Jeff Gothelf, you guys might know him, author of Lean UX and some other very interesting articles and books out there, who says, "Give teams a problem to solve, not a solution to implement." This is as with the bridge example. People in your team need to know why you are doing what, which problem you are solving, and then you can have these discussions around your users, what could be potential solutions, instead of just talking about a solution from the beginning.

The customer-centric value creation canvas

[00:09:04] And this has a lot to do with collaboration. This is very important, because UX and experience and product stuff is not only related to the UX guys. The whole team is involved. And we do this by using that canvas. We created the customer-centric value creation canvas. We didn't create this because there are not yet enough canvases out there, but this canvas directly relates to our framework, to the mindset, to the approach we teach internally. We use this one to clarify the most important questions before we start a project. It can also be used during a project, but it's recommended to do it up front.

[00:09:45] There's a trigger, to answer the question: why are we working on this topic? Where is it coming from? Is it maybe a sales job or whatever? So everyone knows about it. Then you need to define and clarify goals, KPIs. What's the goal of the whole project? Maybe some requirements. Maybe there's another project running in parallel which you should align with. Or there are some limitations with technology, so that also needs to be considered.

[00:10:13] And of course, define the main job. Is it listen to music? Is it feel like a mermaid? Is it remotely connect to another device? And who are your users? There can also often be many, but it helps to prioritize, at least at the beginning, to be able to focus on this or that user. It helps also in discussions and in prioritization. And then the scope: what is out of scope, and so on. When this is clarified, we can move on and we can take care about users and their needs.

[00:10:41] We normally do a workshop internally and encourage everyone to think from the user perspective. What need can you imagine when a user wants to cross the river, or remotely connect to a device, or whatever job you are working on? And of course we also do research with users to find out their needs, but in this kickoff workshop we encourage everyone to think from a user's perspective, and it helps to generate this user-centric mindset, to use this also later in discussions.

[00:11:12] And once this is done, we summarize the research insights and we phrase them normally as job stories, which is not the same as a user story. I don't want to go too deep here. And then, and only then, we think about what can be a potential solution. Only when you clarified these important questions up front. And it helps a lot to discuss in the team, to align how you think about that. When these questions are there, this helps to align, and this is how such a canvas can look like when everyone is invited to put their sticky notes on these specific areas.

UX principles and data-informed decisions

[00:11:47] We have also defined some UX principles for us. The first and most important one is, put the user at the center, because everything we do, we do it for our users. Anything else doesn't make sense. If there's no problem, or no user out there who has a problem that needs that feature, why should we invest time to build the feature? This is very important also to have those user-centric discussions in the teams when we are working on topics.

[00:12:13] And also very important, we want to make data-informed decisions, to avoid opinion discussions, which very often doesn't really help. We're not blindly following data, but we use it, we utilize it. Like usage data, how people use the product, and also any customer feedback, any user insight, interview. Whatever we do is data we use to have data-informed discussions and decisions.

The user focus program

[00:12:42] And in order to achieve this, we created our user focus program, which is basically a user research database where a lot of users are. We can select users depending on what we are looking for, easily recruit users and do interviews with them, or also surveys. And, yeah, actually easily reach out and quickly reach out to them, to find the right ones to help us to develop the product.

[00:13:14] This is how it looks like for an editor, or for me as an admin, the user focus program. And users can apply for it, to join the program, and they provide us a lot of information like, what are your IT skills, product familiarity, what are your roles, how often do you use the product, and many others. This is one part. It's basically divided into two parts, the user part and the survey part, and this is how we can find users related to the target user group I'm looking for, for a specific topic, to really have reliable users in these discussions.

[00:13:53] These are the personas I'm working with, my team and my colleagues are working with, in the area I'm working on. TeamViewer is the TeamViewer core product. We have an IT admin, an IT supporter, we have a home office worker, which has been everyone in the past three years basically, from time to time. And also private users. They are defined in a specific way based on research insights and any insights we gather. They are based on that data we gathered.

[00:14:24] And then there's also a definition of how the IT skill of Sam is, and product loyalty. Product familiarity can sometimes be very interesting. Which devices do they use when they use the product? How often do they use the product? Do they have a license? How much time do they spend? So general behavior and usage modes. In the bottom right you see jobs to be done, needs and goals, potential frustrations and pain points are also defined.

[00:14:51] That's defined for Sam, and all this information that I mentioned before is also provided by our customers who apply for the user focus program. This means we can reach out to them and find, depending on how many filters we apply, we can find the right people, let's say real living personas. And for example, depending on the filters we use, we have like three or 400 Sams in the user focus program. We can reach out to them and talk to them directly.

Job maps, surveys and quantified needs

[00:15:23] The other section is the survey section. We have several templates to create surveys, but I want to mainly introduce the jobs to be done survey section. Quickly, I don't want to go too detailed into what jobs to be done is. This is a job map for the job, support a user with a computer issue, or troubleshoot an end user issue, for example, or remotely connect to another device.

[00:15:50] And this is a job map which is divided into several stages. They always have a beginning, a middle and an end. For example, the trigger is you get a ticket because the customer has a problem. Then the job starts, and then you prepare for the call. You're in the call, you try to solve the issue. You monitor if you actually solved it, and when you solved the issue, then the job is done. You troubleshot this end user issue with your customer.

[00:16:15] All these little post-its you see here are needs we uncovered in research. For example, they are all phrased with the same syntax. For example, minimize the time it takes to organize my contacts or devices when I need to find them later. And all these other post-its are phrased in a similar way. They are just structured in a job map that helps us to structure and cluster all the insights we get, because this is normally a mess when you have all the insights, and then we structure it first onto a job map.

[00:16:46] What we do next, we pick the most relevant ones, so sometimes we need to pre-select, and put them into a survey, which could look like this. This is how a user sees the survey. They want to minimize the time it takes to start a remote control session when I want to troubleshoot a computer problem, for example, and many other needs as well. And then, maybe you imagine the example with the listen to music that I showed you before, they can rate by importance and satisfaction.

[00:17:16] What we get then, as I also showed before, is the data. We get evaluated needs. You see the score here, which is calculated by that formula I mentioned before, by importance and satisfaction. The list is longer, but this one helps us now, the needs on top got the highest score, so very important and rather low satisfaction, and this helps us to prioritize, to discuss with the product owner, product manager, other stakeholders. Maybe we should focus on these five, six needs on top first, because they are most relevant.

[00:17:51] On the left you see that a filter is also applied, so you see only the ratings for the ones who have rather a high IT skill and who are IT admins. We can also remove it or use other filters. And then you can also display it with this map, similar to the one I showed you before, and this tells us now the underserved needs. Maybe you should consider the A2TFQ need. Maybe we should focus on these ones first, and not RMX, because they are obviously not that important for the customers, even if they sounded reasonable at the beginning, or after we did the research.

[00:18:35] So this helps us. That's how we quantify qualitative research insights, structure them, get data that helps us to argue later, to prioritize, and to present potential solutions to others also internally, and to have more confidence that we are working on the right topic, because we have the data. We got a need from a customer in a qualitative interview, and 150 or 200 other customers rated it that way, so this gives us more confidence to be on the right path.

Understand the problem before the solution

[00:19:11] Hopefully you agree with me that we all need to understand the problem first, before we work on the solution. I'm not sure if this guy really said this, I just borrowed that quote from another presentation, but I just agree with it. You really need to understand your problem first before you work on a solution. This is probably not new for you guys, because, yeah. However, when I don't know the problem, how should the solution look like? When I don't know the user and what they want to get done, I cannot start with any mock-up.

[00:19:49] And therefore we created the framework I mentioned at the beginning, based on some other frameworks out there. We also followed the double diamond and some other frameworks, which is based on the double diamond. You probably know it. It's mainly divided into problem and solution space. We have a lot of problems. You need to converge, to define which problems you're going to work on. Then you find many potential solutions, and you need to decide on which solutions you will develop in the end.

The customer-centric value creation framework

[00:20:21] As said, some other frameworks have been considered, and based on that we created that customer-centric value creation framework. This is the high-level definition or illustration of the framework, and I'm going to quickly introduce you to the framework. Don't worry, it sounds, or it looks, more complicated than it actually is.

[00:20:42] At the beginning, there are five stages. There's the initiation phase, then we have understand, explore, materialize, and then you basically release or deliver the solution. Before we start, as I mentioned with the canvas before, we need to clarify project goals, requirements, what's the main job, who's the user. We just need to know this. Otherwise we cannot really work.

[00:21:06] And then there's this first diamond. Actually we have three diamonds here. The first diamond is the understanding diamond. We really do research, understand the customer as I showed you before. Find out a lot of needs, quantify them, prioritize the needs. This can also be done pragmatically if we don't have a lot of time. We very often also do it pragmatically internally. As long as we know that it's a pragmatic approach, it's fine.

[00:21:35] And once we decided on the needs we are going to solve or address, we go into the exploration phase. Ideation, brainstorming, a workshop. Maybe create a mock-up. We check feasibility with the development, and test again with users. And once we feel confident that this is a good solution, we decide on a solution, and then we can hand it over into the materializing phase, which can then be developed. We apply Scrum[?], like build-measure-learn iterations. And then you develop it in sprints and you ship it every two or four weeks. We ship a new improvement.

[00:22:15] All these circles are independent of each other, but they also overlap. I can and I should do research all the time, just constantly checking with customers if there's new insights, if priorities of needs eventually maybe change. And when there's new insights and a new priority, we can inform the exploration phase, and we can always work on the solutions, what can be a solution, what are the ideas.

[00:22:42] And also, once we decided on an idea, then okay, that's the idea, we want to develop it, we put it to the backlog, create the user stories, and then we develop it. So the circles are independent, but they inform basically the other circle. When there's a new insight, like a new need or a new solution that should be developed, it can go to the next phase. That's basically research and development, or research and design and development, in a nutshell.

Summary and closing

[00:23:11] Again, as a summary: first we work with the canvas, then we do research and interviews, and then we prioritize the needs and we use the job map, of course. Then we go into ideation, prototyping, put it to the backlog once we decided, and then we can create the product in sprints, and also think about marketing and promotion.

[00:23:34] If this is interesting to you, or if this was too fast now because of the time, please feel free to reach out, or check my article on Medium. I explained the whole approach there, and I'm also happy if you have questions, feel free to approach me. What I wanted to show you today is that jobs to be done can be a great foundation to create value for customers, because it brings that customer-centered perspective, and also allows you to create data around that.

[00:24:08] In a nutshell, how can you do this, or how do we do it? Involve the customer, at least the perspective. Think from the customer's perspective, gather insights from them, quantify and prioritize their needs, and then find solutions that meet those needs, and then develop it and ship it to the customer. That's again in a nutshell.

[00:24:29] Or we can also phrase it with the quote from Tony Ulwick, who is an author of the Jobs to Be Done book and many other great insights. He's one of the early guys in that area. "Innovation begins with identifying customer needs, and it ends in the creation of items they will buy." In theory, pretty easy. What are your users or your customers? What needs and problems do they have? Find a solution, create a solution and offer it to them, and that's it. It sounds pretty easy in theory. In practice, that's the challenge. And I just showed you today how we approach this challenge with our customer-centric mindset and framework. Thank you.

Q&A

[00:25:13] Host: Thank you very much, Wolfram. That was a really good, detailed insight into the steps of how you go through it. Thanks for sharing that.

[00:25:21] Wolfram: You're welcome.

[00:25:22] Host: We have a question that came in from Alexander Settelmayer, and he was asking, could you give a more detailed example of a customer need? It doesn't have to be a TeamViewer one, but just one that can help make it a bit more tangible.

[00:25:38] Wolfram: A customer need, others use outcome statements, we call it need statements, is the underlying need to a main job. If you are listening to music, if I'm working in a company that provides music stuff and just listen to music is the main job, you do research and you find out a lot of needs. For example, minimize the time it takes to start my favorite music when I go running. That's a need. And that's always phrased in the same way, we always use the same syntax. That's a need, and there are like 50 to 200 needs around the job.

[00:26:14] Wolfram: And that's actually what we are doing research with customers for, to find out the needs. When we talk to them we ask, "Oh, did I get you right?" We get a confirmation for the need. Then, okay, thanks, that's a need, and then we quantify it with the research, to be able to prioritize all the needs we uncovered. I hope that answers the question.

[00:26:34] Host: Yeah, I think it did for me. So it's a problem statement, kind of, is how...

[00:26:39] Wolfram: Yeah, that's a very important thing. I don't care too much about how you phrase it, how you call it. You can even call a job a use case, even if it's wrong in my opinion, but if someone can work with a use case better than with a jobs to be done, you do not need to introduce a new term. So problem statement is also fine for me. I'm pretty pragmatic.

[00:27:01] Host: And I find the book Jobs to Be Done, if you really want to go detailed into how to track and ask questions, I find that very useful, if anybody out there would like that. I have some other questions, particularly about your user research program, like having all those people sign up. I'm jealous, because it's such a huge resource. We don't actually have time for it now, but I'm going to throw some questions into the Slack channel and I'll invite you there to answer them. Particularly about how do you encourage that number of people to volunteer and to give their time to helping you. I think it'd be useful for other people if they could try to replicate something similar.

[00:27:42] Wolfram: Yeah, sure. I'm happy to answer these questions, sure. Thanks.

[00:27:46] Host: Thanks. Well, that brings us to time. So thank you very much, Wolfram.

[00:27:50] Wolfram: Thanks a lot, also.