Kano-Modell: Feature-Requests nach Kundengefühl sortieren

Das Kano-Modell sortiert Features danach, wie Kundinnen und Kunden reagieren, wenn es sie gibt und wenn sie fehlen, statt danach, wie viele Leute danach gefragt haben. Noriaki Kano schlug es 1984 vor, und es ordnet jedes Feature einer von fünf Gruppen zu: Basismerkmal, Leistungsmerkmal, Begeisterungsmerkmal (Delighter), indifferent und umgekehrt. Für ein Team mit einem Stapel Feature-Requests ist daran vor allem nützlich, dass es erklärt, warum ein Request mit Dutzenden Stimmen nichts zur Zufriedenheit beitragen kann, während ein Request, für den niemand gestimmt hat, verändern kann, wie Menschen über das Produkt reden.

Was sind die Kategorien des Kano-Modells?

Basismerkmale sind die Dinge, von denen Kunden annehmen, dass es sie gibt. Niemand lobt sie, und jeder merkt es, wenn sie kaputtgehen. Bei Leistungsmerkmalen ist mehr geradlinig besser, etwa schnellere Berichte oder höhere Limits. Begeisterungsmerkmale sind unerwartet, deshalb kostet ihr Fehlen nichts und ihr Vorhandensein erzeugt echte Begeisterung. Indifferente Merkmale bewegen in keine Richtung etwas, und bei umgekehrten Merkmalen sind manche Kunden glücklicher, wenn sie entfernt werden.

Die Kategorie ist eine Eigenschaft eines Features für eine Gruppe von Kunden zu einem bestimmten Zeitpunkt. Deshalb kann dasselbe Feature für verschiedene Segmente in verschiedenen Gruppen landen.

Wie führt man eine Kano-Umfrage durch?

Zu jedem Feature werden zwei Fragen gestellt. Die funktionale Frage lautet, wie sich die Kundin fühlen würde, wenn das Produkt das Feature hätte. Die dysfunktionale Frage lautet, wie sie sich fühlen würde, wenn es das Feature nicht hätte. Beide haben dieselben fünf Antworten: Das gefällt mir, Das setze ich voraus, Das ist mir egal, Das nehme ich in Kauf, Das gefällt mir nicht.

Die beiden Antworten werden mit dem Standard-Auswertungsraster kombiniert, um die Sicht jeder befragten Person auf jedes Feature einzuordnen:

M steht für Basismerkmal (must-be), O für Leistungsmerkmal (eindimensional), A für Begeisterungsmerkmal (attractive), I für indifferent, R für umgekehrt (reverse) und Q für eine fragwürdige Antwort, die sich selbst widerspricht. Für jedes Feature werden die Buchstaben über alle Befragten gezählt, und der häufigste gibt die Kategorie vor. Liegen zwei Kategorien dicht beieinander, werden beide berichtet, denn eine Aufteilung von 40 zu 38 sagt, dass das Segment gespalten ist, und nicht, dass eine Antwort gewonnen hat.

Welche Feature-Requests gehören in eine Kano-Umfrage?

Nur die, die ihr ernsthaft bauen würdet und nicht nach Bauchgefühl einordnen könnt. Fünf bis fünfzehn Features sind eine brauchbare Länge, und jedes braucht eine Ein-Satz-Beschreibung, die sich eine Kundin ohne Mockup vorstellen kann. Die Kandidaten kommen aus dem erfassten Backlog, nachdem Duplikate gruppiert wurden, denn zehn Requests für dieselbe Sache sollen als ein Feature in der Umfrage ankommen. Der Gruppierungsschritt ist in Feature-Request-Tracking beschrieben.

Bugfixes und alles, was vertraglich schon zugesagt ist, bleiben draußen. Eine Umfrage kann nicht sagen, ob ein Absturz behoben werden sollte.

Wen sollte man befragen?

Menschen, die das Produkt bereits nutzen, aufgeteilt nach den Segmenten, die für euch zählen. Eine Umfrage an die gesamte Liste liefert tendenziell den Durchschnitt mehrerer verschiedener Gruppen, und ein Durchschnitt verdeckt das Ergebnis. Kostenlose und zahlende Nutzer, neue und langjährige Konten, kleine und große Teams ordnen dasselbe Feature oft in unterschiedliche Kategorien ein. Die Ergebnisse jedes Segments bleiben getrennt, und ihr entscheidet, für welches Segment das nächste Release gedacht ist.

Die Leute, die die Requests geschrieben haben, sind ein guter Startpunkt für die Zielgruppe. Dazu kommt eine Zufallsstichprobe aktiver Nutzer, damit die Umfrage nicht nur die laute Minderheit abbildet. Wie man die Anfrage formuliert und verschickt, steht in Kundenfeedback einholen.

Wie wird aus Kano-Ergebnissen eine Prioritätenliste?

Gebaut wird in dieser Reihenfolge: zuerst Lücken bei Basismerkmalen, dann Leistungsmerkmale, bei denen ihr hinter den Alternativen zurückliegt, mit denen eure Kunden euch vergleichen, dann ein oder zwei Begeisterungsmerkmale pro Release, und indifferente und umgekehrte Merkmale zuletzt oder nie. Die Reihenfolge ergibt sich daraus, was jede Kategorie mit der Zufriedenheit macht. Eine Lücke bei einem Basismerkmal zu schließen nimmt einen Grund zum Wechseln weg, Arbeit an Leistungsmerkmalen hebt die Zufriedenheit stetig, und ein Begeisterungsmerkmal ist die Quelle von Differenzierung.

Kano sagt, welche Art von Wert ein Feature hat, und nicht, was es kostet. Die Kategorie wird mit einer Aufwandsschätzung gepaart, bevor sie in einen Plan kommt. Ein Scoring-Verfahren wie RICE-Scoring übernimmt die Kostenseite, und beide ergänzen sich gut: Kano wählt die Shortlist aus, RICE bringt sie in Reihenfolge. Die breitere Entscheidung steht in Feature-Requests priorisieren.

Wandern Features mit der Zeit zwischen den Kategorien?

Ja, und das ist das Nützlichste, was man über das Modell im Kopf behalten sollte. Begeisterungsmerkmale rutschen in Richtung Leistungsmerkmal und dann in Richtung Basismerkmal, wenn Wettbewerber sie kopieren und Kunden sich daran gewöhnen. Zwei-Faktor-Authentifizierung war einmal eine angenehme Überraschung und ist heute bei Business-Software eine Erwartung. Ein Umfrageergebnis ist eine Momentaufnahme. Für jede Kategorie, auf die ihr setzt, wird sie nach einem Jahr wiederholt, oder sobald ein Wettbewerber etwas Ähnliches ausliefert.

Kunden sollten erfahren, wenn ein Delighter erscheint. Ein Feature aus der Kategorie Begeisterung begeistert nur Menschen, die davon erfahren, weshalb die Ankündigung Teil des Features ist. Diesen Kreis zu schließen ist das Thema von Neues Feature ankündigen.

Was sind die Grenzen des Kano-Modells?

Es misst geäußerte Gefühle, nicht Verhalten, und kann deshalb überbewerten, was Leute angeblich wollen. Es braucht genug Befragte pro Segment, um ein Muster zu erkennen, und ein paar Dutzend sind praktisch oft die Untergrenze. Außerdem bewertet es Features einzeln und sagt nichts darüber, wie sie zusammenwirken. Das Ergebnis ist ein starkes Indiz für ein Roadmap-Gespräch und gehört neben Nutzungsdaten und Umsatz. Wie die sortierte Liste zu einem Plan wird, steht in Product Roadmap erstellen.

FAQ

Was ist das Kano-Modell einfach erklärt? Es ist eine Methode, die Features in Gruppen sortiert, je nachdem, wie Kunden sich fühlen, wenn das Feature da ist und wenn es fehlt. Die Gruppen sind Basis-, Leistungs-, Begeisterungsmerkmal, indifferent und umgekehrt, und jede weist auf eine andere Bau-Priorität hin.

Wie viele Personen braucht man für eine Kano-Umfrage? Eine feste Zahl gibt es nicht, aber jedes Segment, das ihr getrennt auswerten wollt, braucht genug Antworten, damit eine klare Mehrheitskategorie sichtbar wird. Ein paar Dutzend pro Segment sind ein verbreitetes praktisches Minimum, und ein geteiltes Ergebnis mit weniger Antworten gilt als offen.

Ist das Kano-Modell besser als RICE? Die beiden beantworten verschiedene Fragen. Kano klassifiziert, welche Art von Wert ein Feature den Kunden bringt, und RICE ordnet Arbeit nach Reichweite, Wirkung, Vertrauen und Aufwand. Viele Teams nutzen Kano für die Shortlist und ein Scoring-Verfahren für die Reihenfolge.

Wie oft sollte man eine Kano-Analyse wiederholen? Bei stabilen Produkten jährlich, früher, wenn ein Wettbewerber ein ähnliches Feature ausliefert. Delighter werden mit der Zeit zu Erwartungen, deshalb kann ein altes Ergebnis auf ein Feature zeigen, das sich nicht mehr abhebt.

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.

Mehr bei changeloop: Entwicklerdokumentation, Changelog-Tools im Vergleich