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, das als Produktstrategie verkleidet ist. Es ist ein lebendes Dokument, das das aktuelle beste Denken des Teams darüber repräsentiert, in welcher Reihenfolge Probleme gelöst werden sollten — strukturiert, um ehrlich darüber zu sein, was bekannt ist und was nicht.
Bevor Sie eine Roadmap gestalten, lohnt es sich, klar über ihren Zweck zu sein. Eine Roadmap erfüllt drei Aufgaben: Sie kommuniziert die Richtung (wohin gehen wir und warum), sie erzwingt Priorisierung (wir können nicht alles tun, also was kommt zuerst), und sie schafft eine Basis für Ausrichtung (damit Engineering, Design, Vertrieb und Support alle 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 dauerhafteste Roadmap-Format für die meisten Teams ist das Drei-Horizonte-Modell. Es ist ehrlich über Unsicherheit: Punkte unter „Jetzt" sind verbindlich, Punkte unter „Demnächst" sind geplant aber nicht festgeschrieben, und Punkte unter „Später" sind richtungsweisend, aber können sich ändern, wenn Sie mehr lernen.
Beachten Sie, dass jedes Element nicht nur beschreibt, was es ist, sondern auch warum es dort ist. 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 Dinge ändern — und sie können produktivere Gespräche führen, wenn ein Kunde etwas anfragt, das nicht auf der Liste steht.
Feature-basierte Roadmaps ("baue X, baue Y, baue Z") erzeugen eine gefährliche Dynamik: Das Team liefert Features und nennt es 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.
Ergebnis-basierte Roadmaps formulieren jedes Element als Ziel um: „Zeit bis zur ersten Wertschöpfung für neue Nutzer von 4 Tagen auf unter 24 Stunden reduzieren." Das Team kann dann entscheiden — und erneut prüfen — wie es dieses Ergebnis erreicht. Diese Struktur macht es auch viel einfacher, ein Feature zu deprioritisieren, wenn Sie einen besseren Weg zum gleichen Ergebnis entdecken.
Der Product Manager besitzt die Roadmap. Das bedeutet, er ist für deren Inhalt, deren Updates und deren Kommunikation an Stakeholder verantwortlich. Aber Besitz bedeutet nicht alleinige Autorenschaft — die besten Roadmaps werden kollaborativ erstellt, mit Input von Engineering (zu Machbarkeit und Aufwand), Design (zu User-Experience-Implikationen) und kundenseitigen Teams (zu Marktsignalen).
Was der PM widerstehen sollte, ist die Roadmap durch ein Komitee zu gestalten. Stakeholder können Input liefern; sie sollten kein Vetorecht über einzelne Elemente haben. Der PM synthetisiert den Input und trifft Entscheidungen. Wenn dem Prozess, mit dem diese Entscheidungen getroffen werden, vertraut wird, wird den Ergebnissen auch vertraut.
Die Jetzt-Spalte sollte jeden Sprint überprüft werden. Die Demnächst-Spalte sollte zu Beginn jedes Quartals überprüft werden, oder wenn bedeutende neue Erkenntnisse eintreffen (ein wichtiger Kunde kündigt, ein Wettbewerber startet etwas Relevantes, ein Discovery-Sprint bringt eine überraschende Erkenntnis). Die Später-Spalte muss einmal pro Quartal überarbeitet werden — nicht um sie zu verfeinern, sondern um zu bestätigen, dass die Richtungswetten noch Sinn ergeben.
Das Ziel ist eine Roadmap, die nie so veraltet ist, dass sie peinlich wird, aber nicht so häufig aktualisiert wird, dass sie Angst erzeugt. Die meisten Teams neigen dazu, zu wenig zu aktualisieren — die Roadmap spiegelt Entscheidungen wider, die vor sechs Monaten getroffen wurden, 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 ein Dokument, das erstellt wird, um Führungskräfte zufrieden zu stellen, wird auf Teamebene ignoriert und auf Stakeholder-Ebene abgelehnt. Eine Roadmap, die echtes Denken, reale Kompromisse und ehrliche Unsicherheit widerspiegelt, wird zu einem Werkzeug, nach dem Menschen greifen — weil sie ihnen tatsächlich hilft, zu entscheiden.