Kano Analysis: Categories, Questions & Worked Example

Kano analysis classifies feature expectations by pairing reactions to a requirement’s presence and absence. The answers distinguish basics, performance improvements, attractive extras, indifference and reverse preferences. Use those categories to understand what customers expect, then consider evidence, costs and product goals before turning a label into a release priority.

Example: choosing a support-portal improvement

Relay is a hypothetical support portal for operations managers at multi-site retailers. It can make one major improvement this quarter: a submission receipt, clearer progress information or automatic recovery of unfinished drafts. The team wants to improve it before reaching another customer group.

A submission receipt could be expected without earning praise, while draft recovery could attract enthusiasm without determining which portal someone chooses. Treating both as equally “important” would miss the distinction between preventing dissatisfaction and adding appeal.

“Better ticket management” is too broad to test. It could mean faster responses, fewer lost requests or less time rewriting a description. Each candidate needs a clear behavior the customer can picture.

For draft recovery, the paired questions could be:

If the portal automatically saved your unfinished ticket so you could return to it later, how would you feel?

If the portal did not automatically save your unfinished ticket, how would you feel?

Offer the same five responses to each: Like it, Expect it, Neutral, Can live with it, Dislike it. The second question is the dysfunctional question. It describes the absence of the capability, not a broken version of an unrelated feature. The CQM methods compendium, published in 1993, explains this paired approach and its classification table.

First check that customers understand what is saved, where to recover it and whether saving is automatic. Different interpretations can look like different preferences.

What the categories mean

The model introduced by Kano and colleagues in 1984 challenges the assumption that every improvement produces a proportional increase in satisfaction.

A must-be requirement is expected. Its absence causes dissatisfaction, while meeting it may attract little praise. A performance, or one-dimensional, requirement produces satisfaction when fulfilled and dissatisfaction when unfulfilled. An attractive requirement, often called a delighter, is appreciated when present but tolerated when absent. An indifferent requirement changes little either way. A reverse response indicates that the person prefers the opposite of the proposed capability. These distinctions are also described in research on quantifying Kano's quality model.

These are customer responses to a specific requirement. Draft recovery is not inherently a delighter, and an email receipt is not universally a must-have. The answers determine the classification for each respondent.

Two answers determine each classification

The lookup below uses the standard CQM classifications. Find the reaction to the present feature in the left column, then read the corresponding reaction to its absence in that row. Each labeled answer gives the classification.

M: must-be. O: one-dimensional/performance. A: attractive. I: indifferent. R: reverse. Q: questionable.

Suppose one Relay customer expects a submission receipt and dislikes its absence. That pair is M. A customer who likes progress information and dislikes its absence gives an O response. Someone who likes draft recovery but feels neutral about its absence gives an A response.

The first answer alone would miss the distinction. Both progress information and draft recovery received “Like,” but the reaction to their absence gives them different roles in the experience.

A winning label can hide a divided audience

To see how aggregation works, suppose 40 customers provide complete pairs for draft recovery. Their classifications are 18 must-be, nine performance, six attractive, five indifferent, one reverse and one questionable.

Must-be is the largest category, at 18 of 40, or 45%. It is a plurality, not a majority. Reporting only “draft recovery is a must-have” would hide the remaining 55%.

Find out who gives each response. Interrupted managers writing long incident reports may differ from people submitting short desk requests. Check recruitment and follow-up evidence. Do not invent that segment explanation from the totals alone.

Keep incomplete pairs separate. One present-feature answer is not enough to classify someone. Report the complete-pair count for each requirement because questions may have different response counts.

Investigate ties and near-ties instead of automatically setting priorities. A must-be/attractive split may reflect use contexts, unclear wording or too little evidence. CQM recommends further investigation of close classifications and possible segments. More respondents cannot fix a question people interpret differently.

Reverse and questionable responses need different treatment

A reverse response is not automatically a bad answer. Imagine Relay proposes sending every ticket update immediately by email. A manager who dislikes constant notifications and prefers their absence may be expressing a legitimate need for a digest or an opt-out. Deleting that response would remove a product design problem.

A questionable pair, such as liking both the presence and absence of the same capability, needs a comprehension check. The respondent may have misread the wording, interpreted two different situations or struggled with the response options. Check the question and relevant answers before excluding it; do not turn every inconvenient response into an error.

Keep all six category counts. If a summary excludes questionable answers, show the total it uses. If a meaningful group prefers the reverse, report that disagreement instead of imposing one feature label.

A feature category is one part of the release choice

Relay's first task is to find out whether its existing experience meets the basic requirement. If receipts already arrive reliably, spending the quarter making them more elaborate may do less for customers than improving visibility into open tickets. If requests disappear without confirmation, that failure could undermine the entire portal.

Compare the remaining ideas with delivery costs and consequences. Draft recovery may prevent serious lost work for one group and add little for another. Progress updates may help, but check which facts customers need and whether operations can supply them.

Kano does not measure implementation effort, revenue, regulatory obligations or willingness to pay. It also does not tell Relay whether customers will switch from their current process. Those questions belong alongside the classification, not inside an invented Kano score.

Use Kano to understand reactions to a requirement's presence and absence. Use MaxDiff when the decision is the relative priority of a defined list; our MaxDiff guide explains that comparison. Use conjoint analysis when the choice concerns complete offers that combine features, service levels and prices. A feature can be a must-have and still fail to justify a particular package price.

Sapien can help a team explore how a proposed feature is understood and compare reactions across a data-grounded simulated audience. That can reveal hypotheses about which requirements feel essential, where an optional benefit adds appeal and how reactions differ between groups. The classifications used to describe actual customer expectations should come from the relevant customers, with the question pairs, counts and disagreements intact.

The output should name the basic failure to fix, performance change that matters and optional benefit worth testing. Keep the reasoning with its evidence. A feature category alone does not finish the roadmap.