Distinguish what prevents dissatisfaction, what improves satisfaction proportionally and what may create delight—without treating every requested feature as equally valuable.
In one minute
The Kano Model treats satisfaction as more than a single linear scale. For each clearly defined attribute, respondents answer two related questions:
- how they feel if the attribute is present or performs well;
- how they feel if the attribute is absent or performs poorly.
The paired response is classified through an evaluation table. Common categories are:
- Must-be: absence causes dissatisfaction; strong delivery may only bring the offer to an expected minimum;
- One-dimensional: better performance tends to increase satisfaction and worse performance tends to reduce it;
- Attractive: presence may create satisfaction while absence is tolerated because the attribute was not expected;
- Indifferent: presence or absence has little reported effect;
- Reverse: some respondents prefer the attribute to be absent;
- Questionable: the response pair is contradictory or the question may be misunderstood.
The categories describe responses in a defined sample, context and time. They do not automatically set a roadmap. Importance, reach, strategy, cost, risk, accessibility and evidence still matter.
Best for: a manageable set of product or service attributes that respondents can experience or imagine consistently.
Avoid when: the problem, user segment or attribute wording is still vague, or a survey would substitute for discovery.
The problem it addresses
Feature lists often combine basic expectations, competitive performance, optional delights and internal preferences. A simple importance rating can make nearly everything appear important and may miss asymmetry: fixing a missing basic requirement can prevent dissatisfaction without generating praise, while an attractive feature may delight only one segment.
Kano analysis adds a structured view of this asymmetry. It is particularly useful after customer needs have been translated into specific attributes but before investment decisions are final.
When to use it
Use the Kano Model when:
- a team has a defined user segment and a candidate attribute set;
- roadmap discussion treats all requests as equivalent;
- minimum expectations and differentiators are unclear;
- a service redesign needs evidence about presence and absence;
- different segments may classify the same attribute differently;
- an existing “delighter” may have become a normal expectation;
- customer evidence must inform—but not mechanically decide—priorities.
When not to use it
Do not use it:
- before defining the customer and decision context;
- with compound attributes containing several ideas;
- to ask respondents about implementation technologies they cannot evaluate;
- as a substitute for behavioural research or usability testing;
- with a convenience sample presented as the whole market;
- as a permanent label for an attribute;
- as an automatic cost–benefit or strategic priority score.
Use Jobs to Be Done to understand the progress people seek. Use Customer Journey Mapping to locate evidence-backed experience problems before defining attributes.
Inputs required
Prepare:
- a decision and defined product or service context;
- explicit user segments and sampling plan;
- a short list of single, understandable attributes;
- neutral functional and dysfunctional question pairs;
- the response scale and published evaluation rule;
- a pilot for comprehension and translation;
- importance, open-text rationale and relevant respondent context;
- a plan to combine classification with effort, risk and strategy.
Step-by-step process
1. Define the decision and segment
State which roadmap, service standard or experiment the results will inform. Define respondents by behaviour or context rather than one broad label such as “all customers.”
2. Translate needs into attributes
Write attributes as customer-observable outcomes. “Single sign-on is available for the organisation” is clearer than “modern identity architecture.” Keep one idea per item.
3. Write the functional question
Ask how the respondent would feel if the attribute were present or performed at the stated level. Avoid praise, technical jargon and assumptions about benefit.
4. Write the dysfunctional question
Ask how the respondent would feel if the same attribute were absent or performed below that level. The wording must describe the opposite state, not a different feature.
5. Pilot the survey
Use cognitive interviews or observation to find ambiguity, compound attributes and inconsistent interpretation. Translate conceptually and test the translation rather than relying on literal wording.
6. Collect with context
Record segment, experience, use frequency or relevant constraints. Randomise item order where appropriate and protect respondents from fatigue.
7. Classify response pairs
Apply the chosen evaluation table consistently. Keep questionable and missing responses visible. Report counts and distributions, not only the winning category.
8. Examine strength and disagreement
Compare categories by segment and time. Satisfaction and dissatisfaction coefficients can summarise direction, but do not erase sample size or mixed responses.
9. Combine with other decision evidence
Review importance, reach, cost, technical risk, legal duty, accessibility and strategic fit. A must-be requirement may be mandatory even when few respondents mention it; an attractive attribute may be expensive or narrow.
10. Decide the next test and review
Record what will be built, improved, tested, deferred or removed and why. Set a review trigger because attractive attributes can become expected and segment composition can change.
AI automation lens
AI can help cluster open-ended needs into candidate attributes, detect compound wording, translate a pilot and calculate classifications under a declared evaluation table. It can compare segment distributions and flag questionable response patterns.
AI must not:
- fabricate respondents or fill missing answers;
- turn vague text clusters directly into survey-ready attributes;
- infer protected or sensitive segmentation without authority;
- hide disagreement behind one predicted category;
- set the roadmap from the Kano label alone.
Every AI-assisted attribute needs human wording review, and every classification must be reproducible from retained response pairs.
Visual model
Text alternative: the model distinguishes attributes whose absence creates disproportionate dissatisfaction, whose performance changes satisfaction more linearly, and whose presence may delight without equivalent dissatisfaction when absent.
Interactive example
Scenario
A B2B invoicing portal team is comparing five attributes for small exporters: correct tax fields, downloadable audit history, automatic translation of invoice descriptions, proactive anomaly alerts and an animated dashboard. Interviews show that customers describe compliance as “obvious,” but roadmap votes favour visible dashboard features.
Your move
Define the respondent segment, write one question pair and explain how the classification should affect—but not determine—the roadmap.
Worked answer
The first segment is finance administrators who issue cross-border invoices at least weekly. For audit history, the functional question is: “How would you feel if every invoice change could be downloaded with actor and timestamp?” The dysfunctional form is: “How would you feel if invoice changes could not be downloaded with actor and timestamp?”
If the attribute is predominantly must-be, the team treats adequate audit history as a release condition, not a marketing differentiator. Translation or anomaly alerts may be attractive for particular segments and deserve bounded prototypes. The animated dashboard may be indifferent. Legal requirements, implementation risk and actual task evidence remain separate gates.
Facilitation notes
- Limit each item to one observable attribute.
- Keep the functional and dysfunctional states symmetrical.
- Pilot every language and segment.
- Display the full distribution and number of responses.
- Investigate questionable and reverse classifications rather than deleting them automatically.
- Separate classification from roadmap authority.
Expected output
- a decision and segment definition;
- a validated attribute list;
- functional/dysfunctional question pairs;
- a sampling and pilot record;
- response-pair data and declared evaluation table;
- category distributions and disagreement by segment;
- importance, effort, risk and strategy overlays;
- a decision, experiment and review trigger.
Common mistakes
- Feature voting renamed Kano. Only one importance question is asked.
- Compound attributes. One response classifies several ideas at once.
- Leading opposites. Functional and dysfunctional questions describe different conditions.
- Category as universal truth. Segment, sample and time are removed.
- Delighter obsession. Basics, accessibility or legal duties are neglected.
- Automatic roadmap. Classification replaces ownership and trade-off decisions.
Quality checklist
- The decision and respondent segment are explicit.
- Attributes are singular and customer-observable.
- Functional and dysfunctional questions are neutral and symmetric.
- The survey was piloted in every used language.
- Classification uses a declared reproducible table.
- Distributions, sample size and questionable responses remain visible.
- Results are segmented where evidence supports it.
- Roadmap choices also consider importance, obligation, effort, risk and strategy.
Template
| Field | Prompt |
|---|---|
| Decision | Which roadmap or service decision will this inform? |
| Segment | Who answers, in which use context and with what experience? |
| Attribute | One observable capability or service condition |
| Functional question | How do you feel when it is present / strong? |
| Dysfunctional question | How do you feel when it is absent / weak? |
| Pilot evidence | What wording or translation changed after testing? |
| Classification | Counts and shares for M, O, A, I, R and Q |
| Disagreement | Which segments or respondents differ? |
| Other evidence | Importance, behaviour, duty, effort, risk and strategy |
| Decision | Build, improve, test, defer or remove; owner and review trigger |
Use the structured Kano workspace template to preserve question pairs, response distributions and decision overlays.
Knowledge check
Question: Customers classify data export as must-be and an animated dashboard as attractive. What follows automatically?
A. Build the dashboard first.
B. Nothing follows automatically; preserve minimum obligations and combine classifications with importance, evidence, effort, risk and strategy.
C. Remove data export because it will not create delight.
D. Treat both labels as permanent.
Answer: B. Kano categories inform a decision; they do not replace release obligations or accountable prioritisation.
Related tools
- Jobs to Be Done identifies customer progress and circumstances.
- Customer Journey Mapping locates experience evidence and unmet needs.
- SCAMPER generates alternative ways to deliver an attribute.
- Decision Matrix combines several explicit decision criteria.
- Benchmarking compares performance or mechanisms with contextual controls.
References
- Kano, N., Seraku, N., Takahashi, F., and Tsuji, S. “Attractive Quality and Must-Be Quality.” Journal of the Japanese Society for Quality Control, 14(2), 1984. https://doi.org/10.20684/quality.14.2_147 (opens in a new tab)
- American Society for Quality. “What is the Kano Model?” https://asq.org/quality-resources/kano-model (opens in a new tab)
- Berger, C. et al. “Kano’s Methods for Understanding Customer-Defined Quality.” Center for Quality Management Journal, 2(4), 1993.
Method profile
- Primary job: classify asymmetric satisfaction responses to defined attributes.
- Core artifact: paired-question evidence with category distributions by segment.
- Decision boundary: the model informs prioritisation; it does not own roadmap, compliance or investment decisions.
- Evidence standard: piloted wording, retained response pairs, reproducible classification and visible sample limitations.
- Review trigger: changed segment, market expectation, product maturity, regulation or attribute definition.