No. 094Product Thinking

Kano Model

Not all qualities satisfy in the same way: some are expected, some please in proportion, some delight, and today's delighters become tomorrow's expectations.

Features affect satisfaction differently: missing basics disappoint, performance pleases in proportion, and delighters please without being expected.

To an executive

Some things must simply work, some win customers in proportion, and a few delight. Spending on the wrong kind wastes money; and delighters soon become expected.

To an engineer

Classify requirements, including quality attributes, as must-be, performance or delighter. Meet must-bes reliably, invest in performance where it pays, and plan for delighters to become baseline.

The idea

In 1984 Noriaki Kano and colleagues published "Attractive Quality and Must-Be Quality" in the Journal of the Japanese Society for Quality Control. They argued that the usual one-dimensional view, where more of a quality always means more satisfaction, is wrong. They proposed a two-dimensional view, looking at how people feel both when a quality is present and when it is absent, and tested it with consumer surveys about television sets and table clocks.

The model sorts qualities into kinds:

Must-be: absence causes strong dissatisfaction; presence is simply taken for granted.
One-dimensional (performance): satisfaction rises roughly in proportion to how well it is done.
Attractive (delighters): absence causes no complaint, because nobody expects it; presence delights.
Indifferent: people do not care either way.
Reverse: some people are less satisfied when it is present.

Qualities also move over time. What delighted users once becomes a performance quality and then a must-be, as competitors copy it and people come to expect it.

Why it works

Satisfaction is not linear. Doubling the effort on a must-be adds nothing once it works, while a small delighter can change how a product is perceived. Knowing the kind tells you where effort pays.

Must-bes are invisible until they fail. Security, availability and data integrity are rarely praised and always punished. The model gives architects language to defend work nobody asks for.

Decay is predictable. Because delighters become expectations, a team can plan to make today's differentiator cheap and reliable before it turns into a baseline.

Where it applies

Quality attribute trade-offs, deciding how much availability, latency or accessibility is enough and where more is worth paying for.
Roadmap and backlog reviews, balancing hygiene work against visible features.
Vendor and platform selection, separating table-stakes criteria from genuine differentiators.
Platform teams, whose internal users treat most capabilities as must-bes.

How to apply

List the candidate qualities and features, including non-functional ones.
Ask both questions. For each, how would users feel if it were present, and if it were absent? Kano used paired questionnaire items; a few user conversations can be enough for a first pass.
Classify by segment. The same feature can delight one group and be indifferent or reverse to another.
Fund must-bes first, to a reliable threshold, then invest in performance where the curve still climbs, then pick a few delighters.
Revisit the classification each planning cycle, and expect drift towards must-be.

Example scenario

A logistics platform team had a backlog split between "reliability work" that product managers kept deferring and a list of dashboard features. Outages of the shipment-tracking API had caused more customer complaints than any missing feature.

The architect ran a short Kano exercise with customer success staff and a handful of shippers. Tracking API availability and correct timestamps came out as must-bes; faster label generation as performance; predictive delay alerts as a delighter. The team agreed an availability target for the must-bes before any new dashboards, kept label speed as a measured performance goal, and built the delay alerts on the event stream already in place. A year later competitors offered similar alerts, and the team was already treating them as baseline.

Questions to ask

Which of these qualities would users only notice if they were missing?
Where does doing better really raise satisfaction, and where have we already done enough?
Which of today's differentiators will users simply expect in two years, and are we ready to make them cheap?

When not to use it

Regulated requirements, which are must-be by law whatever users say.
Very new markets, where users cannot yet say how they would feel about something they have never seen.

How it misleads you

Survey answers can be shallow, and teams sometimes classify features by guesswork while calling it Kano. Delighters can become an excuse to chase novelty while must-bes rot. Treat the classification as a hypothesis, check it against behaviour, and never let a delighter ship on a weak foundation.