Product-Roadmap-Vorlage: Felder zum Kopieren und Ausfüllen

Eine Product-Roadmap-Vorlage ist eine kurze Tabelle, in der jede Zeile ein Punkt ist und jede Spalte ein Feld, das ihr verbindlich gefüllt haltet. Die Version, die für die meisten kleinen Teams funktioniert, hat sechs Felder: das Ergebnis, wer danach gefragt hat, den Status, die Verantwortliche, die Gewissheit und das Prüfdatum. Alles andere, was in Vorlagen zum Download steckt, etwa Swimlanes, Story Points und Quartalsspalten, ist optional und meistens der Grund, warum die Roadmap irgendwann nicht mehr gepflegt wird.

Was gehört in eine Product-Roadmap-Vorlage?

Nehmt nur die Felder auf, mit denen eine Leserin eine Entscheidung trifft, und fügt ein Feld erst hinzu, wenn ihr sagen könnt, wer es liest. Das Ergebnis ist der Existenzgrund der Zeile. Die Quelle lässt eine Kundin ihre eigene Anfrage darin wiederfinden. Der Status zeigt, ob die Arbeit vorankommt. Die Verantwortliche ist die Person, die man fragt. Die Gewissheit verhindert, dass eine Prognose als Versprechen gelesen wird, und das Prüfdatum bewahrt die Zeile davor zu veralten.

Zwei Felder lohnen sich, wenn euer Team danach fragt. Eine “Machen wir nicht”-Liste neben der Tabelle hält fest, wogegen ihr euch entschieden habt und warum, und erspart euch dieselbe Debatte jedes Quartal. Eine Spalte “Zuletzt geändert” zeigt, wann die Zeile bearbeitet wurde, sodass man eine aktuelle Roadmap von einer aufgegebenen unterscheiden kann.

Für eine erste Version lasst ihr weg: Termine jenseits des Prüfdatums, Aufwandsschätzungen, Story Points und Umsatzprognosen. Die gehören in Planungsdokumente, wo sie sich ändern können, ohne dass jemand sie als Zusage liest.

Wie sieht eine ausgefüllte Product-Roadmap-Vorlage aus?

Hier ist die Tabelle mit einer erfundenen Aufgaben-App als Produkt. Alle Punkte sind ausgedacht, und die Statusspalte kennt nur drei Werte.

Zwei Zeilen tragen die Lehre. “Offline-Modus” hat keine Verantwortliche und geringe Gewissheit, und das ist eine ehrliche Art zu sagen: “Wir denken darüber nach.” “Fälligkeitsdaten gesammelt bearbeiten” ist abgeschlossen statt gelöscht, damit die Kundinnen, die danach gefragt haben, noch sehen, wo es geblieben ist.

Wenn ihr lieber Klartext habt, funktioniert dieselbe Tabelle als Markdown-Datei im Repository und liegt so versioniert neben der Arbeit:

| Outcome | Source | Status | Owner | Confidence |
|---|---|---|---|---|
| Keep the last filter | 14 requests | Building | Dana | Committed |
| Company SSO sign-in | 9 requests | Planned | Marcus | Forecast |

Welches Format sollte die Vorlage haben?

Nehmt eine Tabelle, wenn die Roadmap höchstens zehn Punkte hat und die Leserinnen Details wollen. Nehmt drei Spalten, Now, Next und Later, wenn ihr oft die Richtung wechselt und keine Termine verteidigen wollt. Das Now/Next/Later-Layout beschreibt der Atlassian-Leitfaden zu Product Roadmaps neben Timeline- und themenbasierten Layouts.

Die Tabelle oben und ein Board mit drei Spalten enthalten dieselben Daten. Die Tabelle ist besser für Leute, die in der Roadmap arbeiten, das Board für Leute, die nur kurz draufschauen. Product-Roadmap-Beispiele zeigt sechs Formate mit realistischen Punkten und erklärt, woran jedes scheitert, damit ihr das Layout wählen könnt, wenn die Felder feststehen.

Wie füllt man die Vorlage aus, ohne zu raten?

Beginnt mit den Anfragen, die ihr schon habt, und schreibt das Ergebnis zuletzt. Gruppiert offene Anfragen nach dem Problem, das sie beschreiben, zählt sie und tragt die Zahl in die Quellenspalte ein. Eine Zeile ohne Quelle ist eine Meinung. Meinungen sind erlaubt, sollten aber auch so aussehen.

Danach ordnet ihr die Zeilen nach einer Regel, die ihr einer Kundin erklären könnt. Feature Requests priorisieren behandelt Bewertungsmethoden und warum Upvotes allein in die Irre führen. Die Reihenfolge der Zeilen beantwortet “Was kommt zuerst?”, die Statusspalte beantwortet “Was passiert gerade?”.

Schreibt die Gewissheit ehrlich auf. Eine zugesagte Zeile heißt: Das Team wäre überrascht, wenn sie nicht im Zeitraum ausgeliefert würde. Eine Prognose-Zeile ist der Plan, solange sich nichts ändert. Eine Erkundungs-Zeile bedeutet gar kein Versprechen, und eine Roadmap, die Kundinnen Erkundungs-Zeilen zeigt, sollte erklären, was das Wort heißt.

Wie oft sollte man die Vorlage aktualisieren?

Aktualisiert sie bei jeder Statusänderung und prüft jede Zeile an ihrem Prüfdatum. Eine Roadmap veraltet, wenn das Pflegen eine eigene Fleißarbeit ist. Haltet sie deshalb dort, wo die Arbeit ohnehin stattfindet. Ist euer Issue-Tracker die maßgebliche Quelle, können Labels die Statusspalte steuern, und niemand tippt etwas ab. Wie eine öffentliche Roadmap ehrlich bleibt zeigt das Setup mit einem Label pro Spalte, das Changeloop benutzt.

Wenn eine Zeile ausgeliefert ist, sagt es den Leuten, die danach gefragt haben. Das kann kein Vorlagenfeld für euch erledigen, und es ist der Grund, die Quellenspalte überhaupt zu führen. Der Customer-Feedback-Loop beschreibt den ganzen Weg von der Anfrage bis zur Ankündigung.

Sollte die Vorlage öffentlich sein?

Veröffentlicht eine reduzierte Version, wenn Kundinnen sehen sollen, dass ihre Anfrage gehört wurde. Eine öffentliche Vorlage behält Ergebnis und Status und lässt Verantwortliche, Gewissheit und Prüfdatum weg. Sie lässt auch alles weg, was ihr in einem Verkaufsgespräch nicht verteidigen würdet. Eine kleinere Liste, die aktuell bleibt, schafft mehr Vertrauen als eine lange, die verstummt; auf der Vorlagenseite von ProdPad sieht man, wie ein Anbieter seine aufbaut.

FAQ

Was ist eine Product-Roadmap-Vorlage? Es ist eine wiederverwendbare Tabelle oder ein Board mit festen Feldern für jeden Roadmap-Punkt, etwa Ergebnis, Status, Verantwortliche und Gewissheit. Ihr kopiert sie, füllt pro Punkt eine Zeile aus und haltet sie aktuell.

Welche Spalten sollte eine Product Roadmap haben? Mindestens ein Ergebnis, einen Status und eine Verantwortliche. Ergänzt die Quelle der Anfrage, eine Gewissheitsstufe und ein Prüfdatum, sobald die Roadmap mehr als eine Handvoll Punkte hat.

Sollte eine Product Roadmap Termine enthalten? Für die meisten Teams nur ein Prüfdatum. Kalendertermine werden zu Zusagen, die Vertrieb und Kundinnen einem später vorhalten. Nehmt stattdessen eine Gewissheitsstufe und ein Zeitfenster wie Now, Next und Later.

Kann ich eine Roadmap in einer Tabellenkalkulation oder Markdown-Datei führen? Ja. Eine Tabellenkalkulation passt zu einem Team, das gemeinsam bearbeitet, eine Markdown-Tabelle im Repository zu einem Team, das sie versioniert haben will. Wählt den Ort, an dem die Arbeit ohnehin verfolgt wird, damit Updates keine eigene Fleißarbeit sind.

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