Nobody has ever bought a mobile phone because it has a battery in it and yet nobody would buy one without. When categorizing new features, the Kano model is a way to organize them by how well they will satisfy the customers, against how much of it we need to implement.
There are five main groupings in the Kano model, although we often only talk about the first three, which are: Basic needs, performance needs, and delighters.
Basic needs are things that your product must have and yet counter-intuitively, your customers just don’t care about. Imagine selling a mobile phone and claiming “ours has a battery in it!” Nobody cares that it has a battery in it because all mobile phones have batteries in them. Yet, if you shipped one without a battery everyone would be very upset. The customer doesn’t care if the basic needs are there but cares very much when they’re absent, and that’s the key characteristic.
Performance needs are those where more of a thing makes the customers happier and less makes them less happy. Battery life would be a good example. Longer battery life on that mobile phone will make customers happier.
Delighters are where Apple traditionally shines. These are things that no customer asked for. Had you suggested this feature to a customer they might even have shown indifference. “I don’t need that”, and yet once they start using that feature, they can’t live without it. This becomes the differentiator that draws people to the product.
With these first three, there is an interesting behaviour that over time, they shift down and to the right as seen by the large arrow below.
Things that started as delighters become the things that every vendor has to provide. Things that used to make the customers happy, now become basic needs where the customer only notices when it’s absent.
The fourth grouping is Indifferent Quality which is right along the X axis. This is where the customer just doesn’t care whether it’s there or not. Things that the customers are indifferent to, shouldn’t be built, and yet we build lots of these.
If it’s already built, we should be seriously questioning whether we can remove it.
Then the last grouping is Reverse Quality where the customer actively dislikes this. Usually these are features that we put in to justify getting more money out of the customer. We think we can charge more if we add more features, missing the point that this often degrades the whole experience for the customers. As we add more, we generally make it more difficult to use the features that the customers care about.
Adding these features contributes to the “enshittification“ that is widely discussed across products. Just as with indifferent quality, if we’ve already built it, we should be thinking about removing it.
Most feature conversations proceed as though everything on the list is a delighter waiting to happen. The Kano model says otherwise. Some things just need to be there even though the customer doesn’t care. Some truly do add value and some are just waste.
That’s the useful part. It gives you a way to say no to work that would otherwise look like progress. We don’t say “no” nearly often enough, but that’s a different article.
So next time something lands in the backlog, ask which of the five it is. If nobody can say, you’ve learned something already. That tells us we don’t know enough about what our customers actually need.