Product Roadmap – von der Vision zur Realität

Eine Product Roadmap ist ein wichtiges Hilfsmittel zur Schaffung von großartigen Produkten, dabei aber auch eines der anspruchsvollsten Themen im Produktmanagement überhaupt. Wenn sie richtig erstellt wurde, ist sie ein extrem mächtiges Werkzeug für die gesamte Produktentwicklung und kann sogar Herzstück für das gesamte Unternehmen sein.

Eine Product Roadmap beschreibt über einen Zeitraum (meist ein Jahr) den Weg des Unternehmens, um die Vision Wirklichkeit werden zu lassen. Heißt also, es handelt sich um ein Dokument (ich empfehle eine digitale und eine zentral angebrachte Zettel und Post-It Variante) in welchem festgehalten ist, was in einem zukünftigen Zeitraum von der Produktentwicklung umgesetzt wird. Eine Roadmap soll die Ressourcen des Unternehmens geplant auf ein gemeinsames Ziel konzentrieren. Hierbei geht es nicht um meterlange Detailpläne. Ein Lean- und Agile-Mind-Set ist extrem wichtig. Die Product Roadmap ist dabei ein strategisches Werkzeug für das Produktmanagement. Die Produktmanager sind nicht Administratoren sondern die CEOs des Produktes und müssen eine klare Vorstellung davon haben wie ihr Produkt in einigen Jahren aussehen bzw. in welche Richtung es sich entwickeln soll. Die Produkt Roadmap ist dabei der Weg, um diese Vision Realität werden zu lassen.

Allerdings sind in der Realität Product Roadmaps leider eben oft wenig agil und nur eine Liste von schlecht priorisierten Features ohne strategischen Mehrwert. Agilität ist gefühlt schon sehr gut in der digitalen Branche verstanden, aber Vision, Strategie und Taktik sind es scheinbar nicht. Irgendwie sprechen alle darüber, aber alle verstehen auch etwas anderes darunter. Begriffe wie “strategisch” oder “taktisch” werden oft nur als Synonyme für  “wichtig” verwendet. Solche Missverständnisse machen den erfolgreichen Einsatz einer Produkt Roadmap schwierig oder sogar unmöglich. Es geh nicht darum Definitionen auswendig zu lernen, sondern um ein gemeinsames Verständnis. Deswegen kann eine Product Roadmap nicht als einzelnes betrachtet werden, sondern muss in den Kontext von Vision, Strategie und Taktik gesetzt werden.

Die Product Roadmap im Kontext des VISTA Models

Es gibt endlose Veröffentlichungen und Modelle im Bereich Strategie und Taktik. Dabei gibt es allerdings wenig speziell für den Bereich der digitalen Produktentwicklung. Modelle und Ansätze aus anderen Bereichen sind auch nicht ohne weiteres übertragbar oder mir persönlich schlichtweg zu kompliziert. Um eine möglichst einfache Darstellung auf einen Blick zu erreichen und den Kontext zur Vision und Strategie herzustellen, habe ich das VISTA Model (VISTA steht für VIsion, Strategie, TAktik) entwickelt und hier folgend visualisiert (Abbildung). Dabei werden die Begriffe auch direkt in die hierarchische Reihenfolge gesetzt, nämlich zuerst die Vision, folgend die Strategie und darauf aufbauend die Taktik. So ist es möglich sowohl Vision, Strategie, Taktik, also auch die Umsetzungsplanung in Form der Product Roadmap auf einem Dokument darzustellen. Aus Platzgründen ist es zu empfehlen am besten eine Papier und Post-It Variante für die Product Roadmap zu kreieren. Versucht gerne einmal als kleinen Selbstversuch, die Vision, Strategie und Taktik Eures Unternehmens allein oder zusammen mit Kollegen oder Vorgesetzten auf diese Weise darzustellen.

VISTA Model

VISTA Model

Mit so einem VISTA Selbstversuch kann schnell ein gemeinsames Verständnis geschaffen werden. Ohne eine solches gemeinsames Verständnis hat eine Product Roadmap einen schweren Stand bzw. ist eben doch nur eine Auflistung von Features als To-Do-Liste. Nehmen wir jetzt einmal an, dass eine Vision mit abgeleiteten Strategien und Taktiken existiert. Nun kann die Product Roadmap entsprechend der Unternehmenssituation sehr unterschiedlich aussehen. Folgend einige Beispiele.

Die Discovery Roadmap

Eine Discovery Roadmap eignet sich für Unternehmen, die unter großer Ungewissheit und damit Risiko agieren, also vor allem Start-Ups bzw. Unternehmen, die sich an eine Produktinnovation wagen. In einem solchen Fall ist eine Product Roadmap als großes Experiment anzusehen und die Strategie als auch Taktiken sollten als Hypothesen definiert und auch so behandelt werden. Das Bedeutet wenig Detailinformationen auf der Roadmap aber intensives testen, validieren, lernen, adaptieren und pivotieren in allen Bereichen. Deswegen kommen Product Discovery Ansätze in Form von Design Sprints, Design Thinking und Lean-Startup Ansätze hier massiv zum Einsatz. Die Roadmap kann und soll dann auch anhand der gefundenen Ergebnisse angepasst werden. Product Discovery auf diesem Niveau erfordert extrem viel Entscheidungsfreiraum für die verantwortlichen Teams, weil diese schnell reagieren und entscheiden müssen. Neben den Umsetzungszeiten werden also auch die geplanten Product Discoveries in der Roadmap aufgeführt, denn diese definieren was überhaupt als z.B. working software oder MVP umgesetzt werden soll. Eine Discovery Roadmap mit dem VISTA Model könnte ungefähr so (in sehr vereinfachter Form, Roadmap mit nur einer Tactic für Quartal 1 +2) aussehen:

Beispiel Discovery Roadmap

Beispiel Discovery Roadmap

Die Optimierungs Roadmap

Eine Optimierungs Roadmap eignet sich vor allem für Unternehmen, die bereits ihr Geschäftsmodell gefunden haben, also wissen, wie sie Geld verdienen. Wenn ein Unternehmen eher in der Optimierungsphase ist, kann eine Roadmap auch mehr Details enthalten aber ohne die verantwortlichen Teams zu reinen Umsetzern zu degradieren. So können auf einer Optimierungs Roadmap z.B. KPIs genannt werden, die optimiert werden sollen. Dabei hat das Team zwar eine vorgegebene Taktik in Form einer KPI, aber wie die Steigerung erreicht wird bleibt ihnen überlassen. Hier kommen zwar auch qualitative Methoden wie Usability Tests zum Einsatz aber meist nur als Begleitung von quantitativen Methoden wie A/B Testing. Eine Optimierungs Roadmap mit dem VISTA Model könnte ungefähr so (in sehr vereinfachter Form, Roadmap mir nur einer Tactic für Quartal 1 +2) aussehen:

Optimization Roadmap VISTA Model

Beispiel Optimierungs Roadmap

Die Thematische Roadmap

Wie gesagt gibt es unzählige Möglichkeiten und Darstellungsweisen von Roadmaps. Die meisten finde ich allerdings persönlich nicht sehr empfehlenswert und gute Beispiele sind schwer zu finden. Hier ein gutes Beispiel einer sehr einfachen Darstellung für eine thematische Roadmap:

Beispiel Theme Roadmap

Beispiel Thematische Roadmap

Agile Roadmapping

Ich hatte Ende 2014 eine interessante Diskussion mit Jeff Gothelf zum Thema Product Roadmaps. Jeff hasst Roadmaps, weil sie ihm nicht agil genug sind. Er hatte auch massenweise Beispiele für schlechte Roadmaps in petto. Natürlich hat er recht, wenn eine Roadmap nur eine To-Do-Liste ist und damit eine agile Produktentwicklung mehr behindert als unterstützt. Für mich persönlich ist eine Product Roadmap die nicht auf agilen Grundsätzen beruht auch keine nutzbare Roadmap. Im digitalen Produktentwicklungsbereich setze ich ein agiles Mind-Set, Freude am experimentieren und angstloses Scheitern mit regelmäßiger Lernschleife bis ins Top-Management einfach voraus. Hier geht es nicht um die detaillierten To-Do-Listen der Vergangenheit, die von Managern allein erdacht wurden. Es geht darum wie Roadmaps in Zeiten von Lean Start-Up, Design Thinking und Product Discovery funktionieren können.

 

Dieser Artikel ist ursprünglich am 09.12.2013 erschienen und wurde seitdem grundlegend überarbeitet.

Über Daniel Neuberger

Produkt & Design

3 Kommentare

  1. Roman Schmidt

    Ich habe leider schon die Erfahrung gemacht, dass Roadmaps als wasserfallartige Abfolge von Features zu festgelegten Zeitpunkten präsentiert wurden. Und zwar unabhängig davon, ob sich das Produkt noch im Aufbau befindet oder schon im „Wartungsmodus“ angekommen ist.

    Im letzteren Fall treiben oft die einflußreichsten (oder lautstärksten) Kunden und im ersteren Fall die Technikverliebtheit mancher Manager (und damit meine ich eine Ebene über dem PM) die jeweiligen Pet Features nach vorn.

    Ich arbeite die letzten drei Jahre als Product Owner im agilen Umfeld und kämpfe regelmäßig gegen dieses Phänomen an: Wir entwickeln agil und dennoch werden zu definierten Zeitpunkten konkrete Features erwartet.

    Insofern gefällt mir dein Artikel sehr gut, denn er stellt den strategischen Charakter von Product Roadmaps heraus.

    Es ist wie so oft das Problem von „Wie?“ und „Was?“: Stakeholder erzählen lösungsorientiert wie wir Menschen nun mal sind erstmal das „Wie?“. Durch endlose „Warum?“-Kaskaden gelangen wir zum „Was?“, also den eigentlichen Anforderungen. Auf dieser „Was?“-Ebene kann ich schon strategisch planen, iterativ entwickeln, Annahmen prüfen. Von daher sollte das Inhalt der Roadmap sein – vielleicht sogar noch eine abstraktere Ebene darüber: Geschäftsziele, für deren Erreichung ich verschiedene „Was?“-Wege ausprobieren muss. Das „Wie?“ ist aber in jedem Fall Sache der Entwicklung, nicht der Roadmap.

    Dann passt auf einmal auch alles wieder zusammen:
    Ich habe strategische Ziele, die ich in einem bestimmten Zeitraum erreichen möchte. Auf diese Weise kann ich als PM/PO (diese Differenzierung wäre übrigens auch ein Artikel wert…) kreativ agieren. Nicht so bei einem vorgegebenen Feature-Korsett, das sich mit jeder Woche Verzögerung in der Entwicklung enger zuzieht. Für letzteres benötige ich keinen Produkt Manager sondern einen Verwalter, der sich – um es mit de Marco zu sagen – um die „Administrivialiäten“ kümmert.

    P.S.: Grüße an Rainer 😉

  2. Detlev Petersen

    Hallo,

    ich denke, dass die Lieferung zu einem bestimmten Termin nie zu vermeiden ist. Als Kunde würde ich immer die Lieferung der Ware zu einem bestimmten Zeitpunkt erwarten. Termintreue hat etwas mit dem Vertrauen des Kunden in die Leistungsfähigkeit des Lieferanten zu tun. Bin ich zu häufig untreu oder schaffe ich es wiederholt nicht, das Versprochene abzuliefern, muss das zum Vertrauensverlust führen und der Kunde wird irgendwann abspringen.

    Nach meinem Verständnis bedeutet der agile Ansatz, alle Features eines Produktes zu priorisieren, um zur Not den Liefertermin zu halten, wenn auch mit einer geringeren Anzahl von Features. Der Termin steht wie ein Fels in der Brandung, während weniger wichtige kleine Steine daneben fehlen können. Der Schmerz des Kunden über das Nichtvorhandensein aller Feature wird erträglich, indem nur verschmerzbare Features fehlen. Durch das iterative Vorgehen ist zudem die Prognose über das Nachliefern dessen, was aktuell fehlt, besser als ohne periodischen Soll-Ist-Vergleich. Wenn die Feature-Liste unveränderlich ist, ist es nicht mehr agil, weil weder eine Priorisierung der Features stattfindet noch auf etwas verzichtet werden kann noch Features komplett entfallen können noch neue Features hinzu kommen können. Das entspricht nicht der Realität von Neuentwicklungen, am Anfang schon alles zu wissen, was am Ende des Projekt an wichtigen Features implementiert wird. Technik entwickelt sich so rasant, dass selbst die Hardware-Plattform auf der die Softwareanwendung laufen sollen, sich über den Projektzeitraum wiederholt ändern wird. Damit ändern sich selbst die Randbedingungen unter denen entwickelt wird permanent. Zum periodischen Abgleich und Anpassen habe ich keine Alternative mehr. Es anders zu machen, kommt dem Leugnen der Realität gleich und einer unzulässigen Vereinfachung dieser. Der Reiz nicht agil vorzugehen, liegt offensichtlich in der Realitätsvereinfachung dahinter. Weil nicht sein kann, was nicht sein darf, können Mensch recht stur den falschen Ansatz verfolgen, weil die Wahrheit dahinter einen nicht so direkt anspringt, dass sie für keinen mehr zu ignorieren ist.

    Das Manko mit einer schlecht priorisierten Featureliste oder einer unabänderlichen Featureliste erkläre ich mir wie folgt. Ein guter Vertriebsmitarbeiter verkauft Emotionen, Träume und bedient die Gier des Kunden. Damit er dies überzeugend machen kann, muss er die Realität und ein Teil der Wahrheiten ausblenden. Sobald er anfängt, den Realitätsgehalt und die Hürden beim Umsetzen zu stark zu hinterfragen, müssen ihm Zweifel kommen. Damit würde jedoch das Verkaufsmodell zusammenbrechen. Ein guter Entwickler muss Perfektionist sein, alle Fehler kennen und erfassen, alle Hürden aus dem Weg räumen, in allen Optionen denken und dem maximal Machbaren. Ein guter Produktmanager muss auf Basis von Marktanalysen und Markttrends Produkte und Produktfeatures definieren als auch priorisieren. Damit hilft der Produktmanager dem Vertrieb, weil dieser verkaufen kann, was der Kunde will, und die Wahrscheinlichkeit hoch ist, dass der Kunde es auch bekommt. Andererseits hilft der Produktmanager der Entwicklung, sich auf das Umsetzen der wichtigsten Features zu fokussieren.

    Wenn kein Produktmanager existiert, muss sein Job in Personalunion von anderen erledigt werden. Das wird entweder der Vertrieb sein, weil dieser den Kontakt zum Kunden hat, oder die Entwicklung, weil die sich mit dem Umsetzen auskennt, oder beide zusammen. Da keine reine Fokussierung auf das Denken als Produktmanager stattfindet, weil ich dann immer noch das andere Herz in meiner Brust dominant schlagen habe, kann keine vernünftige Featureliste entstehen. Ebenso wäre es problematisch, wenn der Produktmanager von seinen Befugnissen zu schwach aufgestellt ist, also nach wie vor Vertrieb und Entwicklung alles dominieren. Das dürfte ebenfalls zu keiner optimalen Featureliste führen. Ein weiterer Schwachpunkt ist, dass Geschäftsführer oft Betriebswirte sind, deren Metier nicht die Besonderheiten einer Produktentwicklung sind, sondern Bilanzen und Finanzen. Als Gesellschafter bin ich oft Investor und will schauen, ob sich mein Investment lohnt und alles auf dem richtigen Weg. Wer Geld hat und Macht, der will auch bestimmen. Das kann der Punkt sein, wo ich die Verantwortung für Produktfeatures nicht komplett dem Produktmanager überlassen. Damit weiche ich seine Rolle auf. Oft ist es auch so, dass keine Fehlerkultur existiert. Wer zu etwas Nein sagt, was sich später als Fehlentscheidung herausstellt, der wird oft einen Kopf kürzer gemacht. Wer beim Maximum dessen, was umsetzbar und finanzierbar ist, ist auf der sicheren Seite, denn Terminverzug, zu viele Überstunden, ineffektives Arbeiten, unzufriedene Mitarbeiter führen oft zu keinen Konsequenzen. Wenn es wirklich zu massiven Schwierigkeiten kommt, wie Liquiditätsengpässen oder ein wichtiger Kunde abgesprungen ist, können wir meist von Bauernopfern reden oder von Bestraften, die am wenigsten für die schlechte Lage etwas können.

    Das schöne an den ganzen Entwicklungsprozessen und Vorgehensmodellen ist, dass sie auf der Analyse einer Situation beruhen und ein Idealansatz widerspiegeln, um künftig in der gleichen Situation besser seine Ziele zu erreichen. Der Faktor Mensch wird meist dabei komplett ausgeblendet. Es gibt Macht-, Führungs-, Denk-, Ressourcen- und Finanzstrukturen, die ein agiles Vorgehen immer wieder torpedieren werden oder gar unmöglich machen. Wenn alle agil denken und innerlich diese Überzeugung haben, mag es immer noch andere Umständen geben, die das Leben des Ideals erschweren. Es ist unheimlich schwierig, das Ideal 100% umzusetzen, denn welche Firma wäre so hart und konsequent jeden zu entlassen, der dem Leben des Ideals im Wege steht, oder welcher Chef würde zugeben, dass seine Denkstrukturen nicht zum agilen Vorgehen passen?

    Menschen agieren oft nach dem Minimalprinzip, also ein bestimmtes Ziel mit möglichst wenig Mittel zu erreichen. Damit wird Aufwand in erster Linie dort investiert, um sich mit der passenden Fassade zu umgeben. Wenn ISO900x der Markt erfordert, ist es die ISO900x-Fassade. Wenn Agilität der Modetrend ist, zimmere ich eine SCRUM-Fassade. Mit wenig Aufwand und den richtigen Vermittlern, kann ich jedem glaubhaft machen, dass diesem oder jedem Ideal gefolgt wird. Pragmatisch ist sodann das kontinuierliche Verbessern der Idealvorgaben und jeder Prüfer wird mit Freude dieses oder jenes Zertifikat erteilen. Die Schwierigkeit ist, dass Denken bei jedem Mitarbeiter und in jeder Management-Hierarchie gemäß dem neuen Vorgehen zu verändern. In CMM wird für jeden Reifegradlevel von einer Zeitspanne von etwa 3 Jahren ausgegangen.

    Damit sollte die Abweichung vom Ideal der Normalzustand sein, während wir das Ideal gleichzeitig brauchen als Orientierungshilfe, wo wir stehen. Wenn jemand in einer Firma behauptet, dort würde ein Ideal zu 100% gelebt werden, in diesem Fall ein agiles Vorgehen, dann lügt er sich vermutlich in die eigene Tasche. Vermutlich gibt es in einer größeren Firma eher viele unterschiedliche Enklaven, die nach einer Normalverteilung vom Idealzustand abweichen. Die Herkulesaufgabe ist, jeden auf ein neues Vorgehen einzuschwören, dass es aus seiner Überzeugung heraus gelebt wird.

    Wir können es positiv als Grundlage für die Existenz von Evangelisten sehen, die es geben muss, weil die anderen es nicht packen oder noch nicht verstanden haben. Sisyphos als Sinnbild für das immerwährende Arbeiten am Idealzustand, der doch nicht erreicht wird, weil das Ideal durch ein neues ersetzt wurde oder sich die Grundsituation so geändert hat, dass dies einem Anpassungen aufzwingt. Selbst das Umsetzen einer agilen Vorgehensweise könnte als Projekt begriffen werden mit iterativen Annäherungsschritten und wiederholten Anpassen der Featureliste für die anvisierten Ziele. Selbst das angestrebte Ideal ist keine Konstante mehr.

    Viele Grüße
    Detlev

  3. Nicole

    Danke für die ausführliche Beschreibung, danach habe ich gesucht, aber die Texte in Fachbüchern waren mir einfach zu lang 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.