Strategyzer Webinar: Testing Before Building Is The Key To Success

Attendees are in listen only mode. Hi everybody. Thanks for joining. As everyone's trickling in, we'll start the webinar in about two minutes at the top of the hour. So in the meantime, why don't you take a moment to think about what you want to learn from today's session. You can either share it in the chat box of the GoToWebinar panel, or you can tweet us Rategizer and use the hashtag strachat. Let us know what you want to gain from today's session and we'll start in a few minutes.

Sa.

All right, let's get started. Good morning, good afternoon, or good evening wherever you are. Welcome to a another Strategizor Strap Chat webinar session. Today's topic is Testing Before Building is the Key to Success. I'm your moderator Kavi Gupta. I manage content and community at Strategizer. Our host is Alex Osterwalder, co founder of Strategizer and co author of global bestsellers Business Model Generation, Business Model Design and Value Proposition Design. Our guest is Tony Uluk, founder of Stratagen. He is a Thinkers50, recognized management and strategy thinker, pioneer of the popular Jobs to be Done theory and inventor of the outcome driven innovation process. And despite all those incredibly smart things, he's also a good friend and collaborator of Strategizer. And finally, our diligent illustrator and visual thinker Holger Niels Pol, founder of Work Visual Institute and also a frequent collaborator and friend of Strategizer. As always, if you have any comments, any feedback or any ideas or thoughts that can extend the conversation, find us on Twitter Rategizer and use the hashtag Stratchat to add your comments to the conversation. You can also head over to blog.stragizer.com and dig into more in depth content about this topic as well as other topics that pertain to business model design and value proposition design. Throughout this webinar we might be mentioning certain tools. I just want to let you know that those tools that we mention are available for free in our resource library. You simply have to create an account and you get access to 30 plus canvases, tools and templates. Just head to strategizer.com register and create your account. For those of you that are interested in exploring enterprise offers for your large company or team, we do have solutions to help global companies upskill teams, validate new ideas, expand existing business lines, or launch new growth engines. Head over to strategizer.com enterprise to see our offering or if you're willing to send an email to salestrategizer.com I'm just going to hand over the reins to Holger. Alex, why don't you take a moment to tell us a bit about why testing has been such an important topic for us lately.

Yeah, I think the whole jobs to be done concept and testing and different angles on it are really now gaining a lot of traction in the senior executive suite as well. Just in quotes with the doers. So pretty much of a bottom up movement. Right. And I'm really excited that we have Tony Ulwich with us who has been a pillar of the innovation community and thought leader and really brought some tools to the table, some concepts and ideas to the table that have changed the way we think about innovation and basically marketing and product development. So I'm really excited that Tony could join us. So good to have you, Tony.

Alex, it's great to be here. Thanks for the invite.

So let's kick it off right away. Looks like we got the visuals right. One of the things I'd be curious to hear from you is some simply how you got into outcome driven innovation and jobs to be done. How did this all start out? Does that come from some kind of passion or how did you figure this thing all out?

Well, I guess it came out of necessity. This all started years back when I was working at IBM and I was a process engineer, manufacturing engineer, working on a product called PCJR that was announced in big fanfare and was unfortunately a big failure. And it got me very interested in innovation as a process, wondering, you know, how could IBM, company of great resources like that put out a product that was just a billion dollar failure. And after, after that I get very interested in product planning. And so I've spent about six years of my IBM career as a product planner, a market researcher, working, learning all about everything I could about strategy and innovation. And I concluded at that point that there really wasn't an effective innovation process that had been invented yet. So the goal was to go out and create one. So I've spent my whole career doing exactly that. I became an internal consultant, helping IBM, us, Australia, Japan and France formulate their PC growth strategies. And that got me really interested in comfortable, in fact being a consultant. So when the PC business went south in 1991, I left IBM to start my own consultancy.

So you've been doing this for a long time. A lot of experience, a lot of learnings. Now here comes this methodology called Lean Startup with the ideas of build, measure, learn and sometimes People take the build part too literally. Right. They start building something to actually experiment. Now, you're a big proponent of testing before you build anything what Steve Blank would call customer discovery. So tell us a little bit about what that means and how that relates to the lean startup approach. How can we place this to understand the differences, the similarities, and how these things go together?

Sure. So I think there's a couple aspects to it. So let me cover the first one. And that's just understanding customer needs, that aspect. So when I think of that aspect of innovation, I like posing this question. Would you rather learn a few of the outcomes that customers want addressed each time you iterate and then have to iterate dozens of times before all the customers unmet needs are revealed and addressed, or would you just rather know all the customers unmet outcomes right up front and devise a winning solution in the first iteration? I think most people would say, well, we'd love to do the latter, but it's hard to do. And what outcome driven innovation is all about is to help people discover what are all those metrics that people are going to be using to judge the value of my product and capture them all up front so that you're not going through multiple iterations and learning as you go. It's more like a learn fast as opposed to fail fast. So that's the answer on the need gathering side, but there's also the invention side. And when it comes to trying to figure out how to solve a problem, like you have to invent a solution, there is no technology that makes it possible. Then I think failing fast makes sense, but you're failing fast in terms of experimentation, which is like what Edison did. You know, he would try to invent the light bulb. He'd go through thousands of iterations to figure out how to make how to make it work. But that's a little different. That's invention. But when it comes to just defining a product concept that can win in the marketplace, I think understanding the needs first really sets the stage for changing the way you can innovate. And that's what outcome driven innovation does. And based on the jobs theory, people are buying products to get a job done. If we can figure out how they measure success when they're getting this job done, we can just figure out where they're underserved and design a solution that addresses those unmet outcomes, which is what we do.

Excellent. And that's, you know, the whole jobs to be done theory. And the outcome driven innovation theory was the basis for us working on the value proposition canvas with Strategizer. Right. So we're big believers in that. I'd be curious to hear from you. Over this long career that you've had working with a lot of different companies, what were maybe the three biggest or most astonishing insights that you had using the outcome driven innovation approach in the jobs theory?

That's a great question. You know, I'd say probably the biggest thing was in working at IBM. I was in Australia working on a project when the concept of JOBS and ODI struck me for the first time. And that's when I began to construct the process. But we've all heard Levitt saying, people don't want the quarter inch drill, they want the quarter inch hole. As a process engineer, manufacturing engineer, it finally occurred to me that if we could just study that underlying process that people were executing with the product, we could break it down into its component parts and figure out what do we need to measure and control to produce a predictable output. Well, that really led to the big breakthrough in terms of how to define markets and jobs and outcomes and so on certainly was probably the most important discovery. But then there were other pieces that had to come into play as well. And we knew that people using metrics to define value when getting a job done, but we weren't sure how to define them. And this is where we invented, if you will, what we think is like the perfect need statement. That's what a desired outcome statement is. And we spent a lot of time trying to figure out how to, you know, how to invent that statement, what it should look like. So we went back to think through all the different characteristics the perfect need statement should have. So, for example, like if, and I joke about this too, you know, unfortunately, a need statement has to be stated in words. And that means we have to construct words in a way that have meaning to the customer and to the company. And so we have to figure out what does that sentence look like, what structure should it have, what format should it have? And we spent a good decade testing a lot of variations of things to figure out what the perfect outcome statement should consist of. And first thing, of course, it's got to be a constant in the equation or stable over time. Again, this is the process engineer side of me speaking. But innovation at a high level is a simple concept. You're just trying to come up with solutions that address unmet needs. So there's really just two inputs in the process. Solutions and unmet needs. Now, like any good equation, there's got to be constants and variables in the equation. If everything's a variable, we can't solve the equation. So in the innovation equation, clearly the solutions are the variable in the equation, which means somehow we have to define needs as a constant. They gotta be stable over time. And that's why tying these metrics or outcomes to the job the customer's trying to get done became so important. And we felt that because we had a stable unit of analysis being the job, we could then define the needs, the outcomes in that very same way. So one of the top considerations that we had was to make sure we're defining these needs in a way that made them stable over time. Now that was just one factor. We also knew that these statements had to be useful for the entire organization. In other words, we don't want to have one set of needs for the marketing team and another set for the development team and a third set for the R and D team. There should be just one set of needs that come from the customer, that they agree that they're their needs and then they're useful for sales, marketing, development and R and D. So they had to have cross functional applicability. So figuring out how to bake that into the equation took a little bit of time. There's other factors as well, but the other key thing is that they have to be measurable and controllable in the design of your offering. Because once we have all these metrics, we'd want to be able to test ideas, concepts, solutions against that complete set of metrics to see which solutions get the job done best along different dimensions. And, and then from that capability, from that data model, we could systematically construct a solution that got the job done best. So laying all that out, I thought, was the other critical piece. And there is one more though. The third piece is the outcome based segmentation work that we pioneered. And I first got involved with segmentation back at IBM and one of my first exposures to the concept was working with McKinsey & Co. Who did a, a needs based segmentation. What was billed as needs based, but as I learned later, their needs weren't really defined in a way that made the approach effective. But what we've learned over the years is that once we can define a need in a very specific fashion and figure out which are unmet, we can actually segment around unmet needs. And this has been a huge breakthrough because what we've learned is that in nearly every market, people don't agree on what needs are important and unsatisfied. And if you're creating A single solution for the average market consumer. You're probably going to fail because there is no average consumer. We often find that there are some segments of customers that are more underserved or overserved than others for different reasons. And the ability to pinpoint with precision why there's some set of customers more underserved than others and what unmet needs result because of that has become really the cornerstone of figuring out a good market strategy.

That sounds very interesting. And my first reaction is, wow. If we as an organization, let's say I'm an established, you know, Fortune 200 or Fortune 50 company, if I had a good mapping of those unmet needs a across product development, marketing and sales, I would be a lot more effective, not just in innovating, but also then in marketing and selling. So have you seen companies scale up simply that stable thing which you said that jobs don't change that much, the unmet needs don't change that much, or maybe unmet needs change, but the jobs that the customers are trying to get done don't change that much. So it would make a lot of sense if I had across my organization a shared language and a shared understanding of those jobs and maybe even the unmet needs, I could be a lot more effective. So are you seeing organizations kind of scaling that part of innovation, you know, sharing a language to have a good understanding across the silos of those of those jobs and the unmet needs?

Oh yeah, absolutely. I mean, we see our tool use as a transformational tool as well as a strategy tool for the reasons you describe. And the way I think about it is like this. Most companies, they're all well motivated. In other words, everyone on the team is trying to create solutions that address unmet needs, but they all have a different view of what the needs are and which are unmet and so on. And so what we try to do is to take an organization from the point where nobody really knows all the needs to a place where everyone on the team understands all the customers needs and which are unmet. And as you can imagine, that would be very transformational. So now they're all on the same page. Everyone is trying to come up with solutions that address some of the needs. It's just that they're all thinking about it very differently. So if you can bring that common language and the data model, and I'll describe that in a second, then you're really helping to transform the organization. Now when I say the data model, when we do our work, we do qualitative work that defines the job and breaks it down into its component parts and results in a complete set of outcome statements. So there may be 150 different outcome statements that define success from getting the job done. Then we quantify those out in the Marketplace with maybe 600 or 1,000 people to figure out which needs are important and I'm satisfied. And then we do the segmentation as I described. When we have all that data, we put it in Excel spreadsheets that our clients can use for years to make ongoing decisions about value propositions or product improvement or new product creation or MA decisions. It's a whole variety of things because you're onto it, right? If everyone can agree on where the opportunities exist in the marketplace, then the organization can go pursue them in a more systematic fashion. We can have many of our clients use this data model as a onboarding process for new employees. So when they're teaching the new employees what they do, they show them. Here's what we're trying to do. We're trying to create value for customers on all these different dimensions. And that's our goal. And because that's a stable target, that's something that that employee and that team and that organization is going to be doing for years to come. So we believe in data, right? But it has to be the right data. There's a lot of discussion out there about there's so much data, maybe we should just ignore all of it and go with our instincts. We clearly don't believe that. The key is if you had the perfect data, you can make the right decisions all the time. Our goal is to always have that right data. And we think that the job structure and the outcomes and everything I've described thus far is getting us down that right track.

So I just coming out of a meeting with CEO of a Fortune 200 company, let's say I'm an innovation executive, maybe the CTO or the cio, Chief Innovation Officer. And I want to kind of pitch these ideas around outcome driven innovation jobs to be done to my CEO. Is that the right level or should I not even care about what the CEO thinks? And if yes, how would I do that in the most pragmatic way to get the CEO's attention?

It's a great question. We often work at a corporate level with people in charge of innovation, if you will. And it could be the cio, it could be someone that's Chief Innovation Officer as opposed to Chief Information Officer as well. And it's interesting because what we see in most of those organizations, they're not, well, Funded as they should be for pushing innovation. And they don't have control of the business units either. So we often see that the business units make the ultimate decision as to what process and methods they're going to use to create value in the organization. So we have a couple of different approaches, the top down and the bottom up. But the top down approach involves having the corporate team fund the initial education for the business units. So for example, there might be a business unit that has a certain product that is struggling a little bit in the market. So we may pick that business unit first. And they would fund a workshop where we would describe our approach and take the team through the journey where we have customers there for a day and define what the job is, to find a job map, define a set of outcomes and show the business unit that there's really a different way to think about their market. And typically when they see that, they're excited about it and then they take it to the next step, which is to fund the quantification of the needs, to figure out where the opportunities lie and then use that information to build a strategy. So that's a nice way for the corporate team to seed, if you will, the concept across business units. And so we've had success using that approach. But then there's the bottom up approach as well, where you have the business units who know they need help in a certain area, who, who engage in using ODI and jobs be done to address a very specific problem. And when they have success using the approach, then of course others hear about it and begin to use the approach as well. And it kind of gets adopted by word of mouth, never really having approval at a corporate level. So we've seen it go in both directions and ideally it would happen from both directions at the same time. Hopefully that answers your question.

Yeah, one of the things that I'd be interested in, let's take, we took that kind of top level. Now let's think about the teams that start doing this. So they might have some assumptions around what the unmet needs are, but now they get serious with testing these assumptions or even upfront trying to figure out what the unmet needs are of the customers. What are some of the biggest mistakes that teams that start with outcome driven innovation, teams that start with the jobs to be done concept. What are some of the three, maybe three biggest mistakes that teams should avoid when they get excited about this approach and they start doing it?

Well, I would say that the first one is getting confused between the core functional job that the customer's Hiring the product for and the purchase job. I see a lot written out there in the job space that fails to distinguish between those effectively and even focuses more on the purchase job. Of course, products have to be purchased. They have to be installed and set up and cleaned and maintained and disposed of and so on. We call all that consumption chain jobs. They're all part of the product life cycle, but none of them really describe the job that the person's hiring the product for. And that's the core functional job. So I'd say making sure that you're focused on the core functional job and creating a job map and understanding the needs around that is really where you get the information that you need to be successful in the marketplace. Studying the purchase job will help you maybe make the purchase process better, so it's easier for people to research and evaluate and buy your product, which can be important as well. But it doesn't help the product. It doesn't help you create a product that will get the job done better. So I think that's certainly one area. I'd say the second piece that people struggle with is outcome gathering. And it's an interesting concept because what we're doing here, we're trying to define the metrics that people use to measure success and value in getting a job done. And it's more of a listening exercise than anything else. So customers are talking the way they're going to talk anyway. They could be talking about solutions, they could be talking about problems. They're going to give you some story that they want to tell you to describe what they think their need is. And what we're seeking in that conversation is the metric they're using to measure value. And hearing that and be able to hear through all the noise to pull that nugget out is really the key to success. So as an example, you know, interviewing farmers, for example, we're trying to grow a crop as a job. They may say that, you know, they plant all these seeds on the same day, and then a few days later, some of the crops start to germinate and others don't, and then they have to start watering the crops at a different pace and they have to fertilize them differently, and it becomes pretty complicated. So that's an interesting story. So what do we take from that? Well, what they're telling us is that they want to minimize the likelihood that the seeds don't germinate at the same time. That's the metric, right? And that metric is measurable and controllable in design. Of seed product, and it's the metric they're using to measure success and value when getting the job done. So being able to hear that through the noise, I think is. Is really critical. And it just takes a trained ear, right, just to get past all the solutions and all the other information that's being put at you and just pull out that nugget. And if there's one other piece, I'd say the quantitative research, too. A lot of Jobs approaches don't use quantitative research, they just go down the qualitative path, which may give you some insight into what the needs are. But without quantitative data, it's really risky to move forward thinking that you know exactly what the unmet needs are and that you've discovered segments of customers with different unmet needs. Now, if you could do that without quantitative data, that would be pretty amazing, but we don't think that's easy to do or even maybe possible. So trying to work your way through the process, avoiding the use of quantitative data can get you in trouble.

Yeah, so I really like that, in particular, the, you know, the active listening and hearing through the noise. Right. What are those messages? How do customers really measure success and failure? But sometimes you have people pushing back and say, yeah, yeah, that's all good and fine and data and blah, blah, blah, but, you know, then they say, Steve Jobs never, you know, talked to customers or tested his ideas. How do you respond to that?

Yeah, I've heard that a million times, of course. But I'll give you another insight into odi. We believe that we've modeled Steve Jobs brain using odi. Steve Jobs, excellent. Steve Jobs had the uncanny ability to understand the core job the customer is trying to get done. And he had the ability to understand that there were consumption chain jobs that people had to buy the product and set it up and install it and interface with it and upgrade it and maintain it. And it's as if he went through that checklist and got every one of those consumption chain jobs done perfectly, got the core jobs done perfectly. And did he go to customers to get the solution? Of course not. Customers aren't engineers and scientists and they don't know what's possible. But he did understand customers at a very intimate level. And he didn't do traditional research, and nor do we. We don't consider ODI traditional research. But he understood very clearly how people measure success and value in getting a job done. And as a result, he was extremely successful. And there's one other inventor, Edison, who used a very similar approach. They really studied the problem before putting solutions together that would get the job done. And I think those are two really good examples of people that could somehow mentally buck the system, the traditional system, and really shine as inventors in the marketplace. And our goal through all of this is to figure out how the heck did they do that and can we model their thinking. And we actually, like I said, we believe that we've modeled their thinking, the thinking of the top innovators in the space.

Excellent. I really like that analogy, that approach of modeling the brain, that image. Now, if you are a company doing incremental innovation, so you're improving an existing product, service or value proposition, and in a small way, I would assume you have a different approach or slightly different approach than when you're thinking about something radically new, some product that doesn't exist yet, you know, jobs, pains or gains, outcomes that the customer is maybe not used to. So how do those two, you know, how does that differ between incremental innovation and creating something completely new? Or is it exactly the same process?

Yeah, the good news is it's exactly the same process. So think of it like this, right? We're going to go break down the job that you're trying to help customers get done. We're going to understand where all the opportunities are, and we'll figure out if there's segments of customers with different unmet needs, then we create the market and product strategy. This is where you decide what you want to do. So you may already have products that are in the marketplace and you may find a segment of customers that have a handful of unmet needs. Well, if that's the case, then your incremental product improvement strategy is going to take is going to be to take that existing product and add features that address those additional five or so unmet needs. So that would be part of your strategy, but the same data model is going to tell you potentially that there's a whole other segment of highly underserved customers out there that are willing to pay more to get the job done significantly better, which suggests to us that there's room for new platform level solutions, something that hasn't been invented yet, that if it could get the job done a lot better, people would pay a lot more for it. And so if we discover a segment like that in the market, we would suggest to our clients that they pursue that with a new platform level solution, all from the same data set. And again, from that same data set, you may find that there's a part of the job that you just can't get done. But it's really important that can inform an M and A decision, and many of our clients use it exactly for that purpose. You may also discover that there's a couple of unmet needs that nobody can figure out how to address. So you could give that as the assignment to the RD team and say, if you can figure this out, come back and tell us, because that would be these needs are something that are really important and are satisfied currently. A solution would certainly be welcomed in the marketplace. So with this one data set, one project, if you will, you can form all these different decisions. So it can have immediate impact with products that already exist. It can form brand new product solutions, value propositions, and so on.

So that makes a lot of sense. What if I'm not even sure yet which customer segments I'm going into new area and as a company I don't have experience. Can I somehow do? Maybe first superficial understanding of the jobs of my customers and then if I see something, I go deeper just to navigate between potentially interesting segments. Have you ever seen that in companies you work with?

Sure, I have, but I want to use a little different word there just to make sure we're talking about the same thing. They're different markets, not segments. In other words, we often work with clients to say, okay, you know, we've, we're doing well in a lot of core markets, let's go enter new markets. And then they want to figure out, well, what new markets should we enter? Well, the way we define a market is as a group of people in a job they're trying to get done, Right? So now you got to choose between different groups of people in different jobs. So you may say, okay, do I want to get in the market with parents trying to help them pass on life lessons to children. That's one market. Or should we go into the market where we're targeting tradesmen helping them cut wood in a straight line? Or should we target pilots who are trying to fight a war fighter mission or whatever? Right. So there's literally thousands of different jobs that you could be choosing from. So the goal there is to discover the jobs that you think you might be interested in, then begin evaluating them to see which ones would be more exciting or more potentially profitable. To that end, we've created a tool set that I believe you can pull it down off of our homepage on our website. It's called a market selection tool, where we have 42, I think, different criteria that we use to decide what market is more attractive to you. And they get into a whole Variety of things. So, for example, would you rather work in a market where there's 3,000 job executors or 3 million? Would you rather work in a market where people get the job done once a year or five times a day? So you can start thinking through that and realize pretty quickly that there's certain markets from this type of criteria standpoint, that would be far more attractive to go after than others. So then we narrow down the list, and then of course, it comes down to what capabilities do you have and does it match your strategic intent? And, you know, all those internal kinds of questions that come into play as well. And so we go through that filtering exercise to figure out what are these top five markets that might be of interest. And once we've chosen those, then we go deep on each one to figure out exactly where the opportunities are and formulate a strategy for each.

So we've had a nice overview. We navigated through different topics, went, you know, hi, went deep. Now, if I'm somebody who wants to get started with this jobs approach, give me three tips of what are the three first things I should be doing.

So the first thing is to go to your customer and find out what job they're trying to get done. Don't speculate, don't ask what product is my job getting done. All those can get you in trouble. First tip, go out to customers and figure out what they think the job is that they're trying to get done. A quick example there. We worked with a herbicide manufacturer who was very convinced that the job that the customers were trying to get done was to kill weeds. And we go to the customer and they say, well, no, we're not trying to kill weeds. We're trying to grow crops. That's very different. And understanding from the customer's perspective what they're trying to achieve is going to send you down the right path. So that's the first thing. The second thing is create a job map. We have a good piece written in HBR back in 2008 that describes this. What we've learned is that all jobs follow a certain pathway, if you will. There's typically a planning step, and you have to gather inputs, organize them, execute the job, monitor the the execution, make modifications, and then conclude. And it really helps you. It helps guide you to think through all the steps that the customer is trying to get done. And having knowledge of that job in job map can be very, very informative. In fact, for startup in the software space where you're going to create a product that's going to get the whole job done. This can be extremely informative, just understanding all the aspects of the job. And so I'd say those are probably the two top things if you can get everyone in your organization agreed to agree on what job you're trying to help customers execute and have a common understanding of the job map and all the steps you're setting the right direction for your organization.

Okay. Now I had the treat to ask you questions about what I was interested in and some of the things that, you know, I was curious about your point of view on that. Now let's move to Kavi and he will select a couple of questions from the participants so they have the opportunity as well to pick your brain a little bit.

Sure.

Awesome. Thank you. I think one of the first ones that was coming through from a number of of people is the fail fast concept. You know, why does the fail fast scenario or the concept of failing fast scare so many companies?

Why does the failing fast concept scare companies? Well, I think it's because it should. Why should you want to fail fast? Right. The goal again, the failing fast concept, I think can lead you down a path where you never succeed. That's the problem with it. You could keep failing fast and guessing and guessing and trying to get it right and trying to get it right. But you may run out of money before you get it right. And that happens all too frequently. So I think that's. That's something people are trying to avoid. And as mentioned up front, what you want to do, the reason people are failing fast is because they think they can't learn all the needed inputs up front in the process. So they learn them as they go and they make mistakes and they spend money and waste money. What they need to really understand is that you can have this information up front. You can know what the job is and what the metrics people are going to use to measure value. And you can't figure out what needs are unmet and you can design a solution to specifically address them. It's actually possible.

So let's kind of stay on that topic for a little bit. I know one of the ones that you and Alex talk about a lot is the concept of ideas inside companies. Why do you think there's no value in developing products via the ideas that might come up or exist inside a company?

We work with a lot of companies that have ideas database. As I mentioned, there's really two inputs into the innovation process. The ideas, the solutions, and the unmet needs. What we see in most of our Clients with most of our clients is that they don't suffer from a lack of ideas. They typically have thousands of ideas. Many of our clients have ideas database idea databases with tens of thousands of ideas in them. So the problem isn't that there's too few ideas. The problem is they're not sure which ideas will create the most value in the marketplace. So, you know, I like using my Bosch circular saw example for this. And once we presented the Bosch circular saw team with the idea that there was a segment out there that had 14 unmet needs because they struggled to make long cuts, angle cuts, they came up with a solution and conceptualized the new CS20 circle song in just three hours. And the reason they did that, like they said, we've had all these ideas before, but the problem is we've had tens of thousands of ideas. We just didn't know that Those were the 14 features that we had to conceptualize to create a winning product. And that's what we're trying to avoid. So having an ideas database is nice, but you got to match it up against the problem. And what we work heavily on is the problems definition side of the equation. And I think that most companies spend way too much time on the solution side and wait too little time on the need side to really enable them to effectively solve the innovation equation.

Let's talk a bit about the kind of the move from testing to implementation. What is the rice right time for these teams to go from testing implementation. How will they know that they can move into a more kind of execution based process?

So that's a great question. I think separating innovation or the innovation process from the development process. So the goal of the innovation process is to conceptualize the solution that you want to put into development. So everything I mentioned so far pertains to that process. So you can figure out what are the unmet needs and segments of customers with unmet needs and so on and conceptualize a solution and put it into development. Now when development begins, of course then you're going to start making trade off decisions on the way you design your product. You may not have all the information you need from the marketing team, the product planning team to help you make those trade off decisions. If you don't have that information, then going out to customers to get input as you go on the design makes great sense, but you're not up there with the customers trying to define what the product does. That's been done as part of the innovation process. So I think drawing that distinction is very important because we have A very different set of tools that we use to help designers develop than we do to have product planners conceptualize the product to begin with. They're two very distinct problems.

We often talk about a lot of these stuff in the perspective of tech companies. What are some real world examples that you've had, Tony, of testing before building for non tech companies?

Sure. A lot of our clients are non tech companies. The process is still the same, right. Whether you're high tech, low tech, you're still trying to create a product or service that helps customers get a job done better and, or cheaper. So it's the same exact approach. There's just really no difference.

Let me jump in with, let me jump in with a quick question. One of the things that I hear quite often when people try to promote these ideas or try to sell them internally is that some senior leaders will say, yeah, but we do all this, we talk to our customers, we know the needs of our customers. How do you respond to that?

Yeah, you know, I think many of the organizations that we work with collectively have good insight into what their customers needs are. But there's no one person that knows all the needs and there's no agreement on what all the needs are and which are unmet. I think that's where the breakdown comes into play because people, you know, the marketing teams out talking to customers, developers might be as well, they're getting lots of customer input. So yeah, they're right, they're talking, talking to customers, but they don't even agree on what a need is. And if they can't agree on what a need is, they can't agree on what the needs are which are unmet. If there's segments of customers with different unmet needs and without that agreement, it's going to be really hard to gain agreement from the team as to what to go do to create a product that will get the job done better. And that's really where the issue lies.

So it really sounds to me like this is not just a tool or process problem. It's really about redesigning the organization. Like, how do you, how do you get organizations to put together their teams in a different way in order to apply these techniques that, you know, seem to be pretty proven now. Is that a fair assumption?

Sure, yeah, that's exactly what we do. You know, we, we even talk about this as a, as a team transformation. Right. Because what they're getting to do is for the very first time, they're going to agree in the end on what a need is, what the needs are. Which are unmet, and if there's segments of customers with different unmet needs. And in most organizations, they've never had that agreement before. And you can imagine what happens when they do. Right. If they're all on board with that new type of customer insight, they can become much more productive in creating value and delivering value to their customers.

So, you know, you've been doing this for quite a while. Do you see some change in, you know, the adoption of this or frame the question differently? Are there more companies that are interested in doing this now and are more companies adopting this than ever before? It's, you know, speed of innovation has changed. The ferocity of competition has changed, changed. Has this had an impact on, you know, how much, how aware companies are of these new tools and techniques to reorganize their innovation processes?

Yeah, well, it's definitely changed. You know, I would say 10 years ago, it was more rare that we would hear, you know, that the company has used ODI or Jobs on their own and, you know, tried it and so on. That I'd say most of the companies that talk to us today have studied the approach, have tried the approach, like the thinking, and are ready to move forward. And I think there's a couple of reasons for that. Of course, the approach makes great sense and it works. And I think the other reason is companies have tried all the other shortcuts. They've tried to do this without quantitative work. A lot of our clients are the top companies in the world. They're trying to get it right, and they've come to recognize that the traditional methods don't work as well and that this offers hope to get it done right more efficiently. And of course, the other thing that's happened with Clay Christensen's book coming out last October, that has really caused a spike in the job space as well. So all that's again contributed to a moment here where the thinking, the theory, is becoming much more popular and scrutinized and used. And it's a great time.

So Kavi has one more question from the participants I think is really interesting because it's about how ODI and JOBS relates to other tools in particular. So, Tavi, if we can go with this as our last question.

Sure. So, Tony, it's kind of asking how does ODI and its first steps complement or in some ways contrast the value proposition canvas and the business model canvas?

Yeah, great question. To your credit, we love the canvas. We often use them in our engagements as well, and we use them as the canvas that portrays what the client has to do. But ODI and JOBS inform, as you guys, I'm sure are well aware, informs many parts of the canvas. So the canvas really acts as a very nice tool to bring it all together and to tell a story. And it's very useful from that perspective, especially like the segmentation piece. This is where I think the ODI approach really shines. And trying to figure out what is the segment that we're going after. The way most companies would define a segment might be a demographic or that kind of thing, but we can really specify where the outcome based segment exists in the marketplace. I'll just give you a quick example there. In the dental space, tooth restoration, for example, dentists are performing tooth restorations all the time. But what we discovered is that they're very satisfied with the solutions that exist today when they're using them on patients that have healthy gums and require small fillings. But when they're using that same set of tools on patients that have unhealthy gums and require larger fillings, they're very unsatisfied. And the reason is when they have unhealthy gums, the gums tend to bleed more. It makes visualization much more difficult. It makes it much harder to keep the area dry and harder to contour and, and shape a larger filling under those conditions. So we would consider that a segment, right? It's this situation in which they're more underserved in getting the job done. So that's how we define that and put it in the canvas. And of course from there it makes a lot easier to define what the value proposition is too. Right? Because the target's so clear, the problem becomes much more clear. And, and I think tying it all together canvas really tells a great story.

I like that approach of the storytelling. And just in the workshop I did for this large corporation yesterday, it was one of the things that we discussed a lot, right? That's the underestimated part, that we might figure out the jobs pains and gains and come up with good solutions. But when we have to sell this in quotes internally to the internal stakeholders, the adoption change internally, we need to tell good stories, right? So how we package this is actually a pretty powerful, powerful thing. Now I'm going to just ask one more question. Since we have you on the line, we have this great opportunity. I'm curious, you gave a really nice overview of different examples from different industries. Are you seeing more traction, more adoption in some industries? That's the first question. And the second one is which I can imagine the answer. But are there some Industries where this is a lot harder to do.

Sure. So I think we've had traction more in the life sciences market than any other market over the years, and that still tends to be true. And I think that's the case because in life sciences, medical devices and so on, you can't get it wrong. Right. There's a very lengthy product life cycle and approval, regulatory approval process that if you get your product wrong, you're going to be out of the market. So I think companies like that are more willing to spend the time up front to find the problem correctly and get it right. So in situations like that where people can't afford to be wrong, or there's a longer product life cycle, that's typically where we see the greatest adoption for the process.

Thanks so much, Tony.

Just the last question, sorry, Kavi, and then I'll let you wrap it up. Is there areas where this is a lot harder to adopt? Is the interesting answer that actually where some people would assume this is harder to do in life sciences, you know, heavily regulated, this is even more adopted than elsewhere. Are there some areas where you'd say it's pretty tough to do or the obstacles are a bit more important? And then, Kavi, I'll hand over to you to wrap it up.

Sure. So, you know, the medical space, of course, is hard to do, but it's straightforward. I'd say that from a client perspective, clients tell us or perceive that it's hard to do when they are like a component manufacturer, you know, well, up in the supply chain, selling a part that goes into a part that goes into an OEM product, for example, and that causes complexity. Not that it can't be handled, just it's, it's more unconventional. So, for example, you know, we've worked with Rome Haas, we've with their chemical department, who makes paint, chemicals that go into paints. So you could say, well, who's the customer? Well, the manufacturer of the paints would be a customer. And that's the most obvious customer because that's who they sell to. But what if Rome Haas had the knowledge of what are the underserved outcomes of the end user? What are the outcomes of the installer, the painter? What are the outcomes of the architect who's specifying what products to go pursue? Would those insights enable them to create a better product that could be created and manufactured? And the answer, of course, is yes. Right. But companies way upstream often tend to be a bit hesitant to go past their typical customer downstream into those other areas to gather those learnings. So it's not as if it can't be done. And Rome Haas went off and did that. But it's uncomfortable. It seems like an uncomfortable place to go. It's going in a new area that hasn't been explored before by many companies. But it's a great opportunity because all those downstream companies are struggling with the same thing. Right. They're not sure what a need is and what the needs are and which are unmet. So if you can bring all that added value as a supplier of parts all downstream, you can really differentiate yourself in the marketplace.

Okay, I think that is the last question. I don't think Alex is going to jump in. Again, Tony, thank you so much for taking part in this session. Alex and Holger as well, thank you for hosting and visualizing the session. To all the audience members that are paying attention at the moment, we will have a recording available of the session and it will come directly to your inbox in about 24 to 48 hours. That is all the time that we have for this session. Again, Tony, thank you so much to all of you out there in the world. Have a great evening or have a great day, if you're just starting your day. And we are now signing off. Thank you very much, guys.

Thank you, Tony.

My pleasure. Thank you, Alex.