Kano Model Prioritization

What is it?

The Kano Model is a method of analyzing potential product features based on customer perception [1] in order to select the features that deliver the greatest customer satisfaction while offering a viable product.  It originated in the product development space and was published by Dr. Noriaki Kano in 1984 in The Journal of the Japanese Society for Quality Control.  The model has also been applied as a prioritization method to the software development and project solution spaces.

Under the model, potential product features are evaluated on customer perception (or expected customer perception) and then assigned to different categories based on their expected impact on customer satisfaction.  The development team can then select the appropriate mixture of features that deliver the highest customer satisfaction given the constraints the team is operating under (time, budget, resources, etc.).

Feature Categories

As part of the model, Kano identified 5 different categories of product features based on client perception, however most discussions of the Kano Model focus on only three (sometimes four) of those categories. In addition, the names of the categories have been translated different ways by different parties, which means that they may have different names depending on who you are speaking to and which version of the category names they learned.

The table below (mostly taken from Wikipedia[1] with some modifications) summarizes the names of the categories that are commonly used.

 
Author Category 1 Category 2 Category 3 Category 4 Category 5
Kano (1984) Must-Be Attractive One-Dimensional Indifferent Reverse
Cadotte & Turgeon (1988) Dissatisfier Satisfier Critical Neutral
Brandt (1988) Minimum Requirement Value-Enhancing Hybrid Unimportant
Venkitaraman and Jaworski (1993) Flat Value-Added Key Low
Brandt and Scharioth (1998) Basic Attractive One-Dimensional Low-Impact
Llosa (1997 and 1999) Basic Plus Key Secondary
Pohl and Rupp (2011)       [3] Dissatisfier Delighter Satisfier
KanoModel.com Basic Excitement Performance Indifferent Reverse
 

Using the original Kano names (as interpreted above), the categories can be defined like this:

 

Must-Be

These are features that the customer takes for granted.[2] They may not explicitly tell you they want or need this features, but if one of these features is not present or not well constructed the customer will be extremely dissatisfied. Must-Be features are decisive factors[2], if they are not present the customer is not interested in the product at all.  Think of all of the Must-Be features as comprising your minimally acceptable product.  With even one feature missing, the product is not acceptable, no matter what else it may do.

Some examples of Must-Be features are:

The Must-Be features can be thought of as the cost of entry for competing in the product space.  As the graph below shows, even executing all Must-Be features very well does not generate much customer satisfaction because all you are providing is the bare minimum.  Customers expect all the of Must-Be features, and more.

  Kano Model - Must Be Attributes  

To summarize:

If you were mapping the Kano Model to MoSCoW Prioritization, these are "Must Have" priority features.

 

Attractive

These are features that the customer does not request or expect, but which if they are fulfilled leads to a disproportional increase in satisfaction.[2]  Conversely, if they are not present the customer is not dissatisfied.

Attractive features can be thought of as the product differentiators that can really separate your product from competitors.  As the graph below shows, even poor execution of Attractive features adds to customer satisfaction because these are features the customer did not expect at all.  Much like extra gifts on Christmas morning, they delight the customer and because they were unexpected, their absence has no negative implication.

  Kano Model - Attractive Attributes  

To summarize:

If you were mapping the Kano Model to MoSCoW Prioritization, these are "Could Have" priority features.

 

One-Dimensional

These are features that the customer has explicitly demanded and which have the greatest impact on customer satisfaction.[2] Customer satisfaction with One-Dimensional features is directly proportional to the level of fulfillment of the customer's stated desires (thus the one-dimensional name). The higher the quality or level of implementation of the customer's request, the higher their satisfaction. However, products which only fulfill the Must-Be and One-Dimensional features are perceived as average and therefore interchangeable. [1]

The One-Dimensional features can be thought of as your competitive product features where the level or quality of implementation of the feature, or the total number of features, are the main points of concerns.

As the graph below shows, the quality of execution is critical for One-Dimensional features. Do them poorly, or don't do enough of them, and the customer can be very dissatisfied. Do them well, and the client rapidly becomes happy with your product.

  Kano Model - One Dimensional Attributes

To summarize:

If you were mapping the Kano Model to MoSCoW Prioritization, these are Should Have priority features.

 

Indifferent

These are features the customer simply doesn't care about. The customer does not care if they are present or absent.[4]  As displayed in the graph, whether these features are present or not, or implemented well or not, simply does not matter to the customer.  However, that does NOT mean that the features may not be valuable or useful to someone other than the customer.

These are frequently features that the manufacturer finds value in, but not the customer.  Features that making servicing or fixing a product easier or cheaper, or that make it easier to do incremental improvements to the design over time are examples of useful features that customers may be Indifferent to.

As the graph below shows, there is no impact of Indifferent features on customer satisfaction.

  Kano Model - Indifferent Attributes

To summarize:

 

Reverse

The Reverse category is the opposite of the One-Dimensional category. These are features that when present cause dissatisfaction, and when absent cause satisfaction.[4]  These are features that the customer actively dislikes.  As the graph below shows, the more of these that are implemented the more unhappy the customer is.  When they are not implemented at all, the customer is most satisfied.

  Kano Model - Reverse Attributes  

To Summarize:

If you were mapping the Kano Model to MoSCoW Prioritization, these are "Won't Have" priority features.

 

The Two Complications

There are two complications (OK, I call them complications, you call them whatever you want) to evaluating features with the Kano Model.  Both are well known.

The impact of Time

The first complication has to do with the impact of time on customer perception.  Kano pointed out that features that are Attractive initially because they were unexpected, soon come to be expected (One-Dimensional), and then frequently Must-Be.

An example of this is the camera function in cell phones.  Initially it was an Attractive feature.  Many customers initially thought, Who ever thought of putting a camera in your phone? You mean I don't have to carry a separate camera with me all the time? What a great idea!

But then camera's in cell phones became a One-Dimensional feature.  Users expected them.  And features such as the quality of the camera, how easy it was to take pictures, and whether customers could quickly share photo's they took via social media all became important factors.  Cell phone makers started competing on those features and customers differentiated among camera quality when evaluating competing cell phones.

Now in some places (Europe, North America, and parts of Asia mostly) a camera in a cell phone is almost a Must-Be feature for any smart phone.  Even in lower-end smart phones.

The diagram below shows this effect, as the purple arrow shows a feature moving from Attractive, to One-Dimensional, to Must-Be over time.

  Kano Model - The Effect of Time  

Inconsistent Customer Expectations

The second complication has to do with the fact that different customers are likely to have different perceptions of the same feature. The exact same feature could be classified as Attractive, One-Dimensional, and Reverse by different potential customers. To use the camera example above, a camera in a cell phone might be:

The problem is that so far I have not come across any recommendations for how you balance these differing perceptions.  I would assume that most users of the Kano Model try to target the largest potential customer base and favor the perceptions of the largest groups where they overlap.  Or perhaps create different versions of a product that target specific customer segments.

 

Why do it?

The Kano model is particularly useful when evaluating feature trade-offs of a potential product, especially when there is not enough time or resources to provide every potential feature.

 

How do I do it?

NOTE:  I have not found a detailed guide to conducting a Kano Model process, so this section includes a fair amount of my own ideas combined with information from references [1] and [5] below.  This process is fairly time-intensive, so you may want to cut out steps where that is feasible or desirable.

Step 1

Define the problem your product is intended to solve, and the target audience you want to offer that solution to.

If you are working on a project to build an internal-only solution, this is done as part of the project initiative.  But if you are building a product for mass-consumption, this can be more difficult.

 

Step 2

Identify customers that will be willing to participate in the Kano Model analysis.

Research indicates that 20-30 customer interviews are sufficient to identify 90-95% of all product requirements.[1]  However, identifying that number of willing participants and conducting that number of interviews may prove challenging.  When identifying participants, try to select from enough potential customer groups that your target market is broadly represented.  If all of your participants are from a narrow part of your target customer base, then you may not get all the information you need.

 

Step 3

Interview your participants, being sure to ask about the problems they need solved, not just the features they desire.  It is IMPORTANT that you remember that you are asking about generic features, functions and capabilities.  Most of the time you should not be asking about specific ways or methods of implementing those features and functions.  Ask about:

If asking about a specific product (either an existing one you are trying to improve or replace, or competitor's products), there are some additional questions you can ask as well. They are: [1]

Lastly, the Software Engineering Institute at Carnegie Mellon University has provided 10 example interview questions you can use when using the Kano Model.  Those example questions are: [6]

  1. What were some of your most negative experiences in the past regarding .... ?
  2. What were some of your most positive experiences in the past regarding ... ?
  3. What do you wish you could also do when performing ...?
  4. Who else would you like to be able to interact with when performing ...?
  5. How do you feel when something specific such as ... occurs?
  6. How do others around you feel about ...?
  7. How could you be more effective? productive? efficient?
  8. In what ways would you be happier or more fulfilled in performing ...?
  9. When and where do you use ...?

This activity is geared mostly to eliciting One-Dimensional features, but also elicits supporting information as well.

 

Step 4

Analyze the current solution (if any), key competitive solutions (if any), and the existing business process. The goal here is to identify features or requirements that were not explicitly stated.  This involves:

This activity is geared mostly towards identifying unstated Must-Be features, and identifying potential One-Dimensional and Attractive features.

 

Step 5

Using the information gathered in Steps 3 and 4, the development team (and possibly others, such as internal SME's if available) should brainstorm additional features that were not defined in the prior two steps.

This is a brainstorming activity, not an activity to analyze the potential features for pros and cons.  The idea is simply to come up with alternate features that have not been considered so far.

This activity is geared mostly to identifying Attractive features.

 

Step 6

The next step is to rationalize and organize all of the features generated by Steps 3, 4, and 5.  Go through them and organize the features by area or function, clarify language if necessary, and remove duplicates.  Additionally, the language of the feature descriptions should be modified (if necessary) so that it features are described by their utility to the customer and to ensure they do not describe technical solutions to the customers problems.

The output of this step should an ordered and structured list of potential features.

 

Step 7

Once the features have been organized and clarified, the next step is to create a customer survey.  For the survey, two questions are generated for each feature in the feature list created in Step 6 above.

The first question asks the customer what their reaction would be if the feature is included in the product (the functional question). The second question asks the customer what their reaction would be if the feature was NOT included in the product (the dysfunctional question).  Both questions use the same group of possible answers, which are: [1]

  1. I like it that way.
  2. It must be that way.
  3. I am neutral.
  4. I can live with it that way.
  5. I dislike it that way.

In addition to the survey questions, you may also want to ask the survey participants to rank the features.  You can ask them to rank each feature from 1-x (where x is the number of features the customer is evaluating in the survey), or you can ask them to rank each feature on a set scale (say from 0 to 10 where zero is completely unimportant and 10 extremely important).  If you are asking about a large number of features, you may want to use a generic scale for each feature or break the survey up into sections based on feature category (so that there are fewer features in each category to rank).

This also allows the survey participant to focus on one area of functionality at a time, and to potentially (if asked) rank their preference for the features within a specific feature category.  If you do use feature categories and ranking within the survey, you may also want to ask the survey participant to rank the categories as well as the individual features within the categories.

 

Step 8

Once the survey has been completed, it is provided to the participants (and potentially others since responding to the survey is often less work than participating in the interview process discussed in Step 3).

Make sure to track the survey responses to the individual that provided them.  Depending on the number of survey participants, it may be a good idea to assign the participants to persona groups that represent different potential user types in order to better understand the features that each persona type values.

 

Step 9

Once the surveys have been administered, the results are collected and analyzed.  For each feature, the results of the functional and dysfunctional questions are paired to determine the category that feature is assigned to based on that customer's responses. The table below is used along with the answers to determine the category:

  Kano Model - Sample Table of Results

Please note that this table includes a new category value of Questionable.  This is not an actual Kano Model category.  Rather, answers that fit this criteria usually signify that the questions were phrased incorrectly, that the customer did not understand the question, or that there was a mistake in selecting a survey answer.

 

Step 10

Once all the surveys have been analyzed and the features assigned to categories based on each individual survey-takers responses, the development team then aggregates the survey responses and tracks the overall results for each feature.  If the survey participants were assigned to persona groups, you will want to aggregate the responses at the persona level.

An easy way to do this is with a simple table such as the one below:

 
Feature Name Attractive One-Dimensional Must-Be Indifferent Reverse Questionable Total % Final Category
Feature 1 8% 45% 32% 11% 3% 1% 100% One-Dimensional
Feature 2 12% 20% 10% 40% 18% 0% 100% Indifferent
Feature 3 55% 32% 2% 9% 1% 1% 100% Attractive
 

Because there are likely to be some features where customer responses vary considerably to the same potential features, even among the same persona groups, part of the development teams work at this point is to evaluate any contradicting responses and determine which category assignment they are going to move forward with for that feature.  Feature 2 in the table above is one that might require team discussion given that while roughly 42% of customer found it desirable, nearly 20% had a strongly negative reaction and another 20% were indifferent. This is the type of feature that may need to be carefully targeted to specific customer audiences or be implemented in such a way as to be easy enabled or disabled.

One way to further evaluate each feature is to calculate its satisfaction and dissatisfaction coefficients.[1]  Using the information in the table above you would calculate the coefficients using these formulas:

Satisfaction Coefficient = Attractive + One-Dimensional / Attractive + One-Dimensional + Must-Be + Indifferent

Dissatisfaction Coefficient = One-Dimensional + Must-Be / (Attractive + One-Dimensional + Must-Be + Indifferent) x (-1)

 

So for Feature 2 above, we would get these results:

(12+20) / (12+20+10+40) = 0.3902

(20+10) / (12+20+10+40)x(-1) = -0.3659

The Satisfaction Coefficient ranges from 0 to 1, with values closer to one having a higher influence on customer satisfaction.  The Dissatisfaction Coefficient ranges from 0 to -1, with values closer to negative one having a higher influence on customer dissatisfaction.

Based on these values for Feature 2 you can see that it causes slightly more satisfaction than dissatisfaction, but given that both values are much closer to 0 than 1 / -1, it's a feature that may be best left out of the product initially.

 

Step 11

Once the analysis is done, the development team needs to define the initial product that will be built based on the time, resources, and defined goals of the product.  Important goal-questions that drive decisions here can be whether the product is targeted at a mass-market or a specific user-base (such as an internal development project), the target audience (if there are multiple audiences, which is preferred or are multiple versions of the product to be built), and whether the product is expected to be frequently updated or must meet its target customer's needs for long periods in between enhancements (the fewer upgrades, or longer period between, the more the product must focus on meeting as many core needs as possible).

A general rule for selecting features is that they can be prioritized based on their final assigned category in this order:

Must Be -> One-Dimensional -> Attractive -> Indifferent

This selects features for first preventing dissatisfaction as the highest priority, with features that add satisfaction coming secondary.

Also, this evaluation effort is where customer rankings (if they were collected) can be very useful in helping the development prioritize exactly which features are most important out of any category.

 

What Should the Results be?

The results of a Kano Model analysis should be a product feature set that results in the highest customer satisfaction given the constraints the development effort is operating under. If the product is expected to be continually developed, or go through multiple iterations, the resulting feature set should also be broken down by release (at least roughly).

By using the Kano Model process, the product can be implemented so that customer dissatisfaction is discouraged (by focusing on Must-Be and One-Dimensional feature first) and features that engender satisfaction are included or improved as resources allow.

 

Advantages

 

Disadvantages

 

Tips

 

References

  1. Wikipedia page: Kano Model. Accessed on January 20, 2014.
  2. Research Paper: The Kano Model - How to Delight Your Customers. By Elmar Sauerwein, Franz Bailom, Kurt Matzler, and Hans H. Hinterhuber. In:  Preprints Volume 1 of the IX, International Working Seminar on Production Economics, Innsbruck/Igls/Austria, February 19-23 1996, pp. 313-327.
  3. Book:  Requirements Engineering Fundamentals - A Study Guide for the Certified Professional for Requirements Engineering Exam Foundation Level. By Klaus Pohl and Chris Rupp. 2011. Rocky Nook, Inc.  Pgs. 22-23
  4. Article: Discovering the Kano Model. By Dave Verduyn. On the KanoModel.com web site.
  5. Article: Kano Model Analysis - Delivering Products that Delight.  No author identified. On MindTools.com.  Accessed on July 3, 2014.
  6. Presentation:  Elicitation of Unstated Needs - Training Session 1 (KJ+ Method Overview).  No individual authors identified.  On the Software Engineering Institute website.  Accessed January 12, 2016.
 

Related Resources