The Kano Model Explained
Not all features are created equal. The Kano Model helps you understand which features are table stakes, which drive satisfaction, and which create delight — so you build the right things in the right order.
What Is the Kano Model?
The Kano Model is a product development framework created by Professor Noriaki Kano at Tokyo University of Science in 1984. It categorizes product features based on their relationship to customer satisfaction — not all features affect satisfaction the same way.
The key insight: some features are expected (their absence causes anger but their presence goes unnoticed), some are proportional (more = better), and some are delightful (unexpected positives that create loyalty). Understanding which category a feature falls into changes how you prioritize it.
The priority order:
The 5 Kano Categories
Must-Haves (Basic Needs)
当たり前品質 (Atarimae Hinshitsu)
Features customers expect as a baseline. Their presence doesn't create satisfaction — but their absence causes intense dissatisfaction. Customers won't mention these in feedback because they assume they're a given. You only hear about them when they're broken.
When Present
Neutral — 'of course it has that'
When Absent
Angry — 'this is unacceptable'
Examples
- Login/authentication works reliably
- Data doesn't get lost or corrupted
- The app loads in under 3 seconds
- Basic security (HTTPS, password hashing)
- Undo/redo functionality
Strategy: Don't skip these to ship faster. Must-haves are table stakes — get them right first. They won't differentiate you, but failing on them will kill you.
Performance (One-Dimensional)
一元的品質 (Ichigen-teki Hinshitsu)
Features where satisfaction scales linearly with how well they're implemented. More is better, less is worse. These are the features customers explicitly ask for and compare between competing products. Voting boards capture these well — they're the feature requests users submit and vote on.
When Present
Satisfied — proportional to quality
When Absent
Dissatisfied — proportional to lack
Examples
- Storage space (more = better)
- Export options (PDF, CSV, Excel)
- Integration depth (Jira, Slack, Zapier)
- Customization options (branding, themes)
- API rate limits (higher = better)
Strategy: These are where you compete. Feature voting data tells you which performance features users want most. Build the highest-voted ones first.
Delighters (Attractive)
魅力的品質 (Miryoku-teki Hinshitsu)
Features customers don't expect but love when they discover them. Their absence causes no dissatisfaction (users don't know to ask for them), but their presence creates disproportionate delight. These features create word-of-mouth and differentiation.
When Present
Delighted — 'wow, I didn't expect that!'
When Absent
No effect — 'didn't know it existed'
Examples
- Keyboard shortcuts that speed up workflow
- AI-powered suggestions or auto-complete
- Beautiful data visualizations
- Automatic voter notifications when features ship
- Easter eggs or personality in the UI
Strategy: Sprinkle delighters between performance features. They create emotional loyalty that competitors can't easily replicate. But never build delighters before must-haves.
Indifferent
無関心品質 (Mukanshin Hinshitsu)
Features that customers don't care about — their presence or absence has no effect on satisfaction. These are often internal preferences or features built for edge cases that most users never encounter. Identifying indifferent features saves you from wasting development time.
When Present
No effect
When Absent
No effect
Examples
- Backend technology choices (users don't care if it's React or Vue)
- Administrative features only used by 1% of accounts
- Over-engineered settings most users never touch
Strategy: Stop building these. If a feature gets zero votes on your feedback board and zero usage in analytics, it's likely indifferent. Cut it from the roadmap.
Reverse
逆品質 (Gyaku Hinshitsu)
Features where a segment of users actively dislikes the feature. Adding it decreases satisfaction for some users. This often happens when you add complexity that disrupts existing workflows or when 'power features' intimidate casual users.
When Present
Some users dissatisfied
When Absent
Those users prefer the simpler version
Examples
- Forced tutorials on every login
- Complex settings panels that overwhelm new users
- Auto-playing content or notifications
- Mandatory profile completion steps
Strategy: Make reverse features optional or configurable. If a feature delights power users but annoys casual users, put it behind a setting or advanced mode.
Kano + Feature Voting = Better Prioritization
The Kano model tells you what type of feature it is. Voting tells you how much demand there is. Use both together.
Collect with voting
Use a voting board to continuously collect feature requests. The most-voted ideas surface naturally — these are typically Performance features in Kano terms.
Learn moreClassify with Kano
Run a Kano survey on your top-voted features. Is it a must-have you're missing? A performance feature that beats competitors? A delighter that differentiates?
Learn morePrioritize with both
Fix missing must-haves first (regardless of votes). Then build high-voted performance features. Sprinkle in delighters. Skip indifferent features even if they have votes.
Learn moreFree Kano Survey Template
Copy this template and adapt the feature names. Survey 20-50 users for meaningful results.
"Was very easy and intuitive to get started and I was able to do it in a few minutes which was good."
Joe Bloxsome,
Founder at GoPasswordless
Frequently Asked Questions
Still not convinced?
Here's a full price comparison with all top competitors
Is it lacking a feature you need?
Chances are, we're already working on it. Check our roadmap
Okay, okay! Sign me up!
Start building the right features today ⚡️