Transcription
Hello and welcome to another episode of the Product Thinking podcast. Joining us today is Tony Elwick, the founder and CEO of Strategen and a visionary in the fields of innovation and product development. Known as a pioneer of the Jobs to Be Done Theory and inventor of Outcome Driven Innovation (ODI), Tony has transformed how companies understand and meet customer needs. His methodologies, which have been widely adopted by leading companies like Microsoft and Johnson & Johnson, aim to take the guesswork out of product development and enable more predictable success.
With a career that began at IBM, where he witnessed firsthand the challenges of product failure, Tony has dedicated himself to reframing innovation as a science. Today, he'll share insights on turning failures into learning moments, the journey to creating ODI, and his perspective on the future of innovation and customer-centric product strategy.
But before we dive into it with Tony, it's time for Dear Melissa. This is a segment of the show where you can ask me any of your burning product management questions. Go to dearmelissa.com and let me know what they are.
Here's this week's question:
Dear Melissa, my question relates to the transition many companies, teams, and individuals face these days going from output to outcome. However, my organization will still do classic projects, and only a couple of departments will be going full product. This seems a bit counterintuitive to me. How can we make the transition and tap into the potential of the product operating model if we know from the start that not everyone will be following along?
This is pretty common, where a lot of companies might start with one part of the organization and say, "We're going to move this to a product operating model," but other parts of the organization might still be working in project mode. This shift is always a learning journey, and it usually takes many years, but it's going to be difficult along the way.
What you'll probably observe is that within your team, you'll be able to work in a product operating model, meaning you'll be able to talk to customers, talk about metrics, and try to figure out what's the right thing to build. What's going to be hard is getting leadership aligned. Leadership is usually going to be thinking about project management style, like, "We do this project and we move on. Why should we fund this stuff for longer instead of the product operating model?"
What you need to do is get really good at communicating where your efforts are, what you're trying to prove here, why it's the most important thing you could be doing, and how the product will be evolving over time. It's not just one and done. You need to invest in and actually grow what works.
Here, it's important to explain to leadership that when you think about products, we don't want to treat them just like projects. We'll be spinning up many different products that might solve the same problem. Instead, we can lower our footprint of software and our cost if we think about our products as expandable pieces of software that solve the needs of many, so that we get leverage from it.
You may want to start there and align on what the concept is of what a product is, why you're managing a product, and why you should see it over time. It's not going to go away; it's going to keep solving problems, and you want to make sure that's strategic too.
How they see that's connected back to the company strategy and that it will help it grow is crucial. When you're in this kind of mode, a lot of it comes down to communication. Unfortunately, it just takes more work to communicate up, to explain why you work the way you do, to explain, "Hey, we do discovery processes. We're not going to just dive into this. It's not going to be managed by specific hard dates."
You need to get away from some of the misconceptions with the project. Maybe you talk about how your teams are product teams and not project teams. Maybe you get in front of some of those issues ahead of time to make sure that there's clarity. That's what I would advise for, but there will be growing pains along the way.
Let's say that as an organization, it's going to be messy for a while. But I've seen many organizations go through this transition. Just a couple of teams will start with product, they'll spin it up, and try to see what's going on. You can still make your team, if it's doing product, a premier team and an example of what success looks like.
That's what I would focus on: how do I show that by this way of working, we're going to be more successful? We're going to create better products that people love, and then I'm going to tell my success stories to the company so they get really excited about it, and more people want to move into a product operating model.
The other thing to acknowledge here too is that not everything needs to be a product. There are some things that are just not productized. If we're talking about software products that you sell to customers, sure, we want to move those teams into a product operating model, but not everything across an organization needs to be a product.
So let's be very clear about what is a good candidate and what is not, like what team should be operating in product and what team should not be operating in product. You want to make sure that you're setting a good example for the rest of the organization so that it'll be easier for them to jump on board.
Then you can tackle the really hard problems, like budgeting, strategy, deployment, alignment across organizations, and then cross-functional working relationships. I hope that helps, and good luck on that journey.
Now it's time to go talk to Tony.
Welcome to the podcast, Tony. It's great to have you here.
Melissa, thanks for the invite. I appreciate it. I have been a long-time follower of you, Tony, for a long time in your Strategen journey. Before you started Strategen, tell me a little bit about your career and what led you to wanting to go into this type of work.
Yeah, it's a good story because I experienced one of the most humiliating product failures of the decade back then. I was working for IBM at the time, in their PC division, and working on a product called the PC Jr. It was supposed to change the way people did home computing. It was supposed to beat Apple. It was a huge endeavor. I had invested about a billion dollars in the project, and instead of it being successful, the very day after it was introduced, the headlines in the Wall Street Journal read, "The PC Jr. is a flop."
Of course, we didn't believe it, but they were right; it was a flop. It took about a year for us to come to grips with that reality, and it cost a tremendous amount of money. This was my first experience with a product, and I thought products, especially coming from a company like IBM, of course, it was going to be successful.
But as I started studying this, I wondered how did IBM fail so miserably? Not just IBM, but many companies have big failures like that. The funny thing is, it's not just back then in the 1980s; it's still happening today. This has been an issue for years, and it got me very interested in innovation as a process.
I really wondered how they knew that this was a flop the very day after we introduced it. They were using some criteria to judge the value of the product that we didn't know about. Otherwise, we would have built the product to meet that criteria and would have been successful.
It got me thinking about whether it's possible to know way in advance how people are going to measure the value of your product. I didn't have the answer for that, but that was what I set out to do. I spent my last five or six years at IBM trying various methods of innovation practice. Back then, it was QFD, House of Quality, Voice of Customer, and Conjoint Analysis. A few things like that were coming together, but I realized quickly there was no real process for innovation and set out to create one.
So when you were looking back at all of these things at IBM and how people did innovation, what did you do to come up with what you call Outcome Driven Innovation?
As I was looking at different ways to innovate, I realized there was no process there. But it occurred to me that Levitt gave us a nice hint. He said, "People don't want the quarter-inch drill; they want the quarter-inch hole." Then the engineer in me took over and said, "Hey, I have an idea. If we study the process of creating a quarter-inch hole, we could treat it like we do in a manufacturing line."
You study the manufacturing process, you try to figure out what we have to measure and control to produce a predictable output. We automate things, and we do statistical process control to remove variation from the process. We do Six Sigma to eliminate defects from the process. That was my early career at IBM.
I thought if we study the job of creating the quarter-inch hole as a process, we can apply all that same thinking and figure out how to get the job done better, faster, more predictably, and with higher output throughput. So that was the beginning of it. I thought, will people be able to tell us how they measure success? It turns out they do, and we've worked on that language over the years.
We call them the customers' desired outcomes. We all use them. For example, as you're preparing a meal, you think about things like, maybe you overcook the meal, and you'd say, "I don't want to do that." Right? I'd really like to minimize the likelihood of overcooking a meal. Or, "God, this is cooking unevenly." No, I'd like to minimize the likelihood of cooking food unevenly.
Minimize the time it takes to prep the food. Minimize the likelihood of creating the wrong portions. There'd be a whole bunch of metrics that you'd consider to try to prepare the meal perfectly. So the thought was we can go capture those inputs, figure out what the needs are in a given market, and go from there to figure out which are unmet, to what degree, and why.
There are segments of people with different unmet needs, and then build the strategy around creating solutions that get the job done better. So I thought of it as a flash, and I didn't know if it was going to work. So that was the next step: to go try it, and it turns out it works quite nicely, and we've been perfecting it ever since.
What did you do in the early days to test it out and see how it was working in organizations?
I practiced at IBM. They were great to work with, like an internal consultant. I did projects around the globe. Actually, I spent time in Australia for a month and a half on assignment applying the approach to a business unit there, Japan, France, and the U.S. itself.
So I had about two years of experience just getting it ready, and then I decided in 1991 to start my own business. I started advertising, getting some clients set up, and I left IBM and started the practice. The very first project that I executed on was with CTIS Corporation. They were on their last leg in terms of their enoplastic balloon product line. They had 1% market share, and they needed a win.
We tried it out, and one thing was very encouraging. When I was in there interviewing with them to take on this work, there were some nurses in the room next door. They said, "Would you come just apply this process next door? Just show us how this works. Go talk to those nurses and get these inputs that you're talking about."
I said, "Okay, what product are we talking about?" They said, "The sheath introducer." Now, I didn't know what a sheath introducer was, but it didn't stop me. I went in and started asking them about what they were trying to achieve with this sheath introducer, and they told me.
Then we started getting into a discussion about what they were trying to achieve, the very first step of using it, what they were trying to avoid. I went down this path and started writing down these outcome statements. At the end of the session, which maybe took 10 minutes, I collected maybe 10 or 15 outcome statements. They said, "You should hire that guy. He knows your market better than you do."
So I got the assignment. The project turned out amazingly well. They introduced 19 new inop plasty building products, and a year and a half later, they were all number one or two in the market. Their market share went to over 20%. They also discovered a huge unmet need in the market using the process, which was to minimize the likelihood of recent blockage.
It was off the chart; it was a very important, poorly underserved outcome. They said, "We have a product that could probably address that. We're working on it in the lab with 30 other things." We said, "You should triple down your resources and be first to market with that product," which they did, and they succeeded. That product was the heart stent, and that became a billion-dollar business in less than two years. Their stock went from $8 to $108.
It was just a great all-around story, very encouraging. So I could see the process working. I knew how to make it work. Then the question was, can we make it work in all industries or more industries other than just the medical space? I spent the first 10 years, from 1991 until about 2001, pretty much testing this in different companies as a lone practitioner.
Then in 2002, I was published in the Harvard Business Review that case study that featured the quarter story. From then on, I got way too busy and had to start a company and learn how to run and manage a consulting firm. So it's always funny how that ends up. I'm too busy now; I gotta be busier trying to run a company too. But it's a testament that this works and that it's helping people.
When you talk about Outcome Driven Innovation, what I really love about it too is how you contrast it with other types of processes like Agile development processes, design thinking. What have you observed coming into companies and helping them about how the misconceptions around when these different processes are needed hold them back, and where do you see ODI fitting in?
I think the key factor that contributes to confusion is the overlap of the innovation process and the development process. I call the innovation process the front end of innovation, which is really everything before development. The output of that process should be a product concept that, with a high degree of certainty, is going to win in the market before you start developing it. That's the ideal goal, right?
So you shouldn't start developing the PC Jr. and watch your fail at the end. You should know right up front if it's going to win or lose, and don't do it. Separating them out is important. Most companies think of them as one and the same. They think the innovation process starts with the idea and stops at product launch.
I'm just separating the front end of innovation, which is coming up with the product concept, from developing the product. If you want to develop the product, you want to make sure that the product is the product that's going to win in the market. That's what ODI does on the front end. That's when Agile kicks in in development.
So use Agile techniques to develop. The way I like thinking about it is ODI makes Agile more agile because you're not iterating on what the product does while you're creating it; you're only iterating on the product design so that it will perform as nicely as possible.
Separating those two out makes great sense, and I view ODI plus Agile as the great combination for the front end of innovation and development. Then there are other techniques like Lean Startup, for example, that ask you to hypothesize the market, the customer needs, and the solution all at once. That's intertwining everything, right? You're trying to solve a very complex equation.
What we do instead is we first define what market we want to go after, then we define the unmet needs in the market, and then we come up with the solutions that best address those unmet needs. So we solve the equation by really setting up constants in the equation. The market becomes a constant, then the needs become a constant, and then you can come up with the solutions that address them.
It's like solving a simultaneous algebraic equation, right? You solve for the constants in the equation; you can't solve for all the variables at once. We discount the Lean Startup methodology because it causes you to iterate incessantly, and you may never get out of that loop.
There are other tools like design thinking, but design thinking really isn't a process; it is a set of tools that can be used throughout the development process. That's how it was initiated. Now, could you also use some of those tools for the innovation process? Yes, you can, and some people have confused the two again and said design thinking is all about innovation and development.
But really, it's a great set of tools for the development process, but it's not a great set of tools for the innovation process. It doesn't produce a product concept that you know will win in the market before development begins, but ODI does. That's the difference.
What I really like about ODI too is what you just said: we start with that market piece. Where I see a lot of people mess up, I think, when it comes to innovation, especially people in startups, is they go into markets or they're trying to solve a problem in an area they don't know a lot about.
I've seen a lot of, even when I was teaching at HBS, I saw a lot of students be like, "I'm going to go build something to do X in this market." And I was like, "Do you know anything about that market?" And they're like, "No, but it's something I want to go after. There's a problem I want to solve there."
They're not really looking at the landscape or what they should be tackling or if they want to really tackle that market without identifying it. I think that's really interesting about ODI that you start there. I've seen that common mistake. Why do you suggest starting at the market for most companies or for most startups?
We always start at the market because we need to know who our customer is that we're trying to create value for. That's the first question: who are we trying to create value for? Then the second question is, what job are they trying to get done?
So it could be interventional cardiologists trying to restore blood flow to an artery. We need to know who we're targeting and what job they're trying to get done. Notice I'm saying it like that too. I'm not saying what job the product gets done; I'm targeting a group of people, and they're trying to get a job done.
What we see is most product concepts, especially in startups, get a tiny piece of the actual customer's job done. You're not going to hit a home run; you're a feature on a platform, and you're never going to take over the world by pursuing just a feature on a platform.
You want to figure out what is the entire job they're trying to get done and work over the years to create an end-to-end solution that gets the entire job done. Unless you know what that entire job is, it's going to be very hard to figure it out. You'll eventually get there, and markets evolve in that way through guesswork.
But if you know the endgame right up front, you know the entire job, you can lay out a plan to get the entire job done in the most efficient manner, which is what we propose, and that's the most efficient path to growth.
In the ODI model, you were talking about the process. You were talking a little bit about how you don't do the actual building, let's say, and that's more for the development process. When we look at startups as well, what are the steps to ODI, and what are the types of activities that people should be doing during those steps?
Yeah, that's a great question. So the first step is to define the market, to find the group of people you're trying to create value for and the job they're trying to get done. Now, the way we do that is we talk to the customer. That's why it's important to know the group of people you're trying to create value for because you've got to get out and talk to them and get from them their view of what they're trying to accomplish.
So that becomes your market definition. The second step is to understand the customer needs. Now we're going to define needs as the metrics people use to measure success when getting the job done. Minimize the likelihood of overcooking the food or minimize the likelihood of cooking it unevenly.
There's typically anywhere from 75 to 125 of these metrics for any given market, and we capture those by again talking to customers, job executors, as we call them. They have experience executing the job, right? So they've, like in the case of interventional cardiologists trying to restore blood flow in an artery, they've tried to do that hundreds of times.
As you're asking them about these need statements, they can tell you, "Oh, in this stage, I need to do this, then I need to do that, and I've got to watch out and avoid that, and I've got to eliminate that defect." They can go through and tell you all the metrics they're using to measure success.
We train people to think like this and to capture inputs in that manner. The outcome statements have a very specific structure, syntax, and format. We've learned over the years that they need to have that format in order to be useful statements from the beginning of the process to the end.
They're inputs that come from the customer, run through the organization, and they have to inform sales, marketing, development, and R&D. One set of statements that everyone can agree to. Most companies, like we poll all the time, we ask this question: is there agreement in your organization as to what a customer need is?
Ninety percent of product teams say no. We don't even agree on what a need is, never mind what the needs are and which needs are unmet. We can't even agree on what a need is. We've also polled 12 different experts in voice of customer years back, and we had 12 different definitions of what a need is.
So this has been an issue for years. Somebody has to decide what a need is, right? We look at it like, what should a need be? It should be an instruction that comes from a customer that tells you how to get the job done faster, more predictably, or without defects, which is the goal of getting the job done better.
So once we lay all this out, we can come up with this particular format and structure and be sure that we're getting inputs that are going to lead to success. So that's the second step, a very important step, obviously.
The third step is we want to figure out which needs are unmet and to what degree. There may be 10 of those 70 or 100 needs that are really important and poorly satisfied in the market today, and we want to discover which of those needs are.
So we do quantitative research. We'll put a survey together that will go out to hundreds of people, and we ask them to tell us the importance of these outcomes the last time they were getting the job done and how satisfied they were with their ability to achieve that outcome using whatever solution they were using.
We ask them what solution that is too, so we know the answer to that question. With that information, we can start doing our data analysis to figure out are there any needs that are unmet across the entire market? Are there needs that are unique to segments?
The fourth step in the process, as part of that analysis, is what we call outcome-based segmentation. We want to know are there segments of people with different unmet needs? In all the studies that we've done over the years, there are always segments of people with different unmet needs.
In other words, people don't agree on which needs are unmet. The best way to discover those segments is not by segmenting around demographics or psychographics, but segmenting around the unmet needs. Now, most companies can't do that because they don't even agree on what a need is or what the needs are, which needs are unmet.
But we've fixed all that, and now we can discover segments of people with different unmet needs. For example, when we helped Bosch enter the North American circular saw market, they were trying to compete with DeWalt and Makita. They wanted to come up with a solution, a premium brand that would get the job done better at the same price point.
To make that happen, we had to find opportunities to get the job done better. When we looked at the broad market, it looked like there were no opportunities. But when we segmented the market, we found a third of the population that had 14 unmet needs. They were more finished carpenters; they had to make more angle cuts, blade height adjustments, and they had 14 unmet needs that nobody else had.
So that became their target. They came up with a solution that satisfied those 14 unmet needs, and that was their bestselling circular saw in North America for about 10 years or so. So that's why the segmentation aspect is so critical because if you build for the average, you're targeting nobody, usually ineffectively.
Then the last step is to use all the information to come up with the product concept, which we do through ideation. In the case of Bosch again, when we presented those 14 unmet needs to the engineers, it took them three hours to come up with solutions to address all of them.
As they said, "It's not as if we hadn't had these ideas before. The problem is we've had all these ideas before and more. We've had thousands of ideas; we just didn't know that these were the 14 that were really going to create the most value for the customer."
It's all part of getting teams on the right path. The same path is the way I like thinking about it. They have to have the right direction so everyone's creating value for the customer in the most efficient manner, and everyone has to believe it.
These are the two key elements of our approach that have to come together for a company to be successful. They have to be heading in the right direction, and everyone has to be paddling in the same direction. To achieve both of those is the magic of the innovation process right there. If you can do that effectively, you're going to be successful.
When you think about these companies that are not agreeing on what a need is or what it means to them, what do you do to try to encourage them to align on what those needs are? How do you start that conversation or go through that work?
I love that question because we've just learned recently that the best way to do that is to ask them how they define needs. We do individual exercises; we may do workshops. It's fun, but everyone writes down how they think about a need.
Oh, is it a specification, a requirement, a pain, a gain, an exciter, a delighter, a value driver? I could go on. There are 30 terms that we hear that people use to state what a need is. Then if we go into saying, "Write a need statement right now," then everyone compares what they put up there, and they see that there is disagreement.
This proves to them that you don't agree on this basic thing. You're all here to come up with solutions that address unmet needs, and we can't even agree on what an unmet need is or what a need is. So that's the first step, and then offering the solution, of course, is the key.
Why is this a need? Because people buy products to get a job done, and if we can help them get it done better, they'll buy our product. Let's tie needs to statements that show how to get the job done better. It's that simple, right? The logic's there.
If we can get the team to follow that path, the funny thing is they don't all have to know how to do ODI and how to talk to customers. They just have to know that once they get that information, that's the information they should use to drive their product decisions when it comes to needs and outcomes.
I feel like everybody in every organization now is saying, "We're an outcome-driven organization. We got to be concentrating on outcomes." I feel a lot of organizations aren't doing it well or they're getting lost about what an outcome really means.
How do you tie needs back to outcomes? How do you make sure that you're actually writing good outcomes, focusing on the right outcomes, and tying that back to what those unmet needs are?
See, I don't like to use the word "needs." If I could eliminate the word "needs," I would. Outcomes are the needs. People are buying products to get a job done. That's the market. They go through steps along the way; that's what we call the job map.
Then they use these metrics to judge success when getting the job done. Those are their outcomes. Now, you could argue that all of those are needs at some level, but I don't even like to make that argument because it doesn't matter.
The point is just focus on the outcomes tied to getting the job done better, and that's going to help you create products that will get the job done better. Our vocabulary here is so important. We put a glossary of terms together that we like to use that shows how all these pieces fit together.
If you stay in that mindset, you can define adjacent markets differently, you can define segments differently, and they all make sense through that lens. Once you get that thinking in your head and that mindset shift, then it's really hard to see it any other way.
You talked a little bit too about how you have a very specific way of writing outcome statements. What have you found is required in a good outcome statement that makes sure it's in the right direction and useful?
Yeah, so it contains four pieces or elements. One is a direction of improvement, which is always "minimize." So it's going to be either minimize the time it takes to do something or minimize the likelihood of some bad thing happening.
So that's the second part; it's a metric, either time or likelihood. Now, years ago, we used many other metrics, but we've realized that these two really are the most useful in terms of describing what customers are trying to achieve because they either try to get something done faster, more predictably, or without defect.
Now, the faster is tied to time; the more predictably and without defects are tied to the likelihood of you doing something wrong when executing the job or the product doing something unpredictable when using the product. That's it.
Now we're going to talk about minimizing the time it takes to do something in some context. The third statement is the object of control. What are we trying to control in the process? Minimize the likelihood of overcooking the food, right? We're going to try to control the overcooking aspect.
Then the last part is a contextual clarifier, if it's needed. You can talk about what context you're referring to. An interventional cardiologist may want to say, "I want to make my way through a torturous vessel," or "minimize the likelihood of impacting the side vessel when I'm making my way through a torturous path," or something like that, supplying some context to the statement so you know the situation they're struggling with regarding that particular outcome.
So those are the four pieces. We've tested this back in the early 2000s with Microsoft. We worked with them on about 45 projects, and most of the surveys we would use different variations of statements to see what happened.
So we tested them, and we found that the structure that we use today is a structure that gives us the best insights, gives us the best discrimination, causes the least fatigue—all the key things that you look for when you're trying to create a good survey.
We often say the process has been battle-tested; it really has. We've worked with lots of very smart people from the best companies on Earth over the years who've helped us refine the process to make it even more effective.
When you're looking at ODI and for companies that maybe are not engaging with you but they're trying to learn ODI and bring it in, what are some common mistakes that you see them make or misconceptions they have about it?
I say the biggest misconception is they think it's going to be easy because it sounds easy, but in practice, it's not that easy. You need different people with different skill sets to execute the process. You need someone who can manage an entire project and even know how to frame it: who is our customer? What do we—how do we aim ODI at a market?
Just to think through that can be very challenging. We need someone that has to collect all the outcomes from customers. You need good qualitative research skills to make that happen. We need people to build surveys, collect data, run segmentation analyses, and others.
So we need good quantitative researchers, and then you need people that can pull the story together, read the data, understand what it means, and turn it into a strategy. It's not as if any one person in the organization can do all those things.
So having a team of people that can get it done and knowing the responsibilities and just being prepared for what it takes to get good at it—like you can read the book and see how logically it makes sense, but there are just a lot of little nuances in making it happen that should go through the learning curve.
So that's probably the biggest issue I'd say.
When you're thinking about who should be doing ODI too in organizations, I see this a lot in Agile transformations where people go like the leaders go, "Oh, this is like a responsibility of the team. I don't need to know this; just go do it." Then I'll set these goals up here.
Who should be involved in the ODI process from a leveling standpoint? We just went through roles, but are you like a VP of product overseeing this, or like a C-suite executive, or is this for like directors of product?
You should oversee a team of people. So it could be a business unit director who oversees a number of businesses. I see some companies will create a corporate team of ODI practitioners who get assigned to different business units. I've seen it done both ways effectively.
But what you shouldn't do is have all your product managers become experts at doing ODI. That's not right because they're not necessarily strategists and qualitative researchers and quantitative researchers and data analysts. Asking them to do that is really too much to ask.
So that's why we say set up a team. It could be under the head of the business unit; it could be a corporate team that gets used across business units. But think of it like that as opposed to teaching the product team, product managers, or even all the people on the product team.
They don't have to know how to do ODI; they should know what an outcome is. They should know what to do with those need statements once they see them at the end because they're going to use them in their workflows to make the same decisions they always make.
But now they're going to be focused on the customer's outcomes, not some irrelevant piece of information or misleading piece of information. So I think those are some of the important intricacies that come into play.
To me, a lot of what you're talking about feels like doing good research that informs our strategy of where to go, right? Through this process and then narrowing it down.
I've seen in organizations, especially at the director level, let's say, people who run a team of product managers who are working on more innovative types of products or net new things. I've seen them run effective ODI processes, but they've had to bring in other people, like you're talking about on the team, right?
Like they needed a—we'd call them like a product ops analyst type person to help with the data. They need the user researchers to go out and do that, and they're helping to oversee it and run it. Or even like the VPs building a little team underneath them to help figure out how to inform the strategy in product management.
I see a real lack, though, of the work that you're talking about, right? Like actually going out, doing the sifting, trying to point people in the right direction before we set the objective targets that we want to hit and then just dive into the product work.
Yeah, and this is what companies hire us to do because it is a unique skill set. It's specialized. We've been through a lot of iterations of the process. What we spent a lot of time on more recently is not making the process better because it's pretty good, but making it easier to install in a company.
If you think of it like that, with the advent of AI, it's interesting to see the possibilities of synthetic outcome-driven customers, for example, that could be created using the data I just described. But the front end could just be an interface where you could talk to this customer who has all this information about the market based on the ODI data that we feed it, plus other information that would be pertinent.
So there are a lot of fun possibilities here that we're thinking about working on to help get the job done even better.
That's really cool. I like this kind of trend of looking at AI in a lot of the innovation space these days too. I've heard some pushback from people talking about how AI is going to get rid of the need to do some of the stuff that we have been doing around these processes—testing, experimentation.
We talk about the cost to build things being faster, so people are saying, "Oh, you don't really need to test products. Maybe you don't need to do as much research. You just build something, throw it out there, and see if it works."
With all the work that you're doing, do you think that the progressions we're making in software development with the smarter AI features, the faster it is to build things, and the lower cost to build, do you think it's taking away some of the work that we need to do there, or do you think it's only making it more possible to do more of it?
The inefficient way to develop things is to guess and test and iterate. I mean, that's not efficient. If you can do it fast, is it cost-effective? It could be in software. Not all companies just develop software, though, and even software companies need services and sometimes more than that.
So it's not a good across-the-board philosophy to have. You're still guessing, right? The way I like thinking about this is, what are the chances of you randomly coming up with a solution that addresses the top 15 unmet needs in the market if you don't know what they are? It's zero. It's just not going to happen.
But what are the chances of you creating that solution if you know exactly what those 15 unmet needs are in priority order? The answer is about 86% because now you're just relying on your team to use their creativity to come up with solutions that address the needs that you know exist.
If you can do that, you're going to get the job done better and succeed in the market. So my question would be, why would you just do it that way? Who are you going to win? Companies like the medical space that have long product life cycles already know this, right?
A lot of technology firms know this as well. It's in the software space where they just think it's easier to guess and throw it out there and see what happens and get a response. Like I said, it may be cost-efficient, but you're still wasting your time, and you could still do it better by having the needs-first approach or outcome-driven approach as opposed to an ideas-first approach.
When you are looking at the advancement of technology, we talked a little bit about the AI stuff, but what are you excited about in the field of innovation, and how do you think it's changing?
It's changing rapidly. A few mega trends, if you will. You talk about these—the ability to go capture outcomes. People don't want to capture outcomes; they don't want to do the quantitative research. What they really want is a way to query customers to get answers to questions like, "Should we go copy this feature that a competitor just put out because it's so valuable to customers, and without it, we're going to lose market share?"
I would love to know the answer to that question. Right now, using ODI data, you can answer that question. So we just need to learn how to take that kind of command, turn it into the query that produces the answer.
Those are some of the things that we're taking a look at, and I think that's going to bring more predictability to the process. But behind that data or behind that query in that database, there's got to be good data, right? You still have to be following some good practices.
I think that ODI is really well-suited for AI application because it's built with a bunch of rules. It's a rules-based discipline, and so it's a natural fit for an AI application. I'm excited to see that evolve over time.
Tony, thank you so much for being on the podcast with us. If you want to learn more about you and Strategen, where can they go?
You can head right to our website at strat.com, or you could email me if you'd like at alwick@strat.com.
Awesome, and we will put those links in our show notes at the Product Thinking podcast.com. Thank you so much for listening to the Product Thinking podcast. We'll be back next Wednesday with another amazing guest.
In the meantime, if you have any questions for me, go to dearmelissa.com and let me know what they are. We'll see you next time.