Kano Model

Origin & evolution

Professor Noriaki Kano developed the model at Tokyo University of Science (also referred to in some sources as Tokyo Rika University) and published the foundational paper "Attractive Quality and Must-Be Quality" in the Journal of the Japanese Society for Quality Control in 1984, co-authored with Nobuhiko Seraku, Fumio Takahashi, and Shin-ichi Tsuji. Kano's work came from the Japanese quality management tradition, where understanding customer satisfaction was a formal research discipline, and it challenged the prevailing assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference → that more quality always meant more satisfaction. In 1993, Charles Berger and colleagues published "Kano's Methods for Understanding Customer-Defined Quality" in the Center for Quality Management Journal, which codified the survey methodology that most teams use today: the dyad questionnaire asking users how they would feel both if a feature were present and if it were absent. The model has since become standard in product management practice, particularly in cycles where a team needs🫀NeedUserA user need, pain, desire, or constraintView reference → to distinguish maintenance work from differentiation work from strategic bets.

How it works in practice

The model defines five categories.

Must-haves (Basic Quality): features whose absence causes strong dissatisfaction but whose presence is simply expected and generates no positive feeling. Users do not say "I love that this app saves my data" but they would absolutely notice if it did not.

Performance (One-dimensional Quality): features where more is linearly better and less is proportionally worse. Speed, storage, and accuracy are common examples. Investment here tracks directly to satisfaction.

Delighters (Attractive Quality): features that users do not expect and do not miss when absent, but that produce genuine excitement when discovered. These are the differentiators, and a product that has nothing in this category is competing on table stakes.

Indifferent: features that do not move satisfaction in either direction. They cost engineering time but produce no response.

Reverse: features that actively reduce satisfaction when present. Some users want simplicity; adding a feature they find unnecessary makes their experience worse.

Running a Kano analysis starts with a list of candidate features. For each one, write two questions in the dyad format: "How would you feel if this feature were present?" and "How would you feel if this feature were absent?" Each question has five answer options running from "I would like it very much" to "I would dislike it very much." The answer pair for each user maps the feature into one of the five categories. Aggregate across the sample to find the dominant category per feature, then plan the cycle: cover the Must-haves first, optimise one or two Performance features for measurable differentiation, and commit to at least one Delighter as a strategic bet.

A worked example. A team is planning a collaboration feature for a project management tool. Survey results show that real-time presence indicators (seeing who else is online) is a Delighter for current users, but that the absence of comment threading scores as a Must-have: many users rate it as "dislike it very much" when absent. The team deprioritises presence indicators for now and ships comment threading first. The Delighter becomes the next sprint's stretch goal.

When to use it (and when not)

The Kano Model is at its sharpest when a team has a long list of candidate features and the conversation has collapsed into a single "impact" dimension, with every feature competing for points on the same scale. Kano reframes the question: it is not which feature has the highest impact in aggregate, but what kind of satisfaction each feature produces.

It is least useful when the product is brand new and the user base is too small for a reliable survey. Kano's categories emerge from aggregated responses across a sample; a survey of five users does not produce stable classifications. It is also worth remembering that categories are not permanent. A Delighter in 2022 can become a Must-have by 2024 once competitors🥊CompetitorMarket IntelligenceA competing product or companyView reference → ship it and users normalise the experience. The analysis needs refreshing each planning cycle, not just once at product inception.

The model is a complement to effort-and-reach scoring methods, not a replacement. Kano tells you what category a feature falls into; it does not tell you how long it will take to build. Pair it with RICE or a similar scoring method to get both dimensions.

In the Unified Product Graph

The Kano Model is a matrix framework in the prioritisation category. All four primary Kano categories map onto feature⭐FeatureProduct SpecificationA product capability or featureView reference → entities in the Unified Product Graph. The model does not require different entity types for different categories; the Kano classification is a property on the feature⭐FeatureProduct SpecificationA product capability or featureView reference → entity.

This means a feature⭐FeatureProduct SpecificationA product capability or featureView reference → node created during a roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → session carries its Kano category as a queryable property alongside its status, effort estimate, and links to the need🫀NeedUserA user need, pain, desire, or constraintView reference → or job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → it addresses. The same feature⭐FeatureProduct SpecificationA product capability or featureView reference → node appears in the roadmap view, the product backlog, the Kano classification view, and the OST opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → tree, each time with its own framing but always pointing to the same underlying entity. The matrix pattern reflects the categorical grid of the model: features are sorted into cells, and the cell determines how prioritisation logic should be applied to them.