Kano Model

Concept of the skill

What it is: The Kano model is Noriaki Kano's quality and customer-satisfaction framework for classifying features by how customers react when the feature is present and when it is absent.

Mental model: A feature does not have one universal priority score. For a specific customer segment, its presence and absence create a response pattern: must-be basics prevent dissatisfaction, performance attributes move satisfaction proportionally, attractive features delight when present, indifferent features do little, reverse features hurt, and questionable responses need cleanup.

Why it exists: Agents often treat every requested feature as a backlog item with a score. Kano reasoning asks what kind of satisfaction mechanism the feature has before ranking it.

What it is NOT: It is not RICE, ICE, MoSCoW, expected value, open-ended research synthesis, product positioning, or a substitute for non-negotiable safety, accessibility, reliability, or legal requirements.

Adjacent concepts: customer needs, voice of customer, quality function deployment, feature prioritization, delighters, hygiene factors, product research, segmentation, roadmap planning, satisfaction coefficients.

One-line analogy: Kano analysis is a control panel where different levers stop alarms, steadily raise satisfaction, create surprise delight, do nothing, or make the wrong users unhappy.

Common misconception: Delighters are not automatically the top priority. Basics that are missing can dominate satisfaction, and a delighter can become expected over time.

Kano Model

Domain Context

Use this skill when the user has candidate product features, service attributes, customer needs, or roadmap ideas and needs to understand how each one affects customer satisfaction. The method is useful for product management, service design, quality planning, roadmap trade-offs, and customer-needs research.

Keep examples synthetic, public, or aggregate. Do not include personal data, customer identifiers, payment data, private support tickets, confidential roadmap details, or raw interview transcripts unless the user has already supplied them for the task and they are safe to process.

The output of this skill is a Kano analysis brief: customer segment, feature list, evidence quality, category classification, category-specific roadmap implication, and follow-up research or prioritization step.

Coverage

This skill teaches agents to:

1. Decide whether Kano analysis fits the request.
2. Define the customer segment and decision context before classifying features.
3. Phrase each candidate as a user-visible feature, capability, or service attribute.
4. Design paired functional and dysfunctional questions.
5. Classify responses as must-be, performance, attractive, indifferent, reverse, or questionable.
6. Interpret category implications without over-ranking delighters.
7. Handle segment splits, weak evidence, and category migration over time.
8. Feed Kano results into prioritization, positioning, research, or expected-value work without replacing those methods.
9. Detect bad Kano work: classification from feature names alone, yes/no preference questions, averaged-away reverse quality, and stale delighter labels.

Philosophy of the skill

The Kano model matters because customer satisfaction is asymmetric. The absence of one feature can make a product unacceptable, while the presence of another feature creates little extra satisfaction because users already assume it will be there. A third feature may create delight precisely because users did not expect it. Treating all three as ordinary backlog items hides the real product risk.

The method is not "ask customers what they want and build the highest-scoring request." It is a disciplined way to reveal the shape of customer response. The best Kano answer protects basics, invests deliberately in performance attributes, treats delighters as segment-specific bets, and avoids building indifferent or reverse features just because they sound clever.

1. Decide Whether Kano Fits

Use Kano analysis when the request asks how feature presence or absence affects satisfaction for a defined customer segment.

Do not use Kano as the primary method when the user needs:

If the request lacks the minimum inputs, ask for or infer them and label inference clearly.

Customer segment:
Decision horizon:
Candidate features or attributes:
Current product baseline:
Evidence available:
Constraints or non-negotiables:
What decision the classification must inform:

2. Define the Segment and Feature Unit

Kano categories are not universal. Classify each feature for a segment, use case, and point in time.

If different segments disagree, keep separate classifications. A feature can be attractive for power users and reverse for novices.

3. Ask Paired Questions

A Kano survey asks two questions for each feature: one where the feature is present and one where it is absent. The category comes from the response pair, not from a simple "do you want this?" answer.

Functional question:
If [feature] is available, how do you feel?

Dysfunctional question:
If [feature] is not available, how do you feel?

Common response options:
- I like it that way.
- I expect it that way.
- I am neutral.
- I can live with it that way.
- I dislike it that way.

Keep wording concrete and neutral. Do not bundle multiple features into one question. Do not ask leading questions such as "How excited would you be if we added this amazing feature?"

4. Classify the Response Pattern

Use the category definitions before making roadmap recommendations.

Do not classify from the feature name alone. "Dark mode" can be attractive, indifferent, must-be, or reverse depending on user segment, accessibility needs, context, and market expectations.

5. Translate Category to Roadmap Logic

Kano categories guide priority, but they are not the whole priority decision.

For a final roadmap, combine Kano output with prioritization, expected-value, constraints, strategy, technical feasibility, and evidence confidence.

6. Handle Category Migration

Kano categories drift. A feature that delighted early adopters can become a performance expectation and eventually a must-be basic. Re-check categories when:

• competitors normalize the feature,
• buyers start assuming it during sales or onboarding,
• support complaints appear only when the feature is missing,
• a platform or regulation changes expectations,
• a new segment becomes the priority.

Do not cite old delight as current evidence. State the date, segment, and market context behind the classification.

7. Output Format

When applying the skill, use this compact structure.

KANO ANALYSIS

Segment:
Decision:
Evidence quality:

| Feature | Likely category | Evidence | Roadmap implication | Follow-up |
| --- | --- | --- | --- | --- |

Must-be gaps:
Performance investments:
Attractive bets:
Indifferent/reverse candidates:
Questions to validate:
Boundary handoff:

Boundary handoff names which method should take the result further: prioritization for scoring, user-research for evidence collection, positioning for differentiation, or expected-value for quantified payoff.

Verification

Before finalizing a Kano analysis, check:

• Customer segment and decision horizon are explicit.
• Each feature is a single user-visible capability or attribute.
• Functional and dysfunctional questions are paired and neutral.
• Categories are based on response patterns or clearly labeled as hypotheses.
• Must-be gaps are not outranked by speculative delighters without a stated reason.
• Performance attributes include a "how much is enough?" question.
• Reverse-quality signals are preserved, not averaged away.
• Indifferent features have a separate reason if still recommended.
• Category migration over time is considered.
• Kano output is handed to the right next method when cost, strategy, or scoring is needed.

Do NOT Use When

Skill Graph context

Classification

• Subject: reasoning-strategy
• Public: true
• Domain: foundations/product-strategy
• Scope: Kano model feature and customer-need classification for product, service, and quality decisions: classify candidate features by satisfaction response to presence and absence, design paired functional/dysfunctional questions, handle segment differences, translate must-be/performance/attractive/indifferent/reverse categories into roadmap implications, and avoid over-ranking delighters before basics. Excludes generic backlog scoring without customer-response evidence, broad qualitative research synthesis, product-market positioning, and financial expected-value comparison.

When to use

• Use the Kano model to classify these feature requests into must-be, performance, delighter, indifferent, and reverse categories.
• Design a Kano survey for these roadmap candidates.
• Use the Kano model to classify faster search as performance quality and SSO as must-be quality.
• Which of these features are delighters versus basics for this customer segment?
• Explain Kano category drift when an old delighter becomes a must-have expectation.
• Triggers: kano-model, kano-analysis, kano-survey

Not for

• Rank this backlog by reach, impact, confidence, and effort.
• Synthesize these interview transcripts into research themes.
• Design a generic quality-improvement process with DMAIC or PDCA.

Related skills

• Verify with: epistemic-grounding, prioritization, user-research
• Related: prioritization, user-research, research-synthesis, positioning, expected-value, methodology

Concept

• Mental model: Kano analysis maps how a defined customer segment reacts when a feature is present versus absent. The primitives are segment, candidate feature, functional question, dysfunctional question, response pair, quality category, satisfaction effect, dissatisfaction effect, evidence confidence, and time. Must-be features prevent dissatisfaction, performance features move satisfaction roughly with execution quality, attractive features create upside when present without penalty when absent, indifferent features do not matter much, reverse features hurt some users, and questionable responses signal confusion or bad survey design.
• Purpose: This skill prevents agents from treating all feature requests as the same kind of demand. It forces the answer to distinguish basics customers punish you for missing, performance attributes customers reward proportionally, delighters that can differentiate only after basics are covered, indifferent ideas that should not consume roadmap capacity, and reverse features that help one segment while hurting another.
• Boundary: The Kano model is for classifying customer satisfaction response patterns to candidate features or service attributes. It is not a complete prioritization score, open-ended user-research synthesis, positioning strategy, expected-value calculation, accessibility or safety gate, or proof that a feature is worth building. Kano categories can feed those decisions, but they do not replace cost, feasibility, strategy, risk, or evidence-quality checks.
• Analogy: Kano analysis is like a control panel with different levers: some only stop alarms, some raise the gauge steadily, some create a burst of delight, and some should not be pulled for the wrong audience.
• Common misconception: The common mistake is thinking delighters are always the highest priority. In Kano reasoning, missing basics can destroy satisfaction, performance attributes may deserve steady investment, and delighters only matter when they fit the segment and do not mask must-be gaps.

Grounding

• Mode: universal
• Truth sources: https://www.jstage.jst.go.jp/article/quality/14/2/14_KJ00002952366/_article, https://asq.org/quality-resources/kano-model, https://cir.nii.ac.jp/crid/1571980075723369472, https://www.walden-family.com/public/cqm-journal/2-4-Whole-Issue.pdf, skills/reasoning-strategy/kano-model/references/kano-model-sources.md, skills/reasoning-strategy/kano-model/references/upstream-displacement-2026-06-01.md

Keywords

• Kano model, customer satisfaction, must-be quality, performance needs, delighters, attractive quality, feature prioritization, Kano survey, reverse quality, indifferent quality