Von der Feature-Roadmap zur Outcome-Roadmap

Nicht die Features entscheiden über den Erfolg eines Produkts, sondern die Outcomes, die damit erzielt werden.

Diese Outcomes sollten auch die Roadmap eines Produkts widerspiegeln. Allerdings treffe ich in meiner Arbeit mit erfahrenen agilen Produktmanagern noch häufig auf Roadmaps, die nur Features enthalten. Um das zu ändern, haben sich für mich die folgenden 6 Schritte bewährt. Sie geben eine konkrete Anleitung, wie auch Sie Ihre Feature-Roadmap in eine outcomebasierte Roadmap transformieren können. Dadurch stellen Sie den Kundennutzen in den Vordergrund und bleiben gleichzeitig aussagekräftig gegenüber den Stakeholdern.

Schritt #1: Beginnen Sie mit dem gewünschten Geschäftsergebnis

Der Weg zu einer outcomebasierten Roadmap beginnt mit der richtigen Anwendung des Logic Models.

Wir verwenden dieses Wirkmodell nicht wie herkömmlich von links nach rechts, sondern von rechts nach links.

Als Erstes müssen Sie die folgende Frage beantworten: „Welches Geschäftsergebnis soll das Produkt erzielen?“

Das Geschäftsergebnis – der Impact –  ist das Ergebnis, welches das Unternehmen mit der Entwicklung des Produkts erreichen will. Es könnten etwa die Verbesserung des Net Promoter Scores, die Steigerung der Retention Rate, die Reduzierung der Abwanderungsrate oder die Steigerung des Umsatzes sein.

Nachdem ein Geschäftsergebnis definiert wurde, geht es nun darum, die Verhaltensweisen der Nutzer und Kunden zu identifizieren, die zu diesem Geschäftsergebnis beitragen. Messbare Verhaltensweisen der Nutzer, welche die Geschäftsergebnisse beeinflussen, bezeichnen wir als Outcome. Deshalb ist der nächste Schritt:

Schritt #2: Beschreiben Sie die Outcomes für die Nutzer

Das ist häufig sehr schwierig.

Mein Tipp lautet deshalb: Schauen Sie sich an, wie die Nutzer ihr Produkt momentan verwenden. Wenn es noch kein Produkt gibt, dann schauen sie sich an, wie und mit welchen Hilfsmitteln potenzielle Nutzer ihr Ziel gerade erreichen.

Erarbeiten Sie dazu die Kontaktpunkte der Kunden mit Ihrem Produkt oder Service. Gehen Sie durch alle Phasen des Produkts und halten Sie in Gelb fest, wie die Nutzer mit dem Produkt interagieren oder welche Dinge sie unternehmen, um ihr Ergebnis zu erreichen. Diese Übersicht stellt jetzt ein sehr einfaches Modell dar, wie die Nutzer das Produkt verwenden.

Markieren Sie nun in Rot die Dinge, die dazu führen, dass die Nutzer unglücklich sind oder das Produkt ein Fehlschlag werden könnte, und in Grün die Dinge, die dazu führen, dass die Kunden glücklich sind und das Produkt ein Erfolg werden könnte.

Die Erfahrungen, die Nutzer machen, die sie glücklich und unglücklich stimmen, das sind die Outcomes!

Schritt #3: Priorisieren Sie die Outcomes

Der nächste Schritt besteht darin, die Outcomes zu priorisieren. Was sind die Verhaltensweisen, die Sie von Nutzern im nächsten Jahr vermehrt sehen wollen? Welche Verhaltensweisen möchten Sie verringern und in welcher Reihenfolge soll daran gearbeitet werden?

1. HR-Mitarbeiter finden häufiger passende Kandidaten beim ersten Screening des Bewerberprofils.
2. Kürzere Antwortzeit bei Rückfragen zu den offenen Stellen.
3. Mehr Mitarbeiter werben ihre Bekannten und Freunde.
4. Die Fachabteilung führt mehr Fachinterviews durch.

Schritt #4: Erstellen Sie eine Roadmap für eineinhalb Jahre

Die priorisierten Outcomes stellen nun das Rückgrat der outcomebasierten Roadmap dar.

Hierbei gilt es zu beachten, dass der Zeithorizont der Planung immer die nächsten sechs Quartale umfassen sollte. So sind Sie zu jeder Zeit in der Lage, Jahresprognosen gegenüber Stakeholdern aus der Budget- und Finanz-, Projektmanagement- oder HR-Abteilung abzugeben.

Die Features, die sich auf der alten Feature-Roadmap befanden, können jetzt zu passenden Outcomes zugeordnet werden. Hierbei sollten nur Features zu Outcomes zugeordnet werden, welche sich in der nahen Zukunft befinden. In der fernen Zukunft sollten hingegen keine Features auf der Roadmap zu sehen sein. Da bei der Produktentwicklung die Zukunft von Unsicherheit geprägt ist, sollten dort eher offene Fragen oder Problemstellungen zu finden sein, welche Sie noch beantworten müssen.

Schritt #5: Formulieren Sie erste Hypothesen

Das Problem mit Wirkmodellen ist, dass sie suggerieren, dass es einen offensichtlichen Zusammenhang zwischen Feature und Outcome gibt.

Diesen Zusammenhang vorab vorherzusagen, funktioniert nur in den wenigsten Fällen. Meist sind Zusammenhänge erst im Nachhinein erklärbar. Deshalb sollten Sie die Verbindungspfeile im Logic Model als Hypothesen begreifen. Die Features, die entwickelt werden können, sind erst einmal Annahmen darüber, wie ein Outcome beim Nutzer erzielt werden kann. Diese Annahmen müssen mit Experimenten getestet werden. Eine Hypothese könnte etwa folgendermaßen lauten:

Wir glauben, dass die Fachabteilung den Wert der HR-Abteilung mehr schätzt, wenn HR-Mitarbeiter häufiger passende Kandidaten beim ersten Screening des Bewerberprofils finden. Dies wird ihnen möglich sein, wenn sie einen Übersichtskurs im Maschinellen Lernen (ML) und KI besucht haben.

Die Hypothesen entstehen bei dem Versuch, die Fragen auf der Roadmap zu beantworten. Das konkrete Formulieren von Hypothesen ermöglicht es nun den Produktteams, die Entdeckungs- und Entwicklungsarbeit durch die Outcomes für Nutzer voranzutreiben.

Schritt #6: Machen Sie die Fortschritte messbar

Wie viel Outcome ist genug, um das Geschäftsergebnis zu verbessern, und wann ist ein Outcome erreicht?

So lauten die häufigsten Fragen in meinem Professional Scrum mit UX-Training. Hier liegt auch die Wurzel des Problems, warum es eine größere Herausforderung ist, mit Outcomes zu arbeiten, und weshalb viele davor zurückschrecken. Die Messung des Erfolgs von Features, also dem Output der Entwicklung, ist einfach. Die Antwort ist binär. Hat das Team das Feature pünktlich auf den Markt gebracht? Innerhalb des Budgets? Das ist leicht zu messen und lässt sich problemlos feststellen.

Orientieren wir uns aber an den Outcomes, haben wir es mit einem breiten Spektrum von möglichen Ergebnissen zu tun. Haben wir die Antwortzeit bei Rückfragen um 50 % reduziert? Was ist, wenn sie bis heute nur um 38 % reduziert werden konnte? Ist das gut oder schlecht? Ich glaube, wir können dies vorab nicht immer genau festlegen. Wir sollten besser die Entscheidungen auf der Grundlage der gewonnenen Erkenntnisse treffen, die wir über die Zeit sammeln. Hierbei handelt es sich auch um Hypothesen, die formuliert werden müssen:

Wir glauben, dass die Reduzierung der Antwortzeit bei Rückfragen um 50 % dazu führt, dass die Fachabteilung mit der Arbeit der HR-Abteilung um 25 % zufriedener ist.

Zusammenfassend ist der Grundgedanke einer outcomebasierten Roadmap, den Erfolg des Produktes an den Outcomes der Nutzer festzumachen, diese Outcomes als Planungsgrundlage zu nehmen und alles als Annahmen zu begreifen, die als Fragen und Hypothesen formuliert werden können.

Hinweise:

Wenn Ihnen der Beitrag gefallen hat und Sie keinen weiteren mehr verpassen wollen, dann folgen Sie Simon Flossmann auf LinkedIn. Dort erscheint jeden Montag ein neuer Artikel von ihm über agiles Produktmanagement und Scrum.

Hier finden Sie weitere Informationen rund um das Thema Roadmap.

Simon Flossmann hat zwei weitere Beiträge im t2informatik Blog veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.