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 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.

Q: You suggest that solutions shouldn’t be referenced in customer requirements statements. Why not?

Ulwick: It isn’t 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’re trying to get done. When solutions are included in a need statement, it focuses the customer on the “here and now” rather than what they are trying to accomplish. Getting at what they’re 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’t imagine today what a solution will look like in ten years.

Q: 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?

Ulwick: 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’t have that problem.

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.

Q: 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?

Bettencout: Let’s take one what has great relevance to the IT group role – the task of collaborating with others. If you were to ask employees about what introduces variability in this process, they might say something like “other employees are not dependable.”

The metric for this is problematic because “dependable” can mean many different things. If you ask someone to describe undependable behavior, she might say things like “forgets about meetings” and “fails to pass along important information.” These statements begin to get to the level of specificity we need for innovation. They become viable need statements when phrased as “minimize the likelihood that a team member forgets to attend a scheduled meeting” and “minimize the likelihood that a team member fails to pass on to other team members information that is needed for decision-making.”

Q: Can you offer any guidance on how to deal with terms that are inherently difficult to define, such as “simple” or “easy to use?”

Ulwick: Perhaps the best way is to ask the customer to describe something that is not 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’t simple or easy can be very productive. This also holds for other difficult-to-define adjectives, such as “reliable,” “durable” and “scaleable”

Q: How effective are customers at defining their own unmet needs rather than simply asking a way to do what they’re doing a little better?

Bettencourt: If you ask them about the struggles they encounter in the job they’re already 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’s also possible to ask them about what they like and dislike about current solutions they’re using.

The key is to understand that a customer’s likes and dislikes with today’s solutions have to do with their needs in getting the job done. Again, what’s critical is to understand the requirements of a good need statement; you don’t need to be restricted to asking just one specific type of question.

Q: Many engineering-driven organizations have a culture that doesn’t invite customer input. ow do you challenge this culture and effectively turn the focus back on customer needs?

Ulwick: 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’s unmet needs, and they appreciate systematic thinking. In mature markets, where problems can’t 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.

From Innovations, a website published by Ziff-Davis Enterprise from mid-2006 to mid-2009. Reprinted by permission.

Does the following scenario sound familiar to you? An internal customer has come to you with a problem.  Her group is consistently missing deadlines because of poor communication.  E-mails frequently go unread for days, group members don’t respond to questions in a timely fashion and too many meetings are required to get everybody back on track.  The manager read in an airline magazine about wikis, and thinks they are the perfect solution.  She wants you to get one up and running as quickly as possible.

What do you do?  Experienced project managers will tell you that the last thing would be to install a Wiki.  Better solutions may be available, and your job as an IT professional is to analyze the needs the manager has defined and identify the most appropriate solution.

Tony Ulwick and his team at Strategyn would tell you to take one more step back. They’d see all kinds of problems in the needs statement that was just presented.  For example, words like “consistently,” ”frequently,” “timely” and “too many” are vague and subjective. Furthermore, the solution that the manager seeks — better performance against deadline — may be far short of the bigger goal of improving group performance.  You need to define the problem better before tackling a solution.

Optimizing inputs

Strategyn specializes in helping companies optimize customer inputs to improve innovation. Ulwick, who has published widely on this topic, believes that most projects fail not because customers don’t understand the problem but because the people trying to solve the problem don’t ask the right questions.  Strategyn’s methodology starts with helping stakeholders define needs very specifically so that vendors and internal service organizations can innovate from them. That means discarding adjectives and subjective statements, talking about jobs instead of outcomes and using very specific terms.

Over the next two blog entries, I’ll present an interview with Tony Ulwick and Lance Bettencourt, a senior adviser at Strategyn.  You can also find some helpful free white papers on this subject at the Strategyn website (you need to register to view them).

Q: You say businesses often respond to perceptions of customer need rather than actual defined needs. What are some governance principles you believe internal services organizations can embrace to address these needs? Is a structured approach to needs definition necessary?

Bettencourt: Businesses try to respond to too many customer needs because they don’t know which needs are most unmet, so they hedge their bets. An organization must have a clear understanding of what a need is. Without a clear understanding and a structured approach to needs definition, anything that the customer says can pass for a need.

Many organizations are trying to hit phantom needs targets because they include solutions and specifications in their needs statements, use vague quality descriptors and look for high-level benefits that provide little specific direction for innovation.

Customer needs should relate to the job the customer is trying to get done; they should not include a solution or features. They should not use ambiguous terms. They should be as specific and consistent as possible to what the customer is trying to achieve. It’s important that a diverse body of customers be included in this research because different needs are salient to different customers. The ultimate goal is to capture all possible needs.

Q: Your advice focuses a lot on terminology. At times, you recommendations are as much an English lesson as a prescription for innovation! Why the emphasis on terms?

Ulwick: What distinguishes a good need statement from a bad need statement is not proper English, but precision. If a so-called need statement includes a solution, for example, then it narrows the scope of innovation to something the customer is currently using rather than what the customer is trying to get done.

For example, if a need statement includes ambiguous words such as “reliable,” then it undermines innovation in multiple ways. Different customers won’t agree on what that means when, say, printing a document. Or they won’t agree on what “reliable” means in general. This leads to internal confusion and ultimately to solutions that may not address the actual unmet need. Customer need statements have to be precise and focused if you want to arrive at an innovative solution.

Q: You suggest focusing on the job. What’s the definition of “job” for these purposes?

Ulwick: We mean the goal the customer is trying to accomplish or the problem the customer is trying to solve. A job is an activity or a process, so we always start with an action verb when we’re creating a job statement. Positions can’t be jobs. In fact, there may be multiple distinct jobs associated with a given position. For innovation purposes, “job” is also not restricted to employees. We’re not just talking about people trying to get their work done, but all their daily activities.

The best way to get at a clear definition of the job is to begin with the innovation objectives of the organization or, in your example, the IT department. If the goal is to create new innovations in an area where there are already solutions in place, then the organization should understand what jobs the customer is trying to get done with current solutions. If the goal is to extend the product line into new areas, then the definition should begin by understanding what jobs the customer is trying to do in a different but adjacent space. Defining the job helps the organization to achieve its innovation objectives.

Next week, Tony Ulwick and Lance Bettencourt tells how development organizations can ask the right questions to assess customer needs.