A smarter way to decide which features actually matter

The Kano Model is a framework developed by Noriaki Kano in the 1980s for categorising features based on how they affect customer satisfaction. The core insight is that not all features are equal. Some are expected as table stakes. Some genuinely delight. Some don't move the needle either way. And some — if overdone — actually start to frustrate.

Understanding which category a feature falls into changes how you prioritise it, how much you invest in it, and how you sequence it on the roadmap. It's one of the cleaner ways to cut through the "everything is a priority" problem that plagues most product teams.

Basic (Must-Have) qualities — features users expect as table stakes. Their presence doesn't increase satisfaction; their absence causes serious dissatisfaction. Two-factor authentication in a fintech product is a must-have. Nobody celebrates it, but its absence kills trust.

Performance qualities — the more of these, the better. These have a roughly linear relationship with satisfaction. Speed, accuracy, depth of reporting — all performance qualities. Users will pay more for more of them.

Excitement (Delighter) qualities — features users didn't expect but love when they find them. They drive disproportionate satisfaction, but their absence doesn't disappoint. Delighters have a short shelf life: once competitors copy them, they shift into performance or must-have territory.

Indifferent qualities — features that users neither notice nor miss. These are the most dangerous category because teams build them anyway. Every indifferent feature you ship is capacity not spent on something users care about.

Reverse qualities — features some users actively dislike. Onboarding tooltips are a common example: expert users often find them patronising and in the way.

The Kano survey asks two questions about each feature: how do you feel if this feature is present? And how do you feel if it's absent? The five-point response scale runs from "I love it" to "I dislike it."

The combination of functional (present) and dysfunctional (absent) responses maps each feature to one of the five categories. The Nielsen Norman Group has a solid primer on integrating Kano into user research, and it works best when folded into regular discovery cycles rather than run as a one-off.

Plan for 20–50 participants per segment. Less than that and the category distributions get noisy.

The most common mistake is treating delighters as performance features — investing heavily in excitement features until they're over-polished, while must-have qualities are still broken or incomplete.

Another pattern: skipping the indifferent analysis. Teams love to build. Knowing which features users don't care about is valuable precisely because it frees capacity for things that matter.

A third mistake: running the survey once and treating the results as permanent. Kano categories shift over time — delighters become must-haves faster than most teams expect, especially in competitive markets where features spread quickly.

Kano is most valuable at two moments:

• Before a major release — when you have five competing feature priorities and can't do them all
• Post-launch validation — checking whether features you shipped actually land in the expected category

It pairs naturally with {{LINK:jobs-to-be-done}} research: JTBD tells you what users are trying to accomplish; Kano tells you which features best support those jobs and how much satisfaction each one delivers. Together they give you a much tighter brief than either method alone.