Product-Roadmap-Beispiele: sechs Formate und ihr Scheitern

Die Product-Roadmap-Beispiele, die sich zu kopieren lohnen, lassen sich in sechs Formate einteilen: Now/Next/Later, eine Quartals-Timeline, eine Themen-Roadmap, eine Ergebnis-Roadmap, eine öffentliche Roadmap und eine interne Release-Roadmap. Jedes beantwortet eine andere Frage für eine andere Leserin. Das richtige Beispiel ist also das, das zu den Menschen passt, die eure Roadmap lesen werden. Das Layout entscheidet ihr zuletzt.

Jedes Beispiel unten gehört zu einem erfundenen Produkt, einer kleinen Aufgaben-App für Teams, und jeder Punkt ist ausgedacht. Es geht um die Form: was in welchen Platz gehört, wie ein echter Eintrag aussieht und woran das Format nach einem Quartal zerbricht.

Was sind gute Beispiele für eine Product Roadmap?

Ein gutes Roadmap-Beispiel ist kurz, nennt eine Leserin und macht eine Art von Versprechen. Wählt das Format nach dem Versprechen, das ihr zu halten bereit seid: eine Richtung, ein Datum, ein Themenfeld, ein Ergebnis, eine öffentliche Zusage oder ein Auslieferungsplan.

Wie sieht jedes Product-Roadmap-Beispiel aus?

Jedes Format unten wird mit realistischen Einträgen gezeigt, danach folgt, für wen es passt, wann es trägt und woran es meist scheitert.

Now/Next/Later

NOW (wird diesen Monat gebaut)
  Saved views on the inbox
  CSV export that works for large accounts
NEXT (entschieden, Reihenfolge offen)
  SSO for the Team plan
  Slack notifications
LATER (eine Richtung, keine Zusage)
  Mobile app
  Audit log

Dieses Format passt zu einer Firma, die keine Termine versprechen will, was auf viele junge Teams zutrifft. Es trägt, weil die drei Spalten beschreiben, wie sicher ihr seid: “Now” läuft, “Next” ist entschieden, “Later” ist eine Hoffnung. Es scheitert, wenn “Later” zum Parkplatz für jede Idee wird, die niemand ablehnen möchte, und wenn “Next” unbemerkt eine Reihenfolge und ein Datum bekommt, ohne dass jemand es Timeline nennt.

Timeline oder Quartals-Roadmap

Q4 2026
  Okt   Saved views on the inbox
  Nov   SSO beta with five design partners
  Dez   SSO general availability
Q1 2027
  Jan   Slack notifications
  Mär   Audit log (export only)

Dieses Format passt zu Vertrieb, Support und Finanzen, die um etwas herum planen müssen. Es funktioniert, wenn Termine echte Zwänge sind, etwa ein Vertrag, eine Konferenz oder eine Compliance-Frist. Es scheitert, wenn Termine Schätzungen sind, denn ein Monat auf einer Roadmap wird binnen Wochen zum Versprechen in einem Vertriebs-Deck. Wer dieses Format nutzt, kennzeichnet jedes Quartal als zugesagt oder als Prognose und macht das zweite Quartal sichtbar unverbindlicher als das erste.

Themenbasierte Roadmap

THEMA: Erste Woche mit dem Produkt
  Import from CSV and Trello
  Starter templates
THEMA: Bereit für größere Teams
  SSO
  Audit log
  Role permissions
THEMA: Weniger manuelle Schritte
  Slack notifications
  Recurring tasks

Dieses Format passt zu Führungs-Updates und neuen Kolleginnen, weil es erklärt, warum die Arbeit existiert, bevor es die Arbeit auflistet. Es trägt, wenn jedes Thema auf einen Grund verweist, der Kundinnen interessiert. Es scheitert, wenn die Themen so weit sind (“Wachstum”, “Qualität”), dass jeder Punkt unter jedes passt. Dann erklärt die Gruppierung nichts mehr.

Ergebnisbasierte Roadmap

ZIEL: Mehr neue Teams schließen das Setup ab
  Kennzahl: Setup in 7 Tagen fertig, 40 % auf 55 %
  Wetten: import from CSV, starter templates
ZIEL: Weniger Support-Tickets zu Exporten
  Kennzahl: Export-Tickets pro Woche, 30 auf 10
  Wetten: large-account export fix, export status page

Die Zahlen sind beispielhaft, und das Layout ist der Punkt: ein Ziel, eine Kennzahl mit Start- und Zielwert und die Wetten, die ihr eingeht. Es passt zu Produkt- und Entwicklungsteams, denen man die Wahl der Lösung zutraut. Es funktioniert, wenn es die Kennzahl gibt und jemand sie verantwortet. Es scheitert, wenn das Ziel nicht messbar ist oder wenn die “Wetten” dieselbe Feature-Liste wie vorher sind, nur mit einem aufgesetzten Ergebnissatz.

Öffentliche Roadmap für Kundinnen

PLANNED
  Saved views on the inbox
BUILDING
  Slack notifications
SHIPPED
  CSV export for large accounts

Das ist das kleinste Format, und es macht das stärkste Versprechen. Es passt zu Kundinnen, die wissen wollen, ob ihre Anfrage gehört wurde. Es trägt mit sehr wenigen Punkten, ohne Termine und mit Titeln in den Worten der Kundin. Es scheitert als Backlog-Halde: Jedes “Vielleicht”, das ihr aufführt, ist ein Versprechen, nach dem später jemand fragt. Wie ihr eine aus eurem Issue-Tracker betreibt, steht in Öffentliche Roadmap in drei Spalten, deshalb wiederholen wir es hier nicht.

Interne Release-Roadmap

Dieses Format passt zu Entwicklung, QA und Support, die wissen müssen, was gemeinsam ausgeliefert wird und was was blockiert. Es funktioniert, wenn es auf die Woche genau ist und jede Zeile eine Verantwortliche hat. Es scheitert, wenn jemand es für Strategie hält: Ein Auslieferungsplan sagt, was wann das Haus verlässt, und nichts darüber, ob diese Releases die richtigen Wetten waren.

Welches Roadmap-Format solltet ihr wählen?

Wählt zuerst nach der Leserin, dann danach, wie viel Sicherheit ihr tatsächlich habt. Könnt ihr nicht benennen, wer die Roadmap liest und welche Entscheidung sie ihr erleichtert, rettet sie keines der Beispiele oben.

• Kundinnen, die fragen: “Habt ihr mich gehört?” Nehmt das öffentliche Format und bleibt bei wenigen Punkten.
• Vertrieb und Support, die fragen: “Kann ich der Kundin ein Datum nennen?” Nehmt die Quartals-Timeline, mit klar getrennt zugesagt und prognostiziert.
• Führung, die fragt: “Warum diese Arbeit?” Nehmt Themen, oder Ergebnisse, wenn ihr die Daten habt.
• Ein Team, das monatlich die Richtung ändert. Nehmt Now/Next/Later und widersteht dem Datieren.
• Entwicklerinnen, die fragen: “Was kommt wann raus?” Nehmt die Release-Roadmap und haltet sie von der strategischen getrennt.

Die meisten Teams enden bei zwei Roadmaps: einer strategischen in einer der ersten vier Formen und darunter einem Release-Plan. Eine öffentliche Roadmap ist dann eine gefilterte Sicht auf die strategische und zeigt nur, worauf ihr euch festnageln lasst.

Wie schreibt man eine Product Roadmap?

Schreibt eine Roadmap, indem ihr die Leserin benennt, das Format wählt, das zu ihrer Frage passt, nur Punkte auflistet, die ihr in einer Besprechung verteidigen würdet, und jedem Punkt Status und Verantwortliche gebt. Legt dann fest, wie oft sie überprüft wird, bevor ihr sie veröffentlicht.

1. Nennt die Leserin und die Entscheidung. “Der Support entscheidet, was er Kundinnen zu SSO sagt” ist ein Grund. “Alle sollen die Roadmap sehen” gibt euch nichts, wofür ihr gestalten könnt.
2. Beginnt mit dem, was ihr schon wisst. Offene Anfragen, nach einer erklärbaren Regel priorisiert, sind besseres Rohmaterial als ein Brainstorming.
3. Schreibt jeden Punkt als Kundenergebnis. “Einen oft genutzten Filter behalten” liest sich besser als “Persistenz für gespeicherte Ansichten implementieren” und sagt der Kundin, ob es ihr Problem ist.
4. Legt fest, was die Roadmap nicht enthält. Termine, Schätzungen und ein Ideen-Backlog sind die drei üblichen Ausschlüsse.
5. Setzt einen Review-Termin. Eine Roadmap ohne geplanten Review hat eine ungeplante Beerdigung.

Wie hält man eine Product Roadmap aktuell?

Haltet eine Roadmap aktuell, indem ihr Punkte verschiebt, wenn sich die Arbeit bewegt, und zwar an dem Ort, an dem die Arbeit verfolgt wird, und indem ihr festhaltet, was passiert ist, wenn ein Punkt ausgeliefert oder verworfen wird. Eine Roadmap, die jemand von Hand in einem separaten Tool pflegt, veraltet, weil sie niemandes tägliche Aufgabe ist.

Die günstigste Quelle der Wahrheit ist der Issue-Tracker. Entspricht jede Roadmap-Spalte einem Label am Issue, ändert sich die Roadmap, wenn sich das Label ändert, und nichts wird neu getippt. Die Variante von Changeloop nutzt die Labels roadmap:planned, roadmap:building und roadmap:shipped, und trägt ein Issue zwei davon, gewinnt das am weitesten fortgeschrittene. Die Karte nach “Ausgeliefert” zu verschieben ist trotzdem eine eigene Label-Änderung, also macht sie zum Teil des Reviews, in dem ihr den Changelog-Eintrag freigebt.

Dieser Eintrag ist die andere Hälfte. Wird ein Punkt ausgeliefert, sagt der Changelog in den Worten der Kundin, was sich geändert hat, und wer ihn angefragt hat, kann benachrichtigt werden. Diesen Loop zu schließen ist der Sinn des Customer-Feedback-Loops, und die Roadmap ist der Abschnitt dieses Loops, den die Kundin sieht, bevor etwas ausgeliefert wird. Verwerft ihr einen Punkt, sagt es; ein öffentliches “Nein” schließt auch diese Anfrage, und Feature Requests ablehnen zeigt, wie man es formuliert. Teams, die sehen wollen, wie fertige Einträge klingen, stöbern in den Changelog-Beispielen.

FAQ

Was ist das einfachste Product-Roadmap-Format? Now/Next/Later. Es hat drei Spalten, braucht keine Termine und gruppiert Punkte nach Gewissheit. Für ein kleines Team, das oft die Richtung ändert, ist es außerdem das Format, bei dem man sich am schwersten blamiert.

Wie viele Punkte sollte eine Product Roadmap haben? Weniger, als ihr denkt. Unter zehn über alle Spalten genügen für eine öffentliche Roadmap, und eine interne strategische braucht selten mehr als ein Dutzend. Darüber ist es ein Backlog mit schönerer Überschrift.

Sollte eine Product Roadmap Termine enthalten? Nur wenn die Termine echte Zwänge sind, und dann nur fürs nächste Quartal. Danach nehmt Spalten oder Themen. Ein Datum auf einer Roadmap wird in einem Vertriebsgespräch zur Zusage, ob ihr es wolltet oder nicht.

Was ist der Unterschied zwischen einer Product Roadmap und einem Release-Plan? Eine Roadmap sagt, was ihr bauen wollt und warum. Ein Release-Plan sagt, welcher Build an welchem Datum ausgeliefert wird und wer ihn verantwortet. Die Roadmap ändert sich, wenn sich eure Strategie ändert, der Release-Plan, wenn sich die Arbeit ändert.

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-Beispiele