Die meisten Produkt-Roadmaps werden innerhalb eines Quartals nach ihrer Erstellung aufgegeben. Nicht weil Teams undiszipliniert sind, sondern weil die Roadmap auf den falschen Grundlagen aufgebaut wurde: fixen Terminen, Feature-Listen und Stakeholder-Wünschen, die als Plan verpackt wurden. Wenn die Realität unweigerlich abweicht — ein Feature dauert länger, ein Kundenbedarf verschiebt sich, ein Wettbewerber bewegt sich — wird die Roadmap zur Fiktion, und das Team hört auf, sie zu beachten.
Eine Roadmap, der Menschen tatsächlich folgen, ist kein Gantt-Diagramm im Gewand einer Produktstrategie. Sie ist ein lebendiges Dokument, das den aktuell besten Wissensstand des Teams darüber abbildet, in welcher Reihenfolge Probleme gelöst werden sollten — und das so aufgebaut ist, dass es ehrlich damit umgeht, was bekannt ist und was nicht.
Bevor Sie eine Roadmap gestalten, sollten Sie sich über ihren Zweck im Klaren sein. Eine Roadmap erfüllt drei Aufgaben: Sie vermittelt die Richtung (wohin gehen wir und warum), sie erzwingt Priorisierung (wir können nicht alles tun, also was kommt zuerst) und sie schafft eine Grundlage für Abstimmung (damit Engineering, Design, Vertrieb und Support auf dieselben Ziele hinarbeiten).
Eine Roadmap garantiert keine Liefertermine. Sie verpflichtet sich nicht zu bestimmten Features. Und sie ersetzt nicht die Notwendigkeit laufender Discovery. Wenn Stakeholder die Roadmap als Versprechen behandeln, ist das ein Prozessproblem — kein Grund, falsche Präzision in das Dokument einzubauen.
Das langlebigste Roadmap-Format für die meisten Teams ist das Drei-Horizonte-Modell. Es geht ehrlich mit Unsicherheit um: Punkte unter „Jetzt“ sind verbindlich, Punkte unter „Demnächst“ sind geplant, aber nicht festgeschrieben, und Punkte unter „Später“ sind richtungsweisend, können sich aber ändern, wenn Sie mehr dazulernen.
Beachten Sie, dass jedes Element nicht nur beschreibt, was es ist, sondern auch, warum es dort steht. Eine Roadmap ohne Begründung ist nur eine Liste. Wenn Teammitglieder verstehen, warum jedes Element ausgewählt wurde, können sie bessere Entscheidungen treffen, wenn sich die Lage ändert — und sie können produktivere Gespräche führen, wenn ein Kunde etwas anfragt, das nicht auf der Liste steht.
Feature-basierte Roadmaps („X bauen, Y bauen, Z bauen“) erzeugen eine gefährliche Dynamik: Das Team liefert Features aus und hält die Sache für erledigt, auch wenn die Features die Kennzahlen nicht bewegen, die sie hätten bewegen sollen. Das Feature wurde geliefert; das Problem wurde nicht gelöst.
Ergebnisbasierte Roadmaps formulieren jedes Element als Ziel um: „Die Time-to-first-Value für neue Nutzer von 4 Tagen auf unter 24 Stunden senken.“ Das Team kann dann entscheiden — und immer wieder neu prüfen —, wie es dieses Ergebnis erreicht. Diese Struktur macht es auch viel leichter, ein Feature niedriger zu priorisieren, wenn Sie einen besseren Weg zum selben Ergebnis entdecken.
Der Product Manager verantwortet die Roadmap. Das heißt, er ist für deren Inhalt, deren Aktualisierung und deren Kommunikation an Stakeholder zuständig. Aber Verantwortung bedeutet nicht alleinige Autorenschaft — die besten Roadmaps entstehen gemeinsam, mit Input von Engineering (zu Machbarkeit und Aufwand), Design (zu Auswirkungen auf die User Experience) und kundennahen Teams (zu Marktsignalen).
Wogegen sich der PM wehren sollte, ist, die Roadmap im Komitee zu gestalten. Stakeholder können Input liefern; sie sollten aber kein Vetorecht über einzelne Elemente haben. Der PM bündelt den Input und trifft die Entscheidungen. Wenn dem Prozess, der zu diesen Entscheidungen führt, vertraut wird, wird auch den Ergebnissen vertraut.
Die Spalte „Jetzt“ sollte in jedem Sprint überprüft werden. Die Spalte „Demnächst“ sollte zu Beginn jedes Quartals überprüft werden oder immer dann, wenn wichtige neue Erkenntnisse eintreffen (ein wichtiger Kunde kündigt, ein Wettbewerber bringt etwas Relevantes heraus, ein Discovery-Sprint liefert ein überraschendes Ergebnis). Die Spalte „Später“ muss einmal pro Quartal erneut angesehen werden — nicht um sie zu verfeinern, sondern um zu bestätigen, dass die richtungsweisenden Wetten weiterhin sinnvoll sind.
Das Ziel ist eine Roadmap, die nie so veraltet ist, dass es peinlich wird, aber auch nicht so häufig aktualisiert wird, dass sie Unruhe stiftet. Die meisten Teams aktualisieren eher zu selten — die Roadmap spiegelt Entscheidungen von vor sechs Monaten wider, und niemand weiß genau, wann sie zuletzt geändert wurde.
Die Roadmap wird befolgt, wenn — und nur wenn — das Team ihr vertraut. Dieses Vertrauen entsteht durch drei Dinge: Die Begründung für jedes Element ist sichtbar und schlüssig, das Team war an der Erstellung beteiligt, anstatt sie übergeben zu bekommen, und der PM aktualisiert sie zeitnah, wenn sich die Umstände ändern, anstatt so zu tun, als würde der ursprüngliche Plan noch gelten.
Eine Roadmap, die als Verhandlungsinstrument behandelt wird oder als Dokument, das erstellt wird, um Führungskräfte zufriedenzustellen, wird auf Teamebene ignoriert und bei den Stakeholdern mit Groll betrachtet. Eine Roadmap, die echtes Nachdenken, reale Zielkonflikte und ehrliche Unsicherheit widerspiegelt, wird zu einem Werkzeug, zu dem Menschen greifen — weil sie ihnen tatsächlich bei Entscheidungen hilft.