Kano analysis: which features must work, and which could make the difference?

A feature can be essential without making anyone enthusiastic. Another can earn warm reactions without affecting whether someone chooses the product. If a roadmap treats both as equally valuable because customers rated them “important,” the team can spend a release improving the wrong thing.

Kano analysis helps separate those situations. It asks how someone feels when a capability is available and how they feel when it is absent. The combination reveals whether the capability prevents dissatisfaction, improves the experience as it gets better, adds an unexpected benefit, or makes little difference.

That distinction changes the product decision. A missing basic can block adoption. A performance improvement can strengthen the offer. A delighter can differentiate it. None of those labels, by itself, tells you what the feature should cost or whether it deserves the next engineering slot.

Start with the requirement, not the feature name

Consider Relay, a fictional support portal used by operations managers at multi-site retailers. Its product team has capacity for one substantial improvement this quarter. The candidates are a receipt after submitting a ticket, clearer progress information, and automatic recovery of unfinished ticket drafts. The decision is what to improve before introducing the portal to another customer group.

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

Relay should first check that customers understand what is being saved, where they can recover it and whether saving is automatic. Otherwise, apparently different preferences may be different interpretations of the question.

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.

Use both answers to classify a response

The lookup below uses the standard CQM table. Read the present-feature answer down the left and the absent-feature answer across the top.

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

The useful next question is who is in each group. Managers who write long incident descriptions between interruptions may respond differently from colleagues who submit short requests at a desk. Relay should inspect those differences against the recruitment criteria and follow-up answers. It should not invent a segment explanation after seeing the totals.

Keep incomplete pairs separate: a customer who answers only the present-feature question cannot be classified from that answer alone. Report the complete-pair base for each requirement, since different questions may have different response counts.

Ties and near-ties deserve investigation rather than an automatic priority rule. A split between must-be and attractive could reflect distinct usage contexts, unclear wording or insufficient evidence. CQM specifically discusses close classifications as a reason to investigate requirements and possible segments further. A larger sample will not repair a question that means different things to different people.

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.

Preserve all six category counts in the working analysis. If a summary excludes questionable responses, state that denominator. If reverse responses cluster in a meaningful group, report the disagreement rather than forcing a universal feature label.

Turn the classification into a release decision

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 unresolved tickets. If requests disappear without confirmation, that failure could undermine the entire portal.

Next, put the remaining opportunities beside their delivery costs and consequences. Draft recovery might address a serious loss of work for one valuable segment while adding little for another. Progress information might reduce uncertainty, but the team still needs to establish which information customers need and whether it can keep that promise operationally.

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 useful output is a clearer product choice: which basic failure must be repaired, which performance improvement matters to the target group, and which optional benefit deserves a further test. Keep that decision attached to the evidence, rather than treating a category label as a finished roadmap.