---
title: "The Kano Model, Explained for Product Teams"
description: "The Kano model explained: how it sorts features into must haves, performers, and delighters, where Noriaki Kano got the idea, and where it breaks down."
canonical_url: "https://builderscamp.com/guides/other/kano-model-explained"
date_published: "2026-09-16"
date_modified: "2026-09-16"
author: "Andre Albuquerque"
publisher: "Builders Camp"
guide_class: "other"
---

# Kano Model Explained

**TL;DR:** The Kano model, created by Noriaki Kano in 1984, sorts features into must haves, performance features, and delighters based on how each one shapes customer satisfaction, not just whether users say they want it. The model's own warning is that categories shift over time: today's delighter becomes tomorrow's baseline expectation once the market catches up.

Most prioritization frameworks ask how much value a feature creates. The Kano model asks a narrower, more useful question: what shape does that value take in the customer's actual emotional response, and does building more of it even help.

## What are the three categories that matter for prioritization?

| Category | What happens if missing | What happens if you build more of it |
|---|---|---|
| Must have | Real dissatisfaction, the product feels broken or incomplete | Nothing extra; users expected it, so meeting the bar just avoids a complaint |
| Performance | Some dissatisfaction, scaling with how far short it falls | Satisfaction rises roughly in proportion to how much you invest |
| Delighter | No dissatisfaction; users never expected it | Disproportionate satisfaction relative to the effort, because it was a surprise |

A checkout page that works at all is a must have. A checkout page that gets faster the more you optimize it is a performance feature. A checkout page that autofills a shipping address correctly on the first try, before the user expected that to be possible, is a delighter, at least until every competitor does the same thing and it becomes a must have.

## Where did this framework actually come from?

Noriaki Kano, a quality management professor at the Tokyo University of Science, introduced the model in 1984. His starting premise was that customer loyalty does not respond to features the way most product teams assume: satisfaction is not a straight line where more of everything is always better. Some features only prevent complaints; others actively create delight; treating them the same way in a roadmap discussion hides that difference.

## How do you actually collect Kano data instead of guessing?

The classic method is a paired survey question for each feature under consideration: one version asks how a user would feel if the feature were present, the other asks how they would feel if it were absent. Cross-referencing the two answers, not either one alone, is what sorts a feature into must have, performance, or delighter. A single "how important is this to you" rating cannot make that distinction; it collapses exactly the information Kano was built to separate.

## Why do categories shift, and what does that mean for a roadmap?

Nothing stays a delighter forever. Free shipping, dark mode, and same-day delivery all started as delighters in their respective markets and became must haves once competitors normalized them. The practical implication is that a Kano analysis has a shelf life: rerunning it periodically, not treating one survey as permanent truth, is what keeps a roadmap decision grounded in current user expectations rather than a snapshot from a year or two ago.

## Where does Kano actually break down in practice?

It tells you the shape of satisfaction, not the size of the opportunity. A delighter that thrills a tiny fraction of your user base can still score well on a Kano survey while doing very little for the business overall, because the model does not weigh how many users encounter the feature or how much revenue it touches. That is a real gap, and it is why Kano works best paired with a reach-weighted framework rather than used alone.

## How should Kano and a scoring framework like RICE work together?

Run Kano first to understand what kind of satisfaction a feature creates, then use a framework like [RICE](https://builderscamp.com/guides/other/rice-prioritization-framework) or [ICE](https://builderscamp.com/guides/other/ice-scoring-framework) to decide when it earns a spot on the roadmap relative to everything else competing for the same sprint. Kano without a reach-weighted scoring step risks over-investing in a delighter that thrills few people; a scoring framework without Kano risks treating every feature as equally important to satisfaction when the underlying emotional response is completely different.

## Who this guide fits, and who should look elsewhere

This fits a product manager building a feature prioritization process for the first time, and a team that keeps confusing "users said they want this" with "this feature will actually satisfy them." It is not the right tool for ranking a backlog by expected business return alone; that is what RICE and ICE are for.

Builders Camp's [Product Strategy](https://builderscamp.com/bootcamps/product-strategy) bootcamp covers Kano alongside other prioritization and trade-off frameworks as part of building a defensible case for what to build and why, not a single formula applied in isolation. Pairing Kano with a clear [North Star Metric](https://builderscamp.com/guides/other/north-star-metric-examples) keeps the categories tied to an outcome the whole team is actually accountable for.

## Frequently asked questions

### Who created the Kano model, and why?

Noriaki Kano, a quality management professor at the Tokyo University of Science, introduced the model in 1984. His premise was that customer satisfaction is not linear: some features matter only when missing, others scale with how much of them you build, and Kano's model was built specifically to tell those apart.

### What are the actual categories a Kano analysis sorts features into?

Three main ones matter for prioritization: must haves (basic expectations that cause dissatisfaction if missing, but generate no delight for being present), performance features (satisfaction scales directly with how well you deliver them), and delighters (unexpected features that create disproportionate satisfaction relative to the effort behind them).

### How do you actually collect the data to run a Kano analysis?

The classic method surveys users with paired questions about each feature: one asking how they would feel if the feature were present, one asking how they would feel if it were absent. The combination of the two answers is what sorts a feature into must have, performer, or delighter, rather than a single subjective rating.

### How is a delighter different from a performance feature?

A performance feature earns satisfaction roughly in proportion to how much you invest in it; more of it is simply better. A delighter earns satisfaction disproportionate to the investment, precisely because the user did not expect it. The catch is that delighters do not stay delighters forever; once competitors copy one, users start expecting it as a baseline.

### Does a must have feature ever become a competitive advantage?

No, and that is the model's own warning against over-investing there. A must have only prevents dissatisfaction; building it better than the bare threshold rarely moves a satisfaction score, since users do not notice it beyond the point where it simply works.

### What is the most common mistake teams make applying Kano?

Treating a category as permanent. A feature can migrate from delighter to performance feature to must have as an entire market catches up to it, which is exactly what happened to features like free shipping or dark mode, so a Kano analysis from two years ago can already be wrong about where a feature currently sits.

### How does Kano compare to a scoring framework like RICE or ICE?

Kano answers a different question. RICE and ICE rank ideas by expected business impact against effort; Kano sorts features by the emotional shape of customer satisfaction. Many teams run Kano first to understand a feature's category, then use RICE or ICE to decide when to build it relative to everything else on the roadmap.

## Sources

- [ProductPlan: Kano Model (glossary)](https://www.productplan.com/glossary/kano-model)
- [LogRocket: Understanding the Kano Model](https://blog.logrocket.com/product-management/understanding-kano-model/)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.