What it is
The Kano Model, developed by Noriaki Kano, classifies features by the relationship between how much of them you build and how satisfied users are as a result. It groups features into three main categories:
- Basic (must-be) features — expected by default; users barely notice them when present but are very unhappy when they’re missing (e.g., a login screen that actually works).
- Performance features — satisfaction scales roughly linearly with investment (e.g., faster load times, more storage).
- Delighters (excitement) features — unexpected extras that create disproportionate satisfaction when present, but users don’t miss them if they’re absent, since they never expected them in the first place.
Feature classification is typically gathered through paired survey questions (“How would you feel if this feature existed?” vs. “How would you feel if it didn’t?”), which reveal which bucket a feature actually falls into rather than relying on guesswork.
When to use it
The Kano Model is useful during roadmap planning when a team needs to balance “keep the lights on” work (basic features that prevent churn) against differentiation work (delighters that drive word-of-mouth and premium positioning). It’s also a good sanity check against prioritization models like RICE, which can undervalue basic features because they don’t obviously move usage metrics — even though missing them causes real damage.
Common pitfalls
- Chasing delighters while basics are broken. A flashy new feature won’t retain users if core functionality is unreliable — basics have to be solid before delighters pay off.
- Treating the categories as permanent. Delighters decay into performance features and eventually into basics as the market matures and competitors copy them — yesterday’s delight is today’s expectation.
- Skipping the actual survey step. Teams often guess which bucket a feature belongs to instead of validating it, which defeats the purpose of a framework built specifically to correct for gut-feel bias.