Produktroadmap-Planung: 5 Phasen, 3 Horizonte und eine Vorlage

Zuletzt aktualisiert: 15. September 2026

Die Roadmap war an dem Morgen, an dem sie erstellt wurde, korrekt. In der zweiten Woche des Releases hatte sich ein Feature still verdoppelt, zwei warteten auf eine Entscheidung, die niemand aufgeschrieben hatte, und die Folie zeigte immer noch alle fünf in derselben ordentlichen Reihe.

Niemand hat gelogen. Die Präsentation hat einfach keine Möglichkeit herauszufinden, dass sich etwas geändert hat.

Gute Produktroadmap-Planung ist keine bessere Präsentation. Sie schließt die Lücke zwischen Plan und Arbeit, sodass der Plan Dinge erfährt, wenn alle anderen sie auch erfahren. Im Folgenden: die fünf Phasen, in denen sich diese Lücke versteckt, wie man das Ordnungsargument ehrlich führt, und ein funktionierendes Quire-Projekt, aus dem man die Struktur übernehmen kann.

Was ist Produktroadmap-Planung?

Produktroadmap-Planung bedeutet zu entscheiden, was dein Produkt ausliefert und in ungefähr welcher Reihenfolge, und diese Reihenfolge dann mit den Aufgaben verknüpft zu halten, die sie umsetzen. Die erste Hälfte ist ein Argument über Wert. Die zweite Hälfte ist Installationsarbeit, und sie entscheidet, ob das Argument in sechs Wochen noch etwas bedeutet.

Die meisten Ratschläge hören bei der ersten Hälfte auf. Man bekommt Priorisierungs-Frameworks, Stakeholder-Vorlagen, eine Debatte über Themen versus Features. Alles nützlich, und nichts davon berührt das, was tatsächlich kaputtgeht.

Warum entspricht eine Produktroadmap irgendwann nicht mehr der Realität?

Eine Roadmap driftet ab, weil sie getrennt von der Arbeit gespeichert wird, die sie beschreibt. Zwei Artefakte, eine Wahrheit, kein Mechanismus, der sie in Übereinstimmung hält. Also stimmen sie etwa eine Woche lang überein.

Diese Lücke kostet drei konkrete Dinge.

Sie kostet die ehrliche Antwort. Jemand fragt, was als Nächstes kommt, und die Person, die es weiß, muss fünf Leute befragen und aus den Antworten eine Folie neu aufbauen. Bis sie präsentiert wird, beschreibt sie den vergangenen Donnerstag.

Sie kostet die Entscheidungsspur. Ein Feature verschiebt sich, die Roadmap zeigt das neue Datum, und nichts hält fest, wer entschieden hat oder was gestrichen wurde, um Platz zu schaffen.

Sie kostet die Prognose. Kevin Thomas und Cornelius König fanden in Frontiers in Psychology heraus, dass Dauerschätzungen näher an der Realität lagen, wenn die Aufgabe einer ähnelte, die der Schätzende bereits abgeschlossen hatte.

Die eigene ausgelieferte Historie ist das beste Schätzwerkzeug, das man besitzt. Eine Roadmap, die es archiviert, sobald ein Release abgeschlossen ist, wirft das jedes Quartal wieder weg.

Bei Quire haben wir Releases eine Weile über eine Tabelle laufen lassen. Das funktionierte, bis in der Woche jemand eine Frage stellte, die sie ohne Meeting nicht beantworten konnte.

Die Reporting-Hälfte dieses Problems hat ihre eigene Lösung: Stakeholder-Updates ohne Status-Meeting beschreibt das asynchrone Muster, das aus der Arbeit heraus berichtet statt aus jemandes Gedächtnis.

Was sind die fünf Phasen zwischen einer Idee und einem ausgelieferten Release?

Ein Feature durchläuft Intake, Triage, Scoping, Build und Ship, und eine konventionelle Roadmap zeigt nur die letzten beiden. Genug, um ein Diagramm zu zeichnen, aber bei Weitem nicht genug, um ein Quartal zu erklären, denn alles Interessante passiert in den drei Phasen, die keine Spur hinterlassen.

Fünf Orte also, an denen ein Feature tatsächlich steht, und die Rechnung, die kommt, wenn einer davon übersprungen statt durchlaufen wird. Jede Phase unten nennt ihr Zuhause in Quires Product-Roadmap-Vorlage, die dieser Beitrag weiter unten vollständig öffnet.

• 1. Intake lebt im Idea-intake-Abschnitt. Wird er übersprungen, bleibt die Anfrage in einer Direktnachricht und kehrt sechs Monate später als Beschwerde zurück.
• 2. Triage endet in Later oder wird geschlossen. Wird sie übersprungen, schwillt die Liste an, bis niemand ihr mehr traut, und alle führen heimlich eine private Liste.
• 3. Scoped lebt in Next, mit Status Scoped. Wird das übersprungen, öffnet Engineering das Ticket und erbt die Entscheidung, die du aufgeschoben hast, in ihrer eigenen Woche.
• 4. Build lebt in Now, mit Unteraufgaben. Wird diese Verschachtelung übersprungen, liest sich eine undurchsichtige Zeile zwei Wochen lang als achtzig Prozent fertig, ohne dass jemand sagen kann, warum.
• 5. Ship läuft über die Ship-checklist-Unterliste. Wird sie übersprungen, begegnen Kunden dem Feature, bevor der Support informiert wurde, dass es existiert.

Achte darauf, welche Phasen eine Spur hinterlassen. Nur die letzten beiden tauchen auf einer konventionellen Roadmap auf; die ersten drei passieren in Posteingängen und Flurgesprächen, weshalb das Diagramm immer ruhiger aussieht, als sich das Quartal angefühlt hat.

Was ist der Unterschied zwischen einer Produktroadmap und einem Backlog?

Ein Backlog ist alles, was man eventuell tun könnte, in keiner versprochenen Reihenfolge. Eine Roadmap ist der kleine Teil, zu dem man sich verpflichtet hat, mit einem groben Zeitpunkt. Teams geraten in Schwierigkeiten, wenn sie eine Liste führen und sie beides nennen, denn dann liest sich jede Idee darin wie ein Versprechen.

Halte beides in einem Projekt, in unterschiedlichen Abschnitten. Gleiche Aufgaben, gleiche Felder, unterschiedliche Bedeutung.

Die nützliche Konsequenz ist, dass Beförderung zu einem Ereignis wird. Eine Aufgabe von Later nach Next zu verschieben ist eine Entscheidung, die jemand an einem bestimmten Datum getroffen hat, keine Zeile, die nach oben gedriftet ist, während niemand hinsah.

Zum Thema, diese Kandidatenliste nutzbar statt zum Friedhof zu halten: lass deinen Produkt-Backlog die ganze Geschichte erzählen.

Was steckt in Quires Product-Roadmap-Vorlage?

Es ist ein funktionierendes Projekt mit den fünf bereits fest verdrahteten Phasen, kostenlos zu kopieren in jedem Plan. Die Beispieldaten sind ein fiktives v2.0-Release, sodass man sieht, wie die Struktur funktioniert, bevor man sie durch die eigene ersetzt.

Anstatt das aus einem leeren Projekt aufzubauen, nimm Quires Product-Roadmap-Vorlage. Acht Dinge kommen damit:

• Drei Horizont-Abschnitte plus ein Intake-Abschnitt. Now ist das aktuelle Release mit echten Terminen, Next ist das folgende als grobe Form, Later sind Kandidaten ohne Termine, und Idea intake sind untriagierte Anfragen, bei denen nichts ein Versprechen ist.
• Eine fünfstufige Status-Pipeline: Idea, Scoped, In Progress, In Review, Shipped. Scoped existiert bewusst, denn "nicht begonnen" und "niemand hat entschieden, was das ist" sind unterschiedliche Probleme.
• Sechs Roadmap-Felder: Release, Impact, Effort, Customer requests, Source und eine Needs-release-note-Checkbox.
• Features, die sich in ihre echte Arbeit öffnen. Notifications center ist keine einzelne To-do. Es ist das Spec, das Design, der Panel-Build, die Mute-Einstellungen und die Digest-E-Mail, jeweils mit Verantwortlichem und Termin.
• Release-Gates als Meilensteine: Feature Freeze, Code Freeze und GA, als Abhängigkeiten verkettet, sodass die Reihenfolge, in der sie passieren müssen, sichtbar ist.
• Drei Unterlisten, die den Baum quer durchziehen: das aktuelle Release, alles, was einem namentlich genannten Kunden versprochen wurde, und die Ship-Checkliste.
• Ein How-we-prioritize-Dokument, das Regelwerk einmal aufgeschrieben, damit man aufhört, die Methode jedes Mal neu zu diskutieren, wenn man bei einem Element uneinig ist.
• Zwei Reporting-Tabs: ein Dashboard für den wöchentlichen Überblick und Effort by owner, das geschätzte Stunden pro Person summiert, damit man fragen kann, ob das Release zu den beteiligten Leuten passt.

Verschachtelung ist der Grund, warum ein Feature nicht zwei Wochen lang als achtzig Prozent fertig gelesen wird. Wenn Notifications center fünf eigenständige Unteraufgaben sind, wird "achtzig Prozent" zu "die Digest-E-Mail hat noch nicht begonnen, und Ana kümmert sich darum".

Übernimm die Ship-Checkliste, egal ob du sonst irgendetwas anfasst. Sieben Fragen, jede mit einem Namen versehen, und der GA-Meilenstein schließt nicht, bevor sie alle beantwortet sind:

1. Jedes Feature im Release ist Shipped oder ausdrücklich gestrichen und ins nächste verschoben.
2. Release Notes sind für alles geschrieben, bei dem Needs release note angehakt ist.
3. Docs und die API-Referenz sind für jede geänderte Oberfläche aktualisiert.
4. Support ist informiert: bekannte Probleme, Workarounds, was eskaliert werden muss.
5. Die Migration ist an einer Kopie der Produktionsdaten getestet, und der Rollback wurde geprobt.
6. Feature Flags sind für die Launch-Kohorte gesetzt, und die Standardwerte sind bestätigt.
7. Der Hinweis auf der Statusseite und der In-App-Changelog sind für die Release-Stunde geplant.

Punkt fünf sagt geprobt, nicht dokumentiert. Ein Rollback-Plan, den niemand ausgeführt hat, ist ein Wunsch mit Dateinamen.

Duplizieren wirkt auf das gesamte Projekt, sodass der Baum vollständig übernommen wird statt Aufgabe für Aufgabe. Öffne im Dropdown neben dem Titel der Vorlage Mehr und wähle Duplizieren.

Gib der Kopie einen Namen, wähle die Organisation, zu der sie gehört, und klicke auf Erstellen. Etwa eine Minute, und jede Verschachtelungsebene kommt mit – der einzige Grund, warum Kopieren dem Neuaufbau überlegen ist.

Sei dann konsequent damit. Die Struktur ist der nützliche Teil; die Beispiel-Features sind nur Gerüst, und jedes, das man drinlässt, wird im November zu etwas, wegen dem man sich vage schuldig fühlt.

Wie entscheidet man, was ins nächste Release kommt?

Vergleiche Wert gegen Aufwand und halte die Belege für beides sichtbar, statt sie wegzumischen. Priorisierung geht auf vorhersehbare Weise schief: Jemand baut eine Bewertungsformel, die Formel liefert 7,4, und alle nicken zu einer Zahl, die die Meinungsverschiedenheit still begraben hat, statt sie zu klären.

Halte die Eingaben getrennt und sichtbar. In der Vorlage bedeutet das drei Felder bei jedem Kandidaten:

• Impact dafür, was es wert ist – High, Medium oder Low.
• Effort als grobe Einordnung S bis XL.
• Customer requests als Anzahl derer, die tatsächlich danach gefragt haben.

Sortiere nach Impact, lies Effort daneben, und lass die Anzahl verhindern, dass die lauteste Stimme der einzige Input ist.

Dann achte auf die Diskrepanz, die jeden erwischt. In den Beispieldaten kam Dark mode mit 47 Kundenanfragen und einem Impact von Low.

Trotzdem eine faire Entscheidung, da es günstig war und eine wiederkehrende Beschwerde erledigte, aber niemand sollte so tun, als wäre es eine Wachstumswette gewesen. Das meistgefragte Element auf der Liste ist oft nicht das wertvollste, und eine einzige kombinierte Punktzahl ist genau das Instrument, das das verdeckt hätte.

Das ist die Tabellenansicht: dieselben Aufgaben, sechs sortierbare Spalten, nichts exportiert.

Drei Tests, bevor irgendetwas in Now landet. Ist es Scoped? Landet es vor Code Freeze, nicht in der GA-Woche? Hat es eine namentlich genannte Person, kein Team? Ein überfülltes Now ist dasselbe wie kein Now.

Nein zu sagen ist die andere Hälfte, und Dinge für immer in Idea zu lassen ist ein Nein, das niemand laut aussprechen muss. Verschiebe sie mit einer einzeiligen Begründung nach Later, oder schließe sie. Die Ausnahme ist die Customer-committed-Unterliste: Alles, was ein Mensch einem namentlich genannten Kunden versprochen hat, lebt dort, sodass es Streichen zu einem Gespräch macht statt zu einer stillen Bearbeitung um 23 Uhr.

Probiere es an den zehn Kandidaten aus, über die euer Team am meisten streitet. Bewerte sie nach Impact und Effort in einem kostenlosen Quire-Projekt und sortiere dann. Acht der zehn regeln sich meist von selbst, und das Meeting schrumpft auf die zwei, die schon immer der eigentliche Streitpunkt waren.

Wie beantwortet man "was kommt, und wann?" direkt aus der Roadmap?

Man liest es aus den Horizonten, den Meilensteinen und den Status ab, weil alle drei bereits von Leuten gepflegt werden, die ihren Job machen. Das ist die Frage, die die Präsentation beantworten sollte, und der Grund, warum sie immer wieder veraltete.

Die Horizonte beantworten ungefähr wann. Now hat Termine, weil die Arbeit gescopt und einem Verantwortlichen zugeordnet ist. Next hat ein Release, aber keine tagesgenaue Präzision. Later hat bewusst keins von beidem. Later einen Termin zu geben, um organisiert zu wirken, ist der Weg, sich eine Zusage einzuhandeln, der man nie zugestimmt hat.

Die Meilensteine beantworten, was zuerst wahr sein muss. Feature Freeze, Code Freeze und GA sind reale Objekte auf der Timeline mit Abhängigkeiten zwischeneinander, keine Sätze in einem Dokument. Wenn ein Feature den Freeze verpasst, zeigt die Timeline, womit es kollidiert.

Die Status beantworten, was gerade passiert. In Review sieht anders aus als In Progress, das anders aussieht als Idea. Ein Entwickler, der einen Status ändert, aktualisiert die Roadmap als Nebeneffekt seiner Arbeit, was die einzige Art von Reporting ist, die aktuell bleibt.

Das Dashboard beantwortet es für Leute, die die Roadmap nie öffnen werden. Zwei Widgets verdienen sich hier speziell ihren Platz.

Tasks Created vs. Completed stellt die Rate, mit der Arbeit ankommt, gegen die Rate, mit der sie erledigt wird. Das ist das früheste ehrliche Signal dafür, dass ein Release anschwillt statt voranzukommen.

Blocked Tasks verknüpft jedes ins Stocken geratene Element mit dem, was es aufhält, sodass die Standardfrage jeder Roadmap-Review bereits vorbeantwortet auftaucht.

Jedes ausgelieferte Feature in der Vorlage trägt außerdem, was für es geschätzt wurde, gegen das, was es tatsächlich gebraucht hat. Das Muster ist genau das, was die oben genannte Forschung vorhersagt: Arbeit, die etwas ähnelte, das das Team schon einmal gebaut hatte, kam nah dran, während die wirklich neue Arbeit um ein Drittel überzog.

Zwei Mechaniken dahinter sind es wert, für sich gelesen zu werden: wie Meilensteine in Quire funktionieren und wie Aufgabenabhängigkeiten Arbeit miteinander verketten, was einen verpassten Freeze sichtbar statt theoretisch macht.

Sollte Produktroadmap-Planung in eurer Task-Management-Software stattfinden?

Ja, und der Test ist, ob ein Entwickler, der ein Ticket schließt, die Roadmap aktualisiert, ohne darum gebeten zu werden. Ist die Antwort nein, besitzt man zwei Dokumente und eine wöchentliche Abgleich-Gewohnheit, die man irgendwann aufgeben wird.

Präsentationssoftware und dedizierte Roadmap-Tools erzeugen beide ein sauberes Bild. Keines kann sagen, dass der Panel-Build sich verschoben hat, weil keines den Panel-Build enthält. Die Roadmap in dieselbe Task-Management-Software zu legen, in der das Team ohnehin arbeitet, entfernt die Kopie – und damit die Drift.

Wer dieses Tool noch auswählt: Hier ist der Überblick über die beste Task-Management-Software und Task-Tracker, verglichen danach, wie sie verschachtelte Arbeit handhaben.

Es gibt einen Fall, in dem diese Struktur die falsche Form ist, und den sollte man laut aussprechen. Ein Team, das noch danach sucht, was das Produkt sein soll, hat Kandidaten, aber kein zugesagtes Release. Einen Now-Horizont zu öffnen und Termine daraufzusetzen, erfindet ein Versprechen, das niemand gegeben hat.

Führe nur Later und Idea intake, bis wirklich etwas gescopt und einem Verantwortlichen zugeordnet ist, und öffne Now genau in dieser Woche. Die Horizonte sind da, um Zusagen zu halten, nicht um voll zu wirken.

Diese Vorlage ist Teil einer Reihe. Der Rest steckt im Überblick über Projektmanagement-Vorlagen, die euer Team wirklich nutzen wird, einschließlich der für Launches, Status-Reporting und Risiko.

Was ändert man zuerst, wenn man sie kopiert?

Beginne mit den Terminen, denn alles hängt daran. Benenne die Releases um und ziehe die drei Gates auf die eigenen Termine.

Tausche dann die Beispiel-Features gegen echte, jedes mit einer Person statt einem ganzen Squad dahinter.

Streiche zuletzt alles, von dem man insgeheim sicher ist, dass es nie gebaut wird. Eine Roadmap bleibt nur nützlich, solange jede Zeile darauf noch wahr ist.

Key takeaways

Eine Roadmap veraltet, weil sie irgendwo lebt, wo die Arbeit sie nicht erreicht. Macht jede Zeile zu einer echten Aufgabe, und die Drift hört meist auf.

Das bedeutet fünf Phasen statt geplant-und-fertig, drei Horizonte statt erfundener Termine, Release-Gates als Meilensteine mit Abhängigkeiten und Priorisierungsfelder, die ihre Belege zeigen, statt sie in einer Punktzahl zu verstecken.

Nichts davon muss von Grund auf gebaut werden. Nimm eine Kopie von der Product-Roadmap-Vorlage, bewerte die eigenen Kandidaten, halte Now kurz, und die Struktur erledigt die Arbeit bereits.

Bei Quire registrieren, um sie dort laufen zu lassen, wo die Aufgaben ohnehin schon leben, damit die Antwort das nächste Mal, wenn jemand fragt, was kommt, ein Link ist statt ein ganzer Abend.

Häufig gestellte Fragen

Was ist Produktroadmap-Planung?

Zu entscheiden, was ausgeliefert wird, in ungefähr welcher Reihenfolge, und dabei die Arbeit hinter jedem Versprechen zeigen zu können. In Quires Product-Roadmap-Vorlage ist jede Zeile eine echte Aufgabe mit einem Verantwortlichen, einem Release und der darunter verschachtelten Arbeit, sodass Plan und Umsetzung nicht heimlich auseinanderdriften können.

Was ist der Unterschied zwischen einer Produktroadmap und einem Backlog?

Ein Backlog ist alles, was man eventuell tun könnte. Eine Roadmap ist der Teil, zu dem man sich verpflichtet hat, mit einem groben Zeitpunkt. Die Vorlage hält beides in einem Projekt, in unterschiedlichen Abschnitten.

Wie weit im Voraus sollte eine Produktroadmap reichen?

Echte Termine für das aktuelle Release, eine Form für das nächste, nichts darüber hinaus. Dafür sind Now, Next und Later da, denn ein Termin, der erfunden wurde, um eine Folie zu füllen, ist der, auf den man später festgenagelt wird.

Wie priorisiert man eine Produktroadmap?

Wert gegen Aufwand, mit Belegen für beides nebeneinander. Quires Vorlage liefert Impact, Effort und Customer requests als sortierbare Spalten in der Tabellenansicht, bewusst nicht zu einer Punktzahl vermischt, denn eine einzige Zahl verdeckt die Meinungsverschiedenheit, die es wert ist, ausgetragen zu werden.

Sollte die Roadmap im selben Tool leben wie die Arbeit?

Ja, sonst pflegt man zwei Wahrheiten und gleicht sie von Hand ab. Halte sie in der Task-Management-Software, die die Entwickler ohnehin schon nutzen, sodass eine Statusänderung die Roadmap aktualisiert, ohne dass jemand ein zweites Dokument anfasst.

Wann funktioniert diese Roadmap-Struktur nicht?

Wenn noch nichts wirklich verbindlich zugesagt ist. Ein Team, das noch die Form des Produkts sucht, hat Kandidaten, aber kein Release, sodass ein Now-Horizont mit Terminen ein Versprechen erfindet. Führe nur Later und Idea intake, bis etwas gescopt und einem Verantwortlichen zugeordnet ist.

Wie hilft diese Art der Roadmap-Planung einem Team, produktiver bei der Arbeit zu sein?

Sie streicht die Reporting-Ebene: kein wöchentlicher Folien-Neuaufbau, kein Hinterherjagen von sechs Leuten vor einem Stakeholder-Call, kein erneutes Nachfragen, was entschieden wurde. Wenn Roadmap, Gates und Arbeit in einem Quire-Projekt liegen, fließt diese Zeit in produktive Arbeit, statt die Arbeit nur zu beschreiben.