Roadmaps - Fokussierung auf Ergebnisse - Keine Roadmap überlebt die Realität

Sie wird immer wieder gefordert und sorgt in Unternehmen häufig für Stress, Druck und Enttäuschung. Und trotzdem will keiner darauf verzichten.

Die Gründe liegen auf der Hand: Eine Roadmap gibt Struktur und Transparenz, zwingt das Produktteam und die Firma zur Planung, Priorisierung und Abstimmung mit den Stakeholdern, zeigt die Absicht und Richtung der Produktentwicklung auf und kann Stakeholder und User begeistern.

Warum also gibt es so häufig eine Diskrepanz zwischen Intention und Ausgang?

Es treffen immer wieder unterschiedliche Ansprüche und Sichtweisen, was eine Roadmap leisten soll, bei denen es schwer ist, diese in Einklang zu bekommen.

Allen voran ist es meist der Produktmanager /  Owner der die Roadmap erstellt und damit die Ausrichtung und nächsten Schritte des Produktes definiert.  Gerade im agilen Umfeld ist das Produkt meist nicht bis ins Detail ausdefiniert, sondern es ändern sich auch mal kurzfristig die Prioritäten und es wird auf Kunden-Feedback reagiert, welches die Weiterentwicklung des Produktes maßgeblich beeinflussen kann und sollte. Außerdem gibt es immer wieder technische Hürden, aufgrund von alten technischen Schulden oder des Einsatzes von nicht bekannten Technologien. Deshalb ist es eine Herausforderung eine Planung zu erstellen, mit der die Stakeholder abgeholt werden können und nicht zu viel versprochen wird.

Stakeholder haben ein berechtigtes Interesse an einer Roadmap, denn sie wollen selbst auch planen oder zumindest auf dem aktuellen Stand sein, um die Ausrichtung und die Priorisierung gegebenenfalls zu beeinflussen. Sie selbst haben ihre eigene Agenda und Ziele, die nicht unbedingt mit der Roadmap des Produktmanager übereinstimmen und können diese deshalb, werden Sie nicht entsprechend abgeholt, blockieren anstatt zu unterstützen. In manchen Fällen ist einer der Stakeholder so stark, dass die Roadmap mehr durch diesen vorgegeben wird, anstatt dass sie mit diesem abgestimmt wird.

Zusätzlich möchten Stakeholder und auch User gerne wissen, mit welchem Feature zu welchem Zeitpunkt gerechnet werden kann.

Wird also den Wünschen oder Forderungen der Stakeholder und User komplett nachgekommen, dann würde der Produktmanager die Reihenfolge von Features auflisten und mit einem Datum versehen. Voraussichtlich würden dann die meisten Lieferdaten gerissen, Features werden plötzlich ganz gestrichen oder geändert und die Richtung des Produktes ändert sich alle paar Wochen. Die User und Stakeholder sind enttäuscht und verlieren das Vertrauen in das Produktteam, während das Produktteam nicht eigenständig und kundenzentriert arbeiten kann und stets unter enormen Druck steht.

C. Todd Lombardo, Autor des O'Reilly Buches “Product Roadmaps Relaunched”, stellt eine Struktur vor, die im agilen Umfeld meiner Meinung nach eine Lösung sein kann. Denn im Fokus stehen nicht Features und genaue Zeiträume, sondern die lieferbaren Werte, die auf die Vision und Unternehmensziele einzahlen und deren Priorisierung.

Die Struktur sieht folgendermaßen aus:

Die Produktvision ist das Ziel bzw. der angestrebte Kundennutzen, der mit diesem Produkt erreicht werden soll. Sie sollte als Wegweiser in jeder Roadmap vorhanden sein und ist im Zuge der Roadmap nicht verhandelbar.

Z.B. We want to provide with our agent platform the perfect service experience for our customers worldwide.

Mit der Zuordnung zu Unternehmenszielen wird sehr plakativ deutlich, auf welche Unternehmensziele das Produkt bzw. die priorisierten Themen einzahlen, also warum die ausgewählten Themen auf der Roadmap stehen. Die Anzahl der Objectives hängt natürlich von der Größe des Produktes und des Teams ab. Falls die Firma bereits mit OKRs arbeitet, dann macht es Sinn, genau die Objectives auch in der Roadmap zu verwenden.

Z.B. ensure product quality oder ensure a better matching between sellers and buyers.

Zeiträume wie Wochen, Quartale oder einfach mit der Bezeichnung “now”, “next” and “later” bieten Orientierung bei gleichzeitiger Wahrung der Flexibilität. Es wird aufgezeigt, worauf sich kurzfristig konzentriert wird und was grundsätzlich geplant ist, aber noch warten muss.

Auch eine Kombination von eher spezifischen kurzfristigen Zieldaten mit anschließend größer werdenden Zeiträumen ist möglich.

Die Themen umreißen den Lösungsansatz, der eine Möglichkeit ist, ein entsprechendes Kundenbedürfnis oder Ziel zu erreichen. Es muss darauf geachtet werden, dass nicht das Feature aufgelistet wird, sondern tatsächlich das Ziel, was damit erreicht werden soll. Für kurzfristige Zeiträume kann man überlegen, ob man die Features zusätzlich aufführt, aber es sollte die Roadmap nicht verkomplizieren oder unübersichtlich erscheinen lassen.

Z.B. stärkeres Monitoring der WebApp für proaktives Fehlermanagement oder Anzeige individueller Informationen zu möglichen Gemeinsamkeiten der Kunden

Der Disclaimer schützt alle Seiten vor falschen Versprechungen und Erwartungen. Wenn klar ist, dass die Roadmap nur ein Wegweiser ist, sich aber ändern kann und voraussichtlich auch wird, dann kann sich jeder darauf einstellen.

Z.B. The following represents xxx current view of its product development cycle and future directions. It is intended for information purposes only, and should not be interpreted as a commitment on the part of xxx. xxx makes no warranties, express or implied, in this roadmap.

Alles in Allem ermöglicht diese Struktur transparent zu sein, ohne sich in Details zu verlieren und Versprechen zu machen, die nicht eingehalten werden können. Der Verzicht, Features anzukündigen, sondern stattdessen Ziele, ist hier essentiell. Denn es ist recht wahrscheinlich in der Produktarbeit ein Features zu verändern, umzupriorisieren oder zu streichen, während die Ziele seltener geändert werden.

Trotzdem wird das Einführen einer solchen Roadmap nicht einfach sein. Es muss Vertrauen der wichtigsten Stakeholder vorhanden sein, dass diese Roadmap kein Verschleierungsversuch ist und das Produktteam trotzdem Outcome liefern wird und zwar in den Zeiträumen, die genannt sind.  

Mit einem längeren Versuch kann der Produktmanager mit der  Zeit lernen, wie die Komponenten am Besten gefüllt und formuliert werden, diesen Ansatz testen und schauen, ob dieser tatsächlich für weniger Frustration am Ende sorgt.