Why the Kano Model Has Five Categories, Not Three

The Kano model classifies how customers feel if a feature is present versus absent. Satisfaction does not rise in a straight line with more functionality.

Noriaki Kano, Nobuhiko Seraku, Fumio Takahashi, and Shin-ichi Tsuji published the method in 1984. English-speaking product teams still use the 1993 CQM table.

Pronounce it Kah-no. The survey sorts five preference types plus a Questionable flag, not the three-level cut many glossaries still teach.

You get the categories, the functional/dysfunctional pair, the printed 25-cell table, and the mixed-mode rules on one page. The examples are software and UX features (SSO, search latency, dark mode), not cars or hotel warranties.

Key Takeaways

• Satisfaction is asymmetric. Shipping more of a Must-be feature does not delight anyone; missing it tanks the experience.
• The survey method classifies five preference types (Must-be, One-dimensional, Attractive, Indifferent, Reverse) plus Questionable as a data-quality flag.
• Every feature gets two questions: how you would feel if you had it, and how you would feel if you did not.
• Start with the mode from the 25-cell table, then use Better/Worse coefficients when the tally is split. Leave Reverse and Questionable out of that denominator.
• Use Kano to name 9–18 month pillars. Do not use it to pick this sprint's tickets or to score a live login flow.

What Is the Kano Model?

The Kano model is a customer-preference classification method. You map two axes: functionality (absent to fully implemented) against satisfaction (frustrated to delighted).

The 1984 JSQC paper is titled "Attractive Quality and Must-Be Quality," volume 14, issue 2, pages 147-156. The abstract is a questionnaire about a TV set and a table clock, plus a new-clock planning example. It is not a 900-person origin myth.

"More quality equals more satisfaction" only holds for one-dimensional features. Must-be features sit flat once they work. Attractive features sit flat when they are missing.

Satisfaction versus functionality is a curve, not a ranked wishlist. The English instructions most PMs still follow come from the CQM Journal (Berger, Timko, DuMouchel, Pouliot, and colleagues, Fall 1993).

That CQM issue is where the 5x5 lookup and the Customer Satisfaction Coefficient were written down for English readers. The same issue records BBN Software Products applying the method to RS/1 Release 5.0, an early software case.

Kano analysis and Kano method point at the same survey. A page titled only "kano" collides with a city, a brand, and a computer.

Why Preference Type Beats a Wishlist in 2026

UX teams still get asked to "prioritize the backlog." A scored list treats every request as the same kind of need. Jared Spool puts the split in one line: not-sucky is not the same world as delightful.

Must-bes are not yours to invent. Spool's hotel example: the site never promised a bathroom, and you would still leave if the room did not have one. On a product team, that is reliable login, send that works, and an app that does not crash.

Polish on top of those does not register. On r/ProductManagement, the recurring complaint is a cool idea next to a broken essential.

"I once tested some novel ideas in a commercial context. The users sighed. 'This is cool and all, but if I could just login reliably that's all I need.'"
u/poodleface in r/ProductManagement (Oct 2024)

Kano is one instrument inside UX research methods. It answers a narrower question than qualitative research or usability testing: what kind of satisfaction a candidate feature carries, before you spend a quarter building it.

Five Preference Types (Not Three Levels)

Quality-management glossaries still collapse the method into three levels: expected / normal / exciting, or musts / wants / wows. Cambridge IfM, ASQ, and Baymard Institute teach that three-way cut.

The three-way cut is useful on a whiteboard. The questionnaire classifies five preference types. Questionable is a sixth cell in the lookup table: a data-quality flag, not a customer need.

Daniel Zacarias's Folding Burritos essay still opens with four categories, then adds Reverse and Questionable through the questionnaire. That opening is why search snippets say four. Teach five plus Q.

Must-Be

Users do not thank you when SSO works. They leave, or they open a ticket, when login fails, the app crashes, or send does not go out.

You cannot raise satisfaction by polishing a Must-be. You can only stop losing it.

Request volume is not proof a feature is One-dimensional. People file tickets for Must-bes too.

Must-be is also a bad topic for a Kano study once the feature is already in production. Researchers on Reddit treat live auth options as a collapse-to-Indifferent risk. Measure those with CSAT, CES, and behavior, not another pair of hypothetical questions.

One-Dimensional

One-dimensional (Performance) is the only category where "more is better" holds. Faster search, quicker export, more storage, higher API limits: satisfaction tracks the investment.

This is also where wording traps hide. "How would you feel if export finished in under 10 seconds?" is a presence question. The dysfunctional pair is absence of that speed, not "export takes longer than 10 seconds" as a new promise.

Get the pair wrong and the feature codes as something else.

Compete here after the floor is solid. Teams that pour Performance into a product whose Must-bes are broken are decorating a leak.

Attractive

AI-powered suggestions, a well-timed onboarding motion, a no-code automation on a painful workflow: users did not ask for these by name. They tell the story later. Attractive features delight when they appear and go unnoticed when they do not.

Attractive is also the category stakeholders fake. A "wow" animation next to a broken login is a bribe, not a delighter. Spool's Hyatt story (random massages and upgrades while the air conditioning and broken glass stayed broken) is the same pattern.

Attractive is not permanent differentiation. Kano called the slide "quality obsolescence." A feature that codes Attractive this year can code Performance, then Must-be, once users treat it as the default.

Indifferent

Dark mode is the teachable surprise. Stakeholders demand it; in more than one method write-up it codes Indifferent for a large share of respondents. Indifferent means the pair does not move satisfaction either way.

Elaborate permission trees for an SMB product, extra preference panes nobody opens, and "completeness" features added so a competitor checklist looks full also land here. Skip them. An Indifferent win is a roadmap you did not build.

Conjointly reports a 4K HD video item at Attractive 37% and Indifferent 28%, with 2 of 20 features landing Indifferent. When those two bars are that close, print both. The mode alone is a coin flip.

Reverse and Questionable

Mandatory onboarding for power users, over-aggressive push, a Clippy-style assistant: presence hurts, absence helps. That is Reverse.

If a majority comes back Reverse, swap the functional and dysfunctional wording and rescore. You asked the pair backwards, or you shipped the opposite of the need.

Questionable is Like+Like or Dislike+Dislike. The respondent contradicted themselves. That is almost always wording, bundling, or fatigue, not a mysterious customer.

SI Labs treats a Questionable rate above 10% as a rewrite trigger (poorly formulated questions, not confused customers). Drop Q during cleaning. Do not invent a sixth need type.

How to Run a Kano Survey

General sampling, bias, and questionnaire craft belong with your qualitative research practice. The Kano-specific move is the pair.

Functional and Dysfunctional Pairs

Ask two questions per feature, framed as feelings, not utility.

• Functional: "How would you feel if you had this feature?"
• Dysfunctional: "How would you feel if you did not have this feature?"

"Would you use this?" is a different study. Proof of the Pudding follows Matzler (1998): customers care which problem you solve, not how the internals work.

Keep one hierarchical level. Do not mix outcome questions and presence questions in the same instrument. Phrase benefits, not product names.

"Automatically improve how your photo looks" beats "MagicFix." GitLab's handbook bans sales words (easy-to-use, faster, more efficient) and internal lingo.

Write Feature / Behavior / Value in one paragraph. Describe features, not MVCs (GitLab's term for a 1-2 milestone slice). Only new features.

Walk the current experience first. GitLab explains gitlab-ci.yml jobs and stages before candidate CI features. One feature per Qualtrics block; randomize the order.

Dysfunctional is absence, not the opposite. Video export under 10 seconds is the functional claim. "Some videos take longer than 10 seconds" is the better dysfunctional pair.

"Longer than 10 seconds" as a new spec is a different feature. Pre-test with 3-5 real customers. Technical language is the first failure mode SI Labs names.

An optional third question (self-stated importance, 1-9) can sit after the pair. It is not a substitute for the pair.

Answer Wording

The five answers are two sets of opposites with Neutral in the middle. They are not a Likert intensity scale. Do not number them.

People misread "I expect it" as stronger than "I like it."

The 1993 CQM wording is still the taught default:

• I like it that way
• It must be that way
• I am neutral
• I can live with it that way
• I dislike it that way

Teams often shorten those to "I like it" / "I expect it" / "I can tolerate it." Keep the five categories. Do not mix wordings inside one study.

Proof of the Pudding prefers "I have no feelings about this" over "I don't care about this" for Neutral.

An optional sixth "Other" is a confidence check some teams add. A pile of Other answers is a wording problem, not a sixth need type.

GitLab's production wording swaps the ends to "I am delighted by it" and "I am frustrated by it." That is a real-team variant, not the taught default. Keep one wording for the whole study.

Steve Whitby sometimes calls a third importance question a Likert. Only importance is scaled. The five Kano answers are categories.

Feature Count and Sample Size

Fatigue is how you manufacture Questionable.

Teach Whitby's 8-10 as the sitting floor and SI Labs 15-25 as the study ceiling. Past that, you are manufacturing Questionable.

"The power of Kano is in specificity. Don't ask about five features and one question. … I had a group of responses come back where over 70 of the responses were in the questionable category. … I've found it's very difficult to test more than eight to ten in any given short amount of time."
Steve Whitby in "Using The Kano Model In The Real World" (Product Coffee, 30:11)

GitLab pairs 50-80 completed quantitative sets with 5-10 moderated sessions and/or 20-30 unmoderated think-alouds. SI Labs treats 30 per segment as the reliability floor. Three segments means 90 completed sets.

An academic demo in PMC 4769705 used n=50 and expected a 13% margin of error. Thirty is a floor, not a precision sample.

Segment. The same feature can code Attractive for early adopters and Must-be for late ones. Without segments, opposing groups cancel and a feature can look Indifferent in the aggregate.

Host the survey wherever your team already runs research. GitLab used Qualtrics. Dedicated runners (KanoSurveys, Kano+, Conjointly) exist if you want the 5x5 scored for you.

How to Interpret Results

The 25-Cell Evaluation Table

Rows are the functional answer. Columns are the dysfunctional answer. Letters: Q Questionable, A Attractive, O One-dimensional, R Reverse, I Indifferent, M/N Must-be (Natural).

The classic table below follows the grid Proof of the Pudding and SI Labs both trace to Kano et al. (1984), as written down in English in the CQM Journal.

Some vendor blogs swap Attractive and One-dimensional, or drop the "It should be that way" row. Do not copy those grids.

Pouliot (1993) also marks Expect+Expect and Tolerate+Tolerate as Questionable. Most practitioner tables still treat those two cells as Indifferent. Teach the classic table; mention Pouliot as a variant.

Majority, Ties, and Mixed Modes

• Classify each respondent with the table.
• Tally M, O, A, I, R, and Q per feature.
• The feature category is the mode.
• On a tie, leftmost wins: Must-be > Performance > Attractive > Indifferent.
• High Q means rewrite the questions (SI Labs: over 10%) or drop inattentive rows.
• If a majority is Reverse, swap the pair and rescore.
• Always show the tally, not just the winner. Mode hides disagreement.

A constructed 25-respondent demo lands Feature 1 as One-dimensional (10 of 25) and Feature 2 as Must-be / Natural (9 of 25). That is a teaching tally, not a product study.

The PMC 4769705 E-Ebola Awareness System table (n=50) is what a finished academic grid looks like. Requirement R5 tied One-dimensional 18 / Indifferent 18.

The paper still grades it One-dimensional, and the coefficients (SI .52, DI −.48) lean that way. Do not treat those percentages as UX product data.

Better and Worse Coefficients

When Attractive is 45% and One-dimensional is 40%, the mode is a coin flip. Use the Customer Satisfaction Coefficient from Berger 1993:

Better (CS+ / SI) = (A + O) / (A + O + M + I)
Worse  (CS− / DI) = −(O + M) / (A + O + M + I)

Better runs 0 to +1 (delight if you ship it). Worse runs −1 to 0 (pain if you omit it). R and Q stay out of the denominator.

Plot Better against the absolute value of Worse. High/high is Performance; high Better and low Worse is Attractive; low Better and high Worse is Must-be; low/low is Indifferent.

Continuous scoring (DuMouchel: Functional −2 to 4, Dysfunctional −2 to 4) exists if you need variance. Conjointly does not recommend it as the default: the cut-offs are not calibratable per study. Discrete plus Better/Worse is the practical pair.

Worked Example: Software Features, Not Cars

Search for a worked example and you get smartphone cameras and 100,000-mile warranties. Classify a product surface instead.

The labels below are a composite illustration drawn from published method write-ups (SigOS examples, Koji, Vibe question wording, Baymard Gmail notes). They are not a scored study.

Dark mode as Indifferent is the surprise you take into a stakeholder room. "Everyone asked for it" is not a category.

GitLab's internal CI study is the copyable software SOP.

When Delight Decays, and When Not to Use Kano

Attractive slides toward Performance, then Must-be. Kano described that slide in Life Cycle and Creation of Attractive Quality (2001), a QMOD conference paper. A Kano study is a photograph.

Jared Spool puts decay in one line: things that are delightful today will be basic expectations tomorrow.

Fluid multi-touch on the 2007 iPhone was a wow. It is now the floor. In-flight Wi-Fi followed the same path.

Re-run the survey. Do not tattoo last year's labels on the roadmap.

The rule of thumb, once you have current labels:

• Fix Must-be (defense).
• Buy as much Performance as you can afford (compete).
• Ship a few Attractive (offense, word of mouth).
• Skip Indifferent.
• Kill or invert Reverse.

Then stop. Kano does not contain effort.

"The issue with the Kano model is effort is missing in the equation. So you got 2 features and one of them is just a little more preferable in the Kano model? Does that mean you work on that one first? Even if it takes 4 times longer?"
u/MaartenRooseboom in r/ProductManagement (Sep 2020)

Steve Whitby treats Kano as a pointing and classification tool, not a perfect prioritizer. Classify, then run the usual scorer. airfocus said the same of RICE in August 2026: a neat score often masks uncertain guesses as scientific facts.

Enterprise PMs on Reddit keep Kano at the strategic layer, not the sprint board.

u/kiwialec used it in enterprise B2B for 9-18 month pillars: big problems, behaviors to change, value rather than a feature list (Apr 2021). The same writer later noted the ceiling: Kano measures perception. Twenty years ago it would have shown that most people did not care about reading email on phones.

Do not use Kano to:

• Pick this sprint's tickets.
• Score live production health (use CSAT, CES, and usability testing).
• Forecast latent future Must-bes.
• Replace strategy, feasibility, or effort math.
• Run on table-stakes auth that will collapse to Indifferent.

Jobs-to-be-done interviews remain the better tool when you need the progress a user is trying to make, not a feature's satisfaction type. See the JTBD framework when the question is "what job is this for," not "what kind of need is this feature."

Common Mistakes to Avoid

Teaching Three Levels as the Whole Method

ASQ, Six Sigma study guides, and many PM glossaries still say the model has three types of need. Those three are the positive curves. The survey also returns Indifferent, Reverse, and Questionable.

If you only teach must / performance / delight, you have no place to put "skip this" or "you asked it backwards."

Calling the Answers a Likert Scale

Numbering I-like-it through I-dislike-it invites people to treat "I expect it" as a stronger Like. It is a different category.

Keep the labels. Drop the numbers.

Bundling Five Features Into One Question

Whitby's 70% Questionable pile-up came from specificity failures and from stuffing 40 items into a day. One feature per question. Eight to ten per sitting.

Showing Only the Winning Category

Mode hides a 40/45 split. Print the tally. Run Better/Worse when the bars are close.

Conjointly keeps both percentages on the 4K video item for that reason.

Using Kano as a Sprint Oracle

Frameworks structure the argument. They do not decide. u/minhthanh3145 (Jan 2026) uses scores to surface disagreement: if everyone already agrees, the framework added nothing.

If leadership is going to override the list anyway, a filled 5x5 does not save the quarter.

Copying a Swapped Vendor Lookup Table

Like + Dislike is One-dimensional on the classic grid (you like having it and dislike missing it). Some vendor write-ups map that cell to Attractive. Print the table from CQM / Proof of the Pudding / SI Labs, or from this page.

GitLab CI: A Production SOP

GitLab's handbook is the rare public, copyable software SOP. Upstream Studios ran a study on 12 candidate CI features after describing the current gitlab-ci.yml experience.

Example item shape: a list of CI job snippets next to the online pipeline editor, so copying YAML takes fewer steps when someone creates a new pipeline. Images or GIFs allowed. No internal ticket names.

Classification does not explain why, or when to stop pouring into Performance. GitLab followed the quantitative pass with moderated and unmoderated sessions because the numbers will not tell you.

Priority inside GitLab's write-up follows Must-be, then Performance, then Attractive. It still needs an effort layer before anything hits a milestone.

The public page is the method, not a scored leaderboard of GitLab features.