You are here
Was ist eigentlich eine Roadmap? Product Management 

Was ist eigentlich eine Roadmap?

Grundlegend: Eine (Produkt) Roadmap dient der Kommunikation geplanter Initiativen und (Teil-) Ergebnisse innerhalb eines bestimmten Zeitraums.

Was eine Roadmap genau ist, lässt sich aber vermutlich unterschiedlich beantworten und was darunter verstanden wird oder welche Erwartungen an sie gestellt werden, hängt stark vom Betrachter bzw. der Zielgruppe ab. Es gibt verschiedene Arten von Roadmaps, etwa Produkt-Roadmaps, Technologie-Roadmaps usw. Meiner Erfahrung nach werden diese Unterschiede in der Praxis nicht genau differenziert bzw. sind stark von einem jeweils geteilten Verständnis abhängig. Meist interessieren sich bestimmte Personengruppen eben vorrangig für bestimmte Aspekte, wenn’s um das Thema Roadmap geht.

Eine Roadmap für ein Produkt, wie es bei Software der Fall ist, stellt in der Regel also Neuerungen oder Milestones in welchem Zeithorizont geplant sind oder welche neuen Produkte wann zu erwarten sind dar. Dementsprechend plump ist es die vereinbarte Absichtserklärung (auf Basis vorausgegangener Überlegungen, strategischer Abwägungen und einiger Verhandlungen) des geplanten Produkt- oder Portfoliofahrplans für einen bestimmten Zeitraum. Im Unterschied zu einem Gantt-Chart geht es hierbei weniger um die Projektplanung oder kritische Pfade, sondern um die kommunikative Ebene.

Eine Bildersuche bei Google vermittelt schnell einen Eindruck, worum es bei einer Roadmap-Visualisierung im Wesentlichen geht:

roadmap?
Bildersuche bei Google zum Thema Roadmap

Leicht kann man sich vorstellen, dass sobald eine Absichtserklärung in Form einer Roadmap veröffentlicht ist, diese schnell zur Projektionsfläche für eine Vielzahl unterschiedlicher Anliegen wird. Eventuell möchte Marketing und Vertrieb frühzeitig konkrete Einzelheiten zu den noch ‚ungelegten Eiern‘ wissen, um kommunikativ das zu tun, was viele Menschen gerne machen – über die Zukunft reden und Ausblicke vermitteln. Eventuell möchten Kunden ihrerseits bestimmte Details zum konkreten und versprochenen Output verstehen, um selbst Budgets und Investitionen sichergestellt zu wissen oder um zu erfahren, welche Möglichkeiten sich hinter den wohlklingenden Absichten verbergen könnten. Die Entwicklungsteams, z.B. Programmierer, wollen natürlich wissen, welche Herausforderungen und Arbeit auf sie zukommen wird und vor allem sicherstellen, dass im Vorfeld bereits eine gründliche Machbarkeitsüberlegung angestellt wurde. Am Ende kann eine Roadmap enorm viele Diskussionen provozieren, doch dies hängt auch vom konkreten Gegenstand (um welches Produkt, welche Technologie etc. handelt es sich?) der Roadmap ab. Einfache und wenig komplexe Produkte, die klar konturiert der Lösung einer präzisen Problemstellung folgen, benötigen sicher auch keine extrem aufwändige Roadmapkommunikation. In diesem Fall würden vielleicht inkrementelle Erweiterungen über einen zeitlichen Horizont hinweg eingeplant und taktisch abgewogen. Die Kommunikation, welche Neuerungen zu erwarten sind, müsste dabei tendenziell einfach ausfallen, da es sich vermutlich um eine naheliegende Evolution handeln würde. Bei komplexen Produkt- oder Leistungsportfolios kommuniziert die Roadmap natürlich immer implizit auch etwas mehr über den geplanten strategischen Fokus, skizziert implizit, auf welche taktischen Schritte höhere oder niedrige Aufmerksamkeit gelegt wird. Die Steuerung komplexer Portfolios ist immer auch eine Abwägungssache, die eigentlich nie zur Glückseligkeit aller Beteiligten führen kann. Gerade dann ist die Roadmap kommunikativ aber umso wichtiger, selbst wenn jeder Roadmap-Inhalt weitaus heißer diskutiert werden könnte. Schnell gerät also in solchen Fällen eine Roadmap zum Politikum.

Zusammenfassend gilt also eine Funktion der Roadmap in jedem Falle: sie ist ein Kommunikationsinstrument.

 

Wie detailliert sollte eine Roadmap sein?

Es gibt zunächst verschiedene Varianten, wie man mit dem Vehikel einer Roadmap umgehen kann. Das optimale, ‚eine Dokument Roadmap‘, das so für alle Zielgruppen gleichmaßen funktioniert und gilt, muss es nicht geben und gibt es sicher auch selten. Inhalte sollten (und das hängt sicher stark vom Produkt oder der Leistung ab) für die entsprechenden Kanäle und Zielgruppen passend aufbereitet werden. Wenn eine Produkt-Roadmap etwa den Horizont von 1 – 2 Jahren umfasst, dann kann man verschiedene Informationsebenen aus ihr ableiten.

Interne Informationsebenen:

  • Welche Budgets sind vorgesehen oder müssen noch gesichert werden?
  • Welche Aufwände sind einzuplanen, um Neuerungen zu vermarkten? Sind Themen beschlossen, die sich für große Kampagnen eignen?
  • Welche Inhalte (etwa ein neues Produkt / Modul / Feature) sind besonders erklärungsbedürftig, so dass interne Schulung sowie Aufklärung auf Kundenseite nötig ist?
  • Welche strategische Ausrichtung wird durch die Roadmap implizit kommuniziert, die eventuell mit weiteren Kommunikationsmaßnahmen begleitet werden muss?
  • Welche Details ergeben sich als Konsequenz für einzelne Teams einer Organisation?
  • Welche Herausforderungen (z.B. technologischer Art) sind im Zeithorizont X zu lösen oder konkret zu priorisieren?
  • Welche potentiellen Preisimplikationen ergeben sich? Müssen etwa neue Preisstrukturen etabliert werden … etc.? Was bedeutet dies für Bestandskunden und Verträge?
  • Welche Effekte sind für Kunden generell zu erwarten? Ändert sich evtl. die Neukundenansprache?
  • Oft zu wenig diskutiert im Kontext der Roadmap: Fallen bestehende Dinge (z.B. Feature etc.) weg auf Basis der Richtungsentscheidungen?
  • Etc.

Kundensicht:

  • Interessieren mich diese Neuerungen überhaupt? Entstehen für mein Unternehmen, meine Mitarbeiter oder Kunden neue Mehrwerte?
  • Gehe ich als Kunde diesen Kurs weiter mit oder entwickelt sich etwas in eine Richtung, die mir nicht gefällt?
  • Entstehen für mich implizite Konsequenzen, etwa Schulungsbedarf oder Vertragsänderungen?
  • Beinhaltet Neuerung X auch Feature Y, auf welches ich so lange warte?
  • Wann werde ich mit Y rechnen können?
  • Bleibt Produkteigenschaft Z erhalten oder ist sie gefährdet?
  • Werde ich eine Demo oder Informationsmaterial erhalten?
  • Etc.

Die große Fragestellung ist, welche der zahlreichen Informationen mit der Veröffentlichung einer Roadmap bereits vermittelt werden und welche noch in Folge kommuniziert werden müssen. Angenommen, alle Informationen sind in der Vorbereitung der Roadmap bereits erörtert und geklärt worden, dann schließt sich konkret die operative Frage an, durch welche Akteure, Materialien, Kanäle die entsprechenden Zielgruppen nun und je nach Bedarf sinnvoll aufgeklärt werden. Aus dem entsprechenden Ambitionslevel hinsichtlich der Kommunikation und dem Willen zur Transparenz, ergibt sich der entsprechend nötige Detaillierungsgrad im Zuge der Roadmap-Kommunikation. Je nachdem, wie politisch-verfahren ein Unternehmen ist, ergibt sich auch für die Roadmap die Konsequenz der politischen Kommunikation intern. Sind etwa wenig nachvollziehbare Initiativen ‚top-down‘ entschieden worden und der Roadmap zu entnehmen, kann dies natürlich auch auf nicht zu unterschätzenden Widerstand bei Angestellten stoßen oder durch weite Teile der Belegschaft abgelehnt werden. In diesen Fällen wird natürlich viel mehr Kommunikationsaufwand in eine Roadmap gesteckt, um Zweifel abzubauen. Hier wird klar, dass Roadmaps auch als politische Kommunikationsinstrumente herangezogen werden.

Ich persönlich finde, dass wenn eine Roadmap vorrangig propagandistisch für die interne Kommunikation wenig unterstützter Entscheidungen Einzelner fehlverwendet wird, dann hat ein Unternehmen 1. ein Problem, welches sich mit einer Roadmap nicht lösen lässt und 2. nicht verstanden, dass es sein Überleben von Kunden, guten Produkten und nicht von Eitelkeiten abhängt. Doch festzuhalten ist an dieser Stelle, dass eine Roadmap auch eine Art Politbarometer sein kann 😉

Der Detailgrad einer Roadmap sollte sich aus einem kommunikativen Konzept ergeben.

Fragestellungen für die Erstellung eines kommunikativen Konzepts zur Einbettung der Roadmap wären dabei etwa:

  • Wofür soll die Roadmap überhaupt verwendet werden – welche Zielsetzung soll sie erfüllen?
  • Wie komplex ist das Produkt, Portfolio etc. – wie naheliegend sind Neuerungen? Wie erklärungsbedürftig ist das Produkt oder eine Neuerung?
  • Für welche Zielgruppen wird die Roadmap überhaupt verwendet? Dient sie interner Kommunikation, wird sie für Partner und Kunden veröffentlicht?
  • Wie ‚viel‘ strategische Absicht soll die Roadmap kommunizieren?
  • Wie verbindlich ist die Roadmap? Wird sie zur Ankündigung bspw. neuer Releases oder für eine nicht-verbindliche Absichtserklärung verwendet?
  • Gibt es bestimmte Oberthemen / Themes, die Entwicklungen leichter differenzieren lassen und verständlicher machen? Z.B. (eher technisch) Architecture oder (eher marktbezogen) Industrie / Kundensegment X
  • Wichtig: Welcher Entscheidungsprozess liegt einer Roadmap und ihren Inhalten zugrunde?
    • Wird sie im Kreis von bestimmten Entscheidungsträgern langvirig für einen Gesamtzeitraum abgestimmt und entschieden?
    • Entsteht sie auf Basis einer Methode im Gesamtunternehmen und ist einem stetigen Prozess zugeordnet? Etwa ein agiler Ansatz…
    • Werden Kunden oder Partner mit einbezogen?
    • Etc.
  • Wie viele politischen Aspekte (Interessen, Abhängigkeiten zu Dritten, Positionierungen, etc.) determinieren die Roadmap?
  • Welche zusätzlichen Informationsebenen existieren, die mit der Roadmap korrelieren oder welche andere Detailgrade abdecken (Ticket-Systeme wie JIRA, Tools für Ideation, Dokumentationen und Twikis, Kollaborationstools und interne Kommunikationstools usw.)?
  • Über welche Kanäle, Abteilungen etc. werden Kunden informiert?
  • Usw.

Den passenden Detailgrad im Rahmen einer Roadmap-Erstellung und Kommunikation sollte jedes Unternehmen für sich organisch entdecken und ich glaube nicht, dass es jemals DEN STANDARD geben kann. Was ich aber konkret empfehle ist, die Zielsetzungen und Implikationen einer Roadmap abteilungsübergreifend zu reflektieren. Eine Roadmap einzuführen nur um eine Roadmap zu haben, ist kein guter Grund. Wenn eine Roadmap herangezogen wird, sollte dies auch echte Motive beantworten und Rollen bzw. Personen sollten sich um die Roadmap kümmern. Das kann heißen, dass dedizierte Personen inhaltliche Verantwortliche oder ‚Gatekeeper‘ sind oder im Vergleich dazu den Prozess der Roadmap-Erstellung und Kommunikation operativ voran bringen. Sicher empfehle ich auch, dass ZU VIEL POLITIKUM ROADMAP einem Unternehmen schadet, insofern – die Roadmap ist nicht das Produkt selbst! 😉

Wie verbindlich ist eine Roadmap?

Wenn man den Aufwand der Erstellung und Pflege einer Roadmap betreibt, sollte die Zielsetzung hinter dem Ergebnis auch sein, eine verlässliche Aussage zu erzeugen. Alles andere ist meiner Auffassung nach völlig kontraproduktiv. Kommunikative Phantastereien und das Nicht-Einlösen von Versprechen führen verständlicherweise zu Misstrauen auf Kundenseite und ebenso auch bei den eigenen Angestellten. Eine Roadmap kann aus meiner festen Überzeugung nicht das Ziel haben, eine vage Möglichkeit einer unbestimmten Zukunft zu skizzieren, die vielleicht real wird. Sondern das, was auf einer Roadmap behauptet wird, sollte auf jeden Fall eine feste Absicht sein, der nach Kräften nachgegangen wird. Nun gibt es natürlich unvorhergesehene Vorfälle oder Einflüsse, die so nicht einplanbar wären und schlussendlich anders erwarteten Einfluss auf die Priorisierung von Initativen oder die Ausgestaltung dieser nehmen können. Deshalb ist aus meiner Sicht auch ratsam, nicht alles potentiell Denkbare in Form einer Roadmap als Behauptung zu verankern. Man kann Zusatzoptionen oder Best-Case Szenarien durchaus jeder Zielgruppe erläutern, aber Teil der Roadmap sollten sie nicht sein.

Wenn eine Roadmap in der Kundenkommunikation eingesetzt wird, wird die Behauptung schließlich dem realen Output entgegengestellt – das Delta kann Vertrauen steigern oder zerstören. Personen, die im direkten Kundenkontakt stehen, können ein Liedchen hiervon singen. Wenn Fantasie-Ziele auf die Roadmap gepackt werden, um die eigenen Angestellten mit hohen Zielen künstlich zu ‚motivieren‘, führt dies früher oder später zum Vertrauenverlust in das jeweilige Management und sicher auch zur Gegenreaktion: Motivationsverlust. D.h. auch für die interne Kommunikation ist dringend empfohlen, dass die Roadmap einen Realitätscheck standhalten kann, um nicht sinnlos die Energie und Motivation guter Mitarbeiter zu verbrennen.

Da die Roadmap kommunikative Zwecke erfüllt, gibt es aber leider immer auch solche Personen, die durch die Roadmap auf das grundlegende Potential der Produktzukunft hinweisen wollen und die Neigung entwickeln dabei maßlos zu übertreiben. Solche Personen muss man unbedingt aus dem Prozess der Roadmaperstellung und -Kommunikation ausklammern, denn ansonsten werden kontraproduktive Ergebnisse resultieren. Es ist also wichtig, dass wenn ein Unternehmen auch mit Hilfe einer Roadmap die mittelfristige Zukunftsvision transportieren möchte, dass hier ein integeres Management eine vernünftige Balance zwischen attraktiver Vorausschau und nötigem Realismus einfordert und vorlebt. Es ist auch klar anzuraten, dass für die Verabschiedung einer Roadmap konkrete Zuständigkeiten existieren, die sowohl strategische Rahmenbedingungen beachten, aber auch die der Erfüllung der Roadmap persönlich mit verantworten. So kann eine Objektivität zwischen Wollen und Können etabliert werden.

Etwas nicht zu versprechen ist weniger schädlich als falsche Versprechen als Absicht zu verkaufen.

Insofern: Eine Roadmap muss meiner Meinung nach den Anspruch einer verbindlichen Absichtserklärung haben und deckt sich im Optimalfall mit dem realen Output.

Die Roadmap als Projektionsfläche für Feedback

Aufgrund ihrer kommunikativen Funktion führt eine Roadmap natürlich unweigerlich zu Reaktionen. Das ist eine sehr wichtige Eigenschaft der Roadmap.

Man kann eine Roadmap gezielt einsetzen, um Reaktionen auf die Inhalte, die Absichtserklärungen, die Interpretation des ‚Plans‘ einzuholen. Was denken Kunden über die geplanten Neuerungen des Produkts? Eine qualitative Auseinandersetzung in Form von direkten und offenen Gesprächen hilft hier nicht nur dabei, den Kunden genauer zu verstehen, sondern führt auch zu manchen hervorragenden Ideen auf Basis der Gespräche zu den Roadmap-Inhalten. Mit bestimmten Kunden (zum Beispiel langjährige Kunden, mit denen eine beidseitige Vertrauensbasis aufgrund der Zusammenarbeit besteht) sollte man sehr früh über Roadmap-Optionen sprechen. Also auch dann, wenn vielleicht Details noch nicht verabschiedet sind. Gerade die Außenperspektive eliminiert  oft frühzeitig so manche Betriebsblindheit und empfiehlt sich somit generell. Aber im Speziellen die Roadmap, welche eine kommunikative und inhaltsbezogene Funktion erfüllt, sollte man in einem Gespräch mal hinsichtlich ihrer Wirkung und Interpretation prüfen. Wie denkt das Gegenüber über den ‚Plan‘? Wirkt die Absichtserklärung realistisch, überzogen, abgehoben? Sind die Inhalte überhaupt verständlich, zu technisch, zu stark von Bullshit-Bingo geprägt? Was würde der Kunde spontan gerne auf der Roadmap sehen? Diese Einblicke sind wichtig und führen zu großartigen Erkenntnissen.

Umgekehrt bin ich dabei nicht der Meinung, dass Feedback die ausschließliche Quelle aller Entwicklungsideen sein darf. Feedback von Kunden wird hier oft falsch eingesetzt und verkommt zur Wünsch-Dir-Was-Orgie, die in der Regel ohnehin nicht zu großartigen Produkten führt. Kunden haben oft spezifische Einblicke und Perspektiven, kennen Produkte leider oft besser als ihre Ersteller und bezahlen aus einen bestimmten Grund eben auch Geld für Produkt X. Kundenfeedback ist entsprechend essentiell und entscheidend. Umgekehrt bedeutet dies aber nicht, dass Kunden die Menge aller relevanten Perspektiven neben ihrer subjektiven abwägen oder die besten Berater für die Herstellung oder strategischen Abwägungen sein müssen. Meiner Erfahrung nach führt ein zu unkritischer Umgang mit dem Feedback nicht zu besseren Ergebnissen für den Kunden. Wenn etwa im Extremfall jede Kundenanfrage direkte Umsetzung in einem Produkt findet, welches für viele Kunden erhältlich sein soll, dann wird so letztlich kein durchdachtes Produkt designed. Auf diese Weise wird opportun ein Sammelsurium aus Perspektiven in ein Gebilde gepresst, was in Summe keinen höheren Nutzen bringt. Bei Software führt unkritische Produktentwicklung schnell zur Konturlosigkeit, dem Verlust von wichtigen Usability-Eigenschaften, dem Verlust von Einzigartigkeit und Charakter, einer unnötig steigenden Komplexität und letztlich vielleicht sogar der Unbedienbarkeit. Das bedeutet, Kundenfeedback ist wichtig, bedeutet jedoch nicht, dass man aufgrund von Feedback die Verantwortung für die Gestaltung und Sinnhaftigkeit von Produkten ablegt! Kunden möchten oftmals teilhaben und teilen entsprechend gerne ihre Perspektive. Aber Kunden erwarten auch, dass ein Produkthersteller selbsttätig reflektiert, mit Neuem positiv überrascht und ein positives Gesamtergebnis verantworten möchte.

Gleiches gilt für Feedback, welches auf Basis der Roadmap eingeholt werden kann. Eine im besten Falle fundierte Produktstrategie umfasst viele Dimensionen; die Roadmap reflektiert dabei einen Teilausschnitt. Kundenfeedback sollte Einfluss auf die Produktstrategie sowie Roadmap nehmen. Aber die Abwägung aller Einflussfaktoren hat ein Unternehmen in eigener Verantwortung zu treffen und sollte auch hinter dieser Abwägung stehen. Ob ein Kunde die Zukunftsabsichten nachvollziehen kann und wie er über die Ergebnisse (z.B. den anvisierten Milestones / Releases / Neuerungen etc.) denkt … das gilt es durch Feedback zu verstehen. Kunden sind die besten Berater. Das ist bei einer Roadmap nicht anders. Das eigene Denken an Kunden auslagern ist jedoch der falsche Weg.

Welche Faktoren sind bei der Festlegung der Roadmap zu beachten?

Hierfür gibt es wieder nicht das EINE REZEPT – welche Faktoren entscheidend Einfluss auf die Roadmap nehmen, hängt erneut naturgemäß vom spezifischen Gegenstand des Produktes oder der Leistung ab. Es gibt verschiedene Prozesse und Best-Practices, wie etwa Product Roadmaps entstehen, ob z.B. durch kontinuierliche Priorisierungen und Bewertungen, ob im Rahmen eines Stage-Gate-Ansatzes oder durch zentrale Verantwortlichkeiten und Rollen, die für die Priorisierung und Konsolidierung der Roadmapthemen zuständig sein sollen. Inzwischen ist die Roadmap aber zumeist durch Funktionen wie die des Produkt Managements verantwortet.

Letztlich fließen in die Priorisierung aller Aktivitäten für z.B. ein Entwicklungsjahr allerdings sehr viele Betrachtungen mit ein, die teils auf kontinuierlichen Informationen und Parametern beruhen oder teils zeitlich aktuelle Situationen umfassen. So einfach eine fertige Roadmap also auch aussehen mag, nicht selten müssen sehr viele Aspekte im Vorfeld und/oder kontinuierlich ausgewertet werden, um einen Gesamtplan bzw. eine Gesamtintention zu konsolidieren.

Dimensionen, die eine Produktstrategie beeinflussen und somit auch bei dem Festlegen der Product Roadmap betrachtet werden sollten:

  • Kunden und Nutzer: Was benötigen Kunden, wo liegt das Geschäftsproblem, bei dem ein Produkt unterstützt? Was fragen Kunden und Nutzer konkret an, was wollen sie mit Produkt x abbilden, welche Mehrwerte sehen sie …? Wo liegen Defizite im Produkt? Welches Nutzungsverhalten lässt sich beobachten und was kann man davon ableiten? Wie ist das Feedback?
    • NOTIZ: Nicht alles, was Kunden vielleicht benötigen oder haben wollen, fragen sie direkt an. Oft sind erfolgreiche Ideen nicht bekannt, bevor sie den Markt betreten. Von einem Smartphone-Hersteller möchte ich etwa auch mit einer guten Idee überrascht werden, er soll nicht nur das Nötigste liefern.
  • Strategie-Fit: Welche Rahmenbedingungen sind durch die Unternehmensstrategie bereits vorgegeben und was genau bedeuten diese für das Produkt oder das Portfolio? Gibt es konkrete Ableitungen und Ziele, die auch in der Roadmap-Planung konkret beantwortet werden müssen? Welche taktischen Ableitungen sind zu beachten?
  • Product / Market-Fit: Kann das Angebot ein relevantes Problem für einen großen Markt lösen? Welche Rahmenbedingungen müssen erfüllt werden, damit dieser Punkt erreicht ist?
  • Trends am Markt: Wohin entwickelt sich der entsprechende Markt? Bsp. – welche Effekte werden autonome Fahrzeuge auf bestimmte Wirtschaftsbereiche haben? Dinge ändern sich und viele Firmen verpassen es über grundlegende Veränderungen nachzudenken, da der eigene Fokus oft zu Scheuklappen führt, die die Wahrnehmung trüben. Natürlich ist aber auch der spitze, konkrete Markt zu betrachten, der mit der aktuellen Industrie, dem Wettbewerb, der Geographie etc. zusammenhängt. Hier lässt sich meist jedoch nur der reale Puls ablesen, sobald eine Veränderung bereits eingetreten ist.
  • Wettbewerb: Welche taktischen Schritte macht der Wettbewerb? Ob in Bezug auf Feature-Vergleiche, Preiskampf oder hinsichtlich der Positionierung, Wettbewerb gibt es nahezu immer und man sollte wissen, wo wer steht. Von Wettbewerb kann man lernen. Allerdings bin ich nicht ein Verfechter der Fraktion, die glauben, eigene Überlegungen durch Wettbewerbsbeobachtung zu stark zu determinieren. Durch zu viel Beobachtung gerät man zu schnell in die Mühle des Nacheiferns oder Replizierens und schränkt damit kreatives Potential ein. Der Spruch ‚Wettbewerb belebt das Geschäft‚ gilt dann nicht immer, sondern vielmehr kann es zu ‚zu viel Googeln hilft eigenem Denken nicht‚ mutieren. Dies sollte man vermeiden bzw. in der Balance halten, wenn man überzeugt vom eigenen Produkt ist.
  • Trends / Technologie: Technologie hat großen Einfluss auf die Möglichkeit von Entscheidungen. Dies hat bei Software natürlich eine sehr große Dimension, weil sich dort die Standards und Herangehensweisen stets schnell geändert haben. Z.B. im Bereich Security, wenn es um APP-Entwicklung geht oder bei hippen Frameworks. D.h. bei Software existiert das Dilemma, dass man sie eigentlich ständig erneuern muss und sehr schnellen Trends unterworfen ist. Bei der Initiativen-, Projekt- und Budgetplanung (welche Entwicklungsinitiativen sind parallel möglich? welche Aufwände müssen zusätzlich eingeplant werden? wie groß und fachlich aufgestellt sind die Teams?) muss dies berücksichtigt werden und somit entstehen implizit Konsequenzen für die Roadmap. Aber auch Trends, wie etwa Social Media oder Mobile (jetzt definitiv nicht mehr neu und trendy, aber dem war mal so) determinieren, was oder wie etwas zu tun ist. Bei manchen Entwicklungen kommt man (je nach Produkt und Leistung) nicht umher, auf neue UI-Pattern, Endgeräte, Design-Moden etc. zu reagieren. Social Media hat bspw. die Erwartungshaltung an Software verändert. Diese Trends wirken sich aus und trennen nicht selten modern von oldschool. Je nachdem wie technisch das Produkt und wie technisch die Zielgruppe ist, lassen sich natürlich aber auch ganz technische Aspekte auf Roadmaps wiederfinden. Wenn das Produkt etwa eine Graph-Datenbank ist, dann sind neue Mehrwerte natürlich auch oft viel technischer argumentiert als es bei einem neuen Facebook Feature oder einem Hotelbuchungsservice der Fall wäre. Bei stark Technologie-getriebenen Themen ist also der kommunikative Zugzwang State-of-the-art Neuerungen oder grandiose Konzepte vorstellen zu müssen, anders gelagert. Das hat auch damit zu tun, wie stark ein Produkt zusätzlich von einer vitalen Community abhängt, die definitiv andere Aspekte wissen möchte, als ein Budgetverantwortlicher im Enterprise-Bereich.
  • User Experience: UX wird oft mit Usability verwechselt, dabei ist Usability nur ein Aspekt im Kontext der User Experience. Product Design umfasst viele Aspekte und betrifft verschiedene Dimensionen, in denen ein Nutzer mit dem Produkt Erfahrungen aufbaut, projiziert oder anwendet. Das Wissen um den Nutzer ist ein wichtiger Aspekt, aber natürlich auch die Konzeption eines Gesamtsystems. UX umfasst nicht nur User Interface-Aspekte, sondern z.B. auch eben Nützlichkeit, Performanz und Robustheit, … die Gesamtheit aller Eindrücke und Erwartungen. Im Rahmen einer Roadmap sollte die strukturierte Arbeit an User Experience eingedacht sein, denn aus meiner Sicht ist dies eine strategische Dimension. Inwieweit man dies begrifflich unterbringt oder inwieweit man Ergebnisse implizit den Initiativen zuordnet ist meines Wissens nach nicht wirklich standardisiert. Fest steht aber, dass die Ziele und die Investitionen zum Aufbau oder zur Verbesserung der User Experience, sich letztlich in der Debatte um die Roadmap wiederfinden sollten.
  • Machbarkeit / Budget / Staffing: Hier ist die Realismus-Kategorie; welche Dinge sind möglich, was muss noch evaluiert werden, ist genügend Budget, Personal und Kompetenz vorhanden? Welche Dinge kann man vermittels der Roadmap kommunizieren und welche Dinge sollten evtl. zurückgehalten werden? Je nachdem wie konservativ, professionell oder politisch versaut ein Unternehmen ist, fällt die Realismus-Kategorie anders ins Gewicht. Dass sie einen massiven Einfluss haben sollte, ist aber dabei selbsterklärend.
  • Kosten/Benefit/ROI: Wir lukrativ werden welche Initativen sein? Welcher Benefit ergibt sich für den Kunden? Wie profitiert der Nutzer? Bringt eine Initiative ein Portfolio in Summe weiter oder nur in einem spitzen Bereich als Satellit? Soll mit den geplanten Entwicklungen das Bestandsgeschäft gestärkt werden oder sind Neukunden im Fokus? Gibt es Kennzahlen / KPI’s, die zur Kontrolle von Erfolg festgelegt werden können? Welche Amortisierung wird erwartet? Die Liste dessen, was hier betrachtet werden kann ist lang.
  • Risiken:  Risiken ergeben sich aus den beiden Punkten zuvor – generelle Machbarkeit und der zu erwartende Mehrwert. Inwieweit man neue Initiativen, deren Risiken noch nicht abgeschätzt werden können, tatsächlich an die große Glocke – aka. Roadmap – hängt, muss diskutiert werden. Das größte Risiko von allen ist jedoch, dass man durch eine KPI-bezogene Scheinwelt vergisst, dass grandiose Ideen, Liebe zum Detail, wunderbares Design und Nützlichkeit sich nicht immer im Vorfeld messen lassen. Mut zur Entscheidung, Vertrauen in eine gute Idee, den Glauben an ein gutes Team und die Bereitwilligkeit zu eigenem Denken sind also wichtige Triebfedern, die nicht im Zahlenwerk verschüttet werden dürfen.
  • Ausbau von bestehendes Potential: Insofern ein Produkt einzigartige Eigenschaften ausweist und sich von der Masse der Wettbewerbsprodukte abhebt, sollte hier natürlich ein Vorsprung ausgebaut und kommunikativ nicht verschwiegen werden. Die Potentiale des eigenen Ansatzes weiter zu kultivieren bedarf dabei immer ein feines Gespür und Mut, da in solch einem Falle der Markt hier keine Norm vorgibt. Dennoch ist klar, Intellectual Property ist eben deshalb wertvoll und schützenswert, weil es Potential hat. Hat ein Unternehmen einen einzigartigen Ansatz geschaffen, der den Test am Markt besteht, dann wäre es schließlich unendlich dumm, diesen Ansatz nicht zu verfolgen. Es gibt bereits zu viele belanglose Kopien von wenig grandiosen Ideen. Der Ausbau ureigenen Potentials ein Produkt zu optimieren und die ‚unfairen Wettbewerbsvorteile‘ oder einzigartigen Eigenschaften weiterzuentwickeln gehört somit zu jeder Roadmap-Debatte dazu. Umgekehrt auch, dass abgewogen wird, wann dieses Potential voll ausgeschöpft ist, eine historisch gute Idee überholt ist und sich ein EndOfLife anbahnt.
  • Etc. – Es gibt letztlich viele weitere Faktoren, die man mit betrachten sollte, aber die Liste sollte schon mal einen ersten Ansatz bieten …

Bei dieser Vielzahl von Dingen, die man betrachten kann, entsteht oft der Eindruck, dass Roadmaperstellung eine nicht zu erschließende Blackbox oder eine Geheimwissenschaft wäre. Das ist jedoch nicht so, sondern die Notwendigkeit viele Parameter zu betrachten geht mit der Komplexität des Produktes, des Marktes und des eigenen Unternehmens einher. Der Mythos, dass ein super-genialer Typ aufgrund einer coolen Idee eine Rakete baut und einfach einer Vision oder dem Bauchgefühlt folgen kann (was vielleicht ja manche Leute von Elon Musk und den Plänen für die Marskolonialisierung denken), ist leider in der Regel nicht real. Visionen sollten definitiv nicht durch Messwerte dominiert werden, umgekehrt hilft es aber wichtige Faktoren in die Betrachtung mit einzubeziehen, um strategisch kluge Ableitungen für die Vision zu erlangen. Ich glaube, dass Unternehmen kulturell sehr unterschiedliche Ansätze haben, wie die Gegenwart und nahe Zukunft diskutiert wird und viele Perspektiven in die Diskussion mit einfließen. Bei der Konsolidierung einer Roadmap kann sich dieser kulturelle Umgang konkret äußern. Zusätzliche Betrachtungen und Parameter werden grandiosen Ideen nur in dysfunktionalen Organisationen im Wege stehen. Personen mit einer Überzeugung (z.B. für eine Erfindung oder Weiterentwicklung eines Produktes) sind zumeist aufgeschlossen gegenüber der Analyse weiterer Parameter. Eher die ‚faulen Eier im Korb‘ lehnen Betrachtungsvielfalt ab und versuchen eine Roadmap spontan in einem Meeting zu beschließen. Sie sind auch oft diejenigen, die den Kurs nicht einhalten und in alle opportunen Richtungen wechseln ohne dabei eine nennenswerte Vision voranzutreiben. Nochmal – Personen, die wirklich von einer Idee überzeugt sind, können meist objektiv auf die Diskussion von weiteren Einflussfaktoren eingehen, da sie oft daran interessiert sind die Idee zu prüfen, um Stolpersteine auszuschließen. Für eine längerfristige Produktstrategie bei komplexeren Produkten halte ich es für wichtig, sich nicht auf Schlüsselloch-Betrachtungen zurückzuziehen und insofern ist Input hilfreich. Am Ende ist es dabei aber natürlich vorrangig wichtig, dass Personen die Roadmap festlegen und ihre Erfüllung durch das Übernehmen von Verantwortung vorantreiben.

Tools zum Thema

Inzwischen gibt es auch zum Thema Roadmap-Erstellung und Visualisierung Services. Da ich aber hier keine Tool-Reviews unterbringen will, soll dies nur exemplarisch erwähnt werden.

Es gibt also diverse Anbieter, die sich mit ihren Services auf Themen der Produktentwicklung oder Produkt Management fokussiert haben. Aha! stellt bspw. eine Reihe von Funktionen bereit, die typische Arbeitsschritte unterstützen sollen, so auch die Roadmaperstellung. Nett ist, dass Aha! aufgrund der Ausrichtung (nicht ganz uneigennützig) auch versuchen, die Produkt Management Praxis mit ein wenig Informationen zu begleiten, so schreiben sie zum Thema Product Roadmap:

‚The purpose of a product roadmap is to communicate direction and progress to internal teams and external stakeholders. It shows the high-level initiatives and the planned steps to get there. It should not include every feature in the product backlog, or a list of specific engineering bugs. The roadmap is a product management document and should live separately. Creating a product roadmap should be a continuous process throughout the lifecycle of a product. Requirements and features should be generated by lots of folks including: customers, partners, sales, support, management, engineering, operations, and product management. It is up to the product management team to determine the priorities and make sure the roadmap is aligned against the business goals.‘

[Quelle: aha.io ]

Tools: Aha!
Tools: Aha!

Agile Roadmapping

Ich glaube, dass der Trend immer weiter zu einer Dynamisierung von Planung und Kommunikation geht. Agile Methoden in der Entwicklung legen auch nahe, eine agile Methode für den Aufbau und Wartung einer Roadmap zu etablieren. Mehr Bottom-Up-Prozesse werden zudem parallel zu klassischen Top-Down Betrachtungen etabliert werden. Da macht es insgesamt total Sinn, Tools und Methoden als Hilfestellung einzuführen, die eine stetige, dynamischere Betrachtung der Roadmap erlauben und konsistent zur agilen Entwicklungspraxis funktioniert. Agile Roadmapping ist aus meiner Sicht ursprünglich an der internen, agilen Praxis angelehnt (hier gut beschrieben – http://www.mindtheproduct.com/2012/08/agile-roadmapping/). Der wesentliche Unterschied ist aber vielleicht, dass eine ‚agile Roadmap‘ als eine Art ‚lebendes Dokument‘ betrachtet wird (hier ganz gut und sicher nicht uneigennützig dargestellt – https://www.productplan.com/agile-product-roadmap/). Tatsächlich finde ich dies nicht so sehr unterschiedlich zu dem, was hinter jeden anderen Roadmap stecken sollte, aber der Anspruch bzgl. Gültigkeit, Aktualität, Vorhersagbarkeit etc. ist in beiden Fällen sicherlich anders interpretiert. Die kommunikative Funktion ändert sich, denn ein ‚lebendes Dokument‘ wird kommunikativ logischerweise anders eingesetzt als eine aufgearbeitete und eher statisch wirkende Roadmap im klassischen Sinne. Beides halte ich für nützlich, beides produziert Arbeit und in beiden Fällen kann man Transparenz erzeugen, Informationen vermitteln und zwischen Planungsebenen vermitteln. Vielleicht ist der Unterschied beider ‚Methoden‘ heute gar nicht mehr so unterschiedlich, sondern vielmehr der kommunikative Umgang mit der Roadmap und den Erwartungshaltungen, die sie weckt.

FAZIT

Es gibt diverse Arten von Roadmaps und sicherlich gleichsam viele Philosophien, was eine Roadmap genau erfüllen soll und wie man diese am besten erstellt und visualisiert. Sicher ist aber, dass eine Product Roadmap immer eine kommunikative Funktion besitzt und konkrete Arbeit bedeutet. Heutzutage ist es typisch, dass Funktionen wie Produkt Management zuständig für die Roadmap sind. Wie genau eine Roadmap im Unternehmen aber eingesetzt wird, hängt von der Unternehmenskultur und der Komplexität der Organisations sowie dem Produkt / Portfolio ab. Ein Roadmap macht kommunikativ nur dann Sinn, wenn sie auch einen Gültigkeitsanspruch besitzt. Hierbei ist vor allem zu beachten, wie und was man durch die Roadmap kommunizieren möchte. Ich bin mir sicher, dass in nahezu jedem Unternehmen die Roadmap eine Projektionsfläche für mannigfaltige Diskussionen darstellt, im Grunde ist das auch gut so. Doch neben der kommunikativen Ebene sollte es unbedingt auch echte Verantwortlichkeiten oder Strukturen geben, die das Erfüllen der Absichtserklärungen auf der Roadmap auch verantworten und bewirken können. Ob eine Roadmap vorrangig intern Verwendung findet oder dem Kunden zugänglich gemacht wird, hängt (neben der unternehmenskulturellen Einstellung) auch von einem Gesamtkomzept ab, in welches eine Roadmap eingebettet ist. Neben sehr klassischen Roadmap-Ansätzen setzt sich auch vermehrt der agile Ansatz durch. Hierbei gibt es feine Unterschiede in der Zielsetzung und auch in dem, wie diese Roadmap als Kommunikationsinstrument eingesetzt werden kann. Planung kann dabei helfen, Denken zu strukturieren und Komplexität zu erfassen oder herunterzubrechen. Dafür eignet sich der Konsolidierungs- und Evaluationsprozess im Kontext der Roadmap sehr gut. Leider werden Themen und die Themenhoheit auch oft politisch umkämpft, hier ist wichtig, dass eine Roadmap nicht missbräuchlich in Verwendung gerät, denn davon haben am Ende weder Kunden noch ein Unternehmen etwas.

Quellen / Verweise:

Related posts

Leave a Comment