Nach dem Product Strategy Framework von Roman Pichler ist es für Product Owner auf Strategie-Ebene wichtig, Klarheit über das Produkt zu schaffen und dem Team einen groben Plan zu präsentieren. Die Roadmap führt dabei von der Vision über die Strategie bis zur Umsetzung. Erst dann wird der Product Backlog relevant für ein agiles Team und ermöglicht es ihm, zusammen mit dem Product Owner die Roadmap zu nutzen.
Was sind Roadmaps?
Eine Roadmap ist ein grober Plan für die nächsten 1-2 Jahre, der die Ziele angibt, die in dieser Zeit erreicht werden sollen. Hierbei geht es vielmehr darum, auf einen groben Überblick zurückzugreifen, in dem erfüllte Bedürfnisse oder gelöste Probleme dargelegt werden und nicht um detaillierte Listen von Funktionen.
Wie entsteht so eine Product Roadmap?
Oftmals werden Roadmaps bottom-up erstellt, indem bereits vorhandene Produkt-Backlogs gebündelt und in sinnvolle Abschnitte zusammengefasst werden. Man kann das ähnlich wie bei Epics sehen. Dieser Ansatz ist an sich nicht schlecht, aber er lässt viel Potenzial ungenutzt. Der Fokus liegt hier mehr auf der Arbeit und der Strukturierung als auf der Vision und dem Enthusiasmus.
Daher greift man hier besser auf den Top-Down-Ansatz zurück. Man startet mit der Vision, für wen das Produkt gedacht ist und welche Ziele es erreichen soll. Dann werden die komplexen Probleme und Bedürfnisse in kleinere Abschnitte unterteilt, die man erreichen möchte. Anschließend ergibt sich daraus die Roadmap mit den einzelnen Abschnitten. Hier entscheidet man, welches Problem als erstes gelöst oder welches Bedürfnis als erstes mit dem Produkt befriedigt werden soll. Danach füllt man den Produkt-Backlog mit den erforderlichen Inhalten, um gemeinsam mit dem Team die ersten Iterationen zu durchlaufen und das Produkt in Richtung der Vision zu entwickeln.
Welche Art von Roadmap benötige ich?
Häufig wird die Frage gestellt: Wann plant ihr, welche Funktion zu liefern? Diese Frage kann als “klassisch” betrachtet werden, ist jedoch im größeren Kontext durchaus berechtigt. Es ist daher ein sinnvolles Kommunikationsmittel, um dem Rest des Unternehmens und dem Management hier Antworten liefern zu können. Hierbei besteht bereits ein Problem: Welche Erwartung hat mein Empfänger im Hinblick auf die Roadmap und deren Inhalt? Wenn ich zu detailliert meine Informationen herausgebe, kann dies genauso negativ sein wie wenn ich zu wenig Informationen zur Verfügung stelle. Es empfiehlt sich daher, bei der Erstellung der Roadmap zu überlegen, wer der Empfänger ist, welche Informationen er benötigt und welche Erwartungen ich mit der Roadmap wecken möchte.
Als Product Owner kann ich durchaus auch mehrere Roadmaps erstellen, beispielsweise eine öffentliche und eine interne Roadmap. Je nach Anwendungsfall werde ich inhaltlich und datentechnisch entweder genauer oder bleibe etwas oberflächlicher.
Was ist eine Roadmap nicht?
Je detaillierter ich in Daten und Features gehe, umso mehr nimmt die Roadmap einen unerwünschten Charakter an. Sie wird dann schnell als Release Schedule betrachtet und lässt für das Team keinen Spielraum mehr. Sowohl vom Kunden als auch vom internen Management kann dies negative Folgen für das Produkt haben. Ob Kunden lieber auf ein Produkt warten oder sich davon abwenden, wenn es nicht rechtzeitig liefert, bleibt dahingestellt. liefert, oder ob der Druck vom Management aufgebaut wird, wenn Funktionen zu einem bestimmten Zeitpunkt versprochen wurden, aber nicht geliefert werden – als Team benötigen wir gute Gründe für solche Verzögerungen.
Also jetzt dann doch lieber keine Roadmap?
Doch liebe Product Owner. Schließen Sie die strategische Lücke, die Ihnen z.B. Scrum in der Umsetzung offen lässt, und erstellen Sie gemeinsam mit dem Team eine inspirierende und leitende Roadmap. Wie so oft im Agilen ist es nicht die Roadmap selbst, die wichtig ist, sondern das Roadmapping im Team. Eine Roadmap und auch der Product Backlog sind lebende Artefakte. Beim Roadmapping sollten Sie zudem beachten, dass das Team nicht nur aus den Entwicklern und dem Product Owner besteht. Hier ist es empfehlenswert, weitere Beteiligte einzubeziehen.
Wer weitere Gedanken zu Product Roadmap, Strategy und Vision haben möchte, dem kann ich folgende tiefergehende Artikel empfehlen:
- Product Roadmap: Should you build one?: https://sjohnson717.medium.com/product-roadmap-should-you-build-one-1765e360e2de
- Working with an agile Product Roadmap: https://www.romanpichler.com/blog/agile-product-roadmap/
- Product Strategy Framework: https://www.romanpichler.com/blog/my-product-strategy-model/
- The Product Vision Board — A tool for creating your Product Vision: https://medium.com/the-value-maximizers/the-product-vision-board-a-tool-for-creating-your-product-vision-694d130ed5eb
- 10 Product Strategy Mistakes to avoid: https://www.romanpichler.com/blog/10-product-strategy-mistakes-to-avoid/
