Get your new products requirements right with Kano analysis
Are you looking for a tool to assist your development of new product requirements? “Kano analysis,” as many call it, may be part of the answer. Kano analysis is named for its inventor, Noriaki Kano. Kano analysis provides help on two vexing tasks: identify and zero-in on the requirements that drive customer satisfaction, and ascertain how these same requirements impact functionality and capability (Shiba, Graham, & Walden 1993). And, Kano includes time-variant behavior analysis and insight for those all-important investment decisions that you have to make in the face of scarce resources. Kano analysis is no magic bullet, but it's a tool that can help. Latent (hidden) requirements may be discovered or made more obvious. Requirements that are “ah-ha's” today, but may be taken for granted tomorrow, can be identified and prioritized. Let's see how this valuable tool works.
The Kano Chart
Exhibit 1 illustrates the Kano chart. Requirements, per se, are not on the chart. The nature of requirements will be shown with a family of curves. The x-axis represents product functionality or feature richness. Along the x-axis to the right is increasing functionality; to the left, decreasing, absent, or dysfunctionality. The y-axis represents customer satisfaction. Satisfaction increases above the x-axis, it's neutral in the middle where x and y cross, and decreases (growing dissatisfaction) below the x-axis. These axes form four quadrants.
The upper-left quadrant represents positive customer satisfaction in spite of poor or missing functionality. This is the quadrant of latent requirements. In effect, functionality not known to the customer and not provided does not impact product satisfaction.
The upper right is the area of “customer delight.” In this quadrant, the customer is increasingly happy with a more capable and functional product. More memory, more horsepower, more speed, more buttons and knobs all drive delight.
To the lower right and left, the customer is dissatisfied, regardless of functionality. In the left and lower quadrant, functionality is missing or it is disappointing as implemented and delivered. The “small” spare wheel and tire is an example in this quadrant. It was introduced as a weight and cost-saving alternative to the full-size “fifth wheel.” Some functionality of a full-size wheel is missing with this implementation: lower-left quadrant for sure. A minimum functionality of a spare tire is provided, but its very limitations are disappointing nevertheless: lower-right quadrant.
Running horizontally through the chart center is a line representing indifferent priority or disinterest on the part of the customer, regardless of where the requirement lays on the functionality axis. Regulatory requirements that do not raise customer ire or delight fall along this axis. So do company mandated internal requirements that may be altogether necessary to a good product, but have no impact on customer satisfaction.
Now, let's put a family of curves on the Kano chart. Exhibit 2 illustrates the new chart. At first glance, Kano shows what we all know intuitively: some requirements lead to increasing satisfaction with increasing functionality or feature. This idea is represented on the chart as a straight line from the lower left to the upper right. Perhaps a familiar example will show the principle. Consider the computer CPU “megahertz” race. Product developers exclaim: “more is better.” CPU speed has been made into a powerful product discriminator. These requirements are “linear,” labeled “L,” and have the feature that customer satisfaction grows with increasing performance or functionality. Here are the rules for the “L” requirements:
• So long as there is customer demand, “L” requirements require constant investment for refreshment. Refreshment is a time-ordered property of “L” requirements.
• Improvement is almost mandatory to maintain or expand market share, or the impact of “L” requirements decays. L-requirements decay to the horizontal axis. Decay is another time-sensitive property. “L” requirements are a high priority for funding because they influence customer satisfaction so greatly.
• Refreshment requires a “set-aside” in the overall product development budget to continue innovation and competitiveness.
Already mentioned are the requirements that lie along the x-axis but generate no customer interest, whether satisfied or not. These are usually labeled “indifferent,” or “I.” “I” requirements are not necessarily unimportant; “I‘s” just don't influence a buying decision. Example: your palm computer product meets all the regulatory requirements of the FCC for electronic emissions. To most customers, these requirements do not matter much to the customer. Often, internal requirements are just like regulatory requirements. Internal requirements many times fall into the “I” category. Of course, they don't have to. Consider this: external packaging of the desktop computer used to be an “I” for many consumers. Packaging was pretty standard and did not offer much in the way of product discrimination. But Apple has certainly changed that, promoting the packaging “I” into a customer delight category.
Here are the “I” rules for the project manager:
• Make the minimum resource investment possible to meet the requirement.
• Take no risks with “I” requirements beyond those risks necessary to achieve compliance.
• Be compliant, but challenge these requirements before expending time and money.
• Look for opportunities to promote these requirements to the upper half of the chart, thereby gaining a customer reward for an otherwise mandatory investment.
Two interesting curves represent the “must exist,” or “M,” and the “attractive/ ah-hah!,” or “A” requirements. “M” requirements start out along the far right x-axis, but curve dramatically downward in the lower-left quadrant. The “M” requirement is one that if present, the customer is not likely to notice, but if absent, the customer will be highly distressed. Said another way: “M” requirements are the “me-too's,” which do not discriminate well, but if missing are highly detrimental to product acceptance. Look at the floppy disk drive. Is it an “M,” almost unnoticed until missing, or is it an “I”? Like the “I” requirements, “M” requirements rules are straightforward:
• The project manager constantly reevaluates risks; taking no more risk than is required for a minimum capability
• The project manager regulates resource impact, again making the minimum commitment possible
• On account of the potentially sharp reaction to missing or dysfunctional performance, the project manager is mindful of obsolescence. The minimum effort to keep up to the minimum market standard is all that is needed.
“A” requirements start low in the upper left quadrant and curve upward to the upper-right quadrant. These are the “ah-hahs!” or attractive discriminators. Very often, “A‘s” are the features that customers did not know they needed until they saw them. As such, the “A‘s” originate in the “fuzzy front-end” of product development. Whereas the “I‘s” and “M‘s” are sometimes legacy requirements from prior product versions, by and large the “A‘s” are new-to-the-market. As such, their “staying power” is less proven, but their uniqueness makes their potential to discriminate the product much greater, particularly with early adopters. “A‘s” have a tendency to “decay” toward “M” or “I” once they become mainstream. Perhaps the read/write CD, the so-called CD-RW, is a good example of a latent requirement that has become visible, represents the discriminating buying decision in many cases, but may decay to an “M” as it becomes standard equipment.
Here some rules for the “A” requirements:
• “A” requirements are risk prone. Risk analysis is a prudent investment to be made by the project manager.
• Project and product mangers prioritize the “A” requirements; they are not mandatory; usually they are not tied to legacy product already in the market.
• “A” requirements are often highly leveraged for value. Though risky, if successful, they return their investment many times.
Exhibit 3 summarizes the new product development requirements of our computer example.
Asking the Right Questions
In the cycle of new product development, there will be opportunities to address requirements with customers. With Kano analysis as a goal in mind, the project manager develops a plan and interview strategy to validate the key requirements. Exhibit 4 is a typical plan. There are several question styles:
• “Confirming” questions reaffirm the “M” requirements
• “Exploratory” questions test the strength of the “A” and “L” requirements, or they can reveal otherwise latent requirements that may well be “A‘s.”
• “Take-away” questions test the practicality of removing both “I” and “M” capabilities. Take-away questions are of the type: “What if the floppy disk drive were not provided, etc.?”
Sometimes it is necessary to pair questions to obtain effective insight. For instance, “L” requirements can be tested for expansion in the upper-right quadrant with confirming or exploratory requirements, and their sensitivity to decay can be tested with take-away questions.
Kano analysis provides insight to the nature of requirements. The project manager uses the analysis results to make investment decisions, to develop risk assessments, to fashion a strategy for addressing the customer, and for challenging requirements that may no longer be relevant. Kano analysis has the potential to reveal opportunities for promoting requirements into greater influence. Kano analysis is a valuable tool for all those engaged in new product development.
Shiba, Graham, and Walden. 1993. A New American TQM, Four Practical Revolutions in Management. Productivity Press, pp. 221–230.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA