Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Wenn man beginnt, Kundenfeedback in einem Tool wie Productboard, Harvestr, Dovetail oder einem eigenen System zu zentralisieren, taucht schnell eine Frage auf: Wie klassifiziert man sauber ein Feedback, das nicht immer über dasselbe spricht?
Manche Verbatims sind sehr konkret:
- ein Störfaktor auf einem Bildschirm;
- eine Anfrage zu einer Feature;
- ein als schlecht empfundenes Produktverhalten.
Andere sind viel breiter gefasst:
- ein übergreifender Bedarf;
- ein Job to be done;
- eine geschäftliche Einschränkung;
- ein Business-Ziel.
Genau hier beginnen oft die Schwierigkeiten. Das Problem ist nicht nur, Feedback „besser zu sortieren". Das Problem ist, dass ein einziges Klassifikationsmodell nicht ausreicht.
Die Falle der Einachsen-Klassifikation
Viele Teams klassifizieren ihr Feedback nach einer einzigen Logik:
- nach Feature;
- nach Problem;
- nach Thema;
- nach Ziel;
- nach Kundentyp.
Das Problem: Diese Logik funktioniert gut für einen Teil des Feedbacks, wird aber für alles andere wackelig.
Ein Ansatz, der sich ausschließlich auf Features konzentriert, ist praktisch für lokale Reibungspunkte, reduziert Feedback aber zu schnell auf Produktteile. Dabei geht die Geschäftslogik, der übergreifende Bedarf oder das zugrunde liegende Business-Ziel verloren.
Umgekehrt behält ein Ansatz, der sich ausschließlich auf Ziele konzentriert, den Überblick, wird aber unscharf, sobald ein konkretes Problem auf einem Pfad, einem Bildschirm oder einer Interaktion behandelt werden muss.
Mit anderen Worten:
- ein zu lokales Modell fehlt die Perspektive;
- ein zu globales Modell fehlt die Präzision.
Der eigentliche Bedarf: den gesamten Umfang abdecken ohne unnötige Komplexität
Die Herausforderung besteht nicht darin, immer mehr Kategorien hinzuzufügen.
Es gilt, einen Rahmen zu finden, der:
- einfach zu verstehen ist;
- schnell anzuwenden ist;
- hinreichend robust ist;
- Feedback vom sehr Strategischen bis zum sehr Taktischen abdecken kann.
Darin liegt die eigentliche Schwierigkeit.
Mit zu wenigen Klassifikationen vermischt man Dinge, die nicht auf derselben Ebene liegen. Mit zu vielen Klassifikationen wird das System mühsam zu benutzen und damit schlecht angenommen.
Das gute Modell ist nicht das theoretisch „eleganteste". Es ist das Modell, das ein Team dauerhaft wirklich einsetzen kann.
Der Rahmen, den ich verwende: 4 Klassifikationen
Das Modell, das ich verwende, stützt sich auf 4 Klassifikationen:
- Geschäftsziel
- Anwendungsfall / JTBD
- Produktfähigkeit
- Lokaler Reibungspunkt
Die Idee ist einfach: Feedback nach der Ebene klassifizieren, auf der es sich ausdrückt.
1. Geschäftsziel
Man spricht von einem Geschäftsziel, wenn der Kunde ausdrückt:
- ein Business-Ziel;
- eine organisatorische Einschränkung;
- eine operative Priorität;
- ein Risiko;
- eine Transformationsambition.
Beispiele:
- Praktiken zwischen mehreren Teams harmonisieren;
- ein Compliance-Risiko reduzieren;
- die Steuerung verbessern;
- Wachstum absorbieren ohne mehr einzustellen.
Auf dieser Ebene spricht der Kunde noch nicht von einer Feature oder einem konkreten Anwendungsfall. Er spricht davon, was für seine Aktivität zählt.
2. Anwendungsfall / JTBD
Man spricht von einem Anwendungsfall / JTBD, wenn der Kunde beschreibt, was er in seiner Arbeit erreichen möchte.
Wir befinden uns hier auf der Ebene der geschäftlichen Handlung:
- einen Vorfall qualifizieren;
- eine Behandlung verfolgen;
- mehrere Einheiten vergleichen;
- Kontext wiederfinden, bevor man handelt;
- mehrere Personen koordinieren.
Diese Ebene ist besonders nützlich, weil sie hilft, die tatsächliche Arbeit zu verstehen, ohne die Analyse zu früh in eine Lösung einzuengen.
3. Produktfähigkeit
Man spricht von einer Produktfähigkeit, wenn der Kunde ausdrückt, was das Produkt ermöglichen soll.
Zum Beispiel:
- Alarme konfigurieren;
- Zugriffsrechte verwalten;
- eine Historie konsolidieren;
- eine Zuweisung automatisieren;
- mehrere Objekte oder Ereignisse miteinander verknüpfen.
Man befindet sich nicht mehr auf der Ebene des Geschäftsziels, aber noch nicht auf der Ebene einer lokalen Reibung. Man befindet sich auf der Ebene der erwarteten Produktfähigkeit.
4. Lokaler Reibungspunkt
Man spricht von einem lokalen Reibungspunkt, wenn das Feedback etwas Konkretes im Produkt betrifft:
- einen Bildschirm;
- eine Feature;
- einen Filter;
- einen Button;
- ein Formular;
- ein unerwartetes Verhalten.
Beispiele:
- der Filter setzt sich zurück;
- der Export-Button ist schwer zu finden;
- ein Feld muss erneut eingegeben werden;
- ein Formular ist zu lang.
Das ist die taktischste Ebene, bleibt aber unverzichtbar. Ein gutes Insight-System darf diese Granularität nicht verlieren.
Die einfache Regel zur korrekten Klassifikation von Feedback
Um Unklarheiten zu vermeiden, halte ich mich an eine sehr einfache Sortierregel.
Spricht der Kunde von einem Business-Ziel oder einer organisatorischen Einschränkung? → Geschäftsziel
Spricht er davon, was er in seiner Arbeit erreichen möchte? → Anwendungsfall / JTBD
Spricht er davon, was das Produkt ermöglichen soll? → Produktfähigkeit
Spricht er von einem Bildschirm, einer Feature, einem Verhalten oder einer konkreten Reibung? → Lokaler Reibungspunkt
Diese Regel hat einen wesentlichen Vorzug: Sie verhindert, nach dem scheinbaren Thema zu klassifizieren, und zwingt dazu, nach dem tatsächlichen Niveau des Signals zu klassifizieren.
Warum dieser Rahmen mir als der richtige Kompromiss erscheint
Dieses Modell mit 4 Klassifikationen erscheint mir solider als ein Ansatz, der sich ausschließlich auf Features konzentriert.
Warum? Weil Kundenfeedback nicht immer von einer Feature spricht. Es kann auch sprechen von:
- einem übergreifenden Bedarf;
- einem Workflow-Problem;
- einer organisatorischen Einschränkung;
- einem Steuerungsziel;
- einer strategischeren Erwartung.
Umgekehrt erscheint mir dieser Rahmen auch nützlicher als ein Ansatz, der sich ausschließlich auf Ziele konzentriert.
Warum? Weil ein gutes Insight-Management-System auch ermöglichen muss, das Konkrete wiederzufinden:
- was im Produkt blockiert;
- was fehlt;
- was eine lokale Verbesserung verdient;
- was direkt Discovery, Design oder Backlog speisen kann.
Dieser Rahmen hält also besser die Balance zwischen Weitblick und operativer Verwertbarkeit.
Fazit
Alles Kundenfeedback auf einer einzigen Achse zu klassifizieren reicht nicht aus. Das funktioniert, solange das Feedback homogen ist. Aber sobald man gleichzeitig Business-Ziele, Anwendungsfälle, erwartete Fähigkeiten und sehr lokale Reibungen abdecken möchte, wird das Modell zu schwach.
Der Rahmen mit 4 Klassifikationen, den ich verwende, bietet einen besseren Kompromiss:
- Geschäftsziel
- Anwendungsfall / JTBD
- Produktfähigkeit
- Lokaler Reibungspunkt
Er bleibt einfach, deckt den gesamten nützlichen Umfang ab, und kann in einem echten Tool eingesetzt werden, ohne ein überkomplexes System zu werden.
Das ist das Modell, das ich in meinem eigenen Insight-Manager-Projekt einsetzen werde. Das Ziel ist nicht nur, Verbatims besser zu sortieren. Das Ziel ist, die Kundenstimme besser mit Produktentscheidungen zu verbinden — mit einem System, das schlank genug ist, um genutzt zu werden, und strukturiert genug, um langfristig nützlich zu bleiben.
Weiterführendes
Der PM als Kontext-Architekt Das zweite Gehirn ist eine Sackgasse für das Product Management