Post-Image

To Roadmap Or Not To Roadmap

Was ist eine Produkt Roadmap?

Ein Produkt Roadmap soll (den Kunden, den Partner oder den Stakeholder) über erwartbaren Neuerungen des Produktes informieren. Der Roadmap zeigt nicht nur, was erwartet werden kann, sondern implizit auch, was nicht erwartet werden kann. Manche Unternehmen nutzen eine Roadmap zu internen Zwecken, z.B. um die taktischen Entscheidungen für die operative Planung zu übersetzen. Viele Unternehmen nutzen die Roadmap, um auch für Investoren, Partner oder Kunden darzustellen, wohin sich ein Produkt entwickeln soll.

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

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.

Trello als Roadmap-Visualisierung

Siehe hier: https://trello.com/b/ZnTQyumQ/slack-platform-roadmap-for-developers

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:

Ambitionen und Wahrscheinlichkeiten

Roadmap als Wettervorhersage-Equivalent

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.

Geschäftstaktung … Zeitbasierte Roadmaps

Unternehmen sind aber nunmal oft in Quartalen getaktet. Deshalb ist eine weit verbreitete (mindestens im Bereich B2B) Form der Roadmapbetrachtung eine, die Initiativen und Releases in die zeitlich präzisere Darstellung überführt.

Zeitpunkt basierte Roadmaps

Via aha.io: https://www.aha.io/product/roadmaps

Diese Art der Roadmapdarstellung hat einige Nachteile, wenn ein Unternehmen nicht reif damit umgeht. 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 zu einem Reputationsverlust und zu der Erosion von Vertrauen (übrigens: intern wie extern!).

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äufiger, dass diesbezüglich naive Annahmen oder gar Ignoranz weit verbreitet sind. Ich habe zu oft gesehen, dass Manager 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 oftmals Teams verbrannt werden, Produkte oder deren Qualität massiv schlechter werden und Kunden letztlich abwandern.

Es ist daher ratsam, entweder a) flexibel hinsichtlich der Zeit oder b) flexibel hinsichtlich des Inhalts 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 neue Komplexitäten einführen und ihrerseits Zeit (und Hilfe) benötigten, um in die Materie und Praxis vor Ort einzusteigen.

Damit: Wenn man verlässlich informieren will, welche Dinge in welchem Quartal released 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. Die Gefahr bei der Darstellung auf der Zeitachse ist, dass Stakeholder zumeist gerne alle Dimensionen fixiert sehen wollen. Man sollte die Darstellung also nur wählen, wenn allen Beteiligten klar ist, wie die Planung von Entwicklungsprojekten wirklich funktioniert.

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 ankündigt oder doch nur das Erwartbare. Und, wie schon erwähnt, ob es Visionäres ankündigt und dann einhält - oder nicht.

Intern sind zunächst solche Akteure an der Roadmapdiskussion interessiert, die strategisch in die Produktausrichtung einbezogen sind. Oder die, die es gerne wären. 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. Denn die Roadmap kommuniziert implizit, für welche Fokusbereiche mehr oder weniger Investitionen eingeplant werden und in welcher Bandbreite das Unternehmen die Zukunft seines Angebots gestalten möchte. Die Roadmap verrät auch, welche Einflüsse (etwa Rückmeldungen oder Wünsche) von Kunden sowie Partnern aufgenommen werden (oder eben nicht).

Bei lizenzbasierten Geschäftsmodellen (etwa Software-as-a-Service) kann die Roadmapkommunikation Einfluss auf die Wahrnehmung des Services und Unternehmens haben - etwa in Sachen Investitionssicherheit, Innovationsgrad oder Kundennähe. Damit kann die Roadmap einen Einfluss auf die Kundenlyoalität oder Abwanderung (Churn) haben. Dies ist insbesondere dann der Fall, wenn Verträge wenig flexibel sind und etwa längere Laufzeiten beinhalten, so dass die Vorausschau eine wichtigere Rolle spielt. 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. Jemand, er also IT einkauft, hört sich gerne die Argumente an, die der Hersteller liefert. Wenn eine Roadmap nun hier keine Argumente liefert, wird es vermutlich ernste Rückfragen geben.

Je nach Geschäftsmodell und je nach Branche unterscheidet sich der Anspruch (und die Komplexität) bzgl. des Roadmapping-Ansatzes. Doch man kann sich vielleicht schnell vorstellen, dass eine Produkt Roadmap vielerorts hitzig diskutiert wird. Eine Roadmap wird 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 Marketing Budgets früher einzuleiten. Ebenso hilft die Roadmap auch dabei in Szenarien zu denken. Doch dies alles gelingt nur wirklich gut, wenn zwischen Stakeholdern, dem Management und anderen Akteuren ein Minimalkonsens hergestellt werden kann, so dass die Roadmapdiskussion als möglichst Ego-freie Zone funktioniert, in der es um bessere Argumente und denkbare Strategien geht. Wenn es stumpf nur um Quartalszahlen oder Hierarchie geht, dann hilft auch eine Roadmap nicht dabei, qualitative Mehrwerte oder neue Spielräume zu erschließen.

Eine Roadmapdiskussion lohnt sich dann, wenn das Produkt durch diese “Vertiefung” wertvoller für den Kunden wird. Z.B., indem durch die Roadmap die Diskussion über Wertvolles stärker in den Fokus gerückt werden kann. Oder auch dann, wenn Sie Teams eine neue Möglichkeit bietet, Innovationspotentiale gemeinsam zu erschließen. Die Diskussion lohnt sich nicht, wenn die Roadmap als Territorium verstanden wird, auf dem Interessenhaber möglichst viel Raum einnehmen wollen.

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 Roadmapdiskussion wäre unternehmensintern auch ein gutes Mittel, taktische Absichten sowie Notwendigkeiten in eine Handlungsableitung zu überführen, so dass ein Minimalkonsens eine gemeinsame Fokussierung herstellen kann. Sie lohnt sich dann aber nicht, wenn es keine Diskussion auf Augenhöhe zwischen den verschiedenen Diskussionspartnern geben kann. Bspw. ist dies klassisch der Fall, wenn Marketing, Sales und Finance als vital, Research & Development nur als ausführende Kräfte betrachtet werden. Solche überholten Anschauungen versperren den Blick auf die gemeinsamen Ziele und Potentiale.

Für Kunden kann die Roadmap eine interessante Informationsquelle darstellen, wenn es um Investionssicherheit 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 die Bedürfnisse des Marktes versteht und mit Innovationen überzeugen kann.

Eine Roadmap kann sich lohnen! Der Aufwand ist dabei aber stetig und hoch. Doch es kann auch sein, dass die Roadmapdiskussion mehr schadet als nützt.

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 (z.B. im Kontext des Geschäftsmodells)
  • Fragen Sie sich, ob eine Roadmap für Ihre Kunden hilfreich wäre
  • 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
  • Verwechseln Sie Planung nicht mit Marketing - und umgekehrt
  • Klären Sie intern den Unterschied zwischen Vision, Strategie, Roadmap und Backlog
  • Klären Sie früh, wie und von wem die Roadmapdiskussion gepflegt wird
  • Klären Sie wann Ihre Roadmap aktualisiert wird - quartalsweise, kontinuierlich ...
  • Überlegen Sie sich gut, ob Sie verbindliche Aussagen treffen können
  • Machen Sie keine technokratische Roadmap, aber ...
  • ...auch keine, die nicht mehr für die an der Herstellung des Produktes Beteiligten übersetzbar wäre
  • Machen Sie keine Roadmap, um Dritte zufrieden zu stellen - das führt meist zu nichts
  • Nutzen Sie eine Diskussion der Roadmap, um mögliche Szenarien besser zu verstehen
  • Seien Sie empathisch - jede Roadmap wird Interpretationen und Reaktionen hervorrufen
  • Nutzen Sie Reaktionen für konstruktiven Austausch mit dem Kunden
  • Aber: packen Sie nicht spontan Wünsche auf die Roadmap, um den Einzelnen glücklich zu machen
  • Kommunizieren Sie eine Roadmap IMMER ZUERST INTERN
  • Prüfen Sie ernsthaft, ob Sie eine Roadmap wollen
Weitere Beiträge
Fehler beim Aufbau der Produktorganisation

Fehler beim Aufbau der Produktorganisation

Der Aufbau einer Produktorganisation sollte Aufmerksamkeit im Management erhalten. Häufig treten Probleme auf, die man hätte vermeiden können. Ein paar Fehler und Hinweise werden in diesem Post erläutert.

Mehr erfahren
Innovation managen? Ja.

Innovation managen? Ja.

Innovationen sind mehr als kreative Ideen - wenn Innovation auf die Organisation trifft, wird es oft anstrengend. Trotzdem sollte man Innovation wagen!

Mehr erfahren

Newsletter

Neues von conceptMonkey einfach abonnieren

Hier