What is the Kano Model?
The Kano model was developed by Professor Noriaki Kano in the 1980s. It maps the relationship between feature implementation and customer satisfaction on a two-dimensional graph. The key insight is that this relationship is not linear for all features.
Must-be features are baseline expectations. Users do not get excited when they work, but they get frustrated when they are missing. Think of login functionality or data export. One-dimensional features have a linear relationship: the better the implementation, the more satisfied users are. Performance and speed often fall here.
Attractive features are the surprises that delight users. They do not expect them, so their absence causes no dissatisfaction, but their presence creates outsized positive reactions. These are your differentiation opportunities.
Why It Matters for Product Teams
The Kano model prevents a common mistake: spending all your effort on attractive features while neglecting must-be basics. If your must-be features are broken or missing, no amount of delighters will save user satisfaction.
It also explains why some highly requested features do not move satisfaction metrics after launch. If users already expect the feature (must-be), delivering it just removes dissatisfaction. It does not create delight. Understanding this distinction helps you set realistic expectations for the impact of each feature.
Feature categories shift over time. Today's attractive feature becomes tomorrow's one-dimensional expectation. Real-time collaboration was once a delighter in document editors. Now it is expected. Regular feedback collection helps you track these shifts.
How to Apply the Kano Model
Run a Kano survey by asking users two questions for each feature: how they feel when the feature is present and how they feel when it is absent. The combination of answers places the feature into one of the five categories.
Analyze your existing feedback for Kano signals. Feature requests described with frustration or urgency ("I can't work without this") suggest must-be features. Requests framed as wishes or ideas ("it would be cool if") often indicate attractive features.
Use Quackback to collect and categorize this feedback at scale. Tag requests by Kano category and track how the distribution changes over time. This gives you a living map of where to invest.
Balance your roadmap across categories. Ensure must-be features are solid before investing heavily in attractive ones. Use one-dimensional features as your steady improvement engine. Reserve capacity for at least one attractive feature per release to maintain differentiation.