Interview, August 2008 To date there has been little formal effort made by companies, academics or others to define just what types of inputs customers offer when stating their requirements — and what types of inputs companies need to obtain in order to create breakthrough solutions. Keep in mind a requirement is "something wanted or something needed" so arguably solutions, specifications, needs and benefits (as well as wants, desires and other inputs) could all be considered "requirements." But like most processes, certain types of inputs are critical to success while others will lead to failure. Creating a common language around which to label and categorize different types of inputs, then, is the first step in bringing clarity and objectivity to this often undisciplined process. Let's begin by defining what types of inputs companies commonly obtain from customers and explain why using these responses inhibits innovation and growth. Solutions: Many customers offer their requirements in the form of a solution. These inputs are most often stated as a description of the physical or tangible product or service features customers want to see included in the product or service. For example, a manufacturer of toothbrushes may hear from customers that they want more bristles, a rubberized handle or a rotating head. Each of these statements represents a possible product feature or solution. Accepting solutions as customer requirements is common, but the practice is riddled with drawbacks. First, most customers are not technologists, engineers, scientists or materials experts. They don't know how the features they are requesting will impact other possibly more important functional dimensions of the product—and as a result may not want the final product even though it has the requested feature included. Last, they inhibit the company from looking beyond what the customer is requesting—a practice that leads to the creation of "me too" rather than breakthrough solutions. Specifications: A specification is a customer input that gives detailed instruction on a design characteristic such as size, weight, color, shape, look or feel in an attempt to define the solution. For example, toothbrush users may request that a toothbrush have a wider handle or be lighter in weight or have a sleek look. These statements specify how certain parameters of the design should be modified and have many of the same drawbacks as using solution statements as process inputs. Here again, customers are rarely qualified to spec out a product or to understand the ramifications such a requirement will have on other functional dimensions of a product or service. A wider handle, for example, may be requested to prevent the toothbrush from slipping out of the user's hand while brushing. A better solution, unbeknown to the user however, may be a ribbed rubberized grip. In addition, a user may not be aware that a wider handle would make it difficult to maneuver the toothbrush in certain areas—negatively impacting other important outcomes and causing the product to fail. Needs: A need is a universal input that is typically stated as a high-level descriptor of quality and is focused on describing a property of the product or service itself. Customers, for example, commonly say they want a product or service to be "reliable," "effective," "robust," "stable," "resilient," "consistent," "powerful," "serviceable" or "dependable." Toothbrush users, for example, may say they want a toothbrush to be durable and strong. These types of inputs, however, have two key drawbacks. First, they are imprecise statements open to interpretation, presenting designers, developers and engineers with the impossible task of figuring out just what customers really mean by "durable" or "strong." If engineers faced the task of making a toothbrush more durable, for example, would they try to make the bristles last longer, resist fraying or withstand discoloration? Would any of these actions satisfy the customer's true measure of "durable"? Because these inputs are not precise, they are also impossible to measure, preventing designers from determining the degree to which the requirement has been met. As we shall show, a good customer input must be concise, actionable and measurable. Letting employees interpret customer inputs is the point at which product and service failures begin. Benefits: In contrast to a need, which is focused on the product itself, a benefit statement is characterized by what the product or service delivers to the customer. Benefit statements often contain the words "easy," "faster" or "better" and are frequently used by customers to describe what value they would like a new feature or solution to deliver. A toothbrush user, for example, may say they want "cleaner teeth," "faster brushing," or "easy clean-up." Like need statements, these inputs present designers and engineers with information that is not precise, measurable or actionable — leaving too much to chance. In one study we conducted with Motorola cell phone users, for example, we found there were 21 different ways in which customers defined "easy-to-use." They included "minimizing the time it takes to find a contact name," "minimizing the likelihood of calls being made inadvertently" and "minimizing the likelihood of making an error when dialing without looking at the keypad." Without understanding exactly what is meant, and which measures of value are most important, managers run the risk of focusing on the wrong opportunities and making the wrong design trade-off decisions. It is critical for managers to know just what types of information they are obtaining when conducting customer interviews. Many firms knowingly or unknowingly capture a combination of all these types of information and attempt to use each of them – adding to the confusion.