Produkt-Roadmap
Die Produkt-Roadmap ist ein strategisches Dokument, das zeigt, wie sich ein Produkt voraussichtlich entwickeln wird. Sie trägt Themen, die je übergeordnete Anforderungen oder Funktionalitäten bündeln, aufgetragen auf einer grob geteilten Zeitachse: entweder Quartale oder drei Spalten mit den Bezeichnungen jetzt, als Nächstes und später. Sie dient dazu, die Stakeholder auf eine Richtung auszurichten, die Diskussion über die Prioritäten zu eröffnen und das Budget für die Lieferung zu erhalten. Die Agile Extension zum BABOK Guide ordnet sie dem Horizont Strategie zu. Ihre Referenzform stammt von Lombardo, McCarthy, Ryan und Connors, die sie auf den angestrebten Ergebnissen des Produkts und auf unterschiedlich breiten Balken aufbauen.
Ziel
Die Produkt-Roadmap ist das Dokument, in dem eine Organisation auf einer Seite liest, was ihr Produkt werden soll, in welcher Reihenfolge und mit welcher Sicherheit. Jede Zeile ist ein Thema, also eine Menge von Funktionalitäten oder Anforderungen, die demselben angestrebten Ergebnis dienen; jede Spalte ist ein Zeitabschnitt. Die Agile Extension gibt ihr den Zweck, die eingeschlagene Richtung auf die Vision der Lösung hin zu kommunizieren und den Fortschritt auf diese Vision hin daran zu messen, ob die angestrebten Ergebnisse der Stakeholder erreicht werden.
Die Teams führen je ihr eigenes Backlog, die Geschäftsleitung führt ihre Jahresziele, der Vertrieb verspricht im Kundentermin Funktionalitäten. Nichts bringt diese drei Listen zusammen. Die Frage, die in jeder Sitzung wiederkehrt, "Wann haben wir diese Funktionalität?", erhält dann ein Datum, das sich die antwortende Person ausdenkt. Die Roadmap setzt an die Stelle dieses Datums eine Position auf einer Achse und einen Grad an Sicherheit, der mit der Entfernung abnimmt.
Sie dient einer zweiten Entscheidung, die der Guide nennt: dem Erhalt des Budgets für die Lieferung. Ein Ausschuss, der ein Produkt über mehrere Rechnungsjahre finanziert, entscheidet über angestrebte Ergebnisse und über deren Reihenfolge, ein Stoff, den ihm eine Ticketliste nicht liefert. Die Roadmap ist die Grundlage dieser Entscheidung und danach die Referenz, an der sie überarbeitet wird; der Business Case prüft anschliessend jedes Thema für sich.
Der Liefergegenstand ist die nachgeführte Roadmap, dazu das Register der angestrebten Ergebnisse und ihrer Messgrössen. Der Guide ordnet die Technik dem Horizont Strategie zu, dem weitesten der drei Horizonte der Agile Extension.
Einsatz
Wann einsetzen
- Mehrere Teams an einem Produkt: eine einzige Richtung ersetzt so viele Pläne, wie es Teams gibt.
- Mehrjähriger Budgetantrag: der Ausschuss entscheidet über angestrebte Ergebnisse und über deren Reihenfolge.
- Vision steht fest, der Weg ist offen: die Reihenfolge der Themen wird festgelegt, ohne die Lösungen festzuschreiben.
- Stakeholder, die Termine verlangen: die Zeitabschnitte geben eine Antwort, die trägt und die sich diskutieren lässt.
- Produkt für externe Kundschaft: eine öffentliche Sicht kündigt die Richtung an, ohne eine Version zuzusagen.
- Konkurrierende Anforderungen aus mehreren Abteilungen: Themen machen sie über das angestrebte Ergebnis vergleichbar.
Wann nicht einsetzen
- Vision, die in jeder Ausschusssitzung neu verhandelt wird: das Dokument veraltet, bevor es gelesen wird; die Arbeit setzt zuerst bei der Vision selbst an.
- Vertragliche Verpflichtung auf Termine und Umfang: ein Terminplan und eine verbindliche Schätzung beantworten die Anfrage.
- Ein Team, ein Produkt, ein Horizont von drei Monaten: Backlog-Management genügt, um die Reihenfolge zu halten.
Beschreibung
Zwei Formate für denselben Inhalt
Eine Roadmap nimmt zwei Formen an und die Agile Extension verwendet beide, ohne sie zu unterscheiden. Ihr Text beschreibt Funktionalitäten, ausgedrückt als "jetzt, als Nächstes, später"; ihre Abbildung 7.10.1 legt ein Raster aus vier Quartalen an, in dem jede Fähigkeit ein Feld belegt, eines davon in drei Segmente geteilt, verteilt auf das erste, das zweite und das vierte. Die Wahl zwischen diesen beiden Formaten legt fest, was die Leserschaft verlangen kann.
Das kalendarische Format teilt die Achse in Quartale oder Halbjahre. Ein Ausschuss, der an Rechnungsjahre gewöhnt ist, liest es ohne Erklärung und es passt zum Finanzierungszyklus. Der unterschiedlich breite Balken, der über zwei Spalten der Skala reicht, stammt von Lombardo, McCarthy, Ryan und Connors, deren Product Roadmaps Relaunched die Referenzform festlegt.
Das Format jetzt, als Nächstes, später teilt die Achse in drei Spalten abnehmender Sicherheit. Die erste ist zugesagt und finanziert, die zweite ist umrissen, aber nicht terminiert, die dritte ist eine Absicht, welche die nächste Messung umstossen kann. Keine Spalte trägt ein Datum und dem Ausschuss fehlt der Bezugspunkt für das Budget.
Beide Formate tragen denselben Inhalt. Der Übergang von den Quartalen zu den drei Spalten verliert nichts; umgekehrt zwingt er dazu, Termine zu setzen. Nur das kalendarische Format wird im Guide abgebildet.
Produkt-Roadmap
Derselbe Inhalt, in drei Spalten
Jetzt
· zugesagt und finanziert
Ein Konto eröffnen, ohne in die Filiale zu gehen
- Identifikation per E-ID
- Qualifizierte elektronische Signatur
- Übernahme der Daten bestehender Kundinnen und Kunden
Als Nächstes
· umrissen, nicht terminiert
Bezahlen, ohne die App zu verlassen
(QR-Rechnungen und eBill)
Online beraten im Rahmen des FIDLEG
(Risikoprofil online)
Später
· Absicht
Sparen, ohne daran zu denken
Sofortzahlung zwischen Kundinnen und Kunden
Die Elemente
Vision und Strategie eröffnen das Dokument. Die Vision sagt, was die Lösung abdeckt und welches Ergebnis sie anstrebt; sie ist es, die nach dem Guide klärt, was in den Umfang fällt. Die Strategie sagt, auf welchem Weg die Organisation dorthin gelangen will. Eine Liste der abgelehnten Anforderungen, neben dem Dokument geführt, benennt, worauf die Organisation verzichtet. Partner und Kundschaft suchen diese zweite Liste ebenso wie die erste.
Die angestrebten Ergebnisse werden für die Organisation und für die Stakeholder benannt. Lombardo und seine Mitautoren machen das gemessene Ergebnis zum Gerüst des Dokuments: Ein Ergebnis wird mit seiner Messgrösse, seinem Ausgangswert und seinem Zielwert formuliert, "Anteil der ohne Filialbesuch abgeschlossenen Kontoeröffnungen, von 12% auf 45%". Die Messgrösse erlaubt es, im Nachhinein festzustellen, ob das gelieferte Thema gebracht hat, was von ihm erwartet wurde. Ohne sie bleibt ein Thema eine Absicht und sein Fortschritt wird als Prozentsatz des geschriebenen Codes berichtet.
Das Produktmanagement-Team führt das Dokument. Der Guide beschreibt es als klein, geleitet vom Product Owner oder von einer Vertretung der Kundschaft. Er überträgt ihm drei Pflichten: die aktuellen Prioritäten abzubilden, die Sicht auf das jeweilige Publikum abzustimmen und für alle zugänglich zu bleiben, die das Dokument brauchen. Dieses Team ist die benannte verantwortliche Stelle; ohne diesen Namen bleibt die Überarbeitung im zweiten Quartal stehen.
Die Themen sind die Zeilen. Ein Thema fasst Anforderungen, Funktionalitäten oder User Stories zusammen, die demselben Ergebnis dienen. Lombardo und seine Mitautoren lassen es nach diesem Ergebnis benennen: "Ein Konto eröffnen, ohne in die Filiale zu gehen" steht auf einer Zeile und spricht einen Ausschuss an.
Die übergeordneten Anforderungen füllen die Themen. Jede von ihnen fasst Anforderungen oder Stories zusammen, aus denen das Lieferteam sein Backlog zieht. Ihre Granularität nimmt mit der Entfernung ab: Ein Thema aus der Spalte des Zugesagten wird in drei oder vier benannten Elementen beschrieben, ein weit entferntes Thema steht in einem Satz.
Das Rahmenwerk SAFe unterscheidet die Roadmap des Program Increments, jene des Produkts oder der Lösung und jene des Portfolios, je von einem anderen Gremium geführt und über eine andere Dauer. Die Produkt-Roadmap entspricht der Ebene Produkt oder Lösung; die Portfoliosicht gehört zum Portfolio Kanban, das zeigt, in welcher Etappe jede beauftragte Initiative steht.
Wie sie entsteht
Die Reihenfolge zählt: Jeder Schritt nimmt das Ergebnis des vorangehenden als Eingabe. Zuerst wird die Vision in einem Satz geschrieben, dem eine aussenstehende Person widersprechen kann. Danach werden die angestrebten Ergebnisse benannt, drei bis sechs, jedes mit seiner Messgrösse, seinem erhobenen Ausgangswert und seinem Zielwert.
Dann werden die bestehenden Anforderungen gruppiert, Backlog, Support-Tickets, vertriebliche Zusagen und regulatorische Auflagen, jede einem Ergebnis zugeordnet. Eine Anforderung, die sich keinem Ergebnis zuordnen lässt, eröffnet zwei Möglichkeiten: Entweder fehlt das Ergebnis in der Liste, oder die Anforderung gehört nicht zum Produkt. Die so gewonnenen Themen werden geordnet, durch Priorisierung oder durch eine gewichtete Abstimmung des Ausschusses, und auf der gewählten Achse platziert.
Zu bestimmen bleiben die Kadenz der Überarbeitung und der Name der Person, die das Dokument führt. Eine Überarbeitung pro Quartal, vor dem Budgetentscheid, genügt den meisten Produkten. Die Roadmap trägt ihr Überarbeitungsdatum offen, was verhindert, dass eine neun Monate alte Kopie zirkuliert, als gälte sie noch.
Eine Roadmap, mehrere Sichten
Der Guide zählt die Sicht je Publikum zu den Stärken der Technik: Geschäftsleitung, Lieferteam und externe Kundschaft lesen dasselbe Dokument in drei Detailstufen. Die drei Sichten werden aus einer einzigen Quelle abgeleitet. Parallel gepflegt, laufen sie binnen eines Quartals auseinander und die Organisation hat am Ende drei Richtungen.
| Publikum | Frage, welche die Sicht beantwortet | Inhalt | Verbreitung |
|---|---|---|---|
| Geschäftsleitung | Wofür binden wir das Budget des nächsten Rechnungsjahres? | Die Themen, ihr angestrebtes Ergebnis mit seiner Messgrösse, das Budget je Thema, die Quartalsspalten. | Eine datierte Folie, bei jeder Überarbeitung im Quartal. |
| Lieferteam | Was bereiten wir nach der zugesagten Arbeit vor? | Dieselben Themen, aufgeschlüsselt in übergeordnete Anforderungen, mit den Abhängigkeiten zwischen den Teams und den bekannten technischen Einschränkungen. | Das Arbeitsdokument, laufend nachgeführt. |
| Kundschaft und Partner | Geht das Produkt in die Richtung, die ich brauche? | Die Themen und ihre Reihenfolge, ohne Budget, ohne interne Abhängigkeiten und ohne Termin über die Spalte des Zugesagten hinaus. | Eine veröffentlichte Seite, vor jeder Verbreitung durchgesehen. |
Woran die Technik scheitert
Das Quartal als Termin gelesen
Die Verpflichtung auf weit entfernte Termine ist der erste Fehlermodus, den Lombardo und seine Mitautoren dokumentieren, und der Guide nennt dieselbe Grenze: Die Technik wird zum Meilensteinkalender umgedeutet. Ein Thema, das auf dem dritten Quartal liegt, wird im Protokoll zu "Lieferung im September" und danach zu einer Zusage in einem Kundenbrief. Zwei Ergänzungen im Dokument begrenzen die Abweichung: eine Angabe des Sicherheitsgrads je Spalte und das Datum der letzten Überarbeitung. Das dritte Gegenmittel ist eine Praxis: Die erste Überarbeitung, die ein Thema von einem Quartal in ein anderes verschiebt, vor demselben Ausschuss vollzogen, lehrt die Leserschaft, was eine Platzierung wert ist.
Die Vision, die sich jeden Monat ändert
Der Guide bezeichnet die Technik dort als unwirksam, wo Vision und angestrebte Ergebnisse in jeder Ausschusssitzung neu verhandelt werden. Die Roadmap wird dort öfter neu erstellt als gelesen, weil die Ursache dem Dokument vorgelagert ist und kein Format sie behebt.
Das Detail, das die Pflege verunmöglicht
Der Guide weist auf die Pflegekosten einer zu detaillierten oder in zu viele Sichten aufgeteilten Roadmap hin. Ein Thema steht auf einer Zeile und ist aus drei Metern Entfernung lesbar. Sobald eine Zeile eine Ticketliste trägt, gehört der Inhalt ins Backlog und die Roadmap hat begonnen, es zu doppeln. Über drei Sichten hinaus kommt ein Produktmanagement-Team von zwei oder drei Personen nicht mehr nach.
Das nach dem Bauteil benannte Thema
"Migration auf das neue Zahlungs-Gateway" benennt ein internes Vorhaben. Der Ausschuss kann darüber nicht entscheiden, weil ihm ein Ergebnis zum Vergleich fehlt, und nimmt es auf den Ruf der vortragenden Person hin an oder lehnt es ab. Dieselbe Arbeit, "Bezahlen, ohne die App zu verlassen" genannt und mit einer Messgrösse versehen, tritt in den Vergleich mit den anderen Themen ein.
KI-Überlegungen
Ein Sprachmodell dient dieser Technik bei grossen Mengen. Auf einem Export des Backlogs und der Support-Tickets schlägt es Gruppierungen nach Absicht vor und lässt erkennen, welche Themen infrage kommen, eine Arbeit, die ein Team sonst in Workshops über mehrere Halbtage führt; der Vorschlag wird gegengelesen, aber er geht von einem Stoff aus, den niemand vollständig gelesen hätte. Es erkennt Themen ohne Messgrösse, Messgrössen ohne erhobenen Ausgangswert und Anforderungen, die keinem Ergebnis zugeordnet sind. Es vergleicht zwei aufeinanderfolgende Fassungen der Roadmap und listet auf, was sich bewegt hat, was die Traktandenliste der Überarbeitung vorbereitet. Aus einer einzigen Quelle leitet es neben der Sicht für die Geschäftsleitung eine Kundensicht ab und entfernt dabei, was nicht nach aussen gehen darf; gegengelesen wird trotzdem.
Die Reihenfolge der Themen wird nicht bei einem Modell erfragt. Sie hängt von bereits eingegangenen Zusagen ab, von einem Kräfteverhältnis zwischen Abteilungen, von einer regulatorischen Frist und von der Kapazität der Teams; nichts davon steht im vorgelegten Dokument. Die Platzierung auf einer Spalte fällt unter dieselbe Grenze: Ein Modell, das ein Thema datieren soll, liefert ein plausibles Quartal ohne Kapazität dahinter. Die Zielwerte der angestrebten Ergebnisse werden mit denen ausgehandelt, die sie halten müssen. Eine Roadmap trägt unangekündigte Markteintritte, Lieferantennamen und Budgetbeträge: Diese Angaben werden entfernt, bevor etwas an ein öffentliches Modell geht.
Beispiele
Das Produktmanagement-Team einer Kantonalbank führt die Roadmap ihrer Mobile-Banking-App, die vierteljährlich von der Leitung des Privatkundengeschäfts durchgesehen wird. Das Format ist das kalendarische Format über vier Quartale.
Produkt-Roadmap
Kantonalbank, Mobile-Banking-App
Vier Themen tragen vier Ergebnisse und die Balken fluchten nicht. Die Kontoeröffnung schreitet in zwei Etappen über die ersten beiden Quartale voran; die Online-Beratung im Rahmen des FIDLEG liegt auf dem zweiten; das Bezahlen belegt einen Balken über dem zweiten und dritten Quartal und setzt im vierten wieder ein; das Sparen erscheint erst im vierten, als Pilot. Genau diese Unregelmässigkeit zeigt eine Roadmap: Die Themen haben unterschiedliche Grössen und die Sicherheit fällt nach rechts hin ab.
Das Register der Ergebnisse wird neben der Roadmap geführt. Der Ausschuss liest es bei jeder Überarbeitung Thema für Thema nach.
| Thema | Angestrebtes Ergebnis und Messgrösse | Ausgangswert | Zielwert | Budget |
|---|---|---|---|---|
| Ein Konto eröffnen, ohne in die Filiale zu gehen | Anteil der online zu Ende geführten Kontoeröffnungen | 12% | 45% | CHF 1'850'000 |
| Bezahlen, ohne die App zu verlassen | Anteil der aus der App bezahlten QR-Rechnungen und eBill-Rechnungen | 31% | 70% | CHF 940'000 |
| Online beraten im Rahmen des FIDLEG | Aktuell gehaltene Risikoprofile bei Kundinnen und Kunden mit Wertschriftendepot | 54% | 95% | CHF 620'000 |
| Sparen, ohne daran zu denken | Kundinnen und Kunden mit automatisch gespeistem Sparziel | 0 | 8'000 | CHF 210'000 |
Die Spalte des Ausgangswerts fehlt am häufigsten. Ein erhobener Ausgangswert macht aus der nächsten Überarbeitung eine überprüfbare Feststellung.
Visualisierungen
Die Roadmap wird in Zeilen und Spalten gezeichnet: eine Zeile je Thema, am Kopf ihr Ergebnis und ihre Messgrösse, eine Spalte je Quartal. Jeder Balken deckt die Quartale ab, die sein Thema belegt, wobei einer von ihnen von einem Quartal ins nächste hinüberreichen kann. Ein Verlauf oder eine leichtere Kontur auf den rechten Spalten macht die abnehmende Sicherheit sichtbar. Das Datum der letzten Überarbeitung und der Name des Teams, das das Dokument führt, stehen auf der Abbildung selbst, denn diese gerät in Umlauf.
Das Format mit drei Spalten wird als drei Kartenspalten gezeichnet, ohne Zeitskala, wobei allein die linke Spalte Detail trägt. Das Ergebnisregister liest sich als Tabelle, eine Zeile je Thema.
Aufwand
| Phase | Niveau | Begründung |
|---|---|---|
| Vorbereitung | Hoch | Die Einigung auf die Vision und auf die angestrebten Ergebnisse bindet die Geschäftsleitung und die Fachbereiche über mehrere Sitzungen. Die Gruppierung der bestehenden Anforderungen zu Themen setzt voraus, dass das Backlog und die eingegangenen Zusagen nachgelesen werden. |
| Durchführung | Gering | Eine Überarbeitung je Quartal von ein bis zwei Stunden, mit Teilnehmenden, die der Budgetentscheid ohnehin versammelt. |
| Dokumentation | Mittel | Das Dokument ist kurz. Der Aufwand liegt beim Erheben der Messgrössen bei jeder Überarbeitung und beim Ableiten der Sichten je Publikum. |
Werkzeuge
Die Wand bleibt das Werkzeug der Sitzung, in der die Roadmap entsteht: mit Klebeband gezogene Spalten, eine Karte je Thema, eine Verschiebung, die während der Diskussion möglich ist. Sie setzt ein an einem Ort versammeltes Team voraus und bringt nichts hervor, was zirkuliert.
Die kollaborativen Whiteboards (Miro, Mural und ihre Entsprechungen) übernehmen dieselbe Rolle für ein Team, das über mehrere Standorte verteilt ist. Für die Verbreitung taugen sie schlecht, weil die gelegentliche Leserschaft kein grenzenloses Board öffnet, um darin eine Zeile zu suchen.
Tabellenkalkulation und Präsentation tragen die Mehrheit der Roadmaps im Einsatz. Sie liefern ohne Kosten eine Sicht für die Geschäftsleitung, die auf eine Folie passt. Ihre Schwäche ist die Kopie: Eine Folie geht per E-Mail hinaus, verliert ihr Überarbeitungsdatum und zirkuliert danach für sich selbst. Das Überarbeitungsdatum in der Fusszeile zu sperren, begrenzt den Schaden.
Die Produktmanagement-Werkzeuge (ProductPlan, Aha!, Roadmunk, Jira Product Discovery und ihre Entsprechungen) verknüpfen die Themen mit den Items des Backlogs und erzeugen aus einer einzigen Quelle mehrere Sichten und begegnen damit der Grenze des Pflegeaufwands. Sie werden pro Nutzer verrechnet und verlangen, dass das Backlog bereits sauber ist.
Bleibt das Werkzeug, von dem die Messung abhängt: das System, das die Kennzahlen erzeugt, Messungen der Produktnutzung oder ein Dashboard für die Entscheidungsunterstützung. Ein angestrebtes Ergebnis, das niemand vierteljährlich zu messen weiss, lässt die Roadmap ohne Mittel, ihre eigene Wirkung festzustellen.
Quellen
- IIBA, Agile Extension to the BABOK Guide, §7.10 Product Roadmap: der Zweck der Technik, die fünf Elemente, darunter das Produktmanagement-Team und die Themen, die genannten Stärken, darunter die Sichten je Publikum, die drei Grenzen und die Zuordnung zum Horizont Strategie. Abbildung 7.10.1 gibt das kalendarische Format, ein Raster aus vier Quartalen, in dem jede Fähigkeit ein Feld belegt.
- C. Todd Lombardo, Bruce McCarthy, Evan Ryan, Michael Connors, Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty, O'Reilly Media, 2017: die Roadmap als Aussage über die Richtung, das auf den angestrebten Ergebnissen und auf einer Zeitachse aufgebaute Format, der unterschiedlich breite Balken über mehrere Spalten, das nach seinem Ergebnis benannte Thema sowie die dokumentierten Fehlermodi, an erster Stelle die Verpflichtung auf weit entfernte Termine und Funktionalitäten.
- Scaled Agile Framework, Roadmap: die Ausprägung der Technik auf mehreren Ebenen, jener des Program Increments, jener des Produkts oder der Lösung und jener des Portfolios.