Kano Model Prioritization

IMPORTANT! If you are going to use any prioritization method, be sure that you actually implement more than just the highest level of priority items. If stakeholders consistently see that all that will implemented are the highest priority items, then soon they will stop believing that priority levels mean anything and that everything that is not flagged as the highest priority will not get implemented. And if that occurs, then either everything your clients prioritize will be the highest priority or they simply will no longer cooperate because they have lost confidence in the process.


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:



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:

  • That the product complies with all appropriate laws and regulations
  • That a software program could be used with most common interface devices (trackball, mouse, keyboard, etc.)
  • That the user interface is not extremely difficult to work with or unusable
  • That the gas tank in a vehicle does not explode on impact or that some other foreseeable non-standard use (an accident) does not result in the users death
  • That the product does the main thing it is supposed to do (can I track customer info in my CRM system?)

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.




To summarize:

  • May not be explicitly stated by the customer.  They usually fall under “assumed knowledge” on the client’s part.
  • ALL “Must-Be” features MUST be present and usable.  If not present and usable, the product is unacceptable.

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



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.




To summarize:

  • Not stated / requested or expected by customer
  • If present, provide disproportional satisfaction
  • If not present, provide no dissatisfaction

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



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.



To summarize:

  • Explicitly stated / requested by the customer
  • Level of customer satisfaction is equal to level of fulfillment in the product of the customer’s request
  • If not present, does not add to dissatisfaction, but does not increase satisfaction

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



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.



To summarize:

  • Cause no satisfaction when either present or not present.
  • Cause no dissatisfaction when either present or not present.
  • The customer may be indifferent, but that does not mean the feature may not have value to others (manufacturers, distributors, etc.)



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.




To Summarize:

  • Cause satisfaction when NOT present.
  • Cause dissatisfaction when present.

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.




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:

  • Attractive to customers in parts of the world where computers, digital cameras, and similar products are still very expensive or rare
  • One-Dimensional in most of the world where having a camera as part of a cell phone is no longer a novelty, and where the quality of the camera becomes a factor
  • Must-Be (for smart phones at least) in parts of the world where smart phones with cameras have virtually saturated the market
  • Reverse to those users who “… just want to make phone calls dammit! I don’t need a freaking camera in my phone!” 🙂

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:

  • What they are using now to solve their problem (if anything).
  • What are their current pain-points? Ask about both process, technology, and skill issues.
  • What are the minimum capabilities / features they think they need to solve their problem?
  • Similar questions that you would use in standard elicitation activities.

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]

  • What associations does the customer make when using product (x)?
  • Which problems / defects / complaints does the customer associate with the use of product (x)?
  • What criteria did / would the customer take into consideration buying product (x)?
  • Which new features or services would better meet the expectations of the customer? What would the customer change about product (x)?
  • Are there any features of product (x) that they actively dislike?

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:

  • Documenting the existing solution features (to identify those not specifically mentioned)
  • Examining potential solutions or potential competitive products in order to determine what are the features already in the marketplace.  You are looking for those features they all have in common (likely Must-Be and One-Dimensional) as well as outlier features that may be future One-Dimensional features or otherwise offer a competitive advantage.
  • What are the conditions the product will be used in?  As an example, what would be the likely application environment?  This type of information can lead to unstated performance, compatibility, durability, and similar unstated features.
  • Analyzing the current or likely (if for general market consumption) business process to look for feature gaps, improvement or automation opportunities, or unstated constraints.

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:



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 must 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.



  • The results of a well-done Kano Model process can give the product developer very detailed insights into customer preferences, and potentially into customer segments, for the problem-space that was analyzed.  This information should enable the development of a viable product that can be enhanced over to time, or initially released with a feature set that makes it highly competitive from day one.
  • If used for internal development, the Kano Model analysis lets the project team select the feature set that delivers the highest customer satisfaction.  Or to show the expected satisfaction with the product that could be developed under different resource scenario’s using the Satisfaction and Dissatisfaction Coefficients for features that could be implemented or not under various scenarios.



  • A full Kano Model analysis can be very time-consuming, and potentially expensive (especially if travel is required to interview customers, if there are a large number of interviews, in the time of the development team members, etc.).
  • Because the Kano Model process focuses on the customer’s perception of potential product features, it is very easy to overlook important features that the customer may not think of or be aware of (non-functional requirements, regulatory requirements, performance requirements, maintainability and support needs, etc.).



  • Many of the activities undertaken as part of a Kano Model analysis lend themselves to automation.  The survey administration and results analysis should be relatively easy to automate via web portals, SharePoint, or similar systems.  At a minimum, you could create the survey and automate most of the analysis in Excel.



  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.


Other Resources



© 2014 by David Olson

Leave a Reply

Your email address will not be published. Required fields are marked *