3 Roadmaps für Product-Owner: So verbesserst du Refinement, Release-Planung und Stakeholder-Management

Der größte Fehler mit Produkt-Roadmaps?

Stell dir vor, die Vertriebsmanagerin möchte wissen, wann das neue Release erscheint. Die Kollegen vom Marketing wollen die Key-Features des Releases für den Wintersale wissen. Die Entwickler fragen sich, in welches Feature sie die neue KI-Funktion integrieren können. Die Geschäftsführung benötigt Verkaufs- und Umsatzzahlen für ihre Unternehmens-KPIs. Wie kannst du all diese Informationen zur Verfügung stellen?

Der Ratschlag in dieser Situation lautet meistens: Erstelle eine Produkt-Roadmap.

Was passiert, wenn du diesem gängigen Rat folgst? Du erhältst eine Roadmap mit viel zu vielen Details. Die Kollegen vom Marketing benötigen keine technischen Details, um rechtzeitig Werbung zu schalten. Die Entwickler müssen nicht wissen, wie viele Wochen vor Weihnachten die Werbung geschaltet werden muss. Das führt dazu, dass die Roadmap schnell unübersichtlich wird oder einige Fragen der Stakeholder gar unbeantwortet bleiben.

Somit kann eine Produkt-Roadmap für alle schnell zum Problem werden.

Dass dieser Ratschlag so verbreitet ist, liegt wohl auch daran, dass Produkt-Roadmaps meist falsch erklärt werden. Häufig höre ich noch:

„Eine Produkt-Roadmap beschreibt, wie die Produktvision erreicht werden soll.“

Aus meiner Sicht sollte eine Produkt-Roadmap nicht nur einfach beschreiben, sondern sie ist ein Werkzeug zur Kommunikation. Eine Produkt-Roadmap dient dem Austausch mit Stakeholdern darüber, wie sich das Produkt wahrscheinlich weiterentwickeln wird. Unterschiedliche Stakeholder erfordern somit unterschiedliche Roadmaps. Am liebsten wäre mir, wir sprächen deshalb in Zukunft von „Roadmapping“, statt von einer Roadmap. Dies unterstreicht besser, dass es sich hierbei um eine aktive Tätigkeit handelt.

Im Folgenden möchte ich dir drei Produkt-Roadmaps und deren Einsatzzweck vorstellen.

Roadmap #1: Zielgerichtete Produkt-Roadmap

Diese Produkt-Roadmap geht auf Roman Pichler zurück. Sie besteht aus vier Elementen:

• Daten und Versionen pro Quartal: Das Quartal grenzt den Zeitrahmen ein. Das Datum und die Versionsnummer ermöglichen eine Planung von Releases.
• Ziele: Das Ziel des Releases findet sich in der zweiten Zeile.
• Hauptfeatures: Hier werden nicht alle Features des Releases aufgenommen, sondern nur die wichtigsten.
• Metriken: Wertmetriken helfen zu bewerten, ob das Ziel mit dem Release erreicht wurde.

Vorteile und Einsatz der zielgerichteten Produkt-Roadmap:

• Der Fokus dieser Roadmap liegt auf einem konkreten Ziel und nicht etwa auf einer Liste von Features. Das Ziel kann bei dieser Roadmap gut mittels der SMART-Kriterien beschrieben werden.
• Diese Roadmap ist bewusst eher einfach gehalten. Ihre Leichtgewichtigkeit ermöglicht es, dass die Einträge schnell verschoben oder angepasst werden können.
• Für die Sprint-Planung oder das Refinement ist diese Roadmap weniger geeignet. Die Zielgruppe sind weniger die Entwickler, sondern eher Manager anderer Unternehmensfunktionen. Ich denke hier an Vertrieb, Marketing oder Geschäftsführung.
• Aber Achtung: Diese Roadmap hat auch Tücken. Es stehen konkrete Daten fest, wann etwas fertig sein soll. Diese Vorhersagen können schnell als Versprechen fehlinterpretiert werden.
• Das Ziel kann das Produktziel des Scrum Teams sein. Und in Kombination mit Metriken können so natürlich auch OKRs in der Roadmap abgebildet werden.

Betrachten wir nun eine Roadmap, die nicht gegensätzlicher sein könnte:

Roadmap #2: „Story Map“-Roadmap

Diese Roadmap geht auf Jeff Patton zurück und besteht aus drei wichtigen Elementen:

• Aktivitäten: Was unternimmt ein Nutzer, um sein Ziel zu erreichen?
• Funktionen: In den Spalten unter der Aktivität werden Details, Funktionen des Produkts oder Alternativen aufgelistet. Dadurch wird die „User Journey“ mit den Funktionen in Verbindung gebracht.
• Release: Funktionen können als Releases zusammengefasst werden.

Vorteile und Einsatz der „Story Map“-Roadmap:

• Diese Roadmap hilft, große Features in kleine Features zu zerlegen. Somit ist sie sehr gut für das Refinement des Product-Backlogs geeignet.
• Bei der Planung von Releases legt die Darstellung den Fokus auf den Umfang des Releases und nicht auf den Zeitpunkt. Sie beantwortet damit die Frage: „Was wird im Release enthalten sein?“
• Die Sortierung der Funktionen in den einzelnen Spalten kann nach unterschiedlichen Gesichtspunkten erfolgen, etwa nach Wert, Aufwand, Performance, Security, Benutzerfreundlichkeit. Werden die Elemente der Roadmap mit den Stakeholdern verfeinert und angeordnet, fördert dies den Austausch und das Denken in inkrementellen Releases.
• Da die Story-Map als Roadmap viele technische Details enthält, sind die Zielgruppe dafür eindeutig die Entwickler im Scrum Team. Somit ergänzen sich „Story Map“ und zielgerichtete Roadmap sehr gut.

Zum Abschluss noch eine Roadmap, die sich für mich in vielen Unternehmen bewährt hat. Diese Roadmap funktioniert besonders gut dort, wo ein Release-Datum noch als Versprechen und nicht als Vorhersage gesehen wird.

Roadmap #3: „Now, Next, Later“-Roadmap

Ehrlich gesagt: Ich kann dir nicht sagen, wer die „Now, Next, Later“-Roadmap entdeckt hat. Und die Variante, die ich dir vorstelle, ist auch eher unbekannt. Sie besteht aus diesen Elementen:

• Drei Zeithorizonte: Wir unterscheiden hierbei zwischen „Now“, der nahen Zukunft „Next“ und der fernen Zukunft „Later“.
• Farbkodierung: Unterschiedliche Farben helfen, Themen, Projekte, Zielgruppen oder Releases sichtbar zu machen.

Vorteile und Einsatz der „Now, Next, Later“-Roadmap:

• Anstatt über konkrete Daten zu sprechen, wie etwa bei der zielorientierten Roadmap, wird hier das Maß der Unsicherheit sichtbar gemacht. „Now“ steht für die Arbeit im aktuellen Sprint. „Next“ für das, was wichtig ist, und „Later“ für alles andere.
• Die Anzahl der Einträge bei „Now“ sollte durch die Velocity des Scrum Teams begrenzt sein.
• Die Farbkodierung hilft, Zusammenhänge aufzuzeigen.
• Die Anzahl der Einträge in „Next“ entspricht dreimal so vielen wie in „Now“. Dies ist beabsichtigt. Es ermöglicht, mit den Stakeholdern über die Priorität der nächsten drei Sprints zu sprechen. Details für mehr als drei Sprints zu planen ist meistens nicht sinnvoll.
• Die Roadmap liefert nicht so viele Details wie die „Story Map“. Sie ist jedoch auch nicht auf einer so hohen Flughöhe wie die zielgerichtete Roadmap. Daher eignet sie sich sehr gut für das Sprint-Review.

Sind dir drei Produkt-Roadmaps noch nicht genug?

Dann komm zum „Professional Scrum Product Owner – Advanced“-Training.

Dort stellen dir Peter und ich noch drei weitere Roadmaps vor. Das ist natürlich nicht alles. Du lernst auch, wie du Produktziele so formulierst, dass sie wirkliche Ergebnisse beschreiben, deine Produktvision so kommunizierst, dass ihr Menschen auch folgen wollen, und wie du als Product-Owner auch „Nein“ sagst.