Kano model: sort feature requests by how customers feel
6 min read
The Kano model is a way to sort features by how customers react to having them and to lacking them, instead of by how many people asked. It was proposed by Noriaki Kano in 1984 and puts every feature into one of five groups: must-be, performance, attractive (delighters), indifferent and reverse. For a team with a pile of feature requests, the useful part is that it explains why a request with dozens of votes can add nothing to satisfaction while a request nobody voted for can change how people talk about the product.
| Category | Customer reaction when present | Customer reaction when missing | Typical request |
|---|---|---|---|
| Must-be | Nothing, it is expected | Strong dissatisfaction | Password reset, data export |
| Performance | Satisfaction grows with more of it | Satisfaction drops with less of it | Speed, storage, limits |
| Attractive | Delight | Nothing, nobody expected it | A thoughtful automation |
| Indifferent | Nothing | Nothing | A setting few people touch |
| Reverse | Annoyance | Relief | A forced tour or extra step |
What are the Kano model categories?
Must-be features are the ones customers assume exist. Nobody praises them and everybody notices when they break. Performance features are the ones where more is better in a straight line, such as faster reports or higher limits. Attractive features are unexpected, so their absence costs nothing and their presence earns real enthusiasm. Indifferent features move nothing in either direction, and reverse features make some customers happier when they are removed.
The category is a property of a feature for a group of customers at a moment in time, which is why the same feature can land in different groups for different segments.
How do you run a Kano survey?
Ask two questions about each feature. The functional question asks how the customer would feel if the product had the feature. The dysfunctional question asks how they would feel if it did not. Both use the same five answers: I like it, I expect it, I am neutral, I can live with it, I dislike it.
Combine the two answers with the standard evaluation grid to classify each respondent’s view of each feature:
| Functional \ Dysfunctional | Like | Expect | Neutral | Live with | Dislike |
|---|---|---|---|---|---|
| Like | Q | A | A | A | O |
| Expect | R | I | I | I | M |
| Neutral | R | I | I | I | M |
| Live with | R | I | I | I | M |
| Dislike | R | R | R | R | Q |
M is must-be, O is performance (one-dimensional), A is attractive, I is indifferent, R is reverse and Q is a questionable answer that contradicts itself. Count the letters across respondents for each feature and take the most frequent one as its category. When two categories are close, report both, because a 40/38 split tells you the segment is divided, not that one answer won.
Which feature requests belong in a Kano survey?
Only the ones you would genuinely consider building and cannot rank by gut. Five to fifteen features is a workable survey length, and each needs a one-sentence description a customer can picture without a mockup. Pull candidates from your tracked backlog after grouping duplicates, because ten requests for the same thing should reach the survey as one feature. The grouping step is covered in feature request tracking.
Leave out bug fixes and anything already promised to a contract. A survey cannot tell you whether to fix a crash.
Who should you survey?
People who already use the product, split by the segments that matter to you. A survey sent to your whole list tends to produce the average of several different groups, and an average hides the finding. Free and paying users, new accounts and long-standing ones, and small teams and large ones often put the same feature in different categories. Keep each segment’s results separate and decide which segment the next release is for.
Use the people who wrote the requests as a starting audience and add a random sample of active users, so the survey is not only the vocal minority. How to word and send the ask is in how to ask for customer feedback.
How do you turn Kano results into a priority order?
Build in this order: must-be gaps first, then performance features where you trail the alternatives your customers compare you with, then one or two attractive features per release, and indifferent and reverse features last or never. The order follows from what each category does to satisfaction. Fixing a must-be gap removes a reason to leave, performance work raises satisfaction steadily, and an attractive feature is where differentiation comes from.
Kano says what kind of value a feature carries, and it does not say what it costs. Pair the category with an effort estimate before it goes on a plan. A scoring method such as the one in RICE scoring handles the cost side, and the two work well together: Kano picks the shortlist and RICE orders it. The wider decision is in how to prioritize feature requests.
Do features move between categories over time?
Yes, and this is the most useful thing to remember about the model. Attractive features drift toward performance and then toward must-be as competitors copy them and customers get used to them. Two-factor authentication was once a pleasant surprise and is now an expectation for business software. A survey result is a snapshot, so repeat it for any category you are betting on after a year, or whenever a competitor ships something close.
Tell customers when you ship a delighter. A feature in the attractive category only delights people who find out about it, which makes the announcement part of the feature. Closing that loop is the subject of how to write a new feature announcement.
What are the limits of the Kano model?
It measures stated feelings, not behavior, so it can overrate things people say they want. It needs enough respondents per segment to see a pattern, and a few dozen is often the practical floor. It also evaluates features one by one and says nothing about how they interact. Treat the result as strong evidence for a roadmap conversation, and place it next to usage data and revenue. For turning the ranked list into a plan, see how to build a product roadmap.
FAQ
What is the Kano model in simple terms? It is a method that sorts features into groups by how customers feel when the feature exists and when it is missing. The groups are must-be, performance, attractive, indifferent and reverse, and each one points to a different build priority.
How many people do you need for a Kano survey? There is no fixed number, but each segment you want to read separately needs enough answers to show a clear majority category. A few dozen per segment is a common practical minimum, and a split result with fewer answers should be read as unresolved.
Is the Kano model better than RICE? They answer different questions. Kano classifies the kind of value a feature gives customers, and RICE ranks work by reach, impact, confidence and effort. Many teams use Kano to build the shortlist and a scoring method to order it.
How often should you repeat a Kano analysis? Yearly for stable products, and sooner when a competitor ships a similar feature. Delighters turn into expectations over time, so an old result can point you at a feature that no longer differentiates.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.