To Roadmap Or Not To Roadmap

Was ist eine Produkt Roadmap ?

Ein Produkt Roadmap soll (den Kunden, die Nutzer, den Partner oder interne wie externe Stakeholder) über geplante und erwartbare Neuerungen im Produkt informieren.

Der Roadmap zeigt nicht nur, was erwartet werden darf, sondern implizit auch, was nicht erwartet werden sollte. Manche Unternehmen nutzen eine Roadmap zu internen Zwecken, z.B. um die taktischen Entscheidungen für die operative Planung zu übersetzen. Andere Unternehmen nutzen die Roadmap, um auch für Investoren, Partner oder Kunden darzustellen, wohin sich ein Produkt entwickeln soll. Letztlich gibt es verschiedene mögliche Zielgruppen und Roadmap-Ausprägungen.

Es gibt unterschiedliche Wege sich der Erstellung einer Roadmap zu nähern. Manche Teams nutzen einschlägige Tools, andere nutzen Folien oder Tabellen für die Darstellung der Roadmap. Es gibt zudem verschiedene Formate, welche für die Kommunikation der geplanten Produktveränderungen verwendet werden. Allerdings gibt es gängigere und weniger gängige Formen der Darstellung.

Zwei verbreitete Darstellungen sollen hier exemplarisch aufgegriffen werden.

Near Term, Mid Term, Long Term, Released

Slack kommuniziert die Entwicklungen der Slack Plattform für Entwickler etwa über die Slack Platform Roadmap for Developers via Trello.

Die Logik in dieser Darstellungsform orientiert sich an einer feingranularen Betrachtung der geplanten Entwicklungen und könnte auch relative nahtlos mit agilen Entwicklungsprizipien (und Backlogs) vereint werden. Eine solche Roadmap eignet sich für Tickets, Epics oder Themen, die der Nutzercommunity geläufig sind oder die eventuell durch die Community zustande kamen.

Die Unterteilung der Spalten in Near Term bis Long Term übersetzt den Fokus der Aufmerksamkeit oder den Planungsstand. Was steht kurzfristig “auf dem Plan”, welche Dinge sind für die längerfristige Entwicklung wahrscheinlich anvisiert? Die Spalte Released zeigt dann alle abgearbeiteten Themen und wird in der Regel hin und wieder aufgeräumt. Diese Form der Darstellung hat Vorzüge aufgrund der Schlankheit. Sie gibt Orientierung, kann schnell angepasst werden und hängt nicht von bestimmten Veröffentlichungszeiträumen ab, sondern wird konstant gepflegt. Die Nachteile sind, dass sich Tickets nicht besonders gut dafür eignen, neue Mehrwerte kommunikativ zu übersetzen oder strategische Ambitionen zu erklären.

Unter Umständen kann diese Form der Roadmapdarstellung auch anders verwendet werden. Und zwar, indem Sie Wahrscheinlichkeiten von Entwicklungskandidaten visualisiert. Solche Themen, die für die Umsetzung im Bereich “Near Term” eingeplant sind, kann man als solche Themen interpretieren, die eine hohe Umsetzungswahrscheinlichkeit aufweisen. Je weiter in die Zukunft geblickt wird, desto weniger verbindlich und damit unwahrscheinlicher wäre die Realisierung der Kandidaten zu einem jetzigen Zeitpunkt. Also schematisch etwa so:

Die Roadmap kann dann ähnlich wie eine Wettervorhersage verstanden werden. Je kürzer man in die Zukunft blickt, desto besser wird die Prognose. Oder: Je weiter man in die Zukunft blickt, desto weniger verlässlich ist die Prognose.

Roadmaps und Quartale

Unternehmen sind aber nunmal meist in Quartalen und damit verbundenen Zielen getaktet. Deshalb ist eine weit verbreitete Form der Roadmapbetrachtung eine, die Initiativen und Releases in die zeitlich normierte Quartalsdarstellung überführt. Ob dies immer eine solide Grundlage für die Maximierung von Produktoutcome garantiert, sei einfach mal dahingestellt.

Diese Art der Roadmapdarstellung hat genaugenommen einige Nachteile, wenn ein Unternehmen nicht reif damit umgehen kann. Denn anders als bei der Aussage “Mid Term” werden hier ja konkrete Zeitpunkte (etwa fertig in Q2) suggeriert. Es wird eine spezifische Erwartungshaltung geweckt, nämlich hinsichtlich dessen, ab wann ein Feature, ein Release oder ein Produkt verfügbar ist. Wenn diese Versprechen nicht eingelöst werden können, warum auch immer (!), dann führt dies (intern wie extern) zu einem Reputationsverlust und zu der Erosion von Vertrauen.

Man sollte diese Form der Darstellung z.B. nur wählen, wenn das kleine Einmaleins des Projektmanagement beherrscht wird - dem Ausbalancieren von Leistung, Zeit und Kosten. Die Ausbalancierung von Leistung, Zeit und Kosten bedeutet für eine agile Entwicklungsmethode, dass wenn die Zeit und die Personenanzahl festgelegt sind (z.B. über n Sprints á 2 Wochen für 1 SCRUM-Team á z.B. 6 Personen), dann nicht gleichzeitig der Scope / Umfang des zu Erbringenden und somit dessen Wert / Qualität bereits festgelegt sein kann. Den Umfang (bei gleichem Qualitätsmaßstab) kann man nur festlegen, wenn man keine starren Aussagen über die Entwicklungszeit macht. Man sollte also nicht alle Enden des magischen Projektmanagement-Dreiecks fixieren und glauben, dies würde jemals Erfolg bringen. Erlebt habe ich leider schon häufig, dass diesbezüglich naive Annahmen oder gar Ignoranz weit verbreitet sind. Ich habe zu oft gesehen, dass Verantwortliche Zeit, Umfang und “Budget” (~ Anzahl der Kapazitäten) unbedingt festzurren wollten. Dies hat im Ergebnis natürlich noch nie zu guten Ergebnissen geführt. Traurig ist, dass dadurch schnell Talente verprellt werden, Produkte schlechter werden und Kunden letztlich enttäuscht sind.

Es ist daher ratsam, entweder a) flexibel hinsichtlich der Zeit oder b) flexibel hinsichtlich des Inhalts bzw. dem Scope zu planen.

Beides zu fixieren ist deswegen problematisch, weil selbst durch die Erhöhung von Personen (oder das Involvieren Dritter) für die Entwicklung die Geschwindigkeit in den seltendsten Fällen steigt, in der Dinge erledigt werden können. Dies hat verschiedenste Gründe, etwa, dass neue Personen ihrerseits Zeit (und Hilfe) benötigten und zeitweise eingespielte Teams verlangsamen. Wodurch die Rechnung “Viel hilft viel” nicht wirklich immer aufgeht.

Somit: Wenn man verlässlich informieren will, welche Dinge in welchem Quartal veröffentlicht werden können, dann muss ein Ansatz existieren, der die Flexibilität hinsichtlich des Inhalts / Umfangs in die fixen Rahmenbedingungen (Zeit und Personen) integriert. Alles andere ist in der Regel eine fatale Milchmädchenrechnung. Man sollte die Darstellung nur wählen, wenn allen Beteiligten klar ist, wie die Planung von Entwicklungsprojekten wirklich funktioniert und welche Erwartung gemanaged werden muss.

Die Roadmap - mitunter ein Politikum

Da die Roadmap auch insbesondere ein Medium für die (interne oder externe) Kommunikation ist, kann sie schnell zum Politikum mutieren. Viele Akteure haben ein Interesse an dem, was auf einer Roadmap zu finden ist und welche Botschaft sie insgesamt transportiert.

Denn eine Roadmap gibt Aufschluß darüber, wie ambitioniert ein Unternehmen ist. Ob es Visionäres plant oder doch nur das Erwartbare abarbeitet. Und, wie schon erwähnt, ob es das Versprochene dann einhält - oder nicht.

Intern sind natürlich Akteure an der Roadmap interessiert, die strategisch in die Produktausrichtung bzw. dem Steering einbezogen sind. Zusätzlich interessiert die Roadmap die Personen, die an dem Erfolg des Produktes (implizit oder explizit) gemessen werden oder jene, die in regelmäßigem Kontakt mit Kunden, Partnern, Stakeholders / Shareholdern stehen und somit Anworten liefern können müssen.

Die Roadmap kommuniziert implizit, für welche Fokusbereiche mehr oder weniger Investitionen eingeplant werden, ob das Unternehmen die Produktentwicklung fokussiert oder auf vielen Hochzeiten gleichzeitig tanzt. Die Roadmap verrät auch, ob Feedback von Kundenseite ernstgenommen wird (oder eben nicht).

Die Roadmapkommunikation hat möglicherweise Einfluss auf die Wahrnehmung des Unternehmens (z.B. wenn es als Technologiepartner wahrgenommen wird) - etwa in Sachen Investitionssicherheit, Innovationsgrad oder Kundennähe. Damit kann die Roadmap einen Einfluss auf die Kundenloyalität, und die Abwanderung (Churn) haben. Dies ist insbesondere dann der Fall, wenn teure Lizenzverträge Laufzeiten beinhalten, die eine Vorausschau zum wichtigen Indikator für Renewal-Erwägungen machen. Je höherpreisiger Lizenzmodelle ansetzen, desto stärker ist das Interesse vonseiten der Buyer-Persona an dem, was über die Roadmap kommuniziert wird. Denn Investionen (aufseiten des Kunden) in IT sind in der Regel mit der Notwendigkeit verbunden, dass die Investitionen intern strategisch oder im Sinne eines ROI (Return on Invest) argumentiert werden müssen oder budgetiert sind. Wenn eine Roadmap keine Argumente für die Fortführung von Verträgen liefert, wird es vermutlich ernste Rückfragen geben.

Je nach Produkt, Tool, Geschäftsmodell und Branche unterscheidet sich der Anspruch (und die Komplexität) bzgl. des Roadmap-Ansatzes. Doch man kann sich vielleicht schnell vorstellen, dass eine Produkt Roadmap in manchen Unternehmen das Resultat langer und hitziger Diskussionen ist. Eine Roadmap wird letztlich nie alle beteiligten Personen oder alle Empfänger zufriedenstellen. Bevor man eine Roadmap einführt, sollte man sich darüber im Klaren sein.

Lohnt sich eine Roadmap eigentlich?

Diese Frage ist spannend. Die Antwort hängt (aus meiner subjektiven Erfahrung beurteilt) davon ab, wie ein Unternehmen tickt.

Wenn ein Unternehmen eine Möglichkeit sucht, die Summe aller denkbaren Initiativen und Möglichkeiten zu kanalisieren, dann kann eine Roadmap für interne Zwecke überaus hilfreich sein. Sie kann auch helfen, um die Vorbereitung von Launchaktivitäten und die Diskussion von Marketingaufwänden früher einzuleiten. Ebenso kann eine Roadmap einem Steering-Committee dabei helfen, verschiedene Szenarien zu diskutieren. Doch dies alles gelingt nur wirklich gut, wenn zwischen Stakeholdern, dem Management und Produktteams ein realistischer Minimalkonsens hergestellt werden kann. Wenn es stumpf nur um Quartalszahlen oder Zielerreichung geht, dann hilft auch eine Roadmap nicht dabei, qualitative Mehrwerte oder neue Spielräume im Kontext des Produktes zu erschließen. Partner, Kunden und Nutzer haben hierfür meist ein feines Gespühr.

Eine Roadmap lohnt sich, wenn komplexe Zusammenhänge durch die Übersetzung (= Roadmap) in ein verständliches Bild überführt werden können, welches Absichten deutlich macht, die ein Unternehmen mit dem Produkt verfolgt. Die Roadmapdiskussion kann unternehmensintern auch ein gutes Mittel sein, um taktische Absichten sowie Notwendigkeiten zu erklären. Sie kann helfen, Strategie zu operationalisierung und Minimalkonsens für eine gemeinsame Anstrengung herzustellen.

Für Kunden kann die Roadmap eine interessante Informationsquelle darstellen, wenn es um Investionssicherheit oder den Abgleich mit eigenen Bedürfnissen geht. Allerdings kann dies nur gelingen, wenn die Roadmap als verlässliches Instrument etabliert wird. Für Kunden kann eine Roadmap ferner interessant sein, wenn Sie beurteilen wollen, ob ein Unternehmen überhaupt ein guter technologischer Partner wäre, der mit Innovationen und Verlässlichkeit überzeugen kann.

Eine Roadmap kann sich also lohnen! Der Aufwand ist dabei aber stetig und hoch.

Roadmaps stimmen jedoch oft nicht so richtig. Insofern sind sie oftmals Absichtserklärungen. Jede Art der Roadmap hat Vor- und Nachteile. Dennoch lohnt es sich immer über verschiedene Ebenen hinweg ein Alignment für den Produkt-Kurs herzustellen. Dafür kann die Roadmapdiskussion ein hilfreiches Vehikel sein.

Empfehlungen

• Klären Sie zuerst für wen Sie warum eine Roadmap erstellen möchten
• Prüfen Sie, ob die Roadmap überhaupt nötig ist
• Fragen Sie sich, ob eine Roadmap für Ihre Kunden nützlich ist
• Klären Sie, ob Sie die Roadmap für die Kommunikation im Neukundengeschäft oder Bestandskunden einsetzen
• Überzeugen Sie durch das Produkt - nicht durch die Roadmap
• Verwechseln Sie die Roadmap niemals mit einem Gantt-Diagramm
• Klären Sie den Unterschied zwischen Vision, Strategie, Roadmap & Backlog
• Klären Sie wer für den Roadmap-Prozess oder das Product-Steering zuständig ist
• Klären Sie wann Ihre Roadmap aktualisiert wird - quartalsweise, kontinuierlich …
• Überlegen Sie sich gut, wie un-/verbindlich Ihre Kommunikation ist
• Machen Sie keine technokratische Roadmap, aber …
• …auch keine, die nicht mehr an der Produkt-Realität orientiert
• Erstellen Sie keine Roadmap, um Dritte zufrieden zu stellen
• Nutzen Sie eine Diskussion der Roadmap, um Szenarien besser zu verstehen
• Seien Sie empathisch - jede Roadmap wird Reaktionen hervorrufen
• Nutzen Sie Reaktionen für konstruktiven Austausch mit dem Kunden
• Bedenken Sie: Die Roadmap dient nicht dazu, den Einzelnen glücklich zu machen
• Kommunizieren Sie eine Roadmap IMMER ZUERST INTERN
• Prüfen Sie ernsthaft, ob Sie eine Roadmap wollen

Tipp: Wenn Sie alle Beteiligten mit Ihrem Produkt überzeugen können, werden Sie vermutlich keine Roadmap benötigen.