Kundenfeedback landet jeden Tag im Support, während die Produktentwicklung nur begrenzten Platz auf der Roadmap hat. Dazwischen braucht es einen Schritt, der einzelne Wünsche in beschriebene Probleme verwandelt, ihre Wirkung bewertet und prüft, ob sie zu den Produktzielen passen. Ohne ihn bestimmt der lauteste Kunde die Reihenfolge der Arbeit oder das letzte Gespräch, an das sich jemand erinnert. Dieser Leitfaden behandelt genau diesen Schritt: die gemeinsame Sichtung vieler Wünsche statt der Bewertung eines einzelnen Tickets.
Wenn du noch klärst, ob eine bestimmte Nachricht eine Störung oder einen neuen Bedarf beschreibt, beginne mit dem Leitfaden Fehler oder Feature-Wunsch. Hier gehen wir davon aus, dass diese Einordnung schon vorliegt und sich Dutzende solcher Fälle angesammelt haben.
Nach Problem gruppieren, nicht nach vorgeschlagener Lösung
Kunden beschreiben meist die Lösung, die ihnen gerade einfällt: „Baut einen Excel-Export ein“, „wir brauchen ein druckbares PDF“, „verbindet das mit unserer Buchhaltungssoftware“. In einer fiktiven Stundenplan-App für Tanzschulen können diese drei Wünsche auf eine einzige Schwierigkeit zurückgehen: Die Schulleitung muss den Stundenplan an jemanden weitergeben, der die App nicht nutzt. Einzeln gezählt wirkt jeder Wunsch wie eine Nische. Zusammen gezählt zeigt sich ein klares Problem.
Notiere deshalb zuerst die Situation und das Ziel der Kunden und erst danach ihren Vorschlag. Die Frage „Was möchtest du mit dieser Datei machen?“ verrät oft mehr als der Name des Formats. Behalte den Vorschlag, denn er trifft manchmal genau ins Schwarze, aber behandle ihn nicht als fertige Spezifikation. Ein einheitliches Vokabular für Labels erleichtert das spätere Zählen; wie du es aufbaust, zeigt der Leitfaden zum Taggen von Gesprächen und Tickets.
Eine Gruppe muss nicht vom ersten Tag an perfekt sein. Einige breite Probleme mit kurzer Beschreibung sind nützlicher als hundert Labels mit je einem Wunsch. Kehrt dieselbe Schwierigkeit als Fehlermeldung statt als Feature-Wunsch zurück, lies über wiederkehrende Kundenanfragen, denn dort zählt die gemeinsame Ursache mehr als eine Entscheidung über die Produktentwicklung.
Die Gruppenkarte: fünf Felder für das Gespräch über Prioritäten
Jede Gruppe braucht eine kurze Beschreibung, die auch jemand versteht, der nie mit den Kunden gesprochen hat. Die folgende Karte ist ein Prozessvorschlag anhand eines fiktiven Beispiels, kein Ergebnis einer echten Einführung.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Feld | Was du festhältst | Fiktives Beispiel |
|---|---|---|
| Problem | Die Schwierigkeit der Kunden in den Worten des Teams | Der Stundenplan muss an Personen außerhalb der App gehen |
| Wer betroffen ist | Art der Kunden und Situation, in der es auftritt | Schulleitungen vor Semesterbeginn |
| Belege | Verknüpfte Gespräche und Tickets, Zitate, Beobachtungen | Wünsche nach Excel, PDF und Buchhaltungssoftware |
| Aktueller Workaround | Was Kunden heute tun und was es sie kostet | Stundenplan von Hand in eine Tabelle übertragen |
| Entscheidung | Ergebnis der Sichtung, Grund und nächster Prüftermin | Wird in der nächsten Sichtung bewertet |
Das Feld „Belege“ sollte auf konkrete Gespräche verweisen und nicht nur eine Zahl enthalten. Eine nackte Zahl zeigt nicht, ob zehn verschiedene Kunden gefragt haben oder ein Kunde zehnmal. Das Feld „Aktueller Workaround“ schützt vor Überbewertung: Kommen Kunden in zwei Minuten ans Ziel, kann das Problem echt, aber weniger dringend sein als eines, das ihre Arbeit blockiert.
Wirkung, Sicherheit und Passung zu den Produktzielen bewerten
Stelle beim Vergleich der Gruppen drei Fragen. Wie stark hindert das Problem Kunden daran, das Ergebnis zu erreichen, für das sie das Produkt nutzen? Wie sicher bist du, dass du das Problem und seine Verbreitung verstehst? Passt eine Lösung zu der Richtung, die das Team für den kommenden Zeitraum gewählt hat? Eine Gruppe mit großer Wirkung, aber schwacher Passung verschwindet nicht, sondern wartet mit dokumentiertem Grund.
Intercom beschreibt die RICE-Methode: Reichweite, Wirkung und Sicherheit der Einschätzung werden multipliziert und durch den Aufwand geteilt. Der Autor betont, dass der Wert keine starre Regel ist und es gute Gründe geben kann, mit einem niedriger bewerteten Projekt zu beginnen: Intercom: RICE.
Setze die Sicherheit niedriger an, wenn eine Gruppe nur auf Aussagen wie „Wir würden kaufen, wenn ihr das einbaut“ beruht. Das Verhalten der Kunden, etwa ein immer wiederholter manueller Workaround oder ein abgebrochener Ablauf, ist ein stärkeres Signal als eine Ankündigung. Die Größe eines Kunden oder ein nachdrücklicher Ton ist geschäftlicher Kontext, den du notieren kannst, der aber die Beschreibung des Problems nicht ersetzen sollte. Dieselbe Regel gilt für Website-Korrekturen: Wie du die Sicherheit nach Belegen aus Aufzeichnungen und Heatmaps bewertest, zeigt der Leitfaden zur ICE-Bewertung von UX-Verbesserungen.
Jakob Nielsen von der Nielsen Norman Group (2001) empfiehlt, zu beobachten, was Nutzer tun, weil ihre Aussagen, auch darüber, ob sie eine Funktion nutzen würden, das tatsächliche Verhalten schlecht vorhersagen. Der Artikel behandelt Usability-Forschung und liefert keine Methode für die Roadmap-Planung: NN/g: die erste Regel der Usability.
Regelmäßige Sichtung: die Reihenfolge der Schritte
Gruppen sollten nicht bei jeder neuen Nachricht neu bewertet werden. Lege einen festen Rhythmus fest, zum Beispiel einmal pro Planungszyklus, und bereite das Material vor dem Termin vor.
- Neue Wünsche zuordnen.Jemand aus dem Support ordnet neue Tickets bestehenden Gruppen zu oder legt eine neue Gruppe mit kurzer Problembeschreibung an.
- Karten ergänzen.Ergänze bei jeder Gruppe neue Belege und prüfe, ob der aktuelle Workaround noch genauso funktioniert.
- Gruppen vergleichen.Das Produktteam bewertet Wirkung, Sicherheit und Passung zu den Zielen und wählt einige Gruppen für die weitere Arbeit aus.
- Entscheidung und Grund festhalten.Jede besprochene Gruppe erhält ein Ergebnis: eingeplant, zu klären, zurückgestellt oder abgelehnt, jeweils mit einem Satz Begründung.
- Den Support informieren.Das Supportteam weiß, was es Kunden antwortet und wann die Gruppe wieder in die Sichtung kommt.
Eine Priorität auf der Roadmap ist etwas anderes als eine Priorität in der Supportwarteschlange. Ein Kunde braucht vielleicht schnell eine Antwort auf einen Wunsch, der erst Monate später oder nie in den Plan kommt. Die Reihenfolge der laufenden Kontakte behandelt der Leitfaden zu Prioritäten in der Ticketwarteschlange; hier bewertest du die Reihenfolge von Produktänderungen.
Was du Kunden sagst, bevor entschieden ist
Kunden sollten wissen, dass ihr Wunsch verstanden und festgehalten wurde, aber kein Versprechen hören, das niemand freigegeben hat. Der Satz „Ich gebe das weiter, das kommt bestimmt“ erzeugt eine Zusage ohne Verantwortlichen. Besser ist es, den Stand zu beschreiben und zu sagen, was Kunden heute schon tun können.
„Danke für deine Beschreibung. Ich verstehe, dass du den Stundenplan an deine Buchhaltung weitergeben möchtest, ohne ihn abzutippen. Wir haben diesen Bedarf zu ähnlichen Wünschen gelegt, die das Produktteam in seiner regelmäßigen Sichtung bespricht. Ob und wann es eine solche Lösung gibt, kann ich heute nicht zusagen. Bis dahin [beschreibe den Workaround, den du im Konto des Kunden geprüft hast]. Sobald eine Entscheidung gefallen ist, melde ich mich bei dir.“
Betrifft der Wunsch ein laufendes Kundenprojekt statt der Produktentwicklung, gilt ein anderer Ablauf. Dann zählen der vereinbarte Umfang und eine dokumentierte Entscheidung, wie im Leitfaden für den Fall beschrieben, dass ein Kunde den Projektumfang ändert. Melde dich nach der Sichtung bei den Kunden, die mit der Gruppe verknüpft sind, auch wenn die Antwort „nicht in diesem Zeitraum“ lautet. Vorlagen für die Antworten „wird nicht geändert“ und „noch nicht, wir melden uns zu einem festen Termin“ findest du im Leitfaden Feedback-Schleife mit Kunden schließen.
Entscheidungen mit Tags und der App Projekte in Meetlead nachvollziehbar halten
In Meetlead kannst du Gespräche mit Tags versehen und den Posteingang nach mehreren Tags gleichzeitig filtern, was das Sammeln von Belegen für eine Gruppe erleichtert. In der App Projekte verknüpfst du eine Aufgabe mit einem Ticket, einer Aufzeichnung und anderen Aufgaben, legst sie ins Backlog, ordnest sie einem Epic zu, setzt die Priorität und hältst Entscheidungen in Kommentaren fest. Ein Epic kann für eine Problemgruppe stehen.
Diese Verknüpfungen legt das Team von Hand an: Meetlead gruppiert Wünsche nicht automatisch, berechnet keinen Prioritätswert und veröffentlicht keine Roadmap für Kunden. Projekte setzt ein Konto, eine aktive App auf der Website und Zugang im Tarif voraus. Wenn du eine ausgewählte Gruppe in die Umsetzung gibst, folge dem Leitfaden von der Kundenanfrage zur Aufgabe, damit die Aufgabe ein Ergebnis, eine verantwortliche Person und ein Abschlusskriterium hat.
- Die Gruppe beschreibt ein Problem, nicht nur einen Funktionsnamen.
- Die Belege verweisen auf konkrete Gespräche oder Tickets.
- Der aktuelle Workaround und seine Kosten für Kunden sind notiert.
- Die Entscheidung aus der Sichtung hat einen Grund und einen neuen Prüftermin.
- Der Support weiß, was er Kunden aus dieser Gruppe antwortet.
Fragen zu Kundenwünschen und Produktplanung
Reicht die Zahl der Wünsche, um eine Funktion auf die Roadmap zu setzen? Nein. Die Zahl zeigt die Reichweite, sagt aber nichts über Wirkung, Sicherheit oder Passung zu deinen Zielen. Einige Wünsche von Kunden, deren Kernarbeit blockiert ist, können mehr wiegen als viele Wünsche nach einer kleinen Erleichterung. Halte die Zahl zusammen mit den Belegen und dem aktuellen Workaround fest.
Darf man Kunden mit „Nein“ antworten? Ja, sobald eine Entscheidung gefallen ist und du ihren Grund kennst. Erkläre kurz, worauf sich das Team im kommenden Zeitraum konzentriert, und nenne einen vorhandenen Workaround, falls es einen gibt. Ein ehrliches „jetzt nicht“ mit dem Termin der nächsten Sichtung ist besser als ein allgemeines „danke für den Vorschlag“, nach dem der Kunde einen Monat später wieder nachfragt.
