Product Roadmap erstellen: sechs Schritte aus Feedback
5 Min. Lesezeit
Eine Product Roadmap zu erstellen läuft auf Folgendes hinaus: Sammelt, worum Kundinnen schon gebeten haben, gruppiert es nach dem Problem hinter jeder Anfrage, ordnet die Gruppen nach einer Regel, die ihr erklären könnt, legt fest, wie sicher ihr euch bei jeder seid, und veröffentlicht das Ergebnis in einem Format, das zu den Leserinnen passt. Die Reihenfolge ist wichtig. Teams, die mit einem Layout anfangen und es mit Ideen füllen, bekommen ein Dokument, das fertig aussieht und keinerlei Belege trägt. Teams, die mit Anfragen anfangen, bekommen eine kürzere Roadmap mit einem Grund hinter jeder Zeile.
| Schritt | Was ihr tut | Was am Ende dasteht |
|---|---|---|
| 1. Sammeln | Anfragen, Support-Themen und Nutzungsdaten in eine Liste ziehen | Eine Rohliste mit Quelle in jeder Zeile |
| 2. Gruppieren | Duplikate zusammenführen, das Problem hinter jedem Cluster benennen | Zehn bis zwanzig Probleme mit Zahlen |
| 3. Ordnen | Eine Bewertungsregel anwenden und aufschreiben | Eine Reihenfolge, die ihr verteidigen könnt |
| 4. Festlegen | Jeden Punkt als zugesagt, Prognose oder Erkundung kennzeichnen | Ehrliche Gewissheit in jeder Zeile |
| 5. Format wählen | Ein Layout für die Leserin aussuchen | Eine Roadmap als Now/Next/Later, nach Themen oder als Timeline |
| 6. Prüfen | Ein Datum setzen, an dem jede Zeile wieder angesehen wird | Eine Roadmap, die aktuell bleibt |
Wo fängt man an, wenn man eine Product Roadmap erstellt?
Fangt mit den Belegen an, die ihr schon habt, nicht mit einer leeren Seite. Offene Feature Requests, Support-Gespräche mit derselben Beschwerde, Notizen aus Verkaufsgesprächen und Nutzungsdaten aus dem eigenen Produkt sind alle Input. Packt sie in eine Liste und schreibt auf, woher jeder Punkt kommt.
Anfragen kommen selten in brauchbarer Form an. “Slack-Integration hinzufügen” und “mein Team benachrichtigen, wenn sich eine Aufgabe ändert” können dasselbe Bedürfnis sein. Deshalb ist der nächste Schritt das Gruppieren, und deshalb lohnt sich ein Tracker, der Duplikate zusammenführt; doppelte Feature Requests erklärt, wie. Bedenkt außerdem, dass Support-Tickets und Feature Requests unterschiedliche Signale tragen und eine Roadmap, die nur auf einem davon beruht, in die falsche Richtung kippt.
Wie macht man aus Anfragen Punkte auf der Product Roadmap?
Gruppiert die Anfragen nach dem Problem, benennt jede Gruppe als Ergebnis und behaltet die Zahl. Eine Gruppe von vierzehn Anfragen, die alle beschreiben, dass ein Filter nach dem Neuladen verschwindet, wird ein Punkt: “Den zuletzt benutzten Filter behalten”. Die Zahl kommt in die Quellenspalte, damit jede Leserin der Roadmap sieht, wie viel Gewicht dahintersteht.
Schreibt das Ergebnis in den Worten der Kundin. “Persistenz gespeicherter Ansichten implementieren” sagt der Entwicklerin, was zu bauen ist, und der Kundin nichts. Die Formulierung als Ergebnis erzwingt auch eine nützliche Frage: Wenn ihr nicht sagen könnt, was sich für die Kundin ändert, habt ihr womöglich eine interne Aufgabe vor euch, die auf eine andere Liste gehört.
Wie entscheidet man, was zuerst kommt?
Wählt eine Bewertungsregel, schreibt sie auf und wendet sie auf jeden Punkt an. RICE, das Reichweite, Wirkung, Gewissheit und Aufwand bewertet, ist am verbreitetsten; Intercoms Beitrag zu RICE ist die ursprüngliche Quelle. Eine einfachere Regel tut es genauso, wenn ihr sie erklären könnt: Anzahl der Anfragen, gewichtet danach, ob die Anfragende ein aktives zahlendes Konto ist, geteilt durch den groben Aufwand.
Wichtig ist, dass die Regel feststeht, denn die erste Kundin, die fragt, warum ihre Anfrage nicht auf der Liste steht, will eine Antwort. Wo Regel und euer Urteil auseinandergehen, sagt das in der Zeile. Feature Requests priorisieren geht Bewertungsmethoden durch, die Frage der Umsatzgewichtung und was Upvotes aussagen und was nicht.
Wie sicher seid ihr bei jedem Punkt?
Kennzeichnet jeden Punkt mit seiner Gewissheit, bevor ihr irgendetwas veröffentlicht. Eine einfache Skala mit drei Werten genügt: Zugesagt heißt, das Team wäre überrascht, wenn es nicht im Zeitraum ausgeliefert würde. Prognose heißt, es ist der Plan, solange sich nichts ändert. Erkundung heißt, es gibt kein Versprechen.
Diese eine Spalte verhindert den größten Teil des Roadmap-Schadens. Ohne sie liest eine Kundin einen Erkundungs-Punkt als Zusage, der Vertrieb zitiert ihn, und ein Quartal später ist er eine Beschwerde. Marty Cagans Aufsatz über die Alternative zu Roadmaps macht das zugrunde liegende Argument: Eine Liste von Features mit Terminen ist eine Liste von Vermutungen, die als Pläne auftreten, und die Lösung ist, offen zu sagen, was man weiß.
Welches Format sollte die Roadmap haben?
Wählt das Layout zuletzt, nach Leserin. Kundinnen, die fragen, ob ihr sie gehört habt, brauchen eine kurze öffentliche Sicht. Die Geschäftsführung, die fragt, warum diese Arbeit, braucht Themen oder Ergebnisse. Ein Team, das monatlich die Richtung ändert, fährt gut mit Now, Next und Later ohne Termine. Product-Roadmap-Beispiele zeigt sechs Formate mit realistischen Punkten und woran jedes scheitert, und die Product-Roadmap-Vorlage liefert die Felder zum Kopieren, sobald ihr gewählt habt.
Die meisten Teams enden mit zwei Dokumenten: einer strategischen Roadmap für interne Leserinnen und einer reduzierten öffentlichen, die nur zeigt, worauf man euch festnageln darf. Wenn ihr eine veröffentlicht, beschreibt öffentliche Roadmap, wie man sie aus Labels an den Issues steuert, die ihr ohnehin verfolgt.
Wie bewahrt man die Roadmap vor dem Veralten?
Gebt jeder Zeile ein Prüfdatum und haltet die Roadmap dort, wo die Arbeit ohnehin stattfindet. Eine Roadmap, die von Hand in einem separaten Tool gepflegt wird, veraltet, weil niemandes tägliche Arbeit sie einschließt. Wenn jede Spalte einem Label am Issue entspricht, ändert sich die Roadmap, sobald sich das Label ändert.
Schließt den Kreis, wenn ein Punkt ausgeliefert ist. Die Leute, die danach gefragt haben, sollten davon hören, und der Changelog-Eintrag ist dafür der übliche Ort; der Customer-Feedback-Loop beschreibt den ganzen Weg. Entscheidet ihr, etwas nicht zu bauen, sagt auch das. Ein klares Nein hilft der Person, die gefragt hat, und Feature Requests ablehnen behandelt die Formulierung.
FAQ
Welche Schritte gehören dazu, eine Product Roadmap zu erstellen? Anfragen und Daten sammeln, nach dem Problem dahinter gruppieren, mit einer schriftlichen Regel ordnen, jeden Punkt mit eurer Gewissheit kennzeichnen, ein Format für die Leserin wählen und ein Prüfdatum setzen. Der Start bei den Belegen hält die Roadmap kurz und verteidigbar.
Worauf sollte eine Product Roadmap beruhen? Auf Kundenanfragen, Support-Themen, Nutzungsdaten und eurer Strategie, in der Reihenfolge, wie oft sie übersprungen werden. Eine Roadmap ohne Quelle hinter ihren Zeilen ist eine Wunschliste.
Wie weit sollte eine Product Roadmap reichen? Weit genug, um nützlich zu sein, und kurz genug, um glaubwürdig zu bleiben. Für viele kleine Teams heißt das: das laufende Quartal im Detail und das nächste oder die nächsten beiden als Themen. Alles dahinter gehört unter “Later” und bekommt keine Termine.
Wer sollte beim Erstellen einer Product Roadmap beteiligt sein? Die Product Ownerin entscheidet, die Entwicklung prüft Machbarkeit und Aufwand, und Support und Vertrieb liefern die Anfragen und Themen, die sie hören. Kundinnen sehen das Ergebnis in einer öffentlichen Version, bearbeiten sie aber nicht.
Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.