Giving Customers a Fair Hearing

Is there agreement in your company that innovation is the key to growth? Is there agreement that understanding customer needs is the key to success in innovation? Is there agreement on what a customer need is? We have asked this series of questions to people in hundreds of companies, and in doing so have made a surprising discovery. Even though there is broad agreement that innovation is the key to growth and that understanding customer needs is the key to innovation, not even 5% of the companies said there was agreement within their company as to what a customer need is. This suggests a very disconcerting question: How can a company confidently uncover customer needs, determine which are unmet and systematically create products that address them if it cannot agree on what a customer need is to begin with? The answer is it can’t — and this is a root cause of failure in the innovation process.

Most companies already understand that there are four basic approaches to product and service innovation: growing core markets, capitalizing on adjacent market opportunities, discovering new markets and disrupting existing markets. But when it comes to understanding customer needs, voice-of-the-customer programs are undermined in two ways. First, there is no consistent standard that defines just what a “need” is — what its purpose, structure, content and format should be. Although companies talk to customers, the inputs they gather differ in purpose, structure, content and format, introducing variability that can derail the innovation process. Second, companies do not understand that to succeed at all these innovation strategies, two very different types of customer inputs are needed — in other words, they do not realize just how a “need” must be defined given the type of innovation initiative being pursued. Only when companies learn what needs are will they be able to consistently uncover hidden opportunities for growth through innovation.

Our purpose here is to introduce a set of timeless standards that define the purpose, structure, content and format of a customer need statement and thereby to transform the art of requirements gathering, and hence innovation, into a rules-based discipline. These standards, and the theory that supports them, are the result of our analysis of over 10,000 customer need statements collected for products and services covering nearly every industry. These standards apply to the four basic innovation strategies and other innovation strategies that a company might pursue and can benefit any company that wishes to bring predictability to the process of innovation.

The Characteristics of a Requirement Statement

Companies need to remember that it’s not enough to just solicit opinions; getting the right information is crucial. Customer requirements are used by companies to inform and guide many marketing and development decisions — and to drive the innovation process. Generally speaking, they are sought to ensure that critical business decisions related to marketing, development and innovation are optimized for the creation of customer value.

Marketing, for example, relies on customer requirements to help uncover customers’ unmet needs and to find segments of customers with unique unmet needs. Those needs represent hidden opportunities for value creation. Competitive intelligence uses customer requirements to help determine the strengths and weaknesses of the company and its competitors. The development team depends on these requirements to determine how best to improve existing products, devise altogether new products, and evaluate product concepts and ideas. The design team relies on them to make design trade-off decisions. When it comes to messaging, these requirements are used by the communications group to help decide how best to position a product and communicate its value. These decisions are key in achieving growth through innovation and must be informed with complete and accurate data. To make customer input useful to the entire company, it must possess these six characteristics:

1. The statement must reflect the customer’s definition of value. It must not be an interpretation or a translation of what the customer values. It must not be the company’s perception of how customers measure value or how they think customers should measure value. It is all too common for companies to inadvertently translate what the customer has said into something inaccurate or misleading. Value must be defined and measured from the customer’s perspective; otherwise, it is a useless input for identifying hidden opportunities and carrying out other marketing and development activities.
2. The statement must have universal acceptance. A requirement must be relevant to all customers, regardless of geographic location, gender and income level. Otherwise, a different set of requirements is needed from every possible demographic — making regional, national and global innovation, positioning and branding near impossible.
3. The statement must be relevant now and in the future. The underlying need for a product must not change quickly over time, or it will be a moving target that is impossible to hit. It must have the same intended meaning and relevance now as it did 10 years ago and will 10 years from now (for example, people needed tools for cooking before the microwave was introduced). Without this characteristic, companies will not be able to decide today what features to include in a product that may take three to five years to bring to market.

4. The statement must prompt a course of action. A customer requirement must indicate what action to take to solve the problem. Merely finding out that a product must be more reliable, comfortable or easy to use— inputs that each customer will define differently — does little to guide the actions of engineers and designers. If you can’t measure value, you won’t know if you are on the path toward creating it.
5. The statement’s meaning must not be open to interpretation. A customer requirement must be precise and clear enough so that all who read it arrive at the same interpretation of its meaning. This transparency in meaning must begin with the customer, but it also extends to all downstream users of the information such as sales and marketing staff, design engineers and others. Just about every product could benefit from being faster, better and cheaper — but those dimensions must be specifically defined for every case.
6. The statement itself must not confound the way it or other statements are prioritized. A good experiment seeks to determine which specific factor is causing an effect, and it does this by controlling all other sources of variation. The same must be done when prioritizing customer needs. Shifts in structure, content and format may introduce unwanted sources of variability that confound requirement prioritization when requirements are prioritized using phone, face-to-face or Web-based market research surveys. If some statements begin with a verb and others begin with an adjective, if some statements include a solution and others do not, then it’s questionable which one is more important. This is arguably the greatest weakness of most requirement statements today, as a lack of discipline here causes companies to pursue the wrong opportunities and to miss others altogether. When solutions are included in a need statement, for example, we see lower ratings given to that statement than a similar statement that is void of solutions — consequently, an unmet need may not be identified if it contains a solution.

Rules for Creating a Requirement Statement

In science, conducting one successful experiment is not enough to prove a hypothesis — the experiment must be replicable. If, time and again, the same conditions produce the same results, then you’re onto something. The same is true when it comes to customer requirements. Any random set of statements may result in a successful innovation once in a while, but are the results replicable?

To ensure that a requirement statement drives predictable results, it must possess the six characteristics stated above, but this will not happen by chance; the statement must be fashioned in a disciplined manner. Over the course of 15 years, and with the experience of creating thousands of requirement statements, we have defined a set of rules for the structure, content and formatting of these statements.

Rule 1: When capturing customer requirements, the unit of analysis must be the job the customer is trying to get done.

Most companies support the theory that customers buy products and services for a specific purpose: to get jobs done. By jobs, we mean the fundamental goals customers are trying to accomplish or problems they are trying to resolve in a given situation. (Harvard Business School professor Clayton Christensen supports this thinking inThe Innovator’s Solution [Harvard Business School Press, 1997].) This terminology and the thinking behind it have far-reaching ramifications for anyone trying to understand customer needs. Companies must shift their attention from the product and instead focus their requirement-gathering efforts on the execution of the job that the product or service is intended to perform.

From the customer’s perspective, it is the job that is the stable, long-term focal point around which value creation should be centered. Current products and services are merely point-in-time solutions that enable customers to execute jobs. A vinyl record, a CD and an MP3 file, for example, all help customers get the job of storing music done. Focusing on creating a better record doesn’t help in the creation of a CD or MP3 device, but focusing on the job of storing music supports the discovery and creation of new ways to help customers get the job done better — which is the essence of innovation.

Focusing on the job as the unit of analysis has two additional benefits. First, it eliminates the need to worry about latent or unarticulated needs, because thoughtfully selected customers are always able to articulate their requirements for getting a job done better and to indicate what related jobs they want to get done, even in markets for which products do not yet exist.

Second, a focus on jobs ensures that the requirements captured are universal and have a shared relevance (although perhaps not importance) among customers worldwide: Requirements captured in the United States, for example, are valid for the customer population in Europe and Asia, and new or different requirements for a job rarely are seen across geographic location. Surgeons around the world have the same requirements for executing a surgical procedure, corn farmers around the world have the same requirements for farming corn and retirees have the same requirements for managing finances. Why? Because in each instance, the individuals are trying to get the same job done — and they execute it in a similar way and measure success in a common fashion. The job is what they have in common, and it supports a universal language for requirements gathering.

Rule 2: The requirement statement must not include or make mention of a technology, solution or product or service feature.

Innovation is the process of devising solutions that address unmet customer needs (in our terminology, requirements); solutions are the means by which unmet needs are satisfied. Consequently, when talking with customers to obtain their requirements, companies must focus only on capturing those requirements — and these statements must not include or make mention of a solution in any form. When a solution-oriented statement is introduced into the mix, it contaminates the data. We know that this is a widespread problem because many companies use scaling methods such as paired comparison and forced choice to get customers taking a survey to make trade-offs between the attributes of various solutions, a practice that is totally unwarranted when trying to figure out which needs are unmet.

In addition, requirement statements that contain solutions are not stable over time. If a company manufacturing music media back in the 1970s, for example, believed that one customer requirement was bigger records that would hold more songs (a requirement statement that contains a solution: bigger records), it might have created a larger record. But years later, the solutions customers envision for their music storage problems would not even include records. Statements that include solutions soon become obsolete, and companies that accept them as customer requirements come to believe that customer needs change quickly over time.

On the other hand, if our hypothetical 1970s music media company recognized that the requirement really was that customers wanted to increase the number of songs that could be stored for play, it would have been more likely to look beyond existing technologies to devise a next-generation solution. This solution-free statement was valid years ago as well as today, and because it is stable over time, it creates a long-term target for value creation.

Rule 3: The requirement statement must not include ambiguous terms.

The statement must not include words that may be interpreted differently across a customer population or across functional areas within the company, leading to disagreement as to the intent of the requirement statement. Ambiguous words come in a variety of flavors. The most obvious are unfamiliar or complex words that require a definition, but others are abbreviated words, symbols, acronyms and jargon. All must be avoided.

A less obvious source of ambiguity comes from the inclusion of certain adjectives in the requirement statement. We often see adjectives used as an integral part of the requirement. For example, customers may say they want the product or service to be more reliable, durable, comfortable, fresh, clean, etc. These are high-level descriptors of quality, and every industry seems to have its own favored terms. Corn farmers, for example, want their corn to be “standable.” Such words must be defined with precision, and when doing so, several actual requirements can be extracted.

Adverbs also are used in requirement statements to describe a desired action, but they tend to leave the requirement open to interpretation. For example, when corn farmers state that they want to increase the percentage of corn plants that emerge from the ground correctly, the adverb “correctly” could be interpreted in different ways. If “correctly” means “come out of the ground at the same time,” then the requirement would be better stated as “increase the percentage of corn plants that emerge from the ground at the same time.” Precision is the key to eliminating ambiguity. Defining exactly what a vague adjective or adverb means in the body of the requirement helps create a more robust statement.

Lastly, it is important not to include the words “and” or “or” in the statement, as it instantly becomes two requirement statements.

Rule 4: The requirement statement must be brief.

To ensure that a requirement statement is specific without sacrificing brevity, we recommend that the statement adhere to the rules of proper grammar and be able to stand alone as a sentence with the context fully intact.

In terms of specificity, it is not enough to say, for example, “minimize waste.” The cause of the waste must be specified, such as minimize the amount of waste due to overpouring, or due to overcooking, etc. All causes of waste when getting the job done must be specified.

It is also important to ensure that process words are not included in the requirement statement, as they cloud specificity. It may seem quite natural for a requirement relating to the job of data capture and storage, for example, to include words such as check, record, review, meet, keep track of and follow up. However, these verbs are vague, and although they may describe the movement of information, they fail to describe what the underlying requirement is. A properly worded requirement statement should indicate what the customer wants to achieve as a result of an action. For example, customers may say they want to minimize the time it takes to check a schedule, but the underlying requirement may be that they want to minimize the time it takes to determine when their next meeting begins, or to determine how much free time is available throughout the day.

Rule 5: The terminology used in the requirement statements must be consistent.

Using different terms to describe the same action, object or activity introduces unwanted variability, and therefore the possibility of different interpretations, into the requirement statements. If a product is referred to as a “device” in one requirement statement, it should be referred to as a device — and not a unit, system, tool or anything else — in all subsequent statements.

Rule 6: The requirement statements must have a consistent structure, content and format.

Requirement statements must possess a consistent structure, content and format so that unwanted sources of variability will not confound the way the requirement is prioritized by customers for importance or satisfaction. Otherwise, companies undoubtedly will find themselves chasing phantom opportunities while missing others altogether, thereby derailing the innovation process.

Putting Requirement Theory Into Practice

As companies embark on innovation initiatives to help them achieve their goals of core market growth, adjacent market growth and new market creation or disruption, they must recognize that two very different types of customer need statements are required, each having its own unique structure, content and format. These needs — “job statements” and “desired outcome statements” — are defined as follows:

Job Statements

When trying to capitalize on adjacent market opportunities or discover opportunities for new market creation, the customer need takes the form of a job statement, as companies are trying to determine which jobs customers are having trouble getting done. In these two circumstances, the goal of the interviewer is to solicit job statements. (For a structure and format that we have defined for a job statement, see “The Structure of a Job Statement.”)

Because a job specifies the action for which a solution is needed, a job statement must at a minimum contain a verb to introduce the statement and an object of the verb that defines the job to be done. Optionally, a job statement may contain a contextual clarifier, such as “communicate with otherswhile on the go,” to describe the conditions or circumstances under which the job needs to get done and examples that clarify, when needed, the object of the verb. This structure ensures that the job statements are standardized and can be acted upon.

Job statements can be captured for any demographic and context. Once prioritized, they reveal opportunities for adjacent and new market growth. For example, potentially underserved jobs for retired people over 65 may include wanting to pass on life’s lessons to their grandchildren, reconnecting with past friends or staying abreast of anti-aging advances. After prioritizing which jobs to address, a company is in a position to devise new, never-before-seen products or services that will dominate uncontested market spaces.

Desired Outcome Statements

When trying to help customers get a job done better (core market growth) or help a new set of customers perform a job that was previously performed by other, more skilled people (disruption), customer needs are defined differently. To get at these needs, the job of interest is first broken down into discrete process steps. Then, for each step, the company must ascertain from customers what metrics they use to judge the successful execution of that step — and of the overall job. These metrics, or desired outcomes, are the customers’ needs in this situation. Once these metrics are known, the degree to which they are satisfied becomes measurable, thus making the satisfaction of unmet needs controllable and manageable.

When focused on core market growth and disruption, then, the goal of the interviewer is to solicit desired outcome statements. (We first introduced this concept in “Turn Customer Input into Innovation,” in the January 2002 issue of theHarvard Business Review.) By focusing on jobs and uncovering outcomes, over 95% of the companies we have studied have successfully prioritized hidden opportunities in core markets and discovered opportunities for new market creation, leading to new innovations. An outcome statement must adhere to the structure, content and format. (See “The Structure of a Desired Outcome Statement.”)

An outcome statement must at a minimum contain a direction of improvement, a unit of measure to indicate what must be measured and controlled to improve the level of satisfaction and an object of control. Optionally, an outcome statement may contain a contextual clarifier to describe the conditions or circumstances under which the outcome needs to be achieved and examples that clarify, when needed, the object of control. The statement is structured such that the requirement’s satisfaction is measurable. If it can be measured, it can be controlled. When it comes to getting a job done better, a company must be able to quantify the degree to which customer satisfaction is being improved by a new or improved product or service concept. This makes it possible to act on the requirement.

To limit variability from statement to statement, we suggest that each statement begin with either the word “minimize” or “increase.” This eliminates variability and its associated problems with opportunity prioritization. For example, minimize, reduce, prevent, eliminate and decrease all appear to be similar in meaning, but significant evidence suggests that using different words to introduce the same statement in a quantitative survey impacts the importance and satisfaction ratings that are given by customers. In addition, because customers are typically trying to get a job done faster, with less variability and waste, we use the word “minimize” to introduce outcome statements about 90% of the time.

To further limit variability from statement to statement, we suggest that companies choose from a select group of metrics. In more than 95% of our desired outcome statements, our metrics are limited to time, likelihood, frequency, amount, risk or number.

Lastly, when including examples in either a job or outcome statement, the examples must have standardized content and format. We recommend that the example statement contain at least two examples; it must not contain a solution, technology or product feature; and it must refer to the object of action or control. (See “Telling Time: Rules for Structuring Customers’ Need Statements.”)

Best Practices for Uncovering Needs

Now that you know what you are after, how can you best capture a solid set of customer needs? A number of innovation thought leaders swear by observational research. Others suggest using personal interviews, dyads, triads, focus groups and customer visits. What matters isn’t the method; rather, it is going into any customer interaction knowing what inputs you are looking for. Once companies decide that the objective is to understand either what jobs customers are trying to get done or what metrics customers are using to judge the successful execution of a specific job, we believe that they can succeed using a combination of methods.

To capture desired outcomes, a four-step approach is best. The first step is to conduct personal interviews in order to dissect the job the customer is trying to get done into process steps. We call this process “job mapping.” The job map is created so the company and the interviewer have a clear understanding of what job the customer is trying to get done — from the customer’s perspective. It simplifies the data gathering process immensely if the interviewer knows which process steps to focus on when capturing desired outcomes. Without a job map in hand, even the most experienced interviewer is likely to struggle.

The second step is to conduct one or two ethnographic or observational interviews with customers to gain insight into the context in which the job is getting done. This will help the interviewer be more effective at capturing and refining desired outcome statements in subsequent interviews. These interviews also may be used to better flesh out the job map and begin the outcome gathering effort.

The third step is to conduct personal, small group or large group interviews to elicit from customers what metrics they use to measure success in executing each step of the job. This is where the bulk of the desired outcome statements are captured. Group interviews may be mistaken for focus groups, but the goal here is to capture the customers’ desired outcomes — an objective that is foreign in traditional focus groups, which are typically used to test concepts and get general customer feedback. To uncover desired outcomes, companies should first deconstruct the job into discrete steps and then ask, for each step, how performance is measured. For example, when Syngenta AG, a corn seed manufacturer based in Basel, Switzerland, was focused on learning how corn farmers dry the harvest — one specific step performed as part of the job of corn farming — the interviewer asked, “What makes drying the harvest slow or time consuming?” This elicited statements relating to getting the job done faster, such as “Minimize the time it takes to rid the harvest of moisture.” Asking “What makes drying the harvest unpredictable, unstable, or go off track?” helped uncover statements that related to executing the job with less variability, such as “Increase the likelihood that all plants emerge at the same time.” Finally, asking “What is it about drying the harvest that contributes to lower yields?” uncovered statements that relate to increasing output, such as “Minimize yield loss due to excessive heat during pollination.” Through this methodical line of questioning at each step in the value model, a complete picture emerges of all of the customer’s unique measures of value in getting the job done.

The fourth step is to conduct interviews to fill in any missing details that remain after completing the first three steps. A company knows that it has uncovered all the customer’s need statements when all attempts to capture outcomes related to speed, predictability and output have been exhausted for each process step in the job map.

The approach used to capture job statements is similar, but capturing job statements does not require the creation of a job map. Using a mix of personal, ethnographic and group interviews, companies can uncover all the jobs associated with a given demographic and context. With practice, a small pool of employees can be relied on to collect customer inputs for multiple areas of the business when the need arises. (See “Popping the Questions,”)

Adopting New Standards

Knowing what a customer need is in different situations and how requirement statements should be structured and formatted is the key to success in innovation. The outcome-driven innovation model detailed here works when applied to product and service innovation as well as design, operational, organizational and business model innovation. The concepts apply equally well in all situations because the job is the same: to figure out what solution best satisfies customers’ unmet needs.

By questioning old assumptions, companies can finally understand why the old models have not worked and why companies have been led astray by customer input. Job and outcome statements reflect the customer’s own definition of value, have universal and future relevance, prompt action, circumvent misinterpretation and help identify opportunities. With a new set of standards, companies finally can use their customers’ insights to lead them to the forefront of innovation.