A framework for categorizing product features by their relationship to user satisfaction. Features are classified as basic needs (expected, their absence causes dissatisfaction), performance attributes (more is better), or delighters (unexpected bonuses that increase satisfaction). The model helps teams prioritize work that genuinely improves perceived quality rather than just adding volume.
Common contexts
- Running a Kano survey to distinguish table-stakes features from differentiators in a competitive redesign
- Identifying which onboarding features users expect by default versus which ones genuinely delight new signups
- Deprioritizing a high-effort feature that tests as a performance attribute rather than a true differentiator
Use when
Use the Kano model during feature discovery when the team is debating which improvements matter most — it separates 'must fix' from 'nice to have' with user data instead of opinion.
Avoid when
Don't apply Kano to a backlog without first validating the survey questions with real users — a poorly worded functional/dysfunctional question pair produces meaningless category assignments.
Today's delighter becomes tomorrow's basic need faster than most roadmaps account for — the Kano categories need to be re-tested, not inherited from last year's research.
Real-world examples
- Slack's emoji reaction feature tested as a 'delighter' in their 2015 Kano analysis — users didn't know they wanted it but expressed strong delight after experiencing it; today it's a baseline expectation.
- Uber's surge pricing was a Kano 'must-be' violation: users expected consistent prices, and dynamic pricing created the perception of performance deficiency that continues to drive Lyft switchers.
- Apple applied Kano logic when introducing Face ID: it tested as a delighter in 2017 (exceeded expectation) but became a basic expectation by 2019 when every flagship Android copied the pattern.