Key Points
- Why the Needs-First approach of ODI and JTBD theory isn’t more widespread in the software industry
- The difference between Needs and Wants and how customers do know what they need
- How to incentivize organizations to have needs-oriented cultures
- The difference between jobs and desired outcomes
- How to define and structure a customer job, desired outcome
- The use of job maps to describe the full extent of what customers are trying to achieve
- The different use of the core functional job and the emotional one
- How to segment the market when using jobs and needs
- Can we start to have a job- and needs-based understanding for an existing product?
- How ODI and JTBD are different from the Kano model
Transcript
Daniel:
I am very happy to be talking today with Tony Ulwick. He’s a pioneer of jobs-to-be done theory, inventor of the Outcome-Driven Innovation Process, and founder of the innovation consulting firm, Strategyn. He’s also the author of the best-selling book “What Customers Want” and has published articles in a number of prestigious publications. Hey Tony, thanks for your time today.
Tony:
Daniel, my pleasure.
Daniel:
Perfect. Let’s jump right to it. The first question I had for you is although the job-to-be done mindset seems to be catching on, why do you think the Needs-First approach isn’t still completely widespread in the software industry?
Tony:
Well, I think the Needs-First approach isn’t really widespread in any industry, and particularly software. I say the reason in any industry is because I think people just generally have an inclination to think about solutions and they get very passionate about their ideas and solutions and they work hard to bring them to life. And this is all great motivation, but I just think that we just have a natural inclination, inclination as people to wanna focus on solutions. So there’s resistance to take the time and the discipline and everything that’s necessary in order to really get a great set of needs in place and figure out which are unmet and all that before you come up with ideas. It’s just, it’s easier to come up with ideas.
Daniel:
Right.
Tony:
And in the software space, it’s interesting because there’s really an agile mindset in place. And agile mindsets, it’s got a lot of good benefits associated with that, but it has some negatives too. And I think one of them is the fact that developers and product managers in the software space are anxious to build software and they just get started on it and they find it easier or maybe even faster to build it and test it than to really spend time up front to figure out what it should do. I think there’s a price for doing that of course, because you can keep testing and keep trying and keep pivoting and keep failing it fast but you may never get it right. So there is a downside to that and I think a lot of companies are beginning to recognize that.
Daniel:
Right. So that’s also a bit contradictory in the sense of our own expectations towards customers. 'Cause we often hear strong reactions against the notion of listening to customers along with some reference to Henry Ford or Steve Jobs in saying that, “Customers don’t know what they want.” However, for those that understand the difference between a need and a want, what kind of arguments can you give them so that they can sell the importance for this kind of approach within their organizations?
Tony:
Yeah that’s s great question. And your point related to Henry Ford and so on, people would say, if you went to customers and asked them how to improve the horse, they would just say, “I want a faster horse.” But of course people who say that are mixing the concept of needs with solutions. We think about innovation as a process of coming up with solutions that address unmet customer needs. So if you go to customers to ask them their needs and they say, “I want a faster horse,” which is a solution, you’re never really understanding their underlying needs. And this happens all the time and companies confuse needs with solutions. There’s a few true statements in there like, “Customers don’t know what they want.” Well they don’t know what solutions they want, but they do know what needs they have. I think that’s one of the key distinctions.
Like they didn’t know they needed a microwave oven, for example, but they did know they wanted to minimize the time it takes to prepare a meal and minimize the time it takes to clean up after a meal, minimize the likelihood of overcooking a meal. So they have these needs, they don’t know the microwave’s the right solution because they’re not the technologist and the scientist and materials experts. That’s what the company does. The company’s got to come up with the solution. So getting that straight and understanding that customers certainly do understand what their needs are, I think that one hurdle is a big barrier for companies to overcome. If you walk around thinking that “Customers just don’t know what they want, so we’re going to tell them what they want or we’re gonna come up with what we think they want and they’ll want it.” Maybe that worked in the past, but I think that is a pretty arrogant approach that is unlikely to work these days with competitors out there really… Some of them taking the time to understand the true customers’ needs.
Daniel:
Right. So my question here would be how can you try to incentivize and create this kind of culture in an organization? 'Cause sometimes we see a lot of organizations still insisting on their past behavior, on their past processes and trying to think inwards towards what kind of product they should be building.
Tony:
Sure. Well I think the real key is to provide them with the customers’ needs. It’s interesting because companies often say, “Innovation’s everyones responsibility,” which makes it sound like everyone’s responsible for understanding the customers’ needs in order to be innovative. But as you look around the organization, most companies could ask themselves this question, “Is there anyone in my company that knows all the customers’ needs?” And the answer is probably no. And management has put the responsibility on everyone else to figure out what these needs are. I think one of the key starting points is that management needs to recognize that they are responsible for providing the organization with a clear understanding of the customers’ needs. So there should be someone responsible for providing marketing development sales, R&D, with a set of needs statements that they can use to drive the creation of value.
And leaving it up to each individual to figure out a piece of the puzzle, without understanding the entire puzzle, is not really going to work. So one way to look at it, instead of having each individual in a company understand three or four customer needs, what we wanna do is have everyone in the company understand all the customers’ needs, all hundreds of them. And once we get to that point, we can start seeing the benefits of understanding needs prior to drawing conclusions and making decision about what products to build.
Daniel:
Right. And I know that in terms of defining what a need is, you draw a distinction between a job and a desired outcome because they apply to different innovation opportunities. Can you explain the difference between those two?
Tony:
Sure. So we use jobs to define the market. So, in other words, we don’t define the market as a product, so we wouldn’t say it’s the CD market or the MP3 market. We would say that this group of people, music enthusiasts, who are trying to get a job done, which is listening to music. So the job of listening to music is defining the job, if you will. Or parents who are trying to pass on life lessons to children, that would constitute a market. Or dental hygienists who are trying to clean the patients’ teeth, that would constitute a market. So in each of these cases here we’re defining what the job is. And once we define the job, then we go very deep in understanding that job to figure out, how do people measure success along each step of the way, as they get that job done?
So when listening to music for example, as you go deep, you realize that people are trying to quickly figure out how to get the songs in the right order. Or they’re trying to decide what songs to put in their playlist, or they’re trying to minimize the likelihood that the music sounds distorted, or so on. There’s a whole series, often 100 metrics or more, that define how they measure value in getting the job done. And those metrics are the desired outcomes. So while the job defines the market, the outcomes define the needs within the market.
Daniel:
Right. Okay. So exactly how does a job look like? What kind of structure does it have? That’s one of the major accomplishments of your methodology, which is having a set structure for how a job looks like.
Tony:
Yeah, that’s right. So we’ve… It’s like we’re creating a language so we can communicate what a need is, right? It’s not unlike programmers who are trying to create a program. Now if the programmers didn’t agree on what programming language to use, and everyone just typed in whatever they wanted, whatever syntax and format they wanted, it’d be really hard to create a winning application, right? The same thing is true here. If we can’t agree on the language that we’re using to describe what a job is, what an outcome is, then it’s really gonna be hard to move forward. So we’ve spent… As you mentioned, we’ve spent two decades here trying to figure out, what is a market? What should the job be defined like? What should the outcome be defined like?
So, a job is an action statement. It begins with a verb, typically, that denotes the goal of what you’re trying to achieve. And I mentioned a few of them already. So, like the dental hygienist who’s trying to clean the patients’ teeth, or a parent who’s trying to pass on life lessons to children, or people who’re trying to listen to music. They’re generally simple statements that get to the functional element of what people are trying to accomplish. What we see, when people head down the jobs-to-be-done path, we see a common mistake that they make to incorporate an emotional element into the core job that the customer’s trying to get done. We don’t do that. We focus on the core functional job that the customer’s trying to get done, and we create value by helping them address the function they’re trying to achieve. And then we position products around the emotional jobs that they’re trying to get done. And so we separate those two things out.
The functional job is what people are trying to accomplish and that’s why they’re buying the product. The emotional jobs are what they’re hoping to feel or how they wanna be perceived as they use that product. So knowing the difference between those two and separating them out is absolutely critical. That’s what the job statement looks like.
The outcome is a bit more detailed, and we’ve spent a good 20 years trying to figure out: what is the perfect need statement? And back in the early 2000s we worked with Microsoft on about 45 projects or so. And we worked with their corporate market research group, which was great fun. And every time we put out a survey, we would test some variation of the statement. So we’d have our base survey, then we’d have an experimental survey, and we would change the way we would structure these statements to see which ones would get us the best results. And over time, we concluded that an outcome should have an introductory metric, or measure I should say, direction of improvement. Like minimize the time it takes to do something. We need a metric, like time or likelihood, and then the object of control, as we call it, the thing that you’re trying to address, that’s really the desired outcome. And then there’s often a contextual clarifier after that, as well. So those four structures of the statement really comprise what the outcome language is all about.
So when we say, “Minimize the time it takes to get the songs in the desired order for listening,” it describes what we’re trying to achieve, in what context, so it becomes very clear, unambiguous, it’s measurable and controllable in the design of a product, you can evaluate different products against that outcome to see which one’s getting the job done better. The outcome’s stable over time, so people have been trying to minimize the time it takes to get songs in the desired order for listening for decades, right? And they still continue to do that today. And having a outcome statement and a set of needs that’s stable over time is a huge advantage to the organization because it allows them to use those insights to guide their long-term planning and their short-term planning as well. But the point is if you’re focused on those outcomes and satisfying them, you’re definitely heading in the right direction. So you’re not gonna be misguided, you’re not gonna make the wrong decisions because whether it’s gonna take a year or two years or three years to come up with your product, by the time it gets out to the marketplace, it’s still going to address needs that are valid for that customer set.
Daniel:
Right. Everything comes together in what you call a job map, right? Can you explain to me what it is and how we might try to create one?
Tony:
Sure, yeah, absolutely. We came up with the concept of the job map after much iteration. It’s probably in the early 2000s when we started thinking about it this way. But part of that, we would just collect outcomes on a market, on a job and total. And what we noticed over the years is that most jobs follow a certain structure where there’s typically a planning step right up front. And then once you know what you’re trying to achieve, you have to go gather all of your inputs, whether it’s information or raw materials or whatever it might be. You have to gather all that and then organize it in some fashion that’s gonna likely get the job done, so it would work. And it was typically a confirmation step where you make sure everything is all set before you execute the job, then you actually execute it. When you’re executing, you’re monitoring the execution to make sure that everything’s going okay. You make some adjustments if need be and then you conclude.
So we noticed that all jobs follow a similar path and we also noticed that… And many products don’t allow the jobs to get done in that order, which causes iteration and ineffectiveness which open the door to a great set of insights for innovation. And this is what the job map is all about. The job map, it’s not a customer journey map, it’s not a process map, it doesn’t describe what people are doing. What it describes is what people are trying to do, so it’s solution free. If you peel back all the solutions, you’d get at what the costumer is actually trying to accomplish. And we lay out what they’re trying to accomplish in the most effective order, so there is little iteration or rework. And by doing that, if you can define the job that way and understand all the steps in the job map, you can begin to realize where your product has to go over the long term, and it sets a vision for the organization. The vision is, “We’re going to help our customers get the entire job done.” And this is great because what we’ve learned is that customers don’t wanna have to cobble together lots of different solutions and make them work.
They just prefer to go to one vendor and just buy one thing that gets the entire job done. If a company knows what that job is, and the entire job is, it can work systematically towards getting the entire job done better over the years. And like in the music space, just a quick example, people wanna figure out, “How long am I gonna listen to music?” That’s the very first step, it’s a planning phase. What am I listening to music for? Am I just trying to relax and get to sleep? Do I need 15 minutes worth of music or do I need hours worth of music because I’m hosting a party? And then you gotta go gather all the songs and you need to organize them in the order in which you wanna hear them. And then you confirm that you’re ready to go and you hit the button and you execute, you start listening to music. And as you’re executing, you’re listening and you’re monitoring and you’re hearing songs that you don’t really like anymore and wanna change, so you make modifications. Then you go through that entire process, you’re done, you’re concluding.
And so that’s an example of what we’re talking about here. And to get the job… If you think about CDs for example, CDs didn’t let you get much of that job done at all. Let you listen to music but the songs already came in whatever order you bought them in and you had no choice. But then MP3s come along and they allow you to get more of the job done significantly better. Helps you minimize the time it takes to get songs in the desired order for listening, 'cause you can just move them around very quickly. A huge advancement. And then you see streaming services come along and gets the job done even better. It recommends songs for you, things that you’re likely to like, so you can find the songs to go into your collection and so on. It’s interesting because when you think back on the CD, it was only getting a very small part of the job done, and the way that market evolved, and the way all markets evolve is to just discover what the bigger job is and to get more and more of the job done, over time.
Daniel:
Right. So you touched on something there, which is the bigger job. If we look at listening to music as one specific job, and we might include different sets of steps… But if we look at purchasing, or maybe discovering, as different jobs, how can we try to package them together in a way that makes more sense for the customers? Because we might solve one individual job, smaller job, but maybe there are groupings of jobs that make more sense for the customer, right?
Tony:
Well, you’re bringing up two good points there. The first point is that there are multiple customers. So you obviously have the person that’s using your product, and we’re focusing on the functional job. And that’s what we’ve talked about so far. For the user of the product, you wanna help them get the functional job done better. But there’s also the buyer of the product, someone has to purchase it, right? So the buyer may not be the user. In a lot of B2C situations, that’s definitely the case. I’m sorry, B2B situations. And in B2C, it’s more likely that the buyer is the user. But in either case, the buyer… When you put your buyer hat on, you’re using a different set of metrics to decide which product you wanna buy. It’s a set of financial metrics that you use. You wanna minimize your initial costs outlay, minimize the cost over time, minimize the cost of maintenance, minimize the cost of upgrading. And there’s a whole series of financial metrics that are being considered when they’re making the purchase decision.
But the purchase decision is a different job, right? But we don’t define… It’s like every market… In every market, you have to buy the product. So we view the purchasing process as a critical element, but it doesn’t define the market. What defines the market is that core functional job of the dental hygienist trying to clean the patient’s teeth, or parents trying to pass on life lessons to the children. That’s how we define the core job in the real market. Yes, in each case does someone have to purchase the product? They certainly do. And there is a protocol that they follow, or should follow. And that is you need to understand their needs, they need to look at the universe of solutions, they need to prioritize their needs, and then evaluate those solutions against their needs to see which ones are best, and then they can make that decision. And we’ve studied the buying process for a number of companies, and those companies that are very successful help their customers through that process so they can get the purchase job done more simply as well.
Then, to make it a little more complicated, there are also what we call consumption-chain jobs. People who not only have to purchase the product, but they have to maybe install it, or transport it, or upgrade it, or maintain it. And of course people aren’t buying the product so they can transport it, upgrade it, maintain it, they’re buying it to get the core job done. But if you have these consumption-chain elements associated with your product, then you have to make it easy to transport or easy to maintain, or hopefully even eliminate the need for maintenance, for example. So these are all other jobs, if you will, but they don’t define the market. The market’s defined as a core job, and these other factors go along with it. They’re all part of the life cycle of the product that need to be thought through as you’re innovating as well.
Daniel:
Right, so consumption jobs and buying jobs and maybe emotional jobs be considered ancillary to the core job, and related to it somehow? Or are they different groups, the emotional part and these other kinds of functional but smaller jobs?
Tony:
Yes, they’re all related. But if you think of how you’re setting your priority, your priority is around that core functional job. And you wanna create a product that has the function that gets the job done a lot better. In addition, you wanna make that product easy to buy, easy to install, easy to maintain. So all those other factors come into play. And that’s true of every product, right? So those differentiating… Those other factors don’t differentiate the market. It’s only the core job that differentiates what the market is. And the emotional jobs, as you mentioned, they’re very real. But we don’t design the products around the emotional jobs, we position the products around the emotional jobs. So you create function that in many cases as we’ve seen… We do these emotion function correlations where we can see that by satisfying certain needs functionally, that you’re addressing some emotional job as well. And by understanding what the correlation is, you can market or position your product around both the functional needs that you’re satisfying, and the emotional jobs that they correlate with, which is how we use it. So at a very high level, we use the functional insights to innovate on the product side, and we use the emotional jobs to position on the marketing side.
Daniel:
Perfect. Alright, so moving onto the subject of this book that I’m working on… We’re working with existing products, and they were developed through whatever methodology and maybe have found some amount of success, but the team might not have such a comprehensive view of what the customer’s needs are. And in this situation, the product will be probably all over the place in terms of how well it serves those needs that the customers are trying to solve. So how can product managers try to bridge this gap, and create job maps or any kind of analysis for existing products?
Tony:
Sure. So what we recommend as a very simple starting point, and we do this in a workshop format typically… So we recommend a one or two-day workshop with the team, the product team, and a set of customers. So bring in a set of customers with the product team and work together to define what the job is from the customer’s perspective, what the job map is from the customer’s perspective, and then what are those desired outcomes. And typically within a couple days a company can see their market through this jobs-to-be-done lens and begin to innovate in a very different way. So, that is the starting point. Of course they have to have some knowledge of what an outcome is and how to use the job maps and that sort of thing.
We’ve got some pretty good articles out there on the job map, one is in Harvard Business Review called “The Customer Centered Innovation Map” that gives us some pretty good insight into this. And then we have another article on needs, in the MIT Sloan Review called, “Giving Customers a Fair Hearing,” that gives some pretty good detail on what job statements, how they should be defined and how outcome statements should be defined. And the goal of that two-day session is to translate the institutional knowledge that the organization has into an asset really, it’s a set of statements that can be used for years to come to guide the product-development process. So just doing that is a huge first step, getting a common language of innovation, seeing the market through the jobs lens, often it’s transformational.
Daniel:
Excellent. And another question I had on this topic is, in the context of digital products, software products, we typically get tons of feedback and requests from users, and I was wondering if you thought that this is a natural consequence of our lack of understanding of all the customers needs, or is this to be expected even from the most complete kind of product?
Tony:
Well I think it’s a little bit of both of course. Software products are more complex for a number of reasons. Of course you have to understand the functional needs of a customer to get the software to do the right thing, right? So this is what it’s supposed to do. And then there’s other elements too. Then you have the UX and the UI, so from what we often see is much of the feedback that comes in from customers relates to the UX and the UI, and how to make data more accessible and how to set up your option screens, how to use minimal amount of data on the screen, whatever UI and UX requirements need to be met.
That’s where a lot of the feedback comes in, and so what we’ve done to assist with that, is we’ve studied the job of interfacing with software. As you might imagine, there are several rules and a set of outcomes that customers generally like to have satisfied. So optimizing the interface to address the usability outcomes of customers makes pretty good sense, and most companies I would say probably don’t understand what those outcomes are or have access to those. So the combination of all that, and the same thing with UX, most companies don’t have access to what the functional needs are, the UX needs, the UI needs, as result you’re gonna get, like I said, tons of feedback and requests from users. So, I would say that’s pretty common and until you can really turn all that into a science it’s gonna remain pretty common.
Daniel:
Right. So, going back to something that you’ve already mentioned and that you talked about in a recent interview with Des Traynor from Intercom, you talked about the issue of market segmentation, and your methodology customers are segmented by their needs and the job that they’re trying to get done. So, if we were trying to do this for an existing product, is it valid to start from our customer base, or do we need to go and analyze the broader market? I mean, the issue here being that if we were only looking inwards, there’s probably a risk or having an incomplete understanding of the job and the market, right? Is it possible to start this kind of analysis from our existing customers?
Tony:
Well, so you bring up a lot of interesting issues there. The first point I wanted to touch on is that, we segment the markets only around the unmet outcomes, so we actually don’t segment around jobs, generally, unless it’s a platform-level solution that gets many jobs done, then we might segment around jobs. But we segment around the unmet outcomes. And in terms of who we focus on, if we structure… Our preference when we structure a research study is to not only talk to your customers but to talk to all people who are trying to get that job done, and maybe they’re not even using similar-type products.
So getting a good insight into what the broad range of customers are using for products and how satisfied they are using those products along all those different outcome dimensions, it really makes for a very robust competitive analysis. So that’s just what we would typically do, is we interview all different types of customers, we ask them what kind of product they’re currently using to get the job done, and then we say, “Well when using that product, how satisfied are you with your ability to minimize the time it takes to get the songs in the desired order?” And so we have that information for product A for product B, product C, and were able to look at the strengths and weaknesses of each product, which is great because then we can figure out from there: How do we beat each competitor, and then how do we leapfrog all the competitors to get the job done significantly better?
Daniel:
Right. So if we were trying to maybe clarify our own understanding of the jobs and the outcomes that we’re serving, having that kind of session with our own customers is still good enough in that sense, right?
Tony:
It’s a great starting point. Yeah, absolutely. Because especially when you’re defining the job and the job map, going to your customers makes great sense. Even gathering a set of outcomes, starting with your customers, makes great sense. And what we often suggest is you bring in friendly customers, people that know you, that like you, that work with you, that would be very happy to spend a couple of days helping you understand how they think about the job. So that’s a great starting point. And then once you get through that two-day workshop, then take that list of outcomes out to your non-customers, and just validate it and refine it until you have a really robust set of needs that you feel very confident are representative of all customers in the market.
Daniel:
Right. Okay. So moving on to something that is another part of the puzzle, I guess, which is several products usually are trying to serve multiple jobs, multiple outcomes for their users, and in that sense, users might fall within multiple segments, market segments. So when you’re trying to look at a piece of unsolicited feedback that’s coming in, usually in the form of feature requests, how can we try to find out the exact job or desired outcome that that user was trying to get done? Is there a way to maybe ask a good set of questions to understand that?
Tony:
Sure. So I think what you’re saying there is feedback comes in and I’m assuming… It sounds like you’re saying it’s coming in in the form of a solution, like they’re making a request.
Daniel:
Yeah. Exactly.
Tony:
Okay. So they’re asking for a feature…
Daniel:
Yeah.
Tony:
Generally when customers ask for a feature, we can very easily say, “How will that benefit you? What will it help you get done better? What inefficiencies would that eliminate? How will it help you get the job done faster? How will it increase output? How will it reduce waste?” Those questions generally will get you at what is the underlying outcome that they’re trying to satisfy. And you’re on the right point. We don’t suggest that companies accept solutions from customers because again we’re trying to innovate, we’re trying to come up with solutions that address unmet needs. So if our customers are giving me solutions, they’re actually innovating for us. They’re not giving us the needs, and if we don’t dig deep like you’re suggesting, then we could go add features to the product without ever understanding what those needs are. So I think asking that short set of questions and spending the time to go a little deeper, it’s really time well spent.
Daniel:
Perfect. So these kind of one off interactions are very typical, and the kind of study and methodology that you try to apply is more wide-ranging. You need to invest a lot of time in order to get it right. So is it possible to use these kind of one off interactions in a way that they can help us fill in the details and fill in the gaps for having a more complete view of our customers and the market? Are these kind of interactions good enough for that kind of thing?
Tony:
Well I wouldn’t leave it just to only those interactions, but I think they are helpful. So let’s go back to the workshop. After you’ve done that workshop, you’re gonna have a pretty good sense of what your needs are. You might have 80% of them. Like I said, in most markets, there’s between 50 and 150 different outcomes, so it’s pretty extensive. And your goal is to make sure you understand all of them. In the workshop, you’ll get far along the path, but you won’t have all of them. And I think these one off interactions will help you refine and improve it over time.
Tony:
So once you’ve gone through that workshop, you take the insights that you’ve gathered, you put it in the hands of the developers, the marketing team, the sales team, and let them think about that. And as they have interactions with customers in the future, have them add on to it and build onto it. A lot of what we do… We may do something in Google Docs, and this is the way we operate internally as well. We’ll have a set of needs, and the company contributes to refining that set of needs. So it’s all sitting there, and anyone can contribute to it, and what the company is doing is building out a comprehensive set of needs statements. But of course everyone has to agree on what that structure looks like so that people aren’t just typing nonsense in there or things that don’t constitute real good needs statements.
Daniel:
Right. Okay. So I wanted to ask you about something a little bit different, which is another method or model that is used around this topic, the Kano model. And the Kano model contends that customers’ expectations about a product’s benefits change over time. And you talked about how expected outcomes are stable over time, and I wanted to get your take on this subject because one of the things that the model says is that what was once surprising and exciting then becomes a baseline as time goes by. An example of this being having WiFi on a hotel, or having touch screen interfaces for mobile phones. How does this fit within ODI’s concepts? Is it a matter of the nature of the job changing, or maybe that success metrics standards are going up, or a bit of both?
Tony:
The Kano model is highly flawed, and I discovered this years back. The Kano model, it acts or proposes that it’s talking about customer needs, but it’s not. It’s actually referring to solutions, so saying the customer expectations about the product’s benefits change over time. That’s the way they talk about the Kano model, but what they’re really saying is that expectations about product features change over time. Now, we’re in a solutions space. The Kano model is really all about solution space, so even though it says it’s needs, Kano is confusing needs with solutions. And this model, I think, has led to huge confusion out in the industry because he’s making that very basic mistake. And the evidence is that what was once surprising and exciting becomes baseline, right?
Daniel:
Right.
Tony:
That’s the exciters, the delighters. Only solutions are exciters and delighters, right? You can’t have a need that’s an exciter. A need is a need. The way to excite is to create a solution that satisfies the need. And so that whole model is highly confusing. I spent years back in the '80s just studying this, and it led me off in the wrong direction for years, but we finally figured out why. And it’s because now of what I’m saying. And that’s why like examples of hotel WiFi, now it’s expected. Well, that’s right because users had need before so they could work from their hotel room. And now, the solution comes along to satisfy the need, and now people expect that solution to be available when they go to their hotel room.
That’s exactly right, but it’s the solution that becomes the expected solution over time. The need didn’t change. So it’s not because needs change or job change. It has nothing to do with it, and I would suggest that people quit using the Kano model for needs understanding. It’s a great model for solutions understanding. That’s definitely true. If once the solution is expected, you better have that solution on your product or something better than that solution or otherwise people are going to complain. A nice way to think about that is there’s table stakes that come into play. That these needs might be very important, but now they’re very satisfied. And once they’re very satisfied, you’d better keep satisfying them with your solution or else you’re gonna run into some big troubles. That’s why if you’re a hotel that doesn’t offer WiFi, you’re gonna get lots of complaints.
Daniel:
Excellent. Yeah. That clarifies a lot of what I thought about the Kano model. Perfect. Okay so, to wrap it up and maybe summarize some of the things that we’ve talked about, what would your top recommendations be for product managers that are trying to use customer feedback and inputs and trying to create a needs first culture around their product?
Tony:
I think it really comes down to just having the discipline. Just have the discipline, take the time to build out the model. It’s knowable. Understanding the job the customer’s trying to get done is certainly knowable. Creating the job map is knowable. Getting a set of needs is certainly possible. Just take the time to do it. That’s my recommendation, because once you do that, you’re going to have a set of needs that’s gonna guide you and your business, not just for the next week, or next product iteration, but for years. Because the way we’ve structured this, these needs are stable over time. So once you have that understanding, you have a set of metrics that are gonna guide your product creation, your marketing, and everything for years to come. So while it might be grueling, while it might be a bit difficult, getting it done and having the discipline to get it done, build that robust set of needs will pay dividends for years to come.
Daniel:
Great. Well, thanks a lot for your time. It was great talking to you today, and I hope it was also for you.
Tony:
It was, Daniel. Thanks for taking the time. I appreciate talking to you.
Daniel:
Thank you very much, Tony.