Wir sind uns einig, dass die Entwicklung von Features nicht den Beginn eines Entwicklungsvorhabens darstellen sollte.
Die Produktentwicklung sollte mit der strategischen Überlegung beginnen: Welche Ergebnisse wollen die Nutzer mit der Verwendung unseres Produkts erzielen? Allerdings entspricht dieses Vorgehen häufig noch nicht der Realität. Wie können wir das ändern? Indem wir die Produktstrategie nicht mehr in einer Feature-Roadmap ausdrücken, sondern in einer auf Outcome basierenden Roadmap.
Wenn du weiterliest, erfährst du, wie du in 6 Schritten deine Feature-Roadmap in eine outcomebasierte Roadmap transformieren kannst. Dadurch stellst du den Kundennutzen in den Vordergrund und bleibst gleichzeitig aussagekräftig gegenüber den Stakeholdern.
Schritt #1: Beginne mit dem wünschenswerten Geschäftsergebnis
Der Weg zu einer Outcome-basierten Roadmap beginnt der richtigen Anwendung des Logic Model.
Wir verwenden dieses Wirkmodell nicht wie herkömmlich von links nach rechts, sondern von rechts nach links.
Als Erstes musst du die Frage beantworten: „Welches Geschäftsergebnis soll das Produkt vorantreiben?“
Das Geschäftsergebnis – der Impact – ist das Ergebnis, welches das Unternehmen mit der Entwicklung des Produkts erreichen will. Es könnte 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: Beschreibe die Outcomes für die Nutzer
Das ist häufig sehr schwierig.
Mein Tipp lautet deshalb: Schau dir an, wie die Nutzer das Produkt heute verwenden. Wenn es noch kein Produkt gibt, dann schaue dir an, wie potenzielle Nutzer ihr Ergebnis momentan erreichen.
Erarbeite dazu die Kontaktpunkte deiner Kunden mit deinem Produkt oder Service. Gehe durch alle Phasen des Produkts und halte in Gelb fest, wie Nutzer mit dem Produkt interagieren oder welche Dinge sie unternehmen, um ihr Ergebnis zu erreichen. Die Übersicht stellt jetzt ein sehr einfaches Modell dar, wie die Nutzer das Produkt verwenden.
Markiere 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: Priorisiere die Outcomes
Der nächste Schritt besteht darin, die Outcomes zu priorisieren. Was sind die Verhaltensweisen, die wir von Nutzern im nächsten Jahr vermehrt sehen wollen, welche wollen wir vermindert sehen und in welcher Reihenfolge soll daran gearbeitet werden?
Hier ein Beispiel: Ein Unternehmen tut sich schwer, Mitarbeiter im Bereich künstliche Intelligenz (KI) zu finden. Die Zusammenarbeit mit der HR-Abteilung gestaltet sich für die Fachabteilungen frustrierend. Die priorisierten Outcomes könnten wie folgt lauten:
- HR-Mitarbeiter finden häufiger passende Kandidaten beim ersten Screening des Bewerberprofils
- Kürzere Antwortzeit bei Rückfragen zu den offenen Stellen
- Mehr Mitarbeiter werben ihre Bekannten und Freunde
- Die Fachabteilung führt mehr Fachinterviews durch
Schritt #4: Erstelle 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 bist du jederzeit 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 es zu beantworten gilt.
Schritt #5: Formuliere 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 müssen wir 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 wie folgt 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 Produktteams, die Entdeckungs- und Entwicklungsarbeit durch die Outcomes für Nutzer voranzutreiben.
Schritt #6: Fortschritte messbar machen
Wie viel Outcome ist genug, um das Geschäftsergebnis zu verbessern und wann ist ein Outcome erreicht?
Hier liegt die Wurzel des Problems, warum es herausfordernder 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 leicht feststellen.
Orientieren wir uns aber an Outcomes, haben wir es mit einem 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.
Letztlich 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.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für dich. Wie du du mit Outcomes und Roadmaps arbeitest, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.