Skip to content

Commit 00f7f85

Browse files
raifdmuellerraifdmueller
authored
Merge pull request #23 from raifdmueller/feat/anchor-kano-model
feat: add Kano Model anchor (#459)
2 parents 99dcbe9 + 432b5c6 commit 00f7f85

4 files changed

Lines changed: 125 additions & 0 deletions

File tree

‎docs/anchors/kano-model.adoc‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
= Kano Model
2+
:categories: strategic-planning, requirements-engineering
3+
:roles: product-owner, business-analyst, ux-designer, team-lead
4+
:related: moscow, jobs-to-be-done, ears-requirements
5+
:proponents: Noriaki Kano
6+
:tags: customer-satisfaction, feature-prioritization, product-management, requirements
7+
:tier: 3
8+
9+
[%collapsible]
10+
====
11+
Also known as:: Kano Analysis, Kano-Modell, Customer Satisfaction Model
12+
13+
[discrete]
14+
== *Core Concepts*:
15+
16+
Two-dimensional Quality:: Customer satisfaction is not the simple inverse of dissatisfaction — they are two separate axes (presence/absence of a feature × resulting satisfaction)
17+
18+
Five Feature Categories:: Every feature falls into one of five classes that map differently onto the satisfaction curve
19+
20+
Must-be (Basic, Threshold):: Expected baseline — absence causes strong dissatisfaction, presence is taken for granted and earns no credit (e.g., car has wheels, app does not lose data)
21+
22+
One-dimensional (Performance, Linear):: Satisfaction grows roughly linearly with how well the feature is delivered (e.g., fuel efficiency, response time, battery life)
23+
24+
Attractive (Excitement, Delighter):: Unexpected — absence causes no dissatisfaction, presence delights and differentiates (e.g., a thoughtful onboarding gesture, a surprising shortcut)
25+
26+
Indifferent:: Customer does not care either way — flag for cost reduction
27+
28+
Reverse:: Presence actually causes dissatisfaction for the target segment — flag for removal or segmentation
29+
30+
Functional / Dysfunctional Questionnaire:: For each candidate feature, ask the user two paired questions: "How would you feel if this feature were present?" and "How would you feel if it were absent?". The cross-tab of answers maps the feature to one of the five categories
31+
32+
Time Decay:: Categories migrate over time. Today's *Delighter* becomes tomorrow's *Performer* and eventually a *Must-be* as the market matures (mobile camera, HTTPS, dark mode)
33+
34+
35+
Key Proponent:: Noriaki Kano (Tokyo University of Science), originally published in 1984 in the Japanese journal *Hinshitsu* ("Quality")
36+
37+
Historical Context:: Developed in the context of Japanese quality management, alongside Total Quality Management and the Kaizen movement; widely adopted in product management, UX research, and requirements engineering since the late 1990s.
38+
39+
[discrete]
40+
== *When to Use*:
41+
42+
* Prioritising features in a product backlog beyond raw business value
43+
* Distinguishing the "non-negotiables" (Must-be) from the "wow features" (Delighter) before estimation
44+
* User research where you need to understand *why* a feature affects satisfaction, not just whether users like it
45+
* MVP scoping: ensure all *Must-be* features are covered before investing in *Delighters*
46+
* Product strategy reviews: spot *Delighters* that have decayed into *Performers* or *Must-be* and update positioning
47+
* Combining with *MoSCoW Method* — Must-be → Must, Performance → Should, Delighter → Could
48+
49+
[discrete]
50+
== *Related Anchors*:
51+
52+
* <<moscow,MoSCoW Method>> — complementary prioritisation lens (organisation-driven), often combined with Kano (customer-driven)
53+
* <<jobs-to-be-done,Jobs To Be Done>> — discovery side: what job is the customer hiring the feature for, before classifying its impact
54+
* <<ears-requirements,EARS Requirements>> — once a feature is classified as Must-be, EARS gives it the unambiguous wording
55+
56+
Counter-example:: Pure ROI-based ranking — useful but blind to the asymmetry between dissatisfaction (Must-be) and delight (Attractive). Kano corrects that.
57+
====

‎docs/anchors/kano-model.de.adoc‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
= Kano-Modell
2+
:categories: strategic-planning, requirements-engineering
3+
:roles: product-owner, business-analyst, ux-designer, team-lead
4+
:related: moscow, jobs-to-be-done, ears-requirements
5+
:proponents: Noriaki Kano
6+
:tags: customer-satisfaction, feature-prioritization, product-management, requirements
7+
:tier: 3
8+
9+
[%collapsible]
10+
====
11+
Auch bekannt als:: Kano-Analyse, Kano Model, Kundenzufriedenheitsmodell
12+
13+
[discrete]
14+
== *Kernkonzepte*:
15+
16+
Zweidimensionale Qualität:: Zufriedenheit ist nicht die einfache Umkehr von Unzufriedenheit — sie sind zwei eigene Achsen (Vorhandensein/Abwesenheit eines Features × resultierende Zufriedenheit)
17+
18+
Fünf Feature-Kategorien:: Jedes Feature fällt in eine von fünf Klassen, die jeweils anders auf die Zufriedenheitskurve wirken
19+
20+
Basisfaktoren (Must-be):: Erwartete Selbstverständlichkeit — Fehlen führt zu starker Unzufriedenheit, Vorhandensein wird vorausgesetzt und schafft keinen Mehrwert (z. B. Auto hat Räder, App verliert keine Daten)
21+
22+
Leistungsfaktoren (One-dimensional, Linear):: Zufriedenheit wächst etwa linear mit der Qualität der Umsetzung (z. B. Verbrauch, Antwortzeit, Akkulaufzeit)
23+
24+
Begeisterungsfaktoren (Attractive, Delighter):: Unerwartet — Fehlen verursacht keine Unzufriedenheit, Vorhandensein begeistert und differenziert (z. B. eine durchdachte Onboarding-Geste, eine überraschende Abkürzung)
25+
26+
Unerhebliche Faktoren (Indifferent):: Den Kunden ist es egal — Kandidat für Kostensenkung
27+
28+
Rückweisende Faktoren (Reverse):: Das Vorhandensein verursacht in der Zielgruppe Unzufriedenheit — Kandidat zum Entfernen oder zur Segmentierung
29+
30+
Funktional/Dysfunktional-Fragebogen:: Pro Kandidaten-Feature zwei gepaarte Fragen stellen: "Wie würden Sie sich fühlen, wenn das Feature vorhanden wäre?" und "Wie würden Sie sich fühlen, wenn es fehlte?". Die Kreuztabelle der Antworten ordnet das Feature einer der fünf Kategorien zu
31+
32+
Zeitverfall:: Kategorien wandern über die Zeit. Der heutige *Delighter* wird morgen zum *Performer* und schließlich zum *Must-be*, wenn der Markt reift (Smartphone-Kamera, HTTPS, Dark Mode)
33+
34+
35+
Schlüsselvertreter:: Noriaki Kano (Tokyo University of Science), Originalveröffentlichung 1984 im japanischen Journal *Hinshitsu* ("Qualität")
36+
37+
Historischer Kontext:: Entstanden im Kontext des japanischen Qualitätsmanagements, neben Total Quality Management und der Kaizen-Bewegung; seit Ende der 1990er weit verbreitet in Produktmanagement, UX-Forschung und Requirements Engineering.
38+
39+
[discrete]
40+
== *Wann zu verwenden*:
41+
42+
* Features im Produkt-Backlog jenseits des reinen Business-Werts priorisieren
43+
* Die "Nicht-Verhandelbaren" (Must-be) von den "Wow-Features" (Delighter) trennen, bevor geschätzt wird
44+
* Nutzerforschung, in der das *Warum* hinter der Zufriedenheit interessiert, nicht nur das Ob
45+
* MVP-Scoping: sicherstellen, dass alle *Basisfaktoren* abgedeckt sind, bevor in *Begeisterungsfaktoren* investiert wird
46+
* Produkt-Strategie-Reviews: *Delighter*, die zu *Performern* oder *Must-be* verfallen sind, erkennen und das Positioning anpassen
47+
* In Kombination mit der *MoSCoW-Methode* — Must-be → Must, Performance → Should, Delighter → Could
48+
49+
[discrete]
50+
== *Verwandte Anker*:
51+
52+
* <<moscow,MoSCoW Method>> — komplementäre Priorisierung (organisationsgetrieben), häufig mit Kano (kundengetrieben) kombiniert
53+
* <<jobs-to-be-done,Jobs To Be Done>> — Entdeckungsseite: für welchen Job heuert der Kunde das Feature an, bevor seine Wirkung klassifiziert wird
54+
* <<ears-requirements,EARS Requirements>> — sobald ein Feature als Must-be klassifiziert ist, gibt EARS ihm die unmissverständliche Formulierung
55+
56+
Gegenbeispiel:: Reine ROI-Priorisierung — nützlich, aber blind für die Asymmetrie zwischen Unzufriedenheit (Must-be) und Begeisterung (Attractive). Kano korrigiert das.
57+
====

‎docs/changelog.adoc‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,12 @@
22

33
A chronological record of all semantic anchors added to the catalog. Community contributors are credited with thanks.
44

5+
== 2026-05-08
6+
7+
*New anchors:*
8+
9+
* *Kano Model* — Noriaki Kano's two-dimensional quality model classifying features as Must-be, Performance, Attractive, Indifferent or Reverse, surveyed via paired functional/dysfunctional questions; pairs naturally with MoSCoW for backlog prioritisation (proposed in https://github.com/LLM-Coding/Semantic-Anchors/issues/459[#459])
10+
511
== 2026-05-07
612

713
*New anchors:*

‎skill/semantic-anchor-translator/references/catalog.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -570,6 +570,11 @@ Source: https://github.com/LLM-Coding/Semantic-Anchors
570570
- **Proponents:** Albert Humphrey
571571
- **Core:** Strengths, Weaknesses, Opportunities, Threats — internal vs. external strategic analysis
572572

573+
### Kano Model
574+
- **Also known as:** Kano Analysis, Kano-Modell, Customer Satisfaction Model
575+
- **Proponents:** Noriaki Kano (1984, *Hinshitsu* journal)
576+
- **Core:** Two-dimensional quality model — features classified as Must-be (basic, absence dissatisfies), Performance (linear), Attractive (delighter, exceeds expectation), Indifferent or Reverse; surveyed via paired functional/dysfunctional questions ("How would you feel if X were present? / absent?"); categories decay over time (Delighter → Performer → Must-be); complements MoSCoW for backlog prioritisation
577+
573578
### PERT (Program Evaluation and Review Technique)
574579
- **Also known as:** Three-Point Estimation, PERT Network Analysis
575580
- **Proponents:** D.G. Malcolm, J.H. Roseboom, C.E. Clark, W. Fazar

0 commit comments

Comments
 (0)