Make Kano analysis part of your new products requirements
by John C. Goodpasture, PMP
Is Noriaki Kano a familiar name to you? If you are a new products development project manager with a myriad of requirements and decisions to make about their importance and impact on your project, Professor Kano's methods may provide help. “Kano analysis,” as many call it, helps you and your team evaluate product requirements: which requirements drive customer satisfaction, and how do these same requirements impact functionality and capability? [Shoji Shiba, Alan Graham, and David Walden, A New American TQM: Four Practical Revolutions in Management, 1993, Productivity Press]. If this sounds like a traditional matrix array of two requirement influencers, it is, in part. But there is more. Kano analysis adds a degree of dynamic behavior, somewhat a unique perspective, to what is otherwise static. Furthermore, this analysis helps provide the information and insight for those all-important investment decisions that you have to make in the face of scarce resources. Your understanding of this analysis brings valuable insight that you can apply when asking questions of your potential product customers. 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. First, we use a chart (such as shown in Exhibit 1) to display the information needed for a Kano analysis. Requirements, per se, are not on the chart. As we will see, a family of curves displays the nature of requirements. 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.
For instance, 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. Other examples are found in regulatory requirements. These are not often the requirements of the end user. If they are missing, or made less burdensome, then end-user satisfaction may go up. Handgun trigger locks may to some degree fall in this quadrant.
The upper right is the area of “customer delight.” In this quadrant, the customer is increasingly happy with a more capable and functional product. No problem with examples for this quadrant. More memory, more horsepower, more speed, more buttons and knobs all drive delight.
What about the quadrants in the lower half of the chart? To the lower right and left, the customer is dissatisfied, regardless of functionality. In the left and lower quadrant, perhaps functionality is missing or it is disappointing as implemented and delivered. Consider the reaction of many to the introduction some years ago of the “small” spare wheel and tire 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.
Look now at the axes. Running horizontally through the center is a line representing indifferent priority or disinterest on the part of the customer, regardless of where the requirement lies 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. And last is the vertical center axis intersecting the horizontal at the point of “zero functionality.” For our purposes, the center vertical axis holds no significance: there is no functionality to evaluate.
Requirement Curves. Now let's put a family of curves on the Kano chart, as shown in Exhibit 2. 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. This is familiar to most of us who have shopped for a computer for the office or home. Always our attention as customers is drawn to the CPU “speed.” We are told, “More is better.” CPU speed has been made into a powerful product discriminator. An underpowered, sluggish product does not satisfy. The curve starts out in the lower left: the more sluggish, the more dissatisfied. The line extends to the far upper right. 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 somewhat dynamic property of “L” requirements.
■ Improvement is almost mandatory to maintain or expand market share, or the impact of “L” requirements decays. Decay is another dynamic property. Decay may have a slope greater than refreshment or improvement.
■ “L” requirements are a high priority for funding because they influence customer satisfaction so greatly. In effect, the product manager may not have discretion to not fund an “L” requirement.
■ 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 add value for the customer in a manner that will influence a buying decision. Example: Your palm computer meets all the regulatory requirements of the FCC for electronic emissions. To most customers, the reaction is “that's nice to know.” It just doesn't 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. Promotion is a dynamic of Kano analysis. Promotion is no small achievement. Decay is more often the case.
Exhibit 1. The Kano chart is a grid that shows relationships between customer satisfaction and product functionality.
Exhibit 2. These curves illustrate the behavior of customer satisfaction as functions of product functionality.
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.
Exhibit 3. Kano analysis is a tool for making funding choices and evaluating risk.
■ 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 ha!,” or “A,” requirements. “M” requirements start out along the far right X-axis, but curve dramatically downward in the lower left quadrant. The practical view of the “M” requirement is 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. Continuing with the computer example, 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.
■ Because 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.
The “A” requirements are almost the mirror image of the “M” requirements. “A” requirements start low in the upper left quadrant and curve upward to the upper right quadrant. These are the “ah has!” or attractive discriminators. To customers, “A's” start as though they are latent, not missed if not present (upper left quadrant). Very often, they 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 are 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 managers prioritize the “A” requirements; they are not mandatory; usually they are not tied to legacy products 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, the project manager develops a plan and interview strategy to validate the key requirements, such as the typical plan shown in Exhibit 4. There are several question styles:
Exhibit 4. Kano analysis is used to develop the customer and end-user interview questions.
■ “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…?”
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 into 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 and is a valuable tool for all those engaged in new product development.
Reader Service Number 184
John Goodpasture, PMP, is founder and chief consulting officer at Square Peg Consulting, specializing in project management, business process analysis, and training. He has broad practical experience in executive management, project management, system engineering, and operations analysis obtained in a career in government and industry.
PM Network May 2001
May 2001 PM Network