Kano Model Classifier

The Kano model is a framework developed by Noriaki Kano in the 1980s for understanding how product features affect customer satisfaction. It classifies features into categories based on the asymmetric relationship between presence and satisfaction — some features delight when added but do not annoy when missing, while others annoy when missing but earn no credit when present.

There are five main categories plus one diagnostic. Must-be features are basic expectations users assume — missing them causes anger; having them earns no credit. Performance features create satisfaction proportional to how well they are done. Attractive features delight when present but do not annoy when missing. Indifferent features have no effect on satisfaction. Reverse features actively annoy users. Questionable answers indicate inconsistent survey responses, usually a signal the question was confusing.

For each feature, ask two questions. The functional question: "How would you feel if this feature WAS present?" The dysfunctional question: "How would you feel if this feature was NOT present?" Each answer is one of five options: like, expect, neutral, tolerate, or dislike. The pair of answers maps to a Kano category through a fixed evaluation matrix.

Describe the feature concretely from the user's point of view, not in product-team jargon. "If your dashboard loaded in under one second, how would you feel?" beats "If we improved page-load performance, how would you feel?" Avoid leading language and keep both versions of the question parallel — change only the presence/absence framing.

For directional decisions, 20–30 users from your target segment is enough. For published research or major investment decisions, aim for 100+ to get reliable category assignments per segment. Always segment results by user type — Must-be features for one persona are often Indifferent for another.

Use Kano early in product discovery, when you are deciding what to build and want to understand the satisfaction shape of each feature. Use RICE or MoSCoW after — once features are short-listed and you need to decide order or scope. Kano answers "is this feature worth building?"; RICE and MoSCoW answer "of the things worth building, which go first?"