Roger Dennis, over at IdeaPort, posts a multi-part email interview with Tony Ulwick, founder of Strategyn, and creator of Outcome-Driven Innovation (ODI) and author of What Customers Want.
Tony talks about how he originated the concept of ODI and the underlying principle of understanding the jobs that customers are trying to get done:
In my recent book, What Customers Want, (McGraw Hill, 2005), I reinforce the theory that customers buy products and services to get jobs done. [Harvard Business School professor Clayton Christensen introduced this terminology in The Innovator’s Solution. He also cites my work in his book as we have been pushing this thinking for years.] If a company wants to think like a customer, it too must focus on the jobs the customer is trying to get done. This point has far-reaching ramifications.
When the job is accepted as the unit of analysis it means that companies must not capture requirements on a product or service – rather they must capture requirements on the job or jobs that the product or service is intended to perform. This means that instead of asking customers about improving a product, VOC practitioners must be more process focused and
(1) deconstruct the job the customer is trying to get done into process steps, and
(2) determine what metrics customers use to measure the successful execution of the job.
We call these metrics the customers’ desired outcomes. [I first introduced this thinking in the January 2002 HBR article, Turn Customer Input Into Innovation]. We have developed over 40 rules regarding the structure, content and format of these statements. Precision is the key to removing variability from the process.
A customer need, then, is defined as the customer’s fundamental measures of performance associated with getting a job done. This is a critical point, because after these metrics are uncovered, they are prioritized to reveal which are highly important and poorly satisfied (underserved) – thus revealing the best opportunities for growth. This valuable information (which is what I was looking for back in the days of the PCjr) is then used to prioritize the development pipeline, brainstorm new ideas, evaluate product concepts, communicate a products value, etc.
Worth a look.


Chris
Whilst I agree wholeheartedly with the outcomes-driven approach to discovery, practically all the evidence from recent studies in the neuroscience of cognition (summarised by Gazzaniga, LeDoux, Damasio and Zaltman in their recent respective books) suggest that we are far less able to know what emotional outcomes we are looking forward than you suggest. Indeed, nuroscientists suggest that up to 95% of most actions are largely driven by non-conscious processing. When we start asking people to explain what they are doing and what they want from what they are doing, we automatically force them to put a logically consistent structure around their activities that may not have existed previously.
The collection of techniques that you suggest, when used together, do provide a way to develop a balanced understanding of the outcomes people are likely looking for.
Having been involved (years ago) in work task analysis as a discovery tool to drive improvements in human computer interaction, I saw at first hand how little underlying structure there often was to work tasks that you would have thought would have been very carefully structured to create the desired outcome. Trouble is, people are very often "irrational" in their behaviour for any number of reasons.
The key is in recognising that we do not have to pretend we need to know everything about how the customer feels, what they think and what that drives them to do, just enough to improve the experiences that we enable for them.
Graham Hill
Posted by: GrahamHill | November 11, 2006 at 09:06 PM
Hi Graham - thanks for your comment and welcome back! I thought I wouldnt be drawn to blogging so much after my recent experience but here I am again. I hope the posts still make some sense after a a long time with the brain switched off!
Anyway, in response to your comment, I think it is often too easy to portray customers as emotional, illogical individuals who are incapable of knowing or communicating what they want, but the evidence does not support that argument. As we have seen, customers do know what they want – we just have to listen for the outcomes they want to achieve, not what features they think they want.
Customers buy products and services when they need help to get a job done. Understanding what job a customer wants to get done with a product or service is critical to a product’s success.
For example, in the 1980s consumers did not know they wanted or could not articulate their need for an in-car navigation system, but they did know they wanted to minimize the likelihood of getting lost, and to minimize the time it takes to find a route to a specific destination. They also knew they wanted to be notified of traffic problems to avoid delays en-route (a job).
It’s not that customers don’t know what they need; it’s that they don’t know what solution will satisfy their needs. This is natural. Customers are not expected to be able to articulate a technically sound and forward-thinking solution – that is the company’s job. On the other hand, customers are perfectly able to articulate what jobs they are trying to get done and what outcomes they use to measure the successful execution of a job – even if products to help get the job done do not yet exist. When a need is defined as a desired outcome (as in the desire to minimise the likelihood of getting lost or the time it takes it to find a route to a specific destination), the argument for ignoring direct inputs from the customer is shattered; this is because there is no such thing as a latent, unarticulated outcome.
When executing the job of driving to a specific destination, for example, customers may want to:
• Minimise the likelihood of meeting traffic delays, e.g. roadworks, rush--hour hotspots and incidents
• Minimise the likelihood of getting lost
• Minimise the time it takes to adjust a route, e.g. when driving
• Minimise the time it takes to reach the destination
• Minimise the frequency of junctions and turns
• Minimise the amount of fuel consumed
It should also be noted that when captured correctly, desired outcomes are stable over time. People who were driving their cars back in the 1960s for example, wanted to minimise the likelihood of getting lost and reduce the time it takes to arrive at a specific destination (others may wish to increase the number of attractions en-route if they are driving for pleasure) – just as people do today and always will in the future. Desired outcomes have this unique quality because they are fundamental measures of performance inherent to the execution of a specific job. Indeed, they will be valid metrics as long as customers are trying to get that job done.
Consequently, knowing what outcomes customers are trying to achieve gives a company short-term as well as long-term direction in selecting which ideas and technologies to pursue.
The outcomes that should be the focus for improvement however do change over time as new and better technologies are introduced. When in-car navigation systems recently became portable from one vehicle to another for example, customers were better satisfied with their ability to minimise the time it takes to transfer one system from one vehicle to another. This meant that the opportunity to create new value along that dimension was diminished and that manufacturers had to determine which other outcomes were important and unsatisfied before new value could be created.
After nearly 20 years of trying, companies remain frustrated in their efforts to figure out how best to use customer inputs to deliver on the promise of customer-driven innovation. Debate continues as to which is the most effective method for capturing the voice of the customer. A number of writers on innovation, including Clayton Christensen and Dorothy Leonard, swear by observational research. Others suggest using personal interviews, dyads, triads, focus groups, and customer visits. Others fall back on the lead-user method. But argument over which method to use is unnecessary – another mistake frequently made is that the method matters most, but it does not; it’s what customer inputs you are looking for that is fundamental to success. This is what a combination of jobs, outcomes and constraints provide..
Posted by: Chris Lawer | November 09, 2006 at 04:46 PM
Chris
Great to see you back after your spell in hospital.
As you point out in a previous point, much of what we do in our jobs is tacit and automatic. We do our work this way because, well, because this is the way we have always done it. Often, we do our work this way because it minimises the cognitive and emotional burden of work.
The challenge is in understanding both the obvious physical-work aspects of the deconstructed job and the not-so-obvious emotional-work aspects of the job. Both are equally important for effective work design.
Ethnography and other anthropology techniques can help create this more rounded picture.
Graham Hill
Posted by: GrahamHill | November 09, 2006 at 02:05 PM