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:

User need	Better fit
Rank a whole backlog by reach, impact, confidence, and effort	prioritization
Synthesize open-ended interviews, observations, or diary notes	user-research or research-synthesis
Choose market category, alternatives, and differentiated value	positioning
Compare actions by probability-weighted value	expected-value
Design a broad process-improvement sequence	methodology
Decide non-negotiable legal, safety, accessibility, or reliability requirements	the relevant compliance, safety, or quality gate

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.

Input	Good form	Bad form
Segment	"Security admins at 200+ employee companies"	"users"
Feature	"SAML SSO for account login"	"enterprise readiness"
Outcome	"Search results return in under 500 ms"	"better search"
Time context	"2026 B2B SaaS buying expectation"	no market timestamp
Evidence	paired Kano survey, support data, interviews, sales-loss notes	founder intuition alone

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.

Category	Presence	Absence	Product implication
Must-be / basic	Expected, little extra satisfaction	Strong dissatisfaction	Meet the threshold first; missing basics can veto the product
Performance / one-dimensional	More is better	Less is worse	Invest by value, cost, and competitive importance
Attractive / delighter	Creates satisfaction or surprise	Little or no dissatisfaction	Differentiates after basics are covered; validate segment fit
Indifferent	Little effect	Little effect	Deprioritize unless it supports another requirement
Reverse	Creates dissatisfaction for some users	Preferred absent	Avoid, make optional, or segment carefully
Questionable	Contradictory or confused response	Contradictory or confused response	Fix wording, split the feature, or collect better evidence

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.

Category	Default next move	Check before committing
Must-be gap	Fix or provide a credible alternative before delighters	Is it truly expected by the target segment? Is there a compliance or safety floor?
Performance	Size the investment curve	What level is good enough? What is the marginal satisfaction per unit cost?
Attractive	Treat as differentiation option	Are basics already met? Is the delighter hard to copy? Does it fit positioning?
Indifferent	Cut or defer	Does it support internal efficiency, compliance, or another visible feature?
Reverse	Avoid default exposure	Can it be optional, segmented, or hidden behind progressive disclosure?
Questionable	Re-research	Was the feature too vague, bundled, or leading?

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

Instead of this skill	Use	Why
Generic backlog scoring	prioritization	Kano classifies satisfaction response shape; prioritization ranks work across reach, impact, effort, confidence, and constraints
Open-ended customer evidence synthesis	user-research or research-synthesis	Kano needs candidate features and paired responses; it does not discover all themes by itself
Market category and differentiated value	positioning	Kano can inform perceived value, but positioning owns competitive context and buyer framing
Probability-weighted economic choice	expected-value	Kano categories are not payoffs or probabilities
Broad quality-improvement process design	methodology	Kano is one customer-needs classification method, not a full process system