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