Framework
Kano Model
Classify product features by the kind of customer value they create — table stakes, performance drivers, delighters, indifference or active dislike — before deciding what to build.
Use Kano when every feature request is being treated as equally valuable. Shipping a basic expectation prevents disappointment but rarely creates delight; polishing it further may buy almost nothing. A delighter behaves differently: customers do not miss it when it is absent, but its presence can change how the product feels. Kano makes that difference explicit before effort enters the conversation.
The five categories
| Category | If absent | If present | Roadmap implication |
|---|---|---|---|
| Must-be · table stakes | Strong dissatisfaction | Expected, not celebrated | Protect the baseline; stop polishing once it is reliably good enough. |
| Performance · more is better | Dissatisfaction | Satisfaction rises with delivery | Invest where improvement is visible and customers compare alternatives. |
| Attractive · delighters | No disappointment | Disproportionate delight | Use selectively to differentiate; validate that the delight is real. |
| Indifferent | Little effect | Little effect | Cut, simplify or deprioritise unless another constraint justifies it. |
| Reverse | Some customers prefer it | Some customers dislike it | Avoid forcing it; segment the experience or make it optional. |
The categories are not a ranking. A product without its must-be features fails before its delighters matter; a roadmap made only of table stakes becomes competent but forgettable.
Run the paired-question test
Choose one segment and decision
Name whose satisfaction you are testing and what roadmap decision the answer must inform. Enterprise admins and end users can classify the same feature differently.
Ask the functional question
For each feature: "How would you feel if the product had this?" Offer the same five responses each time: I like it; I expect it; I am neutral; I can tolerate it; I dislike it.
Ask the dysfunctional question
Then ask: "How would you feel if the product did not have this?" Use the same responses. The pair matters — asking only whether someone wants a feature turns every nice idea into a yes.
Classify and compare
Use Kano's evaluation table to classify each response pair, then look at the dominant category and meaningful splits by segment. Do not average away disagreement that changes the product choice.
Revisit as expectations move
Delighters become performance features and eventually table stakes. Re-run the classification when the market or customer mix changes.
A worked product example
| Feature in an invoicing product | Likely category | Why |
|---|---|---|
| Accurate totals and saved invoices | Must-be | Failure destroys trust; success is simply expected. |
| Faster month-end reconciliation | Performance | Every reduction in time creates visible value. |
| Proactive anomaly detection | Attractive | Customers may not expect it, but catching an error early creates delight. |
| Animated invoice themes | Indifferent | Novelty does not improve the job most finance teams hired the product to do. |
| Forced AI rewriting of every description | Reverse | Some users experience automation as loss of control rather than value. |
Kano asks what kind of customer value a feature creates. RICE asks how much reach and impact that value may produce for the effort. Classify first, then score — and keep strategic judgment in the room.
Related capabilities
Related tools
Work with Ben
Want help installing this?
Outstride OS is the system behind Ben's founder coaching — pre-seed to Series C. If this page names something you are living right now, start a conversation.