From Innovations, a website published by Ziff-Davis Enterprise from mid-2006 to mid-2009. Reprinted by permission.<\/i><\/p>\n
<\/b><\/p>\n
Last week, I introduced you to Tony Ulwick and Lance Bettencourt of Strategyn<\/a>, a company that helps businesses optimize customer inputs to improve innovation. Their methodology is all about doing away with subjective terms and focusing on the real barriers that customers and internal stakeholders encounter in getting their jobs done. In part two of my interview with them, Ulwick and Bettencourt discuss the details of getting customers to avoid generalities and assumptions in order to create a context in which innovation can flourish. <\/b><\/p>\n <\/b><\/p>\n Q: <\/b>You suggest that solutions shouldn\u2019t be referenced in customer requirements statements. Why not?<\/p>\n Ulwick:<\/b> It isn\u2019t the responsibility of the customer to come up with innovative solutions, but rather to help the company to understand the needs they have for the job they\u2019re trying to get done. When solutions are included in a need statement, it focuses the customer on the \u201chere and now\u201d rather than what they are trying to accomplish. Getting at what they\u2019re trying to get done is the true basis for innovation. In fact, a need statement that includes a solution has a built-in expiration date, which is problematic. The ideal need statement should be just as relevant ten years from now as it was ten years ago. It should guide short-, medium and long-term innovation. A person can\u2019t imagine today what a solution will look like in ten years.<\/p>\n <\/b><\/p>\n Q: <\/b>When you ask people to define their unmet needs, they often simply ask for a better version of what they already have. How do you create questions that get at their true unmet needs?<\/p>\n We ask customers questions like what takes them a lot of time? What introduces variability into the process? What issues do they have with getting the right output from each step? This straightforward line of questioning focuses on the job rather than on solutions and ensures that metrics relate to time, variability, and output. Those are the three types of metrics we see, regardless of customer type or industry.<\/p>\n Q: <\/b>You recommend against using adjectives and adverbs in need definition. Can you give an example of how this rule might apply to an internal customer defining a need to the IT organization to improve workplace productivity?<\/p>\n Bettencout:<\/b> Let\u2019s take one what has great relevance to the IT group role \u2013 the task of collaborating with others. If you were to ask employees about what introduces variability in this process, they might say something like \u201cother employees are not dependable.\u201d<\/p>\n The metric for this is problematic because \u201cdependable\u201d can mean many different things. If you ask someone to describe undependable behavior, she might say things like \u201cforgets about meetings\u201d and \u201cfails to pass along important information.\u201d These statements begin to get to the level of specificity we need for innovation. They become viable need statements when phrased as \u201cminimize the likelihood that a team member forgets to attend a scheduled meeting\u201d and \u201cminimize the likelihood that a team member fails to pass on to other team members information that is needed for decision-making.\u201d<\/p>\n Q: <\/b>Can you offer any guidance on how to deal with terms that are inherently difficult to define, such as \u201csimple\u201d or \u201ceasy to use?\u201d<\/p>\n Ulwick:<\/b> Perhaps the best way is to ask the customer to describe something that is not<\/i> simple or easy to use. Customer needs often have to do with reducing time, variability, waste and inefficiency. Asking him to provide examples of what getting the job done looks like when it isn\u2019t<\/i> simple or easy can be very productive. This also holds for other difficult-to-define adjectives, such as \u201creliable,\u201d \u201cdurable\u201d and \u201cscaleable\u201d<\/p>\n <\/b><\/p>\n Q: <\/b>How effective are customers at defining their own unmet needs rather than simply asking a way to do what they\u2019re doing a little better?<\/p>\n Bettencourt:<\/b> If you ask them about the struggles they encounter in the job they\u2019re already<\/i> trying to get done, they can be quite forthcoming. One way to approach that is to walk them through the steps and asking them about time, variability, and output concerns at each step. However, it\u2019s also possible to ask them about what they like and dislike about current solutions they\u2019re using.<\/p>\n The key is to understand that a customer\u2019s likes and dislikes with today\u2019s solutions have to do with their needs in getting the job done. Again, what\u2019s critical is to understand the requirements of a good need statement; you don\u2019t need to be restricted to asking just one specific type of question.<\/p>\n <\/b><\/p>\n Q: <\/b>Many engineering-driven organizations have a culture that doesn\u2019t invite customer input. ow do you challenge this culture and effectively turn the focus back on customer needs?<\/p>\n <\/b><\/p>\n Ulwick:<\/b> We find that engineers are actually among the most receptive to outcome-driven innovation thinking. They know how hard it is to innovate without a clear understanding of the customer\u2019s unmet needs, and they appreciate systematic thinking. In mature markets, where problems can\u2019t be easily addressed by engineering-based innovation, engineers appreciate the outcome-driven approach. It gives them specifics to work with instead of taking stabs in the dark.<\/p>\n","protected":false},"excerpt":{"rendered":" From Innovations, a website published by Ziff-Davis Enterprise from mid-2006 to mid-2009. Reprinted by permission. Last week, I introduced you to Tony Ulwick and Lance Bettencourt of Strategyn, a company that helps businesses optimize customer inputs to improve innovation. Their … Continue reading
\nUlwick:<\/b> If you know that a needs statement must not include any reference to a solution, and that needs must relate to the job the customer is trying to get done, then you don\u2019t have that problem.<\/p>\n