The Kano Model Explained
The Kano model is a way of sorting product features into categories based on how each one actually affects customer satisfaction — because not every feature makes customers happier in the same way. A professor named Noriaki Kano created it in the 1980s, and its core insight is still useful today: some features are simply expected and go unnoticed unless missing, some features make customers steadily happier the more you invest in them, and a few features genuinely delight customers, even though nobody asked for them.
Quick facts
- The Kano model sorts features into five categories, though three are used most often in practice: Basic (Must-be), Performance, and Delighters (Attractive).
- Customer satisfaction doesn't rise the same way for every feature — some features only prevent dissatisfaction, without ever creating real satisfaction.
- Categories are usually identified by asking customers two questions about each feature: how they'd feel if it were present, and how they'd feel if it were absent.
- Features move between categories over time — today's delighter often becomes tomorrow's basic expectation, once customers get used to it.
- Kano works well alongside other prioritization tools like RICE — Kano tells you what kind of value a feature creates, while RICE helps you rank ideas against each other.
The main categories, explained
| Category | What it means | Effect on satisfaction | Example |
|---|---|---|---|
| Basic (Must-be) | Expected by default — customers don't notice it when it's there, but are very unhappy if it's missing | Its absence causes strong dissatisfaction, but its presence doesn't create real satisfaction | A hotel room having a working lock on the door |
| Performance | The more of this you deliver, the happier customers get, in a fairly direct, linear way | Satisfaction rises steadily as this feature improves | A phone's battery life — better battery life is straightforwardly more satisfying |
| Delighter (Attractive) | Not expected at all, so its absence isn't noticed — but its presence creates real excitement | Creates satisfaction disproportionate to the investment, since it's unexpected | A hotel leaving a free, unexpected welcome gift in the room |
| Indifferent | Customers don't really care either way | Little to no effect on satisfaction | A minor color option most customers never notice |
| Reverse | Some customers actively prefer not having this feature | Can actually reduce satisfaction for some users | Extra notification settings that just add clutter for users who never wanted them |
Why this matters for prioritization
Without the Kano model, it's easy to assume all features are the same kind of "good" — that adding any feature makes customers a little happier. In reality, pouring resources into Basic features beyond what's expected creates almost no additional satisfaction, since customers already assumed they'd be there. Meanwhile, a small, well-placed Delighter can create outsized goodwill relative to how much it cost to build. Understanding which category a feature falls into helps a team avoid over-investing in features that have already hit their ceiling for customer satisfaction, and spot opportunities that are cheap but disproportionately delightful.
How to actually categorize a feature using Kano
The classic method is to ask customers two questions about each feature:
- "How would you feel if this feature were present?"
- "How would you feel if this feature were absent?"
Each question is usually answered on a scale from "I like it" to "I dislike it." Comparing the answers to both questions places the feature into one of the categories above. For example, if customers say they'd be neutral if a feature were present, but very unhappy if it were absent, that's a clear sign of a Basic (Must-be) feature — it's expected, not exciting.
In practice, many product teams skip the formal two-question survey and use judgment instead, especially for smaller decisions — but running the real survey is worth it for bigger, more expensive features, since intuition about what delights customers is often wrong.
A worked example: a food delivery app
Picture a food delivery app deciding what to prioritize next:
- Basic: the app accurately shows the restaurant's current menu and prices. Customers don't think to praise this — they just expect it, and would be furious if the menu were wrong.
- Performance: delivery speed. Customers notice and appreciate every improvement here — a 10-minute-faster delivery genuinely makes people happier, and there's no natural ceiling where they stop caring.
- Delighter: the app occasionally includes a small, free treat from the restaurant, with a note like "on the house." Nobody expects this, and it creates outsized goodwill relative to its cost.
A team that only invests in making the menu "even more accurate" (already a Basic feature that's met expectations) is likely wasting effort compared to investing further in delivery speed (Performance) or testing a low-cost Delighter.
Common mistakes when using the Kano model
- Treating every feature as a potential delighter. Most features are Basic or Performance — genuine Delighters are rare, and trying to make everything delightful usually spreads effort too thin.
- Forgetting that categories shift over time. A feature that delighted customers a few years ago (like free shipping) often becomes a Basic expectation once competitors adopt it too — Kano categorization needs to be revisited periodically, not done once and forgotten.
- Skipping the customer survey and guessing instead. Internal opinions about what delights customers are frequently wrong, especially for teams that are far removed from actual customer conversations.
- Using Kano as the only prioritization tool. Kano tells you the type of value a feature creates, but not how many customers it reaches or how much effort it takes — pair it with a framework like RICE for a fuller picture.
FAQ
Who created the Kano model? Noriaki Kano, a Japanese professor, developed the model in the 1980s as a way to study customer satisfaction more precisely than a simple "customers like this feature or they don't."
Can a Basic feature ever become a Delighter again? Not usually in the same market — once customers expect something, they rarely go back to being delighted by it. New delight tends to come from genuinely new ideas, not from improving an already-expected feature further.
Is the Kano model still relevant today, or is it outdated? It's still widely used, particularly for understanding customer satisfaction in mature products where the basics are already covered and teams are trying to find the next source of real delight, not just table-stakes functionality.
How is Kano different from a simple customer satisfaction survey? A standard satisfaction survey just tells you if customers are happy or not with something as it exists today. The Kano model specifically asks how customers would feel about a feature's presence versus its absence, which is what allows it to sort features into these distinct categories, rather than just producing one overall happiness score.