What is the Kano model?

The three categories

Basic expectations are invisible when present and outrageous when absent. Nobody praises an app for loading, and everybody abandons one that does not. Satisfaction from these caps at zero — perfect execution buys you neutrality.

Performance features move satisfaction proportionally. Faster is better, cheaper is better, more storage is better, and each increment buys a matching increment of goodwill. These are where competitive comparison lives.

Delighters are unexpected and produce satisfaction out of proportion to their cost. Nobody asked for them, so their absence costs nothing — which makes them the only category where you can win without spending more than a rival.

Two minor categories complete the model: indifferent features nobody cares about either way, and reverse features some users actively dislike.

Why the categories need different funding

The practical value of Kano is that it exposes a common allocation error. A roadmap made entirely of performance features produces a product that is measurably competitive and entirely forgettable. A roadmap made entirely of delighters produces a charming product that fails at something basic and loses the customer anyway.

The rough shape that works: basics get whatever they need and no more, because over-delivering on them is invisible. Performance features get the bulk of steady capacity. Delighters get a deliberate, protected slice — small, but never zero, because zero is how a product becomes a commodity.

The iPod's scroll wheel is a delighter in the strict sense. No one requested it. Competing players had all the performance features. The wheel made the device feel different in the hand in a way spec sheets could not represent.

The decay problem

Every delighter is on a timer. Once a feature is copied widely enough, users stop being pleased by it and start being annoyed by its absence — it has migrated from delighter to basic.

Zoom's frictionless join is the textbook case in both directions. Joining a call without an account or a download was a genuine delighter when every competitor demanded installation and login. Within a few years it was table stakes, and any conferencing tool lacking it now reads as broken.

This is why Kano is a repeated exercise, not a one-time classification. A model built three years ago has features in the wrong buckets today.

Where it breaks down

Kano surveys ask people to react to described features, and people are poor at predicting their own reaction to something they have not used. The method is strongest on concrete, easily imagined features and weakest on exactly the ambitious ones you most want guidance on.

Use it to check a roadmap's balance across the three types. Do not use it to settle whether a specific ambitious bet is worth making — that question is not one a survey can answer.