By: Chris Lawer
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.
Original post: http://chrislawer.blogs.com/chris_lawer/2006/11/interview_with_.html
