Product Roadmap: Ja oder nein?

Die Product Roadmap

Die Product Roadmap bildet das priorisierte Product Backlog auf einer zeitlichen Achse ab. Sie gibt unseren Stakeholdern, dem (Scrum) Team und uns selbst einen Überblick über die für die kommenden Wochen geplanten Entwicklungen. Und sie schließt noch weitere wichtige Informationen mit ein.

Für wen ist die Product Roadmap relevant?

Als Product Owner kennst du dein Product Backlog in- und auswendig. Du kennst die als nächstes anstehenden Features. Und du hast einen Plan im Kopf, in welchem Sprint welche Themen angepackt werden. Unsere Stakeholder können niemals so tief im Detail sein! Die Roadmap ist wesentlich übersichtlicher und konsolidierter als das Product Backlog. Und anders als eine priorisierte Liste, gibt sie einen zeitlicher Ausblick: Wann sind welche neuen Features zu erwarten? Gerade das interessiert die Stakeholder mehr als alles andere!

Die Roadmap als Stakeholder-Management-Tool

Anhand der Roadmap könnt ihr mit Stakeholdern die Priorisierung von Themen besprechen. Gleichzeitig lässt sich anhand valider Schätzungen (wie der Velocity in Scrum oder auch der Durchlaufzeiten in Kanban) über zeitliche Erwartungen und deren Machbarkeit sprechen. Und über Trade-Offs: Was ist wertiger – A oder B? Beides? Dann lass uns über den Umfang der Funktionalitäten sprechen. Parallelisieren kostet nämlich!

Damit stellt ihr auch sicher, dass sich eure Stakeholder involvieren. Dem Stakeholder die Roadmap vor die Nase halten ist ein wirksames Push-Prinzip. Weil aus Erfahrung der erhoffte “Pull” oft ausbleibt. Verständlich, ein Stakeholder hat schließlich noch andere wichtige Themen auf dem Tisch. 

Was muss alles rein in so eine Product Roadmap?

Die Roadmap sollte vor allem folgende Frage beantworten: Wann bekommen unsere User was? Interessant ist, wann etwas fertig und damit für den Kunden nutzbar und wertbringend sein wird! Deswegen ist neben den Themenblöcken die zeitliche Komponente super wichtig!

Das Produkt in den Unternehmenskontext einbetten

Außerdem lassen sich auf einem Zeitstrahl auch wichtige Milestones darstellen. Das können große Schritte im Produkt sein. Aber zum Beispiel auch die Messe, auf der ein neues fettes Feature vorgestellt werden soll. Oder der Start einer Verkaufssaison, zu dem ein unterstützendes internes Tool für die Mitarbeiter verfügbar sein muss.

Orientierungshilfe für interne IT-Prozesse

Falls ihr an Release Dates gebunden seid, gehören auch diese für eine gute Planung mit auf die Roadmap. Die Roadmap hilft den (Scrum) Teams bei der Planung ihrer Sprints, aber auch z.B. dem Release Manager und Test Manager bei der Release Planung und Qualitätssicherung.

Eine Roadmap ist weder Lastenheft noch JIRA

Eine Roadmap sollte eine bestimmte Flughöhe haben. Ein A/B Test zur Farbe eines Buttons ist vielleicht sinnvoll aber für die Zielgruppe nicht interessant. Überlegt euch, welche größeren Features oder Anpassungen sichtbar sein sollten. Und achtet auf möglichst selbsterklärende knappe Formulierungen. Formulierungen, die den Mehwert bezeichnen. “Änderungen am Check-Out” lassen viele Fragen offen. Nicht nur die Frage: “Was wird konkret gemacht?” sondern vor allem die Frage “Wozu geschieht das? Was hat der User davon?” Da klingt „Pflichtfelder reduzieren für bessere Conversion“ doch schon ganz anders! Eine Roadmap ist auch ein internes Marketing-Tool!

Abhängigkeiten aufdecken und berücksichtigen

Auch Abhängigkeiten zwischen mehreren Produktteams oder zu anderen Abteilungen (Marketing, Legal, Sales…) kann man auf so einer Roadmap eintragen. Diese Abhängigkeiten zu erkennen und sie sichtbar zu machen ist ein großer Mehrwert einer (Portfolio) Roadmap! Insbesondere in einem skalierten Umfeld, wo mehrere Teams an einem Produkt oder einer Produktpalette arbeiten. Möglichst wenig Abhängigkeiten wünschen wir uns alle, eine Reduktion ist natürlich erstrebenswert. An manchen Stellen kommt man aber nicht daran vorbei, deswegen besser genau hinschauen! An dieser Stelle ist auch relevant, wann das Refinement und die Entwicklung für ein Feature beginnen – der perfekte Zeitpunkt sich intern abszustimmen!

Wie kann eine Roadmap aussehen? 

Format und Tool ist prinzipiell egal, es muss sich vor allem in den Kontext des Unternehmens einfügen und Akzeptanz finden. 

Möglichst „idiotensicher“

Als Stakeholder (egal ob CEO, Entwickler oder Product Owner eines anderen Teams) muss ich auf einen Blick verstehen, welches Feature die User als nächstes bekommen und was für die nächsten Wochen oder Monate aktuell (!) geplant ist. Wenn ihr im Unternehmen viel mit PowerPoint arbeitet, dann macht ihr euch ein Template in PowerPoint! Es kann auch Excel sein oder ein JIRA Plugin oder Trello… wichtig ist, dass Stakeholder das Format akzeptieren und dass es verstanden wird!

Nur ein Format für die ganze Company

Ich empfehle, dass ihr euch unternehmensweit auf ein einheitliches Format einigt. Das macht es allen Beteiligten leichter. Stellt euch vor, dass sich z.B. ein “Director Customer Experience” regelmäßig nicht nur die Product Roadmaps mehrerer Produktteams ansieht, sondern vielleicht auch Marketing Roadmaps etc. Da reicht es, sich auf den Kontext und Inhalt zu fokussieren und nicht jedes Mal das Format neu durchdenken zu müssen.

Leicht zu pflegen

Für Product Owner ist es wichtig, die Roadmap ohne riesigen Bearbeitungsaufwand pflegen zu können. Denn eine Roadmap darf sich verändern und muss jederzeit aktuell sein! Sicherlich ist durch die Roadmap eine parallele Pflege zum Product Backlog nötig. Das ist ein Mehraufwand für den Product Owner. Bedenkt dabei: die Roadmap erfüllt ja auch einen anderen Zweck. Sie hat eine ganze andere Flughöhe, enthält zusätzliche Informationen, visualisiert diese und spricht andere wichtige Zielgruppen an.

Ein Beispiel aus der Praxis

Diese Art der Product Roadmap habe ich das erste Mal bei Trusted Shops eingeführt und gemeinsam mit den Produktteams und Stakeholdern über einen längeren Zeitraum immer weiter optimiert. Die Product Roadmap galt seinerzeit als das Kommunikationsmedium schlechthin im Unternehmen. Streng nach dem Motto „Was nicht auf einer Roadmap steht, gibt es nicht“.

Wir haben damals tatsächlich PowerPoint genutzt. Heute würde man vielleicht lieber Google Slides nehmen, weil das immer auch remote verfügbar ist. Sofern man im Unternehmen die Google Suite nutzen darf. Zwischendurch war es auch mal Trello. Alles was hilft ist valide! 

Ihr seht in diesem Beispiel thematisch geordnete Blöcke. Außerdem eine Spalte für Abhängigkeiten. Und einen Milestone pro Monat. Wir hatten die Maßgabe „One Feature per Month“. Das hieß: Neben notwendigen Themen wie Maintenance, Legal Anforderungen etc. immer auch mindestens ein für den User relevantes Feature shippen! Außerdem war sichtbar, was erreicht wurde, wo wir zeitlich gerade stehen und Veränderungen in der Roadmap haben wir immer ganz transparent markiert. Ganz oben stand das Ziel mit drauf – also messbare KPIs.

Die Roadmap als Kommunikationstool 

Nehmt die Roadmap zum Anlass, regelmäßig mit den Stakeholdern persönlich zusammenzukommen – am besten vor Ort, remote ist natürlich auch eine Möglichkeit. 

Immer wieder darüber sprechen

Besonders wertvoll ist das direkte Gespräch über die Roadmap! „Warum ist dies oder jenes Feature für den Super-Kunden XY denn schon wieder nicht auf der Roadmap?“ Diese Frage hat garantiert jeder Produktmanager schon einmal gehört. Eine gute Product Roadmap sollte diese Frage beantworten, zum Beispiel mit: „Hier sieht man die Weiterentwicklungen, die wir zur Erreichung der Ziele abgestimmt haben.“

Stakeholder als Team einbinden

Bereits in das initiale Befüllen der Roadmap kann man die Stakeholder einbinden. Ich empfehle vor allem, nicht mit jedem Stakeholder separat zu sprechen, sondern alle Stakeholder an einen Tisch zu holen! So habt ihr die Chance, gemeinsam über Priorisierungen zu entscheiden. Jeder Stakeholder schaut verständlicherweise zunächst auf seine eigenen Themen, nicht auf das große Ganze. Wenn ihr lernt, als ein Team im Sinne des Unternehmens und der Kunden Entscheidungen zu treffen, dann seid ihr strategisch ein großes Stück weiter! Das Buy-in für Priorisierungsentscheidungen eines Product Owners ist auf diese Weise viel einfacher erreichbar. Und es spart allen Beteiligten Zeit. Der Product Owner muss nicht ständig von A nach B laufen, Argumente austauschen und Diskussionen immer wieder separat führen. 

Die Scrum Product Roadmap

Eine Product Roadmap ist auch eine tolle Unterstützung für Sprint Reviews in Scrum. So könnt ihr zu Beginn einer Review die Roadmap zeigen: “Das hatten wir für den Sprint geplant!” Und auch für den Ausblick und die Diskussion mit Stakeholdern über die nächsten Schritte kann sie super herhalten.

Sichtbarkeit möglichst für alle

Man kann sie natürlich auch noch anderweitig transparent machen, z.B. im Flur aushängen. Denn wer sich nicht aktiv in Trello, JIRA etc. einlogged oder Teil eines E-Mail-Empängerkreises ist, sieht eure Roadmap gar nicht. Auch das Product Backlog ist aus diesen Gründen oftmals nicht transparent genug. Entweder fehlen die Lizenzen für JIRA oder aber die Hürde ist zu groß: Der Salesmitarbeiter möchte sich nicht in einem weiteren System bewegen müssen. Zumindest die Roadmap sollte wirklich allen zugänglich sein!

Das ist eine Roadmap nicht

Spart euch in Gesprächen Infos wie “Wir arbeiten weiterhin an Thema X” oder “Eigentlich sind wir fertig, aber wir müssen noch ein paar Dinge fixen bevor wir releasen”. Auch wenn es hart klingt: Das interessiert keine Sau. Interessant ist nur was wirklich da ist! Eine Roadmap ist kein Reporting-Tool, kein Beleg dass fleißig gearbeitet wird! Wenn so etwas notwendig erscheint, dann hat das Unternehmen ein ganz anderes Problem.

Agil bleiben

Immer wieder trifft man Produktmanager, die sich gegen das Pflegen von Roadmaps aussprechen. Oftmals sogar mit dem Argument „Nein, wir brauchen keine Roadmap, wir sind doch agil.“ Ein fataler Fehler, wie sich häufig herausstellt. Ein Produkt ohne mittel- bis langfristige Vision und Roadmap ist zum Scheitern verurteilt. Zu angreifbar ist die Argumentation der Product Manager, wenn sie nicht jederzeit einen validen und offen kommunizierten Plan aus der Schublade ziehen können.

Welchen Zeitraum sollte eine Product Roadmap abdecken?

Da die meisten von uns nicht in einem Start-up unterwegs sind, lassen sich nicht jede Woche die letzten Kundenfeedbacks umsetzen. Oder, wie es die Scrum-Theorie definiert, das wertigste Thema aus dem Product Backlog. Das wäre eine schöne ideale Welt für ein Unternehmen. Doch hunderte von aktuellen und alten Kundenfeedbacks, die Vision des Product Owners und unternehmensinterne Prozessoptimierungen gilt es stets aufzunehmen, zu sortieren und regelmäßig neu zu bewerten.

Jedes Quartal aufs Neue!

Ich empfehle genau diesen Horizont von drei Monaten. Mehr passt nicht zum in der heutigen VUCA-Welt nötigen iterativen, agilen Vorgehen. Sonst plant man einfach viel zu viel für die Katz! Und weniger reicht den Stakeholdern meist nicht aus. Ein Quartal lässt sich meiner Erfahrung nach immer ganz gut meistern.

Wie oft darf man die Roadmap ändern?

Natürlich ist eine Roadmap nie in Stein gemeißelt, sie ist vielmehr ein lebendes Dokument. Sie kann sich jederzeit ändern, jede Woche, theoretisch auch täglich. Wichtig ist aber, Änderungen zu kommunizieren und zu erklären! Warum ziehen wir ein anderes Feature vor? Warum verzögert sich etwas? Was haben wir z.B. aus nicht erkannten Abhängigkeiten gelernt? 

Abstimmungsaufwand nicht unterschätzen

Prioritäten dürfen sich bei entsprechender Notwendigkeit also auch innerhalb eines Quartals verschieben. Dies erfordert jedoch einen beachtlichen Abstimmungsaufwand für ein Produktteam, gerade dort wo mehrere (Scrum-)Teams an einem Produktportfolio arbeiten.  Denn Änderungen ziehen durch interne Abhängigkeiten meist auch Konsequenzen für anderen Teams nach sich. Und Stakeholder wollen auch involviert sein! 

Fokus auf Umsetzung statt Overhead

 Die Scrum-Teams müssen alles dafür tun, ihre Roadmaps möglichst geräuschlos und ungestört umsetzen zu können. Zu viele Einflüsse „von außen“ bringen großen Overhead mit sich. Sie verhindern klaren Fokus und die eigentliche Wertschaffung. Und können somit das Erreichen der definierten Produktvision erschweren.

Der Hüter des Prozesses

Gerade in einem skalierten Umfeld – also dort wo mehrere Produktteams zusammenarbeiten – empfiehlt sich die Installation eines „Synchronisation-Masters“ der sich um die Abstimmungen der Teams untereinander kümmert und einen klaren Rahmen für den Roadmap-Prozess sicherstellt, auch den Stakeholdern gegenüber. Diese Funktion kann z.B. ein Agile Coach oder Scrum Master übernehmen.

Eine große Unterstützung für den CPO

Im skalierten Umfeld gibt es meist einen „Head of Product“, „Chief Product Owner“ oder auch einen „CPO (Chief Product Officer)“ etc. Im Optimalfall vereinigt und treibt diese Rolle die übergreifende Vision, welche sich herunterbricht auf die Produktvisionen und Roadmaps der einzelnen Product Owner. Daher ist auch er ein wichtiger Stakeholder und muss stets im Bilde sein über das „Was wird wann gemacht?”. 

Die Product Vision

Die Erstellung, Pflege und Kommunikation einer übergreifenden Product Vision liegt in der Verantwortung des (Chief) Product Owners. Dieses Artefakt dient dazu, allen Stakeholdern die langfristige Ausrichtung des Produktes am Markt transparent darzustellen, ebenso wie den Teams und beteiligten Product Ownern eine Leitlinie zu geben, in welchem Rahmen sie ihre Produkte selbstständig entwickeln können.

Der Nordstern leuchtet den Weg

Die Priorisierung der Product Backlog Items kann immer anhand der Frage erfolgen: Zahlt das auf unsere Vision ein? Somit ergibt sich auch die Roadmap letztlich aus der Vision heraus. 

Mehr als nur ein (generischer) Satz

Das Product Vision Template von Roman Pichler (vgl. Abb. Product Vision Board) hat sich hierfür immer wieder als hervorragendes Tool herausgestellt. Das Auflisten und regelmäßige Updaten der Target Group, Kundenbedürfnisse, Business-Ziele, Konkurrenten, Marketing-Kanäle, Kostenfaktoren und Umsatztreiber hilft enorm bei der Reflexion des aktuellen Status quo. Und es führt in der Essenz zum eigentlichen Vision Statement. Also zu jener Aussage, die das große Ziel, den Sinn und Zweck eines Produktes beschreibt. Diesen Satz sollte jeder am Produkt Beteiligte kennen und nachts um 4 Uhr aufsagen können. Wichtig ist aber die valide, gehaltvolle Basis dahinter.

Die Growth Roadmap

Die Growth Roadmap ist der nächste strategische Schritt! Eine Roadmap ist nicht nur für das Produktmanagement bzw. die Produktentwicklung ein wichtiges Tool. Und letztlich betrachtet die Product Roadmap nur einen kleinen Teil eines komplexen Konstrukts.

Das Produkt alleine macht noch nicht erfolgreich

Zu einem erfolgreichen Produkt gehört viel mehr: Wie vermarkte ich mein Produkt? Ist mein Product Market Fit überhaupt erreicht? In welchen Schritten bekomme ich es verkauft? Stichwort “Sales Funnel”! Egal, wie ihr intern aufgestellt seid, zu einem erfolgreichen Produkt gehören mehr als nur die Features und die technische Stabilität!

Growth ist das Ergebnis eines cross-funktionalen Prozesses

In einem kleinen Start-up machen sich maximal eine handvoll Menschen diese übergreifenden Gedanken. Hier bietet sich eine Growth Roadmap von vorneherein an. Aber auch in großen Corporates bzw. gerade dort ist ein Alignment aller für das Wachstum des Unternehmens relevanten Bereiche mithilfe des Growth Hacking Prozesses essentiell! 

Wachstum jetzt ganzheitlich angehen

Ihr habt ein Produkt am Start aber wisst nicht, wie ihr z.B. die Anzahl der Kunden steigern oder die Usage verbessern könnt? Schlechte Conversion muss nicht gleich schlechtes Produkt bedeuten… Kommt in unsere Growth Programme und startet mit unserer Hilfe eure Growth Roadmap!

Kostenloses Roadmap Template jetzt downloaden: