Kano model: the five feature categories, survey and analysis

The Kano model sorts product features by how they affect customer satisfaction, not by how much work they are. It splits features into five categories: must-be, performance, attractive, indifferent and reverse. The useful insight is that these categories behave differently. Doing more of a must-be feature earns you nothing, while a single attractive feature can carry a release.

Noriaki Kano, a professor at the Tokyo University of Science, developed the model in the early 1980s with colleagues studying quality and customer satisfaction. It survived because it names something every product person has felt: two features can cost the same and land completely differently. This article covers the five categories, how the survey works, how to read the results, and where the method gets misused.

What is the Kano model?

The Kano model is a framework for classifying product features by the relationship between how well a feature is implemented and how satisfied customers are with it. Instead of assuming that satisfaction rises evenly with effort, it recognizes several distinct curves. Some features only create dissatisfaction when absent, some scale linearly, and some delight out of proportion to their size.

That shape difference is the whole payoff. If you treat every backlog item as a point on one straight line, you will over-invest in things customers already assume and under-invest in the one feature they would tell a colleague about. The model gives you a vocabulary for that argument, which is why it keeps showing up alongside scoring methods in idea prioritization work.

What are the five Kano categories?

Five categories, each with its own satisfaction curve. Must-be features are expected and invisible when present. Performance features scale: more is better, and customers can tell. Attractive features delight when present and are not missed when absent. Indifferent features move nothing. Reverse features actively annoy the people you added them for.

Password requirements are the classic must-be: nobody has ever praised a login screen, and everybody notices a breach. Page load speed is a performance feature, measurable and comparable to competitors. An import that reads the messy spreadsheet your customer already has, correctly, on the first try, is attractive: they expected pain and did not get it. And plenty of shipped features turn out to be indifferent, which is the finding teams find hardest to accept.

Do features change category over time?

Yes, and this is the part people forget. Categories drift downward. Today's delighter is next year's performance feature and, eventually, a must-be that earns nothing. Mobile apps, free shipping, dark mode and single sign-on all made that trip. A Kano classification is a snapshot with a shelf life, not a permanent label.

Practically, that means re-running the survey every year or two on your core feature set, and treating any competitive advantage built on a delighter as temporary. It also means the maintenance argument is real: features that slid into must-be territory still have to work perfectly, they just no longer buy you goodwill. Budget for keeping them alive without expecting anything back.

How do you run a Kano survey?

You ask two questions about every feature. The functional question is how the customer would feel if the feature were present. The dysfunctional question is how they would feel if it were absent. Both use the same five answers: I like it, I expect it, I am neutral, I can tolerate it, I dislike it. The pair of answers maps to a category on a standard evaluation grid.

The two-question structure exists to catch people saying yes to everything. Ask only "would you like this?" and every feature scores well, because nobody objects to a free improvement. Asking how they would feel without it separates the features they would genuinely miss from the ones that merely sound nice. Keep the list under about fifteen features, because the survey doubles in length by design and quality drops fast. Sample from real customers in the segment you are building for, not from a mixed list, since a feature is often attractive to one segment and reverse to another.

A third question is worth adding: how important is this feature to you, on a scale of one to nine. Category alone does not tell you which of your six performance features to fund first, and importance breaks that tie.

How do you analyze Kano results?

Two ways, and use both. The discrete method assigns each response pair a category, then reports the most frequent category per feature across all respondents. It is easy to explain and holds up when your sample is small. The continuous method converts responses into satisfaction and dissatisfaction coefficients, then plots features on a two-axis chart, which is better for seeing how strongly a feature pulls in each direction.

The satisfaction coefficient runs from 0 to 1 and tells you how much satisfaction rises when you add the feature. The dissatisfaction coefficient runs from 0 to negative 1 and tells you how much it falls when the feature is missing. A must-be sits near zero on the first and near negative one on the second. An attractive feature sits near one and near zero. Features that land near zero on both are indifferent, and that quadrant is usually more crowded than a roadmap owner would like.

Watch the spread as well as the modal answer. A feature split evenly between attractive and indifferent is not really indifferent: it is a feature for one segment that you surveyed across two. That finding is more valuable than the category, because it tells you the real work is segmentation, and it is exactly the kind of signal a team tracking the whole customer journey and support workload will already have seen from a different angle.

Kano model versus other prioritization frameworks

Kano answers a different question than the scoring frameworks it gets compared to. It tells you what kind of value a feature creates. It does not tell you what to build first, because it says nothing about cost, reach or confidence. Used alone it produces a room full of delighters and a product that cannot log people in.

The clean sequence is to classify with Kano, then rank with something that includes effort. Cover the must-be gaps first because they are dealbreakers, hold your performance features at or above the competitive bar, and fund one or two attractive features per release. Then run the shortlist through RICE scoring or plot it on an impact effort matrix to sequence the work. If your team prefers a lighter commitment ritual, MoSCoW prioritization pairs well with Kano because must-be maps almost directly onto Must.

Where the Kano model goes wrong

Three failure modes are common. The first is surveying the wrong people: internal stakeholders, or a customer list that spans segments with opposite needs. The results average into mush and every feature reads as indifferent. The second is asking about features customers cannot picture. Kano depends on respondents imagining a state accurately, and a one-line description of an unfamiliar capability gets guessed at, not evaluated.

The third is treating the output as a decision. A category is an input. Teams that skip the effort question end up with a roadmap of delighters, each individually defensible, that collectively never ships. The model tells you the shape of the value, and you still have to do the arithmetic on cost.

The quieter problem is that Kano can only classify features you already thought of. It is a sorting tool applied to a list, and the list is where most of the leverage actually sits. If the candidate set is thin, a careful classification of thin options produces a well-organized, unremarkable roadmap.

Getting a candidate list worth classifying

Before you survey anything, widen the set. Run the problem through forced angles, invert it, remove a constraint, borrow a mechanic from an adjacent industry, and you will generate candidates that never come out of a backlog grooming session. Delighters in particular almost never appear on a list built from feature requests, because customers ask for improvements to what exists rather than for things they have not imagined.

That is the step Brainstormer handles: a problem statement in, dozens of genuinely different directions out, clustered into themes and scored on impact against effort. Classify the survivors with Kano, and you are choosing between real options instead of ranking the obvious ones. Teams doing this on a repeating cycle usually work from the product team workflow, and the studio at the top of this page runs the whole arc on your own problem.