{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-05-24T18:59:38.009Z"},"content":[{"type":"documentation","id":"0a09370a-f60b-4287-bbca-1ceeaa400edc","slug":"kano-model","title":"Kano Model: How to Prioritize Features Using Customer Research","url":"https://www.koji.so/docs/kano-model","summary":"The Kano Model (1984) classifies product features into Must-Be, Performance, Attractive, Indifferent, and Reverse categories based on customer emotional response. Teams use paired functional/dysfunctional survey questions to identify which features drive delight, which prevent dissatisfaction, and which waste engineering resources. AI-moderated interviews can run Kano studies at scale in days rather than months.","content":"# Kano Model: How to Prioritize Features Using Customer Research\n\n**Bottom line:** The Kano Model classifies product features by their emotional impact on customers — revealing which features prevent dissatisfaction, which drive delight, and which waste engineering resources entirely. Teams that skip Kano analysis consistently over-invest in features customers do not want.\n\n80% of features in the average software product are rarely or never used (Pendo, 2019). The Kano Model exists to prevent that waste.\n\nDeveloped by Japanese professor Noriaki Kano in his landmark 1984 paper \"Attractive Quality and Must-Be Quality,\" the Kano Model is one of the most cited frameworks in product development history — with over 3,600 academic citations. Its central insight: customer satisfaction is not linear. Building more of a feature does not proportionally increase satisfaction. Different types of features have fundamentally different relationships with how customers feel.\n\n## The 5 Kano Categories\n\nThe model maps features on two axes: how well a feature is implemented (absent to fully present) and how customers feel as a result (dissatisfied to delighted). The resulting curves are non-linear — which is what makes the framework powerful.\n\n
\n \n
\n The five Kano categories at a glance.\n Noriaki Kano, Attractive Quality and Must-Be Quality (1984)\n
\n
\n\n### Must-Be (Basic) Features\n\nThese are non-negotiable baseline requirements. When present, they produce no positive emotional reaction — satisfaction stays neutral. When absent, customers are severely dissatisfied. They are the price of entry to a market.\n\nNo investment in Must-Be features creates delight. It only prevents dissatisfaction.\n\n**Examples:** A car that starts reliably. A mobile app that does not crash. Secure login on a banking platform.\n\n### Performance (One-Dimensional) Features\n\nThese have a direct, linear relationship with satisfaction. More equals better, less equals worse. Every incremental improvement produces a measurable, proportional increase in customer satisfaction.\n\n**Examples:** Laptop battery life. Camera resolution. E-commerce delivery speed. Page load time.\n\n### Attractive (Delighter) Features\n\nThese are unexpected features that produce disproportionate jumps in delight when present. When absent, customers do not miss them because they do not expect them. When present and well-executed, they generate excitement and brand loyalty — this is where differentiation lives.\n\n**Examples:** The pinch-to-zoom gesture on the original iPhone (2007). Netflix personalized recommendations. A hotel leaving handwritten notes for guests.\n\nAs Nielsen Norman Group notes in their prioritization methods guide: \"The Attractive category shows a disproportionate increase in satisfaction to functionality, and users may not even notice their absence — but with good-enough implementation, user excitement can grow exponentially.\"\n\n### Indifferent Features\n\nCustomers genuinely do not care whether these are present or absent. They produce no movement in satisfaction either way. These are a significant source of wasted engineering investment — research suggests 30-40% of the average SaaS backlog maps to this category.\n\n### Reverse Features\n\nThese actively decrease satisfaction when present. Some users are harmed by, confused by, or resentful of features built for other user segments — especially common when teams fail to segment respondents by user type.\n\n**Example:** Overaggressive push notifications. Mandatory onboarding tutorials for power users.\n\n## How to Run a Kano Survey\n\nThe Kano survey uses paired question sets — one functional (feature present) and one dysfunctional (feature absent) — for each feature being evaluated.\n\n### The Question Structure\n\nFor every feature, ask two questions:\n\n**Functional question (feature present):**\n\"How would you feel if this product had [Feature X]?\"\n\n**Dysfunctional question (feature absent):**\n\"How would you feel if this product did NOT have [Feature X]?\"\n\n### Response Scale\n\nBoth questions use the same 5-point scale:\n1. I like it that way\n2. I expect it that way (it is a given)\n3. I am neutral\n4. I can tolerate it\n5. I dislike it that way\n\n### Kano Classification Matrix\n\nPair the functional and dysfunctional answers to classify each response:\n\n| Functional | Like | Expect | Neutral | Tolerate | Dislike |\n|---|---|---|---|---|---|\n| **Dislike (Dysfunc.)** | Performance | Must-Be | Must-Be | Must-Be | Questionable |\n| **Tolerate** | Attractive | Indifferent | Indifferent | Indifferent | Must-Be |\n| **Neutral** | Attractive | Indifferent | Indifferent | Indifferent | Must-Be |\n| **Expect** | Attractive | Indifferent | Indifferent | Indifferent | Must-Be |\n| **Like** | Questionable | Attractive | Attractive | Attractive | Reverse |\n\n### Survey Design Best Practices\n\n- **Sample size:** Minimum 30 responses per customer segment\n- **Feature count:** 15-25 features per survey; beyond 30 causes fatigue\n- **Framing:** Use \"How would you feel if...?\" — not \"Would you use...?\" Feelings, not utility\n- **Order randomization:** Randomize whether functional or dysfunctional question appears first\n- **Add importance:** After each pair, ask \"How important is this feature to you?\" on a 1-9 scale\n- **Segment separately:** Different user types must be analyzed as distinct cohorts\n\n### Calculating Satisfaction Coefficients\n\nAfter classifying features, calculate two coefficients for each:\n\n- **Satisfaction (CS):** (Attractive + Performance) / (Attractive + Performance + Must-Be + Indifferent)\n- **Dissatisfaction (DS):** -1 x (Must-Be + Performance) / (Attractive + Performance + Must-Be + Indifferent)\n\nPlot features on a CS/DS grid: high CS + low DS signals Delighters worth investing in; high DS signals Must-Be baseline requirements to protect.\n\n## The Kano Category Lifecycle\n\nOne of Kano's most important predictions: categories shift over time as market expectations evolve.\n\n**The iPhone example:** When Apple launched the iPhone in 2007, pinch-to-zoom and visual voicemail were Attractive Delighters — unexpected features customers had not known to ask for. The audience reaction was textbook Kano: disproportionate delight from an unanticipated capability. Today, those same gestures are Must-Be features. Any smartphone missing them would be perceived as broken.\n\n**Dark Mode:** An Attractive feature for developers in 2016 became a Performance attribute by 2019 and a Must-Be expectation by 2022.\n\nThis lifecycle migration means Kano surveys need to be re-run regularly — annually, or after major competitor releases.\n\n## Kano vs. Other Prioritization Frameworks\n\n| Framework | Core Question | Best For |\n|---|---|---|\n| **Kano** | Should we build this at all? | Discovery — eliminating features customers do not want |\n| **RICE** | Which validated ideas have the best return? | Backlog scoring — comparing impact vs. effort |\n| **MoSCoW** | What fits into this release? | Scope finalization — aligning teams on what ships now |\n\n
\n \n
\n Three frameworks, three different prioritization questions.\n Koji analysis of Kano, RICE and MoSCoW prioritization frameworks\n
\n
\n\n**Recommended combined workflow:**\n1. Use Kano during discovery to eliminate Indifferent features and identify Delighters\n2. Use RICE to score the shortlisted Kano output against business impact and effort\n3. Use MoSCoW to finalize what fits given capacity constraints\n\nEach framework answers a different question. Combining them produces a more complete prioritization system than any single framework alone.\n\n
\n \n
\n From customer signal to shipped scope in three frameworks.\n Koji recommended Kano-led product prioritization workflow\n
\n
\n\n## The Scale Problem: Why Traditional Kano Studies Are Too Slow\n\nRunning a rigorous Kano study with traditional human-moderated interviews is expensive and slow:\n\n- A 200-interview qualitative Kano study through a research agency costs approximately **$100,000 and takes 8-12 weeks**\n- Static Kano surveys scale easily but cannot probe the \"why\" behind a classification\n- Product cycles move faster than traditional research timelines allow\n\nThis is the gap that AI-powered research platforms are closing.\n\n## How Koji Accelerates Kano Research\n\nKoji's AI-moderated interviews enable product teams to run Kano-quality research at quantitative scale — in days, not months.\n\n**Scale with depth:** Conduct Kano functional/dysfunctional question pairs across 200+ participants while the AI dynamically follows up on unexpected responses. A feature classified as \"Reverse\" by 40 participants? Koji asks each one why — capturing the qualitative reasoning that static surveys permanently miss.\n\n**Structured question types for Kano surveys:** Koji's [structured question framework](/docs/structured-questions-guide) supports six question types — including scale questions (perfect for the 1-5 Kano response scale), single-choice questions (for classification), and open-ended follow-ups — enabling a complete Kano survey with integrated qualitative probing in a single study.\n\n**Speed:** What previously took 8-12 weeks now completes in 72 hours. Teams can run quarterly Kano re-surveys to track category migration as the market evolves.\n\n**AI-generated themes:** After classification, Koji's analysis automatically surfaces the most common reasons behind each category assignment — translating raw Kano data into actionable design direction.\n\nMarty Cagan, author of *Inspired*, frames the problem Kano solves: \"The purpose of product discovery is to quickly separate the good ideas from the bad. The output of discovery is a validated product backlog.\" Kano is the discovery instrument that operationalizes exactly this. AI-moderated interviews make it economically viable at the speed modern product teams require.\n\n## Common Kano Mistakes to Avoid\n\n**Not segmenting by user type.** A feature classified as \"Attractive\" for power users may be \"Indifferent\" or \"Reverse\" for casual users. Always analyze cohorts separately.\n\n**Treating category assignments as permanent.** Re-run annually, or after major competitor releases. Categories shift as market expectations evolve.\n\n**Asking about utility instead of feelings.** \"Would you use X?\" captures rational assessment. \"How would you feel if X were missing?\" captures the emotional reaction the Kano model is calibrated to measure.\n\n**Surveying too many features at once.** Beyond 25-30 features, respondents experience fatigue. This compresses variance and pushes too many features toward \"Indifferent.\"\n\n**Ignoring the Questionable category.** A respondent who says they like a feature both when present and absent is giving a logically inconsistent answer. Filter these responses out — do not reclassify them.\n\n**Using Kano in isolation without the \"why.\"** Kano gives quantitative category assignments but cannot explain why a feature lands where it does. Pair the survey with qualitative follow-up interviews to get the reasoning behind the data.\n\n## Key Statistics\n\n- **80% of features** in the average software product are rarely or never used (Pendo 2019 Feature Adoption Report)\n- **64% of features** are \"rarely or never used\" — 45% never used at all (Standish Group, via Mountain Goat Software)\n- **35% of companies** add features primarily to close deals rather than improve customer value (ITONICS)\n- Teams with comprehensive customer-insight testing protocols report failure rate reductions of **30-50%** (We Are Tenet)\n\n## Related Resources\n\n- [Structured Questions Guide: 6 Types for Better Research](/docs/structured-questions-guide)\n- [Survey Design Best Practices](/docs/survey-design-best-practices)\n- [Jobs to Be Done Interviews](/docs/jobs-to-be-done-interviews)\n- [Qualitative vs. Quantitative Research](/docs/qualitative-vs-quantitative-research)\n- [User Interview Guide Template](/docs/user-interview-guide-template)\n- [How to Analyze Qualitative Data](/docs/how-to-analyze-qualitative-data)\n\n\n## Further reading on the blog\n\n- [Best Online Survey Software in 2026: The Complete Buyer's Guide](/blog/best-survey-software-2026) — From SurveyMonkey to Koji, we compare the top survey tools of 2026 across features, pricing, and use case fit — and explain when traditional\n- [Beta Testing User Research: How to Get Real Insight from Beta Users (Not Just Bug Reports) in 2026](/blog/beta-testing-user-research-2026) — Most beta programs collect bug reports and call it research. They are not the same thing. Here is how product teams in 2026 are running beta\n- [Customer Research Done Right: A Complete Guide for Product Teams](/blog/customer-research-done-right-a-complete-guide-for-product-teams) — Customer research is the foundation of every successful product decision. Learn the types, methods, and best practices that help product tea\n\n\n","category":"Research Methods","lastModified":"2026-05-24T03:23:14.655965+00:00","metaTitle":"Kano Model: The Complete Guide to Feature Prioritization (2026)","metaDescription":"Learn how to use the Kano Model to prioritize product features using customer research. Includes survey templates, classification matrix, and how AI interviews accelerate Kano analysis.","keywords":["kano model","kano analysis","feature prioritization","kano survey","product research","customer satisfaction research","kano model template","kano model examples"],"aiSummary":"The Kano Model (1984) classifies product features into Must-Be, Performance, Attractive, Indifferent, and Reverse categories based on customer emotional response. Teams use paired functional/dysfunctional survey questions to identify which features drive delight, which prevent dissatisfaction, and which waste engineering resources. AI-moderated interviews can run Kano studies at scale in days rather than months.","aiPrerequisites":["basic understanding of user research","product backlog or feature list to evaluate"],"aiLearningOutcomes":["understand the 5 Kano categories and how they differ","write and administer a Kano survey","classify features using the Kano evaluation matrix","calculate satisfaction and dissatisfaction coefficients","combine Kano with RICE and MoSCoW for complete prioritization"],"aiDifficulty":"intermediate","aiEstimatedTime":"18 minutes"}],"pagination":{"total":1,"returned":1,"offset":0}}