Kano model: sort features into must-haves, performance and delighters

The Kano model is a way to sort product features by how customers feel when a feature is there and how they feel when it is missing. Noriaki Kano and his colleagues published it in 1984, and it splits features into must-be, one-dimensional (usually called performance), attractive, indifferent and reverse. Use it to decide what to build first: fix missing must-be features, then add performance features, then pick a few attractive ones, and read every result as a snapshot that will age.

The idea that makes it useful is that satisfaction is lopsided. Some features only cause complaints when absent and earn no credit when present. Others earn delight when present and cause no complaints when absent. A plain "how important is this?" survey cannot tell those apart, and the Kano questionnaire can.

1. Learn the five categories, because the names vary from source to source

The original paper is "Attractive quality and must-be quality" by Kano, Seraku, Takahashi and Tsuji, in the Journal of the Japanese Society for Quality Control, as cited by Nayebi and Ruhe. Later writers renamed most of the categories, so here is the map, using Daniel Zacarias's guide on Folding Burritos for the alternate names:

There is a sixth label, questionable, for answer pairs that contradict each other. Nayebi and Ruhe describe it as a sign of a problem in how the question was phrased or understood, and they leave those answers out of the analysis. Zacarias treats reverse and questionable as artifacts of the questionnaire rather than true categories.

Indifferent is the most useful category nobody wants to hear about. It is where the feature your cofounder has been sketching on napkins for a month might land.

2. Ask two questions per feature, and phrase both around the benefit

Each feature gets a pair of questions. The functional one asks how the person would feel if the product had the feature. The dysfunctional one asks how they would feel if it did not. Nayebi and Ruhe give the five answer choices from the original paper:

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

Zacarias recommends plainer wording for the same five answers: I like it, I expect it, I am neutral, I can tolerate it, I dislike it. Use his version. "It must be that way" confuses people who are not quality engineers, which is most people.

Two more rules from his guide. Phrase the question around what the person gets ("If you can automatically improve how your photo looks, how do you feel?"), not around how it works. And write the dysfunctional question about the feature being absent, which is not always the opposite of the functional question.

He also describes a third question that several teams add: how important the feature is, on a 1 to 9 scale. Add it. It helps you separate a must-be that people care about intensely from one they barely think about.

3. Score every answer pair with the evaluation table

Each respondent's pair of answers maps to one category through the evaluation table. Rows are the answer to the functional question (feature present) and columns are the answer to the dysfunctional question (feature absent). This version is reproduced from Nayebi and Ruhe, who credit Kano's 1984 paper:

The letters are A for attractive, O for one-dimensional, M for must-be, I for indifferent, R for reverse and Q for questionable.

Three patterns carry most of the meaning. Like it present and dislike it absent is one-dimensional. Like it present and expect, neutral or live with it absent is attractive. Expect, neutral or live with it present, combined with dislike when absent, is must-be. Zacarias notes that a revision by Pouliot also marks the expect/expect and tolerate/tolerate cells as questionable, so check which table your survey tool uses before comparing results across studies.

4. Read the results with counts first, then two coefficients

Here is a made-up example. A small company sells appointment software to physiotherapy clinics and is choosing between three features. It surveys 40 clinic managers, one segment, and scores each manager's answers with the table:

The simplest reading, which Zacarias calls discrete analysis, takes the most common category for each feature. Reminders are must-be, booking is one-dimensional and the waitlist is attractive. When two categories are close, his tie-break is must-be, then performance, then attractive, then indifferent.

The counts hide how strong each pull is, so add the coefficients from Berger and colleagues (1993), as given by Nayebi and Ruhe. Satisfaction is (A + O) divided by (A + O + M + I). Dissatisfaction is (M + O) divided by the same total. Reverse and questionable answers are left out.

• Reminders: satisfaction 12 / 39 = 0.31, dissatisfaction 31 / 39 = 0.79.
• Booking: satisfaction 25 / 39 = 0.64, dissatisfaction 26 / 39 = 0.67.
• Waitlist: satisfaction 23 / 36 = 0.64, dissatisfaction 8 / 36 = 0.22.

The decision follows. If the product lacks reminders, build them first: managers will be unhappy without them and will not thank you for them. Booking moves satisfaction both ways, so it is the next investment. The waitlist pleases about as much as booking but costs little goodwill if it waits a quarter. (The 11 indifferent managers presumably have patients who never cancel. Lucky them.)

Short version: take the most common category per feature, then use the two coefficients to rank features inside a category.

Zacarias also describes a continuous method, credited to DuMouchel, that turns each answer into a score and plots the averages with error bars. It is worth it once you have dozens of features and hundreds of answers. For three features and 40 managers, the table above is enough.

5. Build missing must-be features before performance ones, even though sources disagree

Zacarias says to build must-be features first, then as many performance features as you can, then a few attractive ones. NN/g's prioritization article (Sarah Gibbons, 2021) lists performance first, then must-be, then attractive, then indifferent.

Follow the must-be-first order when a must-be is actually missing. A clinic that cannot send reminders will not stay long enough to enjoy your booking page. The tradeoff: must-be work rarely shows up in a demo, so expect it to feel like slow progress.

Note that NN/g's version is a different exercise. Its team scores each item on functionality and satisfaction from -2 to 2 and plots them, with satisfaction drawn from user research. That is a fine workshop format, but it is the team's judgment on a chart, not the paired-question survey.

6. Rerun the survey when competitors catch up, because delighters decay into must-haves

Zacarias points out that attractive features turn into performance and then must-be features over time. His example is the iPhone touchscreen, which amazed people in 2007 and is now a basic expectation. He names competitors rushing to offer the same functionality as one of the causes.

So treat a Kano result as dated the day you collect it. In the made-up example, the cancellation waitlist is attractive this year. Once two competitors ship one, clinic managers will start answering "I expect it" and the same feature becomes a must-be you are late on.

The tradeoff of rerunning is survey fatigue among the same customers. Rotate who you ask, and only retest features that a competitor has shipped since.

7. Do not trust a Kano survey from a dozen B2B customers on its own

Kano is a counting method, and counting needs numbers. Zacarias recommends at least 15 customers per demographic, segmenting by persona, and testing no more than three features in a first study when respondents are volunteers.

Many B2B products cannot meet that. If you have 12 customers and the buyer, admin and daily user each answer differently, you have three segments of four people. One person switching an answer can flip a feature's category.

In that situation, run the survey as a conversation starter and pair it with interviews. Ask each respondent about the last time they needed the feature, and pay attention to anyone whose answers came out questionable, since that usually means the question confused them. Zacarias notes that a majority of questionable answers points to a problem with what you are asking. How to validate feature requests covers how to turn a request into the job behind it, and product survey questions covers keeping the survey short enough to finish.

Kano also says nothing about price. It tells you a feature would delight people, not that they would pay more for it. For that, look at willingness to pay research, and if you have a few hundred buyers and a packaging decision, conjoint analysis.

Your next step

Pick the three features you are arguing about, write a functional and a dysfunctional question for each around the benefit, and test the wording on two colleagues before sending it to customers. If you lack enough customers in a segment, Instant Expert can find people who match a description such as "practice managers at physiotherapy clinics with three or more locations" and send them paid invitations for a short call or a written answer, and you pay only if someone books or answers. For help designing the study, see the directory pages for product management consultants and user research experts.