Join Murray Robinson and Shane Gibson in a conversation about Outcome-Driven Innovation with Tony Ulwick. Most products fail in the market because they don’t meet customers’ needs better than the alternatives. To succeed, we need to study the problem that customers are trying to solve, the process they use to solve it and the metrics they use to measure success. When we understand the job to be done and the outcomes to achieve, we can design a product that meets those outcomes significantly better than our competitors and be sure to win in the marketplace. Product Design, Innovation, Jobs to be done, Customer Research.

Read along you will

 Shane: Welcome to the no nonsense podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson.

Tony: And I’m Tony Ulwick. 

Murray: Hi Tony. Thanks for coming on . We wanted to talk about outcome driven innovation and product management with you today. It’d be good if you could kick us off by telling us who you are and what your background is. 

Tony: Sure. I have an engineering background, mechanical and MBA as well. I started my career at IBM back in the 1980s, on a product planning team. And one of the first products we worked on was called the PC junior. The day after it was introduced the wall street journal had the headlines, the PC junior is a flop and it was, oh God, it was horrible.

What a feeling, as you might imagine to have your product declared the flop just the day after it was introduced but it got me really interested in innovation as a process because I thought, how can IBM with all this fast resources just fail so miserably and just get it so wrong.

And that led me down a career path in an innovation first with IBM, I spent my last five or six years there, trying to think through a better way to approach an innovation process. Then I struck out on my own in 1991, starting Strategyn and have been in the consulting business ever since. We’ve worked with many of the fortune 1000 companies, I think 35 of the top 40 top medical device companies, and just a whole array of different industries over the years, helping them create better products and services and implementing digitalization strategies and everything innovation.

Murray: Okay. So what is outcome driven innovation? 

Tony: Outcome driven innovation is an approach to innovation. So there’s different ways you can approach the innovation process and the way like thinking about the innovation process. What you’re trying to do is to devise a solution that addresses unmet customer needs. And ideally, what you’re trying to do is conceptualize some product that, is gonna win in the marketplace before you even start developing the product. So this was my first thought after that IBM debacle, it was like obviously some people were using a set of metrics to judge the value of that PC junior. We had no idea what they were, but I thought if we only knew two years ago, when we started developing the product, what metrics we should use to judge the value of our product and make sure we address those metrics, then we could be certain to win in the marketplace. So that sent me down this path of trying to figure out what are those metrics? How can we figure those out? 

It all came together in the 1990 timeframe when I was still at IBM. And I thought you. About this quote that you might have heard before. People don’t want the quarter inch drill. They want the quarter inch troll the famous Levi quote. And it, all of a sudden occurs me instead of studying products and how to make better products. Let’s study the other half of the equation, let’s study what people are trying to accomplish. Let’s study the underlying process people are trying to execute with the product. They’re using the product to execute a process. Don’t study the product, study the process. As a manufacturing guy. I thought that’s great, cuz now we can figure out what are the metrics that these customers are using to measure success as they execute that process and turns out that works perfectly well.

So I call those metrics, the customer’s desired outcomes and the basic concept is we wanna understand all the outcomes that people are trying to achieve as they. Using their product and trying to get a job done, if you will, and figure out which of those metrics are underserved and come up with solutions that will address those metrics.

Now the beauty of all this is the foundation is stable. In other words, the thing that people are trying to do, doesn’t change over time, the solutions change over time. So we’re setting everything up in problem space, if you will, instead of solution space and and think of it as setting up a model, 

we’re laying out the basic tenants, people buy products to get a job done. So products succeed in the marketplace when they help people get a job done better. So to bring predictability to the innovation process, we must be able to verify that the solution that we’ve conceptualized will get the job done better than competing solutions.

And we have to be able to do that before we even develop it. So the whole idea is to understand these customers outcomes in some level of priority order, use the outcomes to drive our ideation efforts. So we’re coming up with solutions that address the outcomes and in total getting the job done significantly better.

Murray: So I can think of a couple of examples in my lifetime where products have been so spectacularly better than everything else out there that you just want to use them straight away. The first one is Google. I remember using Alta Vista and Yahoo.

And they were all. Not very good. And then Google came along and it was 10 times better. Once you used it, you wouldn’t go back. Another similar experience would be with the apple iPhones. When it first came out, they were just spectacularly better than the alternative, which would’ve been the Symbian NOIA phone or Blackberry.

 So you’ve got something you’re trying to achieve and a lot of companies actually make it quite hard to achieve whatever it is you’re trying to achieve and you just buy it from them cause there’s no alternative in the industry. And then somebody comes along and just completely changes it and then you don’t want to go back. So am I on the right track there? 

Tony: Absolutely. And you bring up some interesting points too Murray because, there’s several aspects of innovation. One is, people are buying a product to get a job done. But then they have to buy the product. If you can’t buy the product and can’t interface with it and can’t upgrade it and support it, then you’re not gonna buy it.

It fails. So we call those consumption, change jobs. They’re all part of the customer journey, if you will, but products have to be designed in such ways. So they’re easy to acquire. They’re easy to set up to install, to upgrade, to repair, to maintain, to dispose of. Now, of course, people aren’t buying products so they can maintain them and upgrade them, dispose of them.

They’re buying them to get that core job done that we were talking about. So you have to get it right on both fronts. And there’s actually a third leg to the stool too. You have to appeal to the buyer of the product. Now, many B2C scenarios the buyer is the user of the product, but B2B, the buyer’s often a different person. They never even use the product. So now you have to appeal to them along a different dimension. It’s usually a financial dimension and they try to get a financial job done if you will, for the organization. Reduce overall operating costs or something like that. So those are the three legs of the stool and you really have to consider all three in order to ensure your success with a new product.

Murray: How do you identify these jobs to be done? 

Tony: It’s interesting because companies are already in markets, and one of the first things we suggest that companies do is to figure out what markets are they in when you look at it through this lens? I like talking about job student theory, more or less as a perspective or a lens where you now make the job itself, the unit of analysis.

So when you do that, everything gets defined a little differently. So a market is no longer a use case or a persona or product or technology or vertical or geography, or however you currently define your market. It’s not that. A market is now a group of people and the job they’re trying to get done. So we’re gonna go with that market definition. A market’s a group of people and the job they’re trying to get done. And it’s really interesting because we often work with companies and they’re not really sure what job the customer’s trying to get done. They know what job their product does, but we’re not trying to figure out what job the product does.

We’re trying to figure out well people using that product, but what job are they trying to get done? So for example, you could have a kettle maker, making kettles to heat water, and they can go to customers and say why you hire my kettle? And they’d say I hire it so I can heat water, which is true. But it’s really just part of a bigger process. The heating water so they could make some hot beverage for consumption. Now if they were to understand the bigger job, they could eventually evolve into a platform level solution, like espresso did and get the entire job done on the single platform. So it’s really important to understand the job through the lens of the customer, as opposed to through the lens of the product.

Shane: So that’s an interesting lens in that if you understood the tasks that happen when a job needs to be done. That often the innovation is somebody who has streamlined those tasks, they have made them less complex. So that idea of espresso, where if I looked, if I did compos the jobs to be done, it’s, fill the kettle with water, push the button, wait for it. To boil, put the coffee, in a plunger, pour the water into the plunger, wait for it to be. Press the plunger down, pour it into the cup, try not to burn myself in any of those steps. And then you take the espresso example, so I still gotta fill the water thing up at the back, cause it’s not plumed in, but after that I stick my pot in, I push a button, I go for a bit of a walk. When I hear it, make the noise, my coffee turns up and Lucki enough, I don’t burn myself. I do have a slight problem that sometimes I forget the cup to put the cup under the machine. That’s my fault, not theirs. But , if I think it, in that lens, there is a bunch of steps, a bunch of tasks to get the job done of making a coffee. And they’ve automated a lot of it. They made it least complex and actually they’re, coffee’s not that bad. 

Murray: But Tony, boiling the water. Isn’t really a job to be done. Is it the job to be done is getting yourself a coffee.

Tony: That’s right. So we call the job to be done that higher level abstracted job prepare the hot beverage for consumption. We call the steps along the way, job steps and then underneath each job step are these measurable outcomes. Yes, I’m trying to heat the water. That’s one step. So , outcomes might be, I wanna minimize the time it takes to get the water to the desired temperature. I wanna minimize the likelihood of exceeding the desired temperature. I wanna minimize the likelihood of it, burning my mouth when I’m drinking the hot cup.

And Shane, you may have one in there that says, minimize the likelihood of forgetting to put the cup under the the machine itself to collect the liquid. So these are really detailed, granular statements that define how people measure success as they go through each step. And so there might be 10 steps to the job, and there might be 10 outcomes per step. So it’s generally between 7,500 plus outcomes for any given job. And so they’re complex, but what you’re trying to do is to understand the job at such a granular level of detail, that once you discover where the opportunities are, you can take the appropriate actions. There may be a hundred outcomes associated with preparing the hot beverage for consumption. But if you knew that, minimizing the likelihood that the water exceeds the desired temperature, was the most importantly outcome, that’s where you focus, your innovation effort. 

Shane: It reminds me back in the old enterprise days when we did business process mapping, we looked at what everybody was doing. And then we looked at ways of doing it slightly better. We didn’t tend to focus on the outcome as much as we should have. But it sounds like that pattern is now being applied into product. And we do it early, not after the fact. 

Tony: There’s, a major twist to it. What you were describing I think Shane is creating what we would call a process map. What are you doing? I’m doing this, then I’m doing that. And so on. We think of a process map in solution space. What we’re trying to do is to understand this in problem space. So we, we don’t write down what they’re doing. We write down what they’re trying to do. That sounds like a subtle nuance, but it’s a huge difference because what they’re trying to do is in problem space.

Murray: You’re looking at it from their point of view, not from your point of view. 

Tony: Exactly. We’re looking through the lens of the hole maker, not the drill maker, as I like saying it. And from their perspective, They’re trying to, plan the cut. We’d help Bosch, for example, enter the north American circular soul market. They wanna plan out the cut. They want to set up the device to make the cut. There’s very specific things that they’re trying to do as opposed to how they’re doing it.

So with that twist in mind it takes a little bit different skill in terms of your customer interviewing. And this is why we call a outcome driven innovation. It’s outcome driven because we’re tying everything back to what they’re trying to achieve. And we don’t get into solution space until after we know all the customer’s outcomes, which are unmet. If there’s segments of people with different unmet outcomes then we target the most unserved outcomes. So like in the Bosch example we identified a segment of the population. It was about a third of the market that had 14 unmet outcome. We just laid them out in front of them. And that’s when ideation begins, then they start thinking how do we address each of these outcomes and what was interesting in that case? And in most cases, it took them about three hours to conceptualize a winning product, as they said it’s not as if we hadn’t had these ideas before.

But the problem is we’ve had thousands of ideas before, and we didn’t know that these were the 14 outcomes that people were struggling with. The way they’re thinking of it is one of the chances that Bosch team or any team would just randomly come up with a solution that addresses 14 unmet needs in a segment. If they didn’t know the segment existed and they didn’t know those were the 14 unmet needs. And of course the answer’s near zero, but once they know the chances of success go up quite dramatically. 

Murray: I’ve been a product manager and inside companies, you’re trying to work out what people want. Mostly you look at your competitor’s products and you see what’s selling and get ideas from that . And you also look at your market research What are people saying? But that tends to be pretty broad. Market research doesn’t usually talk about jobs to be done. It just talks about, demographics and who likes what really?

Tony: A lot of traditional market research is grounded in solution space. And if you’re doing competitive analysis and you’re saying this product has this feature, maybe we should add it well, maybe you shouldn’t. Let’s say that, Bosch looks at, their competitor Marita and they have this new feature on this circular saw well, they added that feature presumably to address an unmet need. What Bosch would do under instruction would be to understand what is the unmet need that feature is addressing, and then go in the market to figure out if that’s an important need, that’s unmet. And if it is, then it might be worth copying, but if it isn’t just let them go add cost to their product, not necessarily. And so that’s more of the mindset we approach with.

Murray: So do we do this through customer interviews? Are we getting customers in and say, talk us through the steps that you are doing as you are using these products and tell us what you are thinking. How do we find out these things? 

Tony: Yeah. It’s really interesting. This goes back to my early days as a researcher and I always found it remarkable because, watching people do research. The usual scenario is the interviewer and the interviewee don’t know what input they’re trying to capture. And most organizations, there’s no agreed upon definition of what a need is. So the interviewer can’t tell the interviewee, Hey, here’s how we define a need. And we’re gonna capture statements that look like this. So it typically happens is there’s a conversation and it gets transcribed.

And then the researcher looks through the pages of the transcription later on and highlights things that seem meaningful. But neither party still knows what an need is. Cuz it’s never been defined upfront. With our approach we change both sides of that equation. The interviewer knows what a need is. It’s an outcome statement. It has an object of control, a contextual clarifier. It’s a sentence that’s structured in a certain way. And we basically show that to the customers before the interviews began. And we say, we’re gonna take you on a little journey or you’re gonna take us on a journey actually.

And we’re gonna ask you about this job, and we’re gonna go from beginning to end and it’s gonna be like a slow motion, super slow motion view of everything you’re trying to achieve as you go about and get the job done from beginning to end. And these interviews generally last about three hours or so two to three hours. So they’re not like half hour interviews where we just barely get to know the the person we’re interviewing. What we do is we ingrain them into this environment. We keep them in problem space the whole time we never talk about products, we only talk about. The job they’re trying to get done.

We validate that with them. And there may be two or three people, that we’re talking to at a time. So we validate the job to be done. And then we create what we call a job map, which are all those job steps. So we break out the steps and then under each step, we go very slowly and ask ’em. What is that first thing you’re trying to accomplish?

We’re trying to minimize the time it takes to heat the water to the desired temperature. Is there anything you’re trying to avoid? We’re trying to minimize the likelihood of overheating the water, and so it’s step by step and slow motion. And so three hours later, we might have gone through most of those steps and have, five or six outcome statements for each step. So that’s the end of the interview. And then we go to the next interview and repeat the process again, 3 people spent two, three hours And we build on it. The other thing we’re doing is we’re showing people what we’re writing in real time. So they’re watching us type and these days, of course, everything’s online and remote.

So they’re just looking at our screen and they’re learning what kind of inputs we’re looking for because we write down what we’re looking for. And they’re all in the same format, the same structure as outcome statements. So within a half hour or so they say, oh, I get what you’re trying to do here.

And they’ll just start talking in outcome language, they’ll say, I wanna minimize the likelihood of burning my fingers when I’m heating the water or, I wanna minimize the likelihood of the coffee or the beverage being too strong. So then now we’re both on the same page and we’re all talking outcome language. And in this environment, there’s no such thing as latent needs that people don’t know they have, cuz they know exactly what they’re trying to achieve. They may not know the best solutions of course, but they know exactly what they’re trying to achieve. 

Now I can’t say a hundred percent of the time, but most of the time, some people would never adopt that language. and those are the more frustrating meetings, but, let’s say that happens. Maybe you cut the interview a little bit short and you just get the person or the two people that do adopt the language and get them to come back for another two hour, three hour interview. So let’s say you did that a few times. So then you might ask the question you’ve only talked to six people now. What let’s say after we do those two sessions, we have 90% of the outcome statements.

So then what we do is we go into the one hour interview format and we take the set of statements and we present it to other customers and we go through it in slow motion and ask them to validate what we’ve already heard. See if they makes sense and to add anything that might be missing.

So we just start filling in the gaps. So we’ll do that in maybe 10 more interviews. So now we’re, at about 16 different people handful of interviews like that, but we’re not doing 30 interviews, that used to be the old standard. Let’s go talk to 30 people for an hour piece and see what we come up with. You’ll converge on something. But this is much more specific than that. We know what the job is. We know what the job steps are. We’re just seeking out the outcome statements associated with each step in the job. 

I’ll give you a great example. One team member and I spent six hours. We had two spine surgeons and we started from scratch and in six hours we had. The job definition down. We had the job map created and we had collected 150 outcome statements on a surgical procedure, a very complex surgical procedure. And then we took those statements. We put them in front of four or five more spine surgeons. They were 99% right. To begin with. We fine tuned it. And then put that survey out into the field to figure out well, which of those needs were important and not well satisfied. And that, that, led our client to figure out where the needs were so they could build a winning product.

Murray: This reminds me a bit of Tom Gill’s approach. I don’t know if you know Tom Gil, but he. Is also out of IBM at a similar time bit earlier than you, he comes more from engineering and his whole approach is about success metrics, outcome metrics for developing products. Because in our industry the first thing happens is that a group of managers turn these outcomes into product features and then they’d get turned into system requirements. And then you get this long list of things you have to build. And all anybody cares about is did you build them in the next six months or not? You can ask your product owners, what’s more important and what’s less important, but nobody is talking about the outcome for the customer you’re trying to achieve. 

Tony: You know, The concept of success metric is, in line with what we’re taking. I don’t know that methodology, but the concept’s similar. But, one thing that we do that makes this easier is we tie it back to the job the customer’s trying to get done. So when you say a success metric success at doing what, like you have to know what that is, it’s gotta be bounded, and so everything we’ve talked about so far helps bound what you’re studying. I mean it’s broad and it’s granular, but at least it’s bounded. 

Shane: So the top level above a job step, what was the term you used for that

Tony: Above the job steps is the core job to be done.

Shane: So I can imagine that sometimes you may end up with a boundary that is one job to be done. And then sometimes you may end up with a number of jobs to be done.

Tony: We define a market as a group of people getting a job done. So we wanna define the market. And once we define what that job is, then you break it down into job steps and outcomes. Your customer’s gonna tell you how to define the market. Just like in that kettle example, you go to the people using the kettle and you say you are using this product. What job are you trying to get done? Ultimately I’m trying to prepare a hot beverage for consumption. Okay, great. So that’s the job you’re trying to get done. And they studied that whole job, even though they’re a kettle maker, because they’re trying to figure out well, other opportunities, maybe there’s some adjacent steps to heating the water to the right temperature that they could also impact and make their product more valuable in the grand scheme of things.

Murray: I have done some customer interviews. Where we talked about, some of these sort of things, not as thoroughly as you, but I’m aware of two criticisms of job to be done theory. The first one is that in say 1910, if you asked people about how they’re getting to work, and you went through jobs to be done theory, they talk about horses and hay and Hoves and roads and everything. So the problem and the solution space are intertwined in people’s minds. And because you are going through all this detail about the jobs to be done, it’s all on the assumption from your customer. That it’s about horses. So if you went through this process, what you’d get out of it is faster sweetest smelling horses. 

Tony: I’ve heard this lots of times. The saying’s been around for years, and the saying is, Henry Fort says, if I asked people what they wanted, they would’ve said faster horses. And then Steve jobs came along years later and said, people don’t know what they want until they see it. Now it’s interesting how people interpret those statements. They walk away saying you know what?

People don’t know what they want. So, since they don’t know what they want and they have latent needs, let us just come up with their own ideas and see if they like. So they follow this ideas, first approach to innovation. They never attempt to understand the customer’s needs because they think customers don’t know their needs, but Henry forward and Steve jobs never said that.

What they’re saying is if I ask people what solution they wanted, they would’ve set a faster horse and people don’t know what solutions they want until they see ’em. Those are true statements, but that’s in solution space. A solution is not a need, a solution satisfies a need. I think you’re right to say, people conflate solutions with needs, and that’s one of the big problems in the innovation space. They conflate solutions, space with need space. This is why it’s so important to understand. What the customer’s trying to accomplish at the job level, at the job set level at the outcome level prioritize all those needs before you ever even have an idea. So if you were to apply this back in 1910, you’d say people, you’re hiring a horse. What are you trying to do? I’m trying to get from point a to point B, and I want minimize the likelihood of getting robbed along the way. I want to, minimize the likelihood that I get sick. You could imagine if he’s just stuck to the script like that, you’d end up with a set of outcomes that you could easily conceptualize a different kind of mechanism to move people from point a to point B. I think people who criticize jobs we’ve done from that lens are suffering from what many suffer from, and that the conflation of solution space with problem space. 

Shane: I think as humans, we love to play in the solution space. It’s a fun place to be, we all love creating solutions and creating new things. And, I did it on this podcast, I automatically jumped to jobs to be done as the steps, the processes of people that they’re doing, not what they’re trying to achieving. If I do think about the Henry Ford example, I agree with you. The outcome is I wanna get somewhere faster. The solution may be a faster horse, or it may be a car, but, I wanna get somewhere else faster and maybe safer and less cost. 

Murray: But I think the concern is that you would spend a lot of time talking about horses. Cause that’s what the customer wants to talk about.

Shane: But that’s a skill, it’s a skill to focus on the outcome and use a technique to get to the outcome not focus on the steps and what we are doing, and then try and solution it because that’s what we do as humans. 

Tony: Great point. When we’re in these interviews with customers. We keep them in problem space. We never talk about solutions. We never talk about products. And I can tell you, it is hard to keep them from talking about products, but once you get ’em going and you’re showing them the outcomes and you’re explaining them, then what are you trying to do next? What are you trying to avoid? It just don’t give me in to talk about products and they won’t . And once they learn what you’re trying to capture, they stay away from product conversation as well. And by the way, if they do talk about a product and say I like this product better than that one, I would say why, what feature does it have on it that makes it better? And they name the feature, which is still a solution. And then I’d say how does it help you get the job done better? And then they could state the outcome. 

Shane: I’m almost at the stage now where I think there’s two major patterns for solution spacing. There’s the lean UX patent, which is create a solution WT in front of a bunch of people. See what they hate, what problems it doesn’t solve and then iterate it. And then there’s the research first pattern, which is understand the area and then figure out what the problem is, and then figure out what a solution might be and then test whether that solution fits.

And for me, the lean UX one always seemed easier because there were a bunch of steps that I understood that I could use to do that. And whenever I talked to somebody in the research space, it was always very arty, it was somebody who was an expert or a coach who knew how to do it, but they couldn’t tell me how to do it. What I like about this is I think I understand this process, this process of talking to somebody about the jobs they’re doing and the outcomes they’re trying to achieve. And then I can think about a solution and whether it’s gonna fix it. So, I like that. But, how does this fit in with that whole lean UX product, thinking of build a solution and see if they will come.

Tony: So there’s three different approaches. One is ideas first. Let’s come up with ideas. See if they stick the second, like you said, is the research approach, but let’s call it the needs first approach. Okay. Where you’ve try to uncover the customer’s needs and figure that out and then come up with a solution. But we’ve pulled this dozens of times and we ask product teams. Is there agreement on your product team as to what a customer need even is? And 90% of product teams say no. Now this is a problem. And we’ve done other research. We’ve talked to 15 experts in the space and, they have 15 different definitions of what a need is. So the problem is there is no agreement on what a customer need is. And this is why we have the third approach, which is an outcome driven approach to innovation outcomes first. 

Instead of ideas first or needs first, because you can’t define a need, let’s define a need as an outcome and apply the outcome first approach to innovation. Now this makes lean even leaner and agile, more agile because the whole goal is to move quickly to get a product to market one that’s gonna win in the marketplace.

And the whole goal of the innovation process that we’ve created, outcome driven innovation is to be able to conceptualize the solution that you know, is gonna win in the market before you even start developing it. So this means that you have to be able to conceptualize a solution that address CMET needs, and then verify that it’s satisfying the outcomes to a great enough degree.

So at the back end of the process, once we know what all the unmet needs are, we use those to do the ideation. Like I talked about in the Bosch case, they came up with solutions that address those 14 unmet needs. And then we go back to customers with those featured descriptions. And we say, here’s your current level of satisfaction with these outcomes.

If we were to deploy these features, to what degree would improve satisfaction. And now we have our data points, so we can quite literally measure how much better we will get the job done. And what we’ve found throughout the years is that if you can get the job done, 15% better or more, that’s gonna be a winning product.

So there’s a threshold, and you can imagine this, would you ever switch from your favorite brand to get a job done 1% better or 2% better or 5%? At some point you go I would switch, but it’s gonna be significant. And that’s why we say, to win an innovation, you gotta get the job done significantly better, which means you have to know all the measurable outcomes that are UN men, because you can’t just one and go address it and you’re have a winning product. That’s incremental improvement. There are 10 on the needs. You wanna know all 10 and you wanna address all 10. Now you have a breakthrough improvement and a break through product..

Murray: Isn’t price also important here though. Cause if I get 20% better, but I’ve gotta pay 20% more for it, maybe it’s not better for me. 

Tony: Well, yeah you’re right. So the answer is sometimes it’s okay and sometimes it’s not. One of the questions we use in our surveys is we ask people how much they’re paying today to get their job done. And how much would they pay to get it done perfectly. Two simple questions.

You have to imagine like getting a haircut, how much do you pay today? And how much would you pay if you could get it done perfectly. And those might be the same number or two different numbers, but it gives you some idea. If there is price elasticity, if there is, then we say you could pursue a differentiated strategy, which we define as getting the job done better and charge more. Cuz you can. But if they come back and say, Hey, we don’t wanna pay more. Then you have to pursue what we call a dominant strategy and you have to come up with a solution that gets the job done better and more cheaply. 

A quick example we worked with cruel on track to help them enter the electronic evidence discovery business. Market was highly under served cuz everything was being done manually. It was taken forever. There was so many mistakes and people were not willing to pay more to get the job done better. So their solution which was digital of course got the job done significantly better and significantly cheaper. And those are the best kind of innovations of course. Because you win every part of the market, the overserved people, the underserved people non-consumers, they can all buy now if you’re getting it done significantly cheaper and better people wanna buy it

Murray: Shane let’s talk about your product. Just tell people what it is and tell us what you think the jobs to be done are.

Shane: So organisations have a lot of data. People wanna get to that data quickly so they can use it to do something. When we look at the jobs, there are a whole lot of steps that people do, and it takes a lot of people and those people cost a lot of money, and so we are looking at ways of solving that problem. How can we give people their data quicker, faster, cheaper, all those good things. And we’re experimenting with understanding what those job steps are and how we can fix that problem. Now the challenge I have is my natural behavior as solutioning. I come from a solutions background. I come up with an idea and then we build that idea and then maybe we’ll test it. I’m definitely not doing a research or an outcome first approach.

Tony: What is the product that you’ve created? Describe the product for a second.

Shane: So people subscribed for a fixed monthly fee and we make their data available for them. Under the covers. I can align our solution to a SAS data platform that we use to do that work. And I can align that with a bunch of our time to use that platform to deliver their outcome. But the product they’re paying for us is a fixed monthly fee to get access to their data when they need it.

Tony: Access to their data. So, they’re putting their data in your platform or your product. 

Shane: So a customer that has between one and a hundred employees will have somewhere between 20 and a hundred source systems that they type their data into. We grab that data and put it together and we put it together in our platform because that makes us faster. 

Tony: So you, help them, find different files and things that they’ve stored and things like that. Is it file management or is it more like you’re actually helping them analyze data.

Shane: So the data is typically what we call structured data, but it’s typically about core concepts. So it’s about the concept of a customer or concept of a product or the concept of an order. So we will see things like customer orders product, and they will have a question that says, how many customers we have how many orders did they place? What products did they purchase? And we make the data available to answer those business question.

Tony: Okay. The group of people sounds like knowledge workers. 

Shane: They’re typically leaders of a company, who have a business question, they want to answer with data. They know the data exists, but nobody could ever give them the data to answer that question. 

Tony: The way we typically analyze a market that exists, cuz we, we do this a lot with startups. Like they already have an idea, which means you’re already chose a market. You’re already targeting a group of people in a job to be done. Now what I wanna do is to discover what that is. 

Shane: So our group of people is an analyst, there are a bunch of people that have a school which lines them with being an analyst. And they sit within that organization, 

Tony: So, the data analysts.

Shane: Data analyst or a business analyst, but data iterate analyst, they have to have some literacy.

Tony: So what we generally do we built a canvas it’s called the market definition canvas. And I’m trying to do is to take you through it without showing it or explaining it. But at a high level, what we do, the first question we say is what is this product that you have? So you can name it, whatever.

And then we ask who would use this product? So it could be data analysts data managers, maybe knowledge workers, maybe executives. I’ve heard you say all these different categories, so write them all down. And then we try to elevate that up to a higher level of abstraction. Cause if all these different categories of people would use the product, can we describe them in a different way? The corollary for the Bosch circular saw example, we say you try to create a circular sauce or so who’s gonna use it. It’s plumbers, electricians, roofers, framers, carpenters, general contractors, a lot of people.

But what could we call them? So let’s call ’em tradespeople. And then on the other side of the equation, we say you’re using a circular on, but are there other products you’re using in conjunction with that circular saw? Just like with the kettle. Are there other products you use in the conjunction with the kettle? Yes. So what are they, so I’ll ask you Shane to go through the same here in just second, what are the other products people use in conjunction with yours? And why are they doing that?

Because they’re cobbling together solutions to get a job done. And what you’re trying to do is to get from them. What is that higher level abstracted job. So you’ll end up with this market definition, like trades people trying to cut wood in the straight line, for example. So you, try to elevate it up so that it fits all the circumstances, cuz you don’t want to narrowly define your market or pre segment your market. There’s no need to at this point, you wanna approach anyone? Who’s trying to get this job done regardless of their business title. It may be a new category of people. That’s why I mentioned knowledge workers, that might be a way to capture all, data managers, data analysts, executives, maybe they’re just, knowledge workers. That’s how we would approach that. And then you would have your market defined with the jobs to be done, and then you could apply everything else that we talked about. 

Shane: I’m really glad to hear that there’s a canvas for it. Canvases are a great way of articulating a pattern in a summary level. And it’s also a great way of giving examples. 

Tony: Steve blank, who wrote the four steps to the epiphany published one of our blog posts last November, where we introduced this market definition canvas. And I think the reason he liked it is that in the lean startup methodology, there is no market definition step, and that’s true of many innovation processes. There’s no market definition. Step. We asked this question in a webinar just a couple days ago. Is there agreement as to how to best define your markets? 80% of the population says, no, we can’t agree on how to define a market. And and the only startup, the way they would do this is they would suggest that the entrepreneurs hypothesize the market, the product and the customer’s needs all at once and then go out to customers and the customer discovery process and figure out if it’s right. And if it’s not right, then modify it, iterate and so on. The problem with that is you try to solve three equations at once. You’re try to pick your market. You’re trying to pick the needs. You should go target, and you’re trying to define the solution, 

So we would say. Don’t hypothesize ’em all at once. Just do one thing at a time first, just define your market, as a group of people and the job they’re trying to get done. Now that’s a stable focal point around which to analyze your market and do customer discovery. So now you can go to customers and ask them, how do they measure success when getting a job done so we can figure out all their needs, and do quantitative work to figure out which needs are unmet. Now we know we have a viable market and we have a viable set of unmet needs to go target. Now we come up with the solution. This is the fastest way to achieve product market fit because you’re doing it in a very systematic order, find your market to find the unmet needs, to find the solution that addresses the unmet needs. Like the Bosch team, it took ’em three hours to conceptualize the product. Once they knew what the problem was. 

Shane: To use an example from our startup we’ve got interesting choice on some product market fits because we’ve done it in a different order. Our initial hypothesis was analysts were underserved we have enough experience to know it’s true. But when we were talking to customers who were giving us money they didn’t actually have analysts. They just wanted the problem solved. They wanted the outcome of getting data. And so we’ve got traction in that market, but it wasn’t the market we were aiming for.

So if we had to gone and actually define the market and define the unmet needs, we probably would’ve come up with two definitions. Two different groups of people in the job. They’re trying to get done. One being that analyst and the other, being that leader of the organization. If we had to started at the beginning of the right way we would’ve come up with two buckets of markets and figured out which one we were going after first or decided we were gonna go and try and go after both for whatever reason. But at least it would’ve been a conscious decision, not an unconscious behavior. So I like that idea of reduce uncertainty. because otherwise we are just trying to Bo the ocean and that’s a nightmare.

Tony: A true. 

Murray: I want to ask you about the next step, which is going to market. So you’ve, done this research. You’ve got a prototype product based on what people have told you. How do we use this to go to market then. 

Tony: It’s gonna depend on whether you’re B2C or B2B. More specifically, it’s gonna depend on if the buyer is the job executor or if the buyer’s not the job executor. What we’ve learned over the years is I love B2C, cuz some are simpler, toothbrush, fresh manufacturer, you focus on the consumer. They use the product, they buy it, they dispose of it. So you can talk to them and get all the needs. And when you do your marketing, you only have to appeal to them. And B2B, when the buyer’s not the job executor, the go to market strategy becomes a bit more complex because the buyer is the one making the purchase decision.

Now product of course has to. The job executor’s job done better. And if it can get it done better and more cheaply, the chances are the buyer’s gonna wanna buy it. But you’re gonna have two go to market messages, one to the job executor one to the buyer, keep ’em separate. You have to appeal to both people. From the job executor’s standpoint. You satisfied these 14 IME needs. You gonna get the job done 15% better or more. That’s great. From the buyer’s perspective, you’re reducing cost. You’re reducing downtime. This financial metrics that they’re looking at that are going to appeal to them. They may never use a product, they just want something that’s gonna save the business some money or make it more efficient or reduce time to market, or, some of these higher level strategic or financial jobs that, they’re trying to get done. So you can apply the same approach. Go talk to the buyers figure out what job they’re trying to get done appeal to them in very much, same way. 

Murray: So this seems like a very rational approach, Tony, and people criticize this approach because it is so rational. I, I was watching a video with Simon cynic the other day, who said, people don’t buy your products cause of how they work or, what the result is. People buy your products because of your why. People buy apple because it’s revolutionary. It makes you a rule breaker if you like. So there’s a lot of emotion and strikes me jobs to be done is missing the examination of the emotional side of product purchasing. 

Tony: That’s interesting that I mentioned that because we lay out, several types of jobs. I mentioned a few of ’em already the core functional job. The customer’s trying to get done the consumption jobs, purchase the product and set it up and those things. And then there’s also what we call related jobs and there’s also emotional jobs.

So the emotional jobs get at what you’re talking about. Emotional jobs are interesting. But you can’t design a product per se, around an emotional job with no functional context. If you went to a designer and said, Hey, create a product that makes me look cool. You don’t know whether to develop a car, a shirt, a watch whatever.

It’s gonna be in context. So when we define a market as a group of people getting a job done, whether it’s the circular saw users or parents trying to pass on life lessons to children, or surgeon trying to repair rotator cuff, we’ll ask them, what are the emotional jobs you’d like to achieve?

The way we say it’s a little different, we say how do you wanna be perceived as a result of getting the job done? Or how do you wanna avoid being perceived? Like parents may say, I wanna be perceived as a good parent by my peers. That’s an emotional job, but the functional job is to pass on life lessons to children. I, can build a product around passing on life lessons to children. I can’t build a product around the single input of, make me look like a good parent in front of my peers. I need some context. So we use all these emotional jobs and it’s generally 10 to 20 of them per market. And we put ’em in our studies and we figure out which of those emotional jobs are important and unsatisfied as well.

Now, what we do with ’em in the end is really interesting. We learned this actually from Microsoft. We worked with them back in the early two thousands on about 40 plus projects. And we were experimenting with this emotion function, correlation. This is what we called it. But here’s how it works.

So once you know what the unmet needs are in a market, the functional unmet needs, and let’s say there’s 10 of them and you satisfy five of them we get new product. And as you’re ready to announce it, you run a correlation analysis between those five outcomes and the emotional jobs. And you can see which ones correlate.

So you can go to the market and say, Hey, we can functionally help you do this. And emotionally, it makes you feel like this. That’s the one, two punch you’re looking for. So we do include emotional jobs. So people who say that not reading all the chapters in my book cuz it’s in there and it has been for decades. We generally use it for marketing purposes and it can be a very effective tool to appeal to customers, both emotionally and functionally. Works better in some industries and others. Automobiles are functional and emotional. If you’re selling bricks, not very emotional. It plays more or less importance depending on the industry. 

Murray: So you’ve been doing this for quite a long time now, what have you learnt over the last 30 years?

Tony: It’s interesting because the approach hasn’t changed much in 30 years. I think what I’ve learned is that people are really resistant to a discipline approach to innovation and not everybody, but most everybody. And Shane, I think you hit the nail in the head earlier. You mentioned, most people are good at having ideas, so they have ideas that’s easy. And so why take that away from people? Most people aren’t good at all the analytics of trying to figure out who the market is and what the needs are and which are unmet and how to segment and which to target and what strategy to pursue.

That’s a lot of work. To make innovation. Predictable is a lot of work. And I think people. Shortcut cut it. And management supports that and the whole VC industry is set up that way. It’s stuck in a rut, if you will. Now I think some point in the future, everyone will adopt outcome driven innovation. We’re trying to make it easier for them to do that by putting together some new courses and materials. But it’s spent 30 years. And I did get my expectations set correctly years ago. I read an article back in the eighties that said for change to truly take place in, in a business organization, it takes about 20 to 30 years. And we’ve made some progress. I think we’ve done a pretty good job of convincing some portion of the population that being disciplined makes great sense. The next challenge is making it easy for the rest of the population to follow. And that’s what we’re trying to.

Murray: okay, good. Shane, how about we go to summaries? 

Shane: So I like the idea that the definition of innovation is something that meets unmet customers need. And I like the idea that you talked about defining the metrics to evaluate the success of your product up front before you even start working on your product. I also like the idea of studying the process, don’t study the product, so this idea that we are thinking about jobs to be done and outcomes, not solutions. In the data world, we often talk about core business processes and we do that because we know that the core business process of an organization doesn’t change often. We know that the source systems we type data into change all the time. We know the questions that we ask often change, but those core business processes are fairly sticky. And so I like the idea that the things people do doesn’t change but the solution often does. 

I keep coming back to your definition of a market. Group of people and the jobs they are trying to get done is a definition of a market. And I think that’s a really nice, clear definition or a way of defining it that I haven’t heard before. And I love the espresso example. So I think about a kettle and I could boil the Kele to make a coffee, but I could boil the kettle to get a hot water bottle. Same job different outcome. You don’t wanna get those two confused. So I like that I like the framework. I like the idea of jobs to be done, job steps, job outcome and then focusing on what the outcome is. And then I’m only do some more research about those lenses, those emotional jobs and those different lenses. 

I like the way you focus on what are they trying to do. What problem are they trying to solve? What’s the outcome of that problem to solve? What are they trying to achieve? I like the idea that, research used to take 30 people times an hour. And by using this approach, you can spend less time to still get a better quality outcome. And then you talked about three models in the market, ideas first, needs first or outcome first and that we should be focusing on outcome first. But we all know that coming up with a core solution and having an idea is much easier than executing it. 

I like the idea that, we have to be 15% better to make people switch. I’m an Apple fan, if I’m gonna change, it actually has to be that much better for me to change that emotional job to be done. If it does, I will switch this hasn’t happened yet.

I like the idea about, how much do they pay today to get the job done? And if it was better, how much would they pay to get that outcome in a better way. So I think doing that early helps validate that market that we talked about. 

Definitely gonna go and investigate the canvas cuz I’m a great fan of canvases that are done well, helps me understand how to adopt an approach. And then, you talked about defining the market first, define the unmet need and then define the solution. So that almost goes back to that conversation we had on the podcast previously around research first, then define the problem, then define the solution. But this gives me some actionable ways of doing it .

Which I prefer I also like your definition of bio versus user. So I talk about bio features, user features and investor features and they are different. We work in the B2B space. So the way you articulated that the outcome for the person buying is often different for the outcome of the person using. I’m gonna experiment with that. I’m actually gonna go and change the website to have space where it says you are the buyer in a space where it says you are the user, because I think that might solve my problem of sometimes the person buying our solution is a leader in the organization that just wants access to that information. And they don’t care how they get it. They just want it to be. And our second option is those analysts that actually want to do that job and their outcomes. They want to do it faster and better and easier and with less pain. And so there’s two different outcomes because they are two different personas. So therefore they are two different markets. Another awesome podcast. Thank you, Murray. What have you got? 

Murray: Okay. my, thoughts once again, we need to focus on outcomes and companies don’t do that. Why don’t they focus on outcomes? They focus on things like revenue and sales, but outcomes for the customer. No people forget about that all the time, and it can even be quite difficult to get people to focus on things like revenue and lead generation. So often companies. That we are working with in the product space are completely focused on features and that’s all, everything is about. There is a big movement in the agile community to say, stop focusing on features, focus on goals, set outcome measures, focus on value. What is the value of what you’re trying to do? And the product owner, which is kind of a product manager for a small engineering team is really being encouraged these days to think a lot about what is the business value, the customer value that you are trying to deliver as well as the technical feasibility.

We just keep getting this message over and over again, focus on the outcome, focus on the goals because people don’t, why don’t they? Cause it’s hard, cuz it’s different. Because organizations are very inward looking. I think generally, organizations are a political cage match where managers get to the top by, beating competitors internally. And so people get very internally focused and then everybody just forgets. And then when you think about purchasing and procurement, if you’re gonna go and engage somebody to help you build a product that procurement people are totally focused on deliverables and features.

It’s gonna take some real leadership in organizations to talk about outcomes, to talk about value, to allow the time and the money to go and do the research. I think using your canvases and your approach, people can learn how to do this themselves pretty cheaply. Why can’t you take some people who are already quite good at analysis and go and get them to start talking to customers using this approach.

Now, I take a point from Debbie Levitt to say that cause they’re novices, they’re probably not gonna be very good at it. And you’re probably better getting some, skilled researchers to help you. They’ll probably get a better outcome, but if you don’t have that sort of money, if you don’t have that sort of permission, you could do this yourself for that too much trouble.

And what I would do is I would build it into your process. You’re doing it alongside your product development team and starting earlier, obviously so that you understand, but products go through a life cycle and they have to have iterations. And so if you’re already in the middle of a product, then start doing this so you can work out what you should be doing next. It just seems really obvious to me. I like your approach. I think , you answered the criticisms well, So, like anything, it probably just takes practice and developing skills to do it well. 

Tony: I think everything you said could be summed up to a higher level obstacle. And that is, I think companies need to adopt a different innovation mindset. It’s a mindset shift cuz everyone’s so focused on solutions, cuz we’re asking people to take the economic principle that people buy products to get a job done. And we’re saying if that’s true, then why don’t we define a market as a group of people getting a job done and then why don’t we find needs as metrics that people use to measure success when getting a job done and then why don’t we segment around those outcomes and then why don’t we target the unmet outcomes?

The funny thing is all we’re doing is asking people to use a different data set to make the same decisions they’re already making. But the data set is all in problem space and people just aren’t used to being there. What we’re trying to do is to get people, to see through a different lens, the lens of the hole maker, not the drill maker. And once you flip the switch, you’ll never go back. Once you see it through that lens, everything looks very different and much better over here. But getting people to see through that lens is hard. And so I think most of the things you said can be summed up into making that happen. And sure hope we can.

Murray: We have the same problem in the agile space. Tony. Once the light goes on it, stays on. But getting the light to go on can be quite hard, particularly with managers. 

Tony: Everything we talked about, makes agile more agile, because if you can get a product into development that you know is gonna win, you don’t have to change the product definition as you’re developing it. Now you’re just iterating on the design, not on what the product does.

Murray: All right. Thank you very much for talking to us now, how can people find these canvases and tools and find out more about you and, strategy? 

Tony: Probably the best place is the Strat and website@straton.com. It’s a great place to go. I also have a free audiobook and ebook at jobs to be done. book.com, all hyphens jobs, hyphen to hyphen jobs, to be done, book.com. And I also have a medium site where I write some of my more personal articles and beliefs and opinions and post them up there. And that’s jobs to be done. Dot com.

Murray: Great. That’s fantastic. Really appreciate it. Thanks for coming on. Love talking to you.

Tony: No, it’s been my pleasure. Thanks for inviting me. I appreciate it.

Exit: That was the no nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact Murray evolve, that’s evolve with zero. Thanks for listening.