Kano Model: How to Prioritize by Customer Delight

What is the Kano model in plain terms?

The Kano model is a way of sorting product features by the shape of their relationship with customer satisfaction rather than by a single importance rating. It assumes satisfaction is asymmetric: the same feature can create delight when it exists and create nothing when it is missing, or the reverse.

Noriaki Kano, Nobuhiko Seraku, Fumio Takahashi, and Shin-ichi Tsuji published the original theory as “Attractive Quality and Must-Be Quality” in the Journal of the Japanese Society for Quality Control in 1984. Their starting point was a practical puzzle: companies that delivered everything customers asked for still produced products customers shrugged at. Quality, they argued, has two dimensions, objective and subjective, and one linear satisfaction scale hides the useful part.

The model survived because it explains a pattern every product team notices. Removing a feature nobody praises can trigger a support escalation, while shipping a feature customers love can go unnoticed at renewal.

The five categories, and what each one costs you

A must-be feature is expected. Meeting the expectation produces no gratitude; failing it produces anger. Login, accurate billing, data security, and a page that loads quickly all live here.

A performance feature behaves like a slider: more is better, less is worse, and satisfaction moves roughly in proportion. Faster exports, larger storage, better search relevance, and lower price sit in this group. Competitors fight openly here because customers can compare.

An attractive feature delights when present and is not missed when absent. It is the cheapest source of differentiation, because customers did not expect it and therefore did not include it in their comparison set.

An indifferent feature changes nothing either way. That is useful: it tells you what not to build. A reverse feature actively reduces satisfaction for some segment when present, as excessive notifications and forced tutorials do. Reverse features are worth hunting because they are usually cheap to remove.

Why does a single importance score fail?

A single importance score fails because it averages two different curves into one number. When you ask “how important is this feature from 1 to 5?”, most respondents answer 4 or 5, and the ranking mostly reflects how the question was worded.

Consider a realistic result from a B2B scheduling product. Two features both score 4.2 out of 5 on importance:

• Feature A: CSV export of schedules. 68% call it important. The Kano survey classifies it as must-be: 71 of 120 respondents expect it, and 44 would be angry without it.
• Feature B: automatic time-zone detection for shared links. It also scores 4.2, but Kano classifies it as attractive: 58 of 120 say they like it, and only 9 would be upset without it.

Under the importance ranking, these features look interchangeable. Under Kano they need different treatment. Feature A must exist and work reliably; shipping it earns no credit. Feature B is a marketing asset that can be announced, priced into a higher tier, or used in a competitive comparison. Building A first is defensible. Treating them as the same kind of work is not.

How do you run a Kano survey step by step?

You run a Kano survey by pairing two questions per feature, collecting enough responses to be stable, classifying each response through the evaluation table, and then aggregating the counts into a category and two coefficients.

Step 1: Choose 15 to 25 candidate features

Do not survey your entire backlog. Pick features that are genuinely undecided, plus two or three you already know the answer to. If a known must-be comes back attractive, the question wording or the sample is broken.

Write each feature as a concrete capability, not a slogan. “Bulk-edit 50 tasks at once” is testable. “Better collaboration” is not.

Step 2: Ask the functional and dysfunctional pair

For every feature, ask two questions with the same five answer options:

• Functional: How do you feel if this feature is available?
• Dysfunctional: How do you feel if this feature is not available?

The scale is: I like it, I expect it, I am neutral, I can live with it, I dislike it.

This pairing is the heart of the method. Asking only the functional question measures desire. Asking both measures the asymmetry, which is the actual signal.

Step 3: Keep the wording neutral

Small wording changes move results more than most teams expect. Avoid leading phrases such as “wouldn’t it be great if”, and avoid implementation details, because respondents start evaluating your technical approach instead of their need. Keep every feature description the same length and specificity.

Step 4: Classify answers with the evaluation table

Each respondent produces one answer pair per feature, and the pair maps to a single letter. The standard table below is the version popularized by Berger and colleagues in 1993.

A = attractive, O = one-dimensional (performance), M = must-be, I = indifferent, R = reverse, Q = questionable.

Q answers are logically contradictory, such as liking the feature both when it exists and when it does not. Those responses get discarded, and a high Q rate is a signal that the question was confusing.

Step 5: Aggregate to a category

The simplest rule is the mode: whichever category received the most answers becomes the feature’s type. When two categories are close, the usual tie-break order is must-be, then performance, then attractive, then indifferent, because a failed must-be cannot be compensated by a delighter.

Step 6: Calculate Better and Worse

The mode throws away useful information, especially on features that split 45% attractive and 40% performance. The coefficients keep it:

• Better = (A + O) ÷ (A + O + M + I)
• Worse = −(O + M) ÷ (A + O + M + I)

Better ranges from 0 to 1 and measures how much satisfaction rises if you ship the feature. Worse ranges from −1 to 0 and measures how much satisfaction falls if you do not. Reverse and questionable answers stay out of the denominator.

A worked example with 120 responses

A workflow automation product tests four features with 120 users. After cleaning, the counts look like this:

Read the rows as investment decisions:

• Approval chains moves satisfaction in both directions. It is performance work, so compete on quality because customers will notice improvements.
• Audit log export has a weak Better and a strong negative Worse. It is insurance: no praise when present, a compliance problem when broken. Set a reliability target and stop polishing.
• Suggested automations has the highest Better and a mild Worse. That is where differentiation lives.
• Custom colour themes scores low on both. Building it consumes a sprint and changes nothing measurable.

With six engineering weeks, the defensible sequence is: fix the audit export reliability, ship a limited version of suggested automations, then improve approval chain quality. Colour themes wait indefinitely.

How do you turn coefficients into a roadmap decision?

You turn coefficients into a roadmap decision by plotting Better against the absolute value of Worse and then weighting each quadrant by cost and strategic fit. The plot itself is descriptive; the decision needs a second input.

The missing input is cost. A delighter with a Better score of 0.70 that takes 14 weeks may still lose to a lower-scoring feature that takes two weeks and unlocks a sales segment. Kano ranks by satisfaction potential, not by return on engineering time.

A practical scoring approach: multiply Better by the share of revenue exposed to the segment, divide by estimated engineering weeks, and treat the result as a first-pass order. Then override it deliberately, in writing, when strategy demands. The override is fine. Silent override is what erodes trust in the method.

Do delighters really decay into must-be features?

Yes, and faster than most roadmaps assume. Attractive features become performance features as competitors copy them, and performance features become must-be as expectations reset.

The pattern is easy to see in ordinary software. Free HTTPS, a mobile app, dark mode, two-factor authentication, and calendar sync were all differentiators once. Each is now expected, and several are compliance requirements. None of them earn praise today.

Two implications follow. First, a delighter has a shelf life: budget for it to stop being a delighter in 12 to 36 months, depending on how visible it is and how quickly the category copies features. Second, re-run the survey annually or every 18 months. Reusing a two-year-old result is how teams end up defending a feature that customers now consider baseline.

> Practical tip: Tag each feature with the date it was classified. A delighter older than 24 months should be treated as one category lower until re-tested.

Kano vs RICE, WSJF, and MoSCoW: which should you use?

Kano answers a different question, so the frameworks stack rather than compete. Kano tells you what kind of value a feature creates; RICE, WSJF, and MoSCoW tell you what to do first given effort, delay cost, and constraints. A workable split is to run Kano once or twice a year to set each feature area’s category, then sequence the quarter with RICE or WSJF inside those categories. Give must-be work a reliability target instead of a ranking, and reserve a fixed slice of capacity, such as 15%, for attractive work so operational demands cannot crowd it out.

What are the limitations and trade-offs?

The limitations are real and worth stating before you present results to a leadership team.

Sample size. Category assignment is unstable in small samples. Research by Chapman and Callegaro questions reliability below roughly 200 responses per homogeneous segment, so a 40-person survey is a directional signal, not a classification.

Segments hide inside the mode. A feature can be must-be for professional users and indifferent for casual users. Pooling both groups produces one answer and hides the split.

Direction, not magnitude. Kano says satisfaction will move, not by how much. It will not tell you whether the delighter is worth $24,000 or $240,000.

Hypothetical bias. Respondents evaluate a described feature, not a working one. Description length, examples, and question order all shift answers.

No cost dimension. A high Better score on an expensive feature can outrank a cheap must-be fix if you read the chart naively.

Reverse features need segment analysis. A feature that delights one group and annoys another shows up as low Better and low Worse when pooled, which reads as indifferent and hides a real conflict.

> Common mistake: Presenting the Kano chart as a ranking. The chart has no cost axis, so it cannot rank. Present it as a classification, then show the cost-weighted sequence separately.

Who should use Kano, and who should skip it?

Kano fits teams with a defined user base, a backlog large enough to require trade-offs, and a product mature enough that basic expectations are met. Skip it before product-market fit, where 30 early users cannot produce stable categories, and in products where the important requirements are fixed by regulation. Teams that cannot act on the result should not spend three weeks collecting it.

If you only have a week, run the paired questions with 12 to 15 customers in interviews and classify by hand. Use the output to challenge assumptions rather than to rank a roadmap.

Where Kano results meet execution

The survey is the easy half. The hard half is keeping the classification attached to the work. In practice, Kano output dies in a spreadsheet nobody opens after the planning meeting, and the backlog reverts to whoever escalates loudest.

Two habits prevent that. Store the Kano category as a field on the feature or epic itself, so it travels through planning, design, and review. Then review the distribution each quarter: if 80% of committed work is must-be, you are running maintenance and should say so out loud, because the roadmap is not producing differentiation.

Doitify is built for that second half: goals become projects with tasks, sub-tasks, and checklists, and custom fields, roadmaps, and work reports keep attributes like a Kano category visible from intake through delivery. It is our product, so treat that as a disclosure rather than a review. A survey tool plus a spreadsheet still handles the analysis; the difference is that the classification stays attached to the work.

Conclusion

The Kano model earns its place because it fixes a specific, expensive error: treating all customer requests as the same kind of work. A must-be feature needs a reliability target, a performance feature needs a competitive benchmark, and an attractive feature needs a small, time-boxed bet before it decays into table stakes.

Run the paired questions, keep the sample honest, compute Better and Worse, and put cost next to the score before you resequence anything. Used that way, Kano does not replace RICE or WSJF. It gives them a category to work inside.

If this post on kano model was helpful, you might also enjoy Software Development Project Template: Sections, Example, and How to Use It and How to Automate Deadline Notifications (5-Step Workflow).