The Kano Model: How to Prioritize Features by Customer Delight

Not all features affect happiness the same way. Some you barely notice when present but hate when missing; others delight you precisely because you didn't expect them. The Kano model captures this asymmetry, and it's one of the most useful lenses for deciding what to build — because it stops you from polishing wow-features while neglecting the basics that quietly drive people away.

The categories

The Kano model sorts features into a few types based on how their presence or absence affects satisfaction.

Basic expectations (must-haves). Features users assume will be there. Having them earns no praise; missing them causes anger. A password reset, saving your work, the app not crashing. These don't delight — they prevent churn. Neglect them at your peril.

Performance features (more is better). Features where satisfaction scales with how well you do them: speed, storage, number of integrations. Users notice and reward improvements here linearly, so these are where competitive comparison happens.

Delighters (attractive features). Unexpected features that create outsized joy — a thoughtful shortcut, a delightful animation, a "how did they know I wanted that?" moment. Their absence isn't penalized (nobody misses what they didn't expect), but their presence can differentiate you.

There are also indifferent features (users don't care — avoid building these) and reverse features (some users actively dislike them).

Why the asymmetry matters

The key insight is that these categories behave differently, so treating them equally is a mistake. Pouring effort into delighters while a basic expectation is broken is like adding a spoiler to a car with no brakes. Conversely, once your basics are solid and your performance features are competitive, delighters are where you win hearts.

There's also a time dimension: delighters decay into expectations. Yesterday's wow-feature becomes today's baseline once competitors copy it. What delighted users a few years ago is often a must-have now. So the model is a moving target you re-evaluate over time.

How to apply it

The classic method is a short survey: for each feature, ask users how they'd feel if it were present, and how they'd feel if it were absent. The pattern of answers classifies the feature. But you don't always need a formal survey — your feedback board already tells you a lot. Requests framed as complaints ("it's broken that I can't…") point to basics; requests framed as wishes ("it'd be amazing if…") often point to delighters.

Then prioritize in order: fix broken basics first, keep performance features competitive, and sprinkle in delighters to differentiate once the foundation is solid.

Kano alongside other frameworks

Kano tells you the type of value a feature provides, but not the effort or reach. That's why it pairs well with a scoring framework like RICE: use Kano to make sure your basics are covered, then use RICE to rank within your options. See our overview of six prioritization frameworks for how they fit together.

Start with what users tell you

Kano needs real input about how users feel — which starts with listening. Create a free feedback board on FeatureRequest, watch how requests are framed, and use the Kano lens to separate the basics you must nail from the delighters that set you apart.