Kano Model

The Kano model classifies features by how their presence (or absence) affects customer satisfaction. Some features delight when present; others infuriate when absent. The math is non-linear, and the implications for what to build are non-obvious.

Origin

Noriaki Kano introduced the model in 1984 in a paper for the Japanese Society for Quality Control. Kano's research distinguished between linear features (the more, the better, in a straight line) and non-linear features that delight, dissatisfy, or have no effect on customer satisfaction. The framework gained traction in product management in the 2000s through total quality management literature and entered mainstream software product management around 2010.

The five categories

1. Must-be (basic). Customers expect these; their presence creates no satisfaction, but their absence creates strong dissatisfaction. A car that doesn't start. A SaaS tool with no SSO. Customers don't praise must-bes; they assume them.
2. Performance (linear). The more, the better, more or less linearly. Faster page load, longer battery life, more storage. Customers can articulate preference; investments here produce proportional satisfaction gains.
3. Delighters (excitement). Customers don't know they want them, but their presence creates disproportionate satisfaction; their absence creates none, because customers didn't expect them. The feature that gets shared on social media after launch.
4. Indifferent. Customers don't care either way. Often where features go to die; sometimes where engineering effort accumulates without business return.
5. Reverse. Some customers want them; others actively dislike them. Animations on enterprise dashboards; gamification in productivity tools. Often a sign of segment misfit, not feature failure.

The decay over time

Kano's most important and least understood point: features migrate down the curve over time. Today's delighter is tomorrow's performance feature is the day-after's must-be. Auto-save was a delighter in 2005, a performance feature by 2010, a must-be by 2015. The implication: a backlog full of must-be features is treadmill work; a backlog full of delighters is the only way to lead the market, but each will be commoditized in 3-5 years.

When Kano is the right tool

Kano is the right tool for: feature prioritization across a backlog where the team is trying to allocate engineering time strategically; understanding why a competitor's apparently "weaker" product has loyal customers (often: they nailed must-bes); and understanding why "feature parity" rarely changes market position (matching competitors' performance features doesn't move you; only delighters or unique must-bes do).

It's a poor fit for: early-stage products without enough customer data to classify features reliably; B2B sales-led companies where features are negotiated per-deal; or commoditized markets where price dominates feature preference.

How to apply it

1. List candidate features. 10-30 features per analysis is reasonable. Use specific, customer-facing descriptions, not internal jargon.
2. Run the Kano survey. For each feature, ask two questions: "How would you feel if this feature were present?" and "How would you feel if this feature were absent?" Five-point scale: I like it / I expect it / I'm neutral / I can tolerate it / I dislike it.
3. Classify each feature. The combination of answers maps to a Kano category. "I like it" + "I dislike it" → performance. "I expect it" + "I dislike it" → must-be. "I like it" + "I'm neutral" → delighter.
4. Segment results. Different customer segments often classify the same feature differently. Don't average; report per segment.
5. Build the prioritization map. Must-be gaps come first (they limit the achievable satisfaction ceiling). Performance investments next (they produce proportional value). Delighters where they fit the strategy (high upside, low downside if absent).
6. Refresh annually. Categories drift as the market matures and customer expectations evolve.

Worked example: a customer support tool's roadmap

A customer support tool runs a Kano study on 12 candidate features for the next planning cycle:

• Must-be (gaps to fix): SAML SSO (enterprise customers can't even consider the tool without it). Email forwarding works reliably (currently has bugs that customers tolerate but are vocal about).
• Performance: Faster search across tickets; better SLA reporting; more granular permissions. All proportional satisfaction gains; investment here is reliable but not exciting.
• Delighters: AI-suggested replies based on prior tickets; auto-categorization of inbound; built-in customer health score derived from ticket patterns. High excitement, low expectation. Risk if competitors ship them first; opportunity if you lead.
• Indifferent: Support for nine additional integrations beyond the top 20 already supported; customizable agent avatars; expanded keyboard shortcuts.
• Reverse (one): Gamification dashboard showing agent rankings — beloved by some managers, actively disliked by agents and by enterprise customers as creating bad culture.

Recommended sequence: SSO and email forwarding fixes immediately (must-be gaps cap deal size). Performance features as ongoing investment. AI-suggested replies as the strategic delighter for the year. Skip the indifferent features and the reverse one.

How Kano goes wrong

• Skipping the survey. Classifying features by gut feel produces the team's biases, not customer reality. The survey methodology is what makes Kano credible.
• Single segment. Averaging across segments hides the fact that a feature is must-be for enterprise and indifferent for SMB.
• Static use. Kano done once and filed misses the decay dynamic. Re-run annually.
• Building only delighters. Delighters generate excitement; must-bes prevent loss. A product full of delighters with weak must-bes loses deals quietly.
• Building only must-bes. The opposite failure: a roadmap of must-bes is defensive and produces no excitement, no leadership, no story.

Critique

Kano's classification is empirically grounded, but the survey methodology can be slow and noisy at small sample sizes. The model also assumes customers can articulate preferences for features they haven't yet experienced — a known weakness of any survey-based research. Practitioners often combine Kano with other prioritization methods (RICE, value-effort) to balance customer-stated preferences with team-side feasibility. The conceptual contribution — that satisfaction is not linear in feature presence — is the durable insight; the specific survey methodology is the operational tool.