The Kano Model: How to Prioritize Features by What Users Actually Value
The Kano model classifies features by how they affect user satisfaction, not just by effort and impact. This guide covers the five categories, how to run a Kano survey, and when to use the model over simpler prioritization frameworks.
By The Cala Voice Team ·Most prioritization frameworks measure two things: how hard something is to build and how much impact it will have. This is a useful starting point, but it misses a dimension that turns out to matter significantly: not all positive impact is the same kind of positive impact.
A feature that prevents users from churning if it is absent operates differently from a feature that linearly improves satisfaction the more you invest in it, which operates differently from a feature that delights users precisely because they did not expect it. Treating all three the same way, scoring them on impact and effort and ranking the results, produces a roadmap that is logical but systematically underweights the features that create the most durable competitive differentiation.
The Kano model, developed by Noriaki Kano in 1984, is a framework for classifying features based on how they affect user satisfaction. It does not replace effort and impact estimation. It adds a dimension that changes which features are worth building at all.
The Five Categories
Kano identified five ways a feature can relate to user satisfaction. Three are the ones that matter most for product decisions.
Basic needs (must-haves)
Basic needs are features that users expect without being able to articulate them. Their absence creates strong dissatisfaction. Their presence creates no satisfaction. It is simply the baseline that users assume. Security and privacy in a banking app. Page load speed on any web product. The ability to export data from a tool that stores your data.
The defining characteristic of a basic need: it cannot delight users no matter how well you execute it. Users do not notice it when it is there. They notice immediately when it is not.
The product implication is that investing heavily in basic needs beyond a threshold produces almost no return in satisfaction. Getting them to "good enough" is essential. Going beyond "good enough" is a misallocation.
Performance needs (linear)
Performance needs are features where more is genuinely better and satisfaction scales roughly linearly with the level of execution. Battery life in a smartphone. Speed of a search feature. Range of a filter. Depth of reporting in an analytics tool.
Users can articulate performance needs when asked, and their satisfaction increases directly with how well you execute them. This is the category most prioritization frameworks implicitly assume everything falls into, which is why they work reasonably well but miss the edges.
The product implication: performance needs are worth investing in continuously, but the return is predictable and incremental. Improving battery life from 8 hours to 10 hours increases satisfaction. Improving it from 10 to 12 increases it again by roughly the same amount. There is no discontinuity.
Excitement needs (delighters)
Excitement needs are features that users do not expect and cannot articulate before they experience them, but they produce disproportionate satisfaction when present. Their absence creates no dissatisfaction, because users had no prior expectation. Their presence creates genuine delight.
The classic example is the first time a product anticipated a need the user did not know they had. Spotify Discover Weekly when it launched. The first time a maps app showed you real-time traffic. Features that feel like the product understands you rather than just serving you.
The product implication is the most strategically interesting one: delighters are where competitive differentiation comes from. A product that executes on basic needs adequately and does performance needs well is a competent product. A product that also delivers genuine delighters earns loyalty and word of mouth that competent execution cannot produce.
Indifferent features
Features that users neither notice nor care about in either direction. They have no meaningful effect on satisfaction when present or absent. Many features that teams spend significant time debating fall into this category, and arguments that feel important internally turn out not to register with users at all.
Reverse features
Features that actually decrease satisfaction for some users when present. Complexity that overwhelms new users. Options that add cognitive load without adding value. Personalization that feels intrusive rather than helpful. Identifying reverse features matters because shipping them is worse than not shipping them, and they are rarely caught by conventional prioritization.
How Satisfaction Changes Over Time
The most important insight from the Kano model is that feature categories are not fixed. They decay.
Features that were delighters in one period become performance needs as users adjust their expectations. Features that were performance needs become basic needs as the market normalizes them. What delighted users three years ago is often what infuriates them today when it is absent.
The first time a food delivery app showed you real-time delivery tracking was a delighter. Today it is a basic need — its absence would cause users to switch products. The first time a streaming service produced a recommended playlist based on your listening history was a delighter. Today, recommendation quality is a performance need that users evaluate consciously when comparing services.
The product implication: your Kano analysis from two years ago is wrong today. The category each feature belongs to requires ongoing reassessment. The strategic question of what will be a delighter two years from now that users do not yet know to ask for is one that requires looking ahead of the market, not just at it.
How to Run a Kano Survey
The Kano model has a specific survey methodology that makes feature classification rigorous rather than intuitive.
For each feature you want to evaluate, you ask two questions: a functional question ("How would you feel if this feature was present?") and a dysfunctional question ("How would you feel if this feature was absent?"). Each question has five response options: I would love it, I expect it, I am neutral, I can live with it, I dislike it.
The combination of functional and dysfunctional responses maps each feature to a category for each respondent. A feature that users would love if present but are neutral about if absent is a delighter. A feature that users expect if present and dislike if absent is a basic need. A feature where more presence increases satisfaction linearly is a performance need.
Aggregating these responses across your user base gives you a distribution. Not every user categorizes every feature the same way, which is itself useful information. If a feature is a basic need for enterprise users but a delighter for casual users, you have a product decision to make about which segment you are optimizing for.
When to Use the Kano Model
Kano is most useful in two situations.
The first is roadmap planning when you have a long list of potential features and need to go beyond effort-and-impact scoring to understand which features create durable differentiation versus which ones just add incremental value. Running a Kano survey on your top 20 candidate features takes a few weeks but produces a map of where the strategic leverage actually is.
The second is competitive analysis. Mapping your competitors' products through the Kano lens, covering which of their features are basic needs you must match, which are performance needs where they have an advantage, and which are delighters driving their NPS, is a cleaner framework for understanding competitive positioning than a feature comparison matrix.
Kano is less useful for small, incremental decisions or in early-stage products where the core value proposition is still being validated. In 0-to-1 work, understanding the category of a feature matters less than understanding whether the underlying problem is real. Once there is evidence of fit and the question shifts to what to build next, Kano becomes a more valuable tool.
Kano in a PM Interview
The Kano model comes up in PM interviews most often in two contexts: product design questions where you are asked to prioritize which features to build, and metrics questions where you are asked to define what success looks like.
In a product design question, applying Kano framing demonstrates that you think about feature value in terms of user psychology and satisfaction dynamics, not just raw impact. Noting that a feature is a basic need ("users will expect this: it removes dissatisfaction but does not create delight") versus a potential delighter ("this is unexpected, and if executed well it could be a genuine differentiator") shows a more sophisticated prioritization instinct than effort/impact scoring alone.
In a metrics discussion, the insight that different feature types should be measured differently — basic needs measured by absence (complaint rates, support tickets), performance needs measured by level (rating, NPS correlation), delighters measured by discovery and adoption curves — is a signal of analytical nuance that most candidates do not bring.
For the full framework landscape, PM Interview Frameworks covers how Kano fits alongside other prioritization tools. For the product design question format where prioritization decisions come up most, the Product Design Interview Guide covers the structure.
Cala Voice includes framework audio briefs — short audio explainers on Kano, RICE, Jobs to Be Done, and the other frameworks that come up in PM interviews — so you can review them on your own schedule before your mock sessions.