Kann man Businesswert messen?

Seit ich mit agilen Teams arbeite, begegne ich immer wieder dem Wunsch, den zu erwartenden “Business Value” eines Features zu “messen”. Den Wunsch dahinter verstehe ich. Wäre für jedes Feature schon vor der Umsetzung absehbar, wie viel Nutzen die Organisation daraus ziehen würde, wäre Priorisierung eine triviale Aufgabe.

Schätze den Aufwand, bilde das Verhältnis von Nutzen zu Kosten, sortiere absteigend, löse auftretende Abhängigkeitsprobleme. Fertig. Gerade für Product Owner ein risikofreies Schlaraffenland, in dem jede Entscheidung zweifelsfrei begründbar wäre – eine attraktive Vorstellung.

Die Herausforderung

Jetzt können wir natürlich den Mehrwert eines Features, dessen Umsetzung in der Zukunft liegt, nicht objektiv bestimmen. Er hängt von zukünftigem Handeln anderer Menschen ab und ist damit ungewiss. Vom “Messen” als objektivem Ideal sollten wir uns hier also schon einmal verabschieden. Selbst wenn wir alleine den finanziellen Nutzen betrachten und nur rückblickend aufschlüsseln, welcher Teil eines vergangenen Quartalsergebnisses auf eine konkrete Handlung unsererseits zurückzuführen sein könnte, ist das schon eine steile Aufgabe. Für “Intangibles”, wie Nachhaltigkeit, Image oder Kundenzufriedenheit, stehen wir dann erst recht vor einer ordentlichen Herausforderung. Das Ganze jetzt auch noch in eine ungewisse Zukunft hinein zu tun, kann einen zu der Aussage verleiten, dass Businesswert überhaupt nicht messbar wäre. Und das hat natürlich einige dazu gebracht, es eben doch zu versuchen.

Die meisten mir bekannten Lösungsansätze basieren mehr oder weniger auf dem gleichen Ansatz: das vorhandene Wissen im Team expliziter zu machen. Gerne werden dazu vorhandene Schätz- und Priorisierungsmethoden genutzt. Wir können Planning Poker zu “Business Value Poker” ummünzen, “Buy a Feature” spielen oder mögliche Produktfeatures in eine Vier-Felder-Matrix einsortieren. Was wir so sicher reduzieren können, ist das Gefühl von Unsicherheit bei der Entscheidung selbst. Schließlich haben wir so lange darüber diskutiert – das muss doch die richtige Entscheidung sein, oder?

Ich habe da so meine Zweifel. Letztendlich sind durch das Schätzen ja wenig neue Informationen in die Entscheidung eingeflossen. Regelmäßig werden Teams von der Tatsache kalt erwischt, dass sich ihre Kunden überhaupt nicht so verhalten, wie von ihnen angenommen. Auch dafür gibt es natürlich Erklärungsmodelle und man kann sich auf Aussagen zurückziehen wie “die Kunden wissen einfach nicht was für sie das Richtige wäre”, wahrscheinlicher ist es aber, dass das Team einfach auf Basis fehlerhafter Annahmen über die Kundenbedarfe arbeitet. 

Für mich findet ein logischer Fehlschluss schon deutlich früher statt. Aus der Tatsache, dass sich mit Wissen über den zukünftigen Businesswert alle Priorisierungsfragen beantworten lassen würden, wird umgekehrt abgeleitet, dass man für jede Priorisierung erst einmal den zukünftigen Businesswert abschätzen müsste. Das stimmt schlicht und ergreifend nicht. Natürlich lässt sich jedes Problem auf eine grundsätzlichere Fragestellung reduzieren, die schwieriger zu beantworten ist, aber das bringt uns nicht weiter. Verallgemeinerung macht die Lösung schwieriger, nicht einfacher.

Daten und Metriken

Daten und Metriken – auch über den Businesswert – sind kein Selbstzweck. Ihre Aufgabe ist es, Entscheidungen leichter zu machen. Eigentlich kann man sogar sagen: überflüssig zu machen – entscheiden kann man nach Heinz von Foerster schließlich nur das Unentscheidbare. 

Im Kern sind beim Thema Messen/Schätzen immer wieder die gleichen drei Fragen zu beantworten:

1. Welche Entscheidung ist zu treffen?
2. Welche Informationen wären geeignet, das Risiko dieser Entscheidung nennenswert zu senken?
3. Wie und woher beschaffen wir diese Informationen?

Die Crux beim Businesswert ist also, dass man ihn natürlich objektiv messen könnte, aber nur im Nachhinein, nicht in dem Moment, in dem die Entscheidung notwendig ist. Dazu kommt: Isolierte Schätzungen durch das Team führen oft nicht zu besseren Entscheidungen, weil hierbei keine neuen Informationen über die Umwelt generiert werden. Das Risiko, mit dem wir uns in einer Produktentscheidung beschäftigen sollten, steckt im Markt, nicht im Team. Um es zu senken, müssen wir neue Informationen über den Markt gewinnen, durch Beobachtung von echtem Marktverhalten heute. Das macht die Kennzahl “Businesswert” in meinen Augen mehr oder weniger wertlos. Wertvoller wäre eine Vorgehensweise, die gezielt neue Informationen über Kunden und Markt erzeugen kann und die geeignet ist, für konkrete und dringende Entscheidungen das Risiko spürbar zu senken.

Welche Entscheidung ist zu treffen?

Wenn keine Entscheidung zu treffen ist, brauchen wir auch keine Informationen. Wenn ein Feature zwingend jetzt sofort umzusetzen ist – etwa aufgrund rechtlicher Anforderungen – ist keine Entscheidung und damit auch keine Informationsbeschaffung nötig. Damit brauchen wir auch den Businesswert nicht zu bestimmen – nicht, weil es ihn nicht gäbe, sondern weil die Information für das weitere Vorgehen irrelevant ist.

Was uns im Rahmen dieses Beitrags interessiert sind Situationen, in denen wirklich eine Entscheidung notwendig ist, wenn wir also eine Auswahl aus mindestens zwei Optionen treffen müssen, die (eventuell unbekannte) Risiken aufweisen. Eine solche Situation könnte etwa sein, dass wir innerhalb eines begrenzten Zeit- und Kostenrahmens nur eine Teilmenge aller möglichen Features umsetzen können, also eine bestmögliche Auswahl treffen müssen. Oft gilt es auch Ja/Nein-Entscheidungen für einzelne Aufgaben zu treffen. 

Nicht zuletzt sollten wir uns hier schon die wesentlichen Kriterien bewusst machen, an denen sich die Entscheidung messen lassen wird. Was steht aktuell im Fokus – Kundenzufriedenheit, Umsatz, Nachhaltigkeit, Sicherheit, besseres Marktverständnis? Jeff Patton unterscheidet hier zwischen “Building to Learn” und “Building to Earn”. Diese Strategien unterscheiden sich fundamental. Handlungen, die geeignet sind, Marktreaktionen und Nachfrage besser zu verstehen, werden nicht gleichzeitig auch den Umsatz maximieren. Und welche Strategie angewendet wird, kann über Wohl und Wehe des ganzen Produkts entscheiden. “Building to Earn”, also Fokus auf wirtschaftlichen Erfolg, fährt in einem wenig verstandenen Marktumfeld schnell das ganze Projekt an die Wand. “Building to Learn” ist alleine oft nicht ausreichend, um die eigene Wirtschaftlichkeit sicherzustellen. Welchen Fokus wir also für unsere Produktentwicklung setzen, bestimmt unmittelbar mit, welche Informationen wir für Entscheidungen brauchen.

Entscheidungen zur Reduktion von Risiken

Welche Informationen wären geeignet, das Risiko dieser Entscheidung nennenswert zu senken? Steht die zu treffende Entscheidung fest, können die fehlenden Informationen eingegrenzt werden. Als Beispiel können wir uns eine Situation vorstellen, in dem ein Produkt um einen größeren Block an Funktionalität erweitert werden könnte, aber nicht klar ist, ob diese Funktionalität bei den Kunden auf Zustimmung stoßen würde. Das Risiko in der Entscheidung ist hier also einerseits, dass das Produkt ohne die Funktionalität hinter seinen Möglichkeiten zurückbleibt und früher oder später gegenüber Konkurrenzprodukten den Kürzeren zieht. Andererseits entstehen durch das Umsetzen erhebliche Aufwände, und wir riskieren, das Produkt mit Funktionalität zu verkomplizieren die gar nicht benötigt wird. Nutzer einfach mit möglichst vielen Features zu bewerfen, in der Hoffnung einen Nerv zu treffen, kann dem Anspruch an eine professionelle Produktentwicklung nicht gerecht werden.

Informationen, die uns im Beispiel interessieren könnten, wären etwa:

• Wie wichtig finden Kunden diese Funktionalität im Vergleich zu anderen Erweiterungsoptionen?
• Wie groß ist der Prozentsatz an Bestandskunden, die die neue Funktionalität als spürbaren Mehrwert empfinden würden?
• Wie viele Neukunden könnte die neue Funktionalität anziehen, wie viele Bestandskunden drohen wir dadurch zu verlieren?
• Wie müsste die neue Funktionalität ausgestaltet sein, damit ihre positiven Auswirkungen die negativen deutlich überwiegen?

Wie und woher beschaffen wir diese Informationen?

Wenn das Entscheidungsproblem sauber definiert ist, stellt sich das Erheben der relevanten Informationen oft als überraschend einfach heraus. Schließlich geht es gar nicht darum, eine umfassende, monatelange Marktstudie mit allen Bells and Whistles zu machen – wir brauchen nur so viele Informationen, um das Entscheidungsrisiko spürbar zu senken, auch wenn diese Informationen dann immer noch unscharf oder unvollständig sind.

Die Frage, wie Kunden die Wichtigkeit verschiedener möglicher Funktionalitäten im Vergleich zueinander einschätzen, lässt sich einfach dadurch beantworten, dass man die Kunden die Priorisierung selbst vornehmen lässt. Das kann bei kleinerer Zielgruppe per Umfrage oder sogar per Workshop stattfinden, Spotify und Microsoft etwa haben aber auch gezeigt wie man mit “User Voice”-Plattformen sogar mehrere hunderttausend Nutzer in die Priorisierung einbeziehen kann.

Wenn es um das tatsächliche Austesten neuer Funktionalität geht, sind Ansätze wie Nutzerstichproben oder A/B-Tests bewährte Wege. In den letzten Jahren sehe ich häufiger alte und neue Produktversionen im Parallelbetrieb, bei denen dem Nutzer die Entscheidung überlassen wird, welche der Versionen er/sie nutzen will. Daten darüber, wann Nutzer auf die neue Version wechseln, wie viele das tun und ob es häufig Wechsel “zurück” gibt sind wertvoller Input für die Weiterentwicklung des neuen Produkts.

Nicht zuletzt ist auch die Arbeit mit Prototypen und Nutzerinterviews immer noch nicht so weit verbreitet, wie sie meiner Meinung nach sein sollte. Ich biete mich hin und wieder gerne Startups als Testnutzer an und bin jedes Mal wieder beeindruckt, wie viele konkrete Ideen für die Verbesserung ihrer Produkte wir in 60 bis 90 Minuten zusammengetragen bekommen. Viele dieser Ideen sind technisch leicht umzusetzen, haben aber größere Auswirkungen darauf, ob sich der Nutzerworkflow gut durchdacht anfühlt: einen Button anders beschriften, einen fehlenden Hinweistext hinzufügen, Elemente aus dem UI entfernen die für den aktuellen Workflowschritt nicht benötigt werden. 

Businesswert kann man messen. Man sollte aber nicht.

Wie viel würde Apple heute dafür zahlen, den Business Wert der Markteinführung des ersten iPhones 2007 beziffern zu können? Die Auswirkungen dieser Entscheidung sind massiv gewesen. Sie hat einen ganzen Markt umgekrempelt, mehrere neue Märkte erschaffen und Apples Marktwert seitdem verdreißigfacht. Und der Wert dieser Information heute ist (nahezu): Null. 

In dem Moment, wo wir den Businesswert “messen” könnten, brauchen wir ihn nicht mehr, weil die Entscheidung, für die diese Information relevant wäre, schon längst gefällt worden ist. Was wir stattdessen machen sollten, ist das inhärente Risiko in unseren Produktentscheidungen bewusst zu reduzieren, indem wir am Markt und bei unseren Nutzern relevante Informationen einsammeln. Das ist eine ganz andere Fragestellung, mit direkten Auswirkungen auf die Art und Weise, wie ein Produktteam mit seinem Kontext interagiert.

Auch in der Produktstrategie stellen sich ganz andere Fragen. Zu oft begegnen mir noch aufwändige Foliensätze, in denen graphisch dargestellt wird, wie unterschiedliche Angebote “ineinandergreifen”. Wichtige Fragen, etwa welche Vorgehensweise den größtmöglichen Lerneffekt für unsere Entscheidungen erzeugen würde, werden selten beantwortet.

Kurz: Metriken zum Business Value dienen lediglich der (Selbst-)Beruhigung von Teams, Kunden und Stakeholdern und haben wenig Nutzen für das tägliche Tun. Klassische Investitionsentscheidungen, die im Vorfeld Kosten und Ertrag vollständig aufgeschlüsselt sehen wollen, passen nicht in agile Ansätze, bei denen kontinuierliche Auseinandersetzung mit Komplexität und Risiko im Vordergrund steht. Ein souveräner Umgang mit Ungewissheit in der Produktentwicklung besteht nicht im “Messen” von Business-Wert, sondern darin, durch gezielte, leicht durchführbare Tests Informationen über Kunden und Markt zu erheben, die das Risiko für Investitionsentscheidungen auf ein vertretbares Maß senken können.

Inspiriert wurde ich zu diesem Beitrag u.a. durch einen Tweet von Jutta Eckstein und das Buch “How to Measure Anything” von Douglas Hubbard.

Zur Frage, wie sinnvoll es ist, alles in Daten abbilden zu wollen, gibt es hier noch den Artikel “No Data Driven Management“.

(Das Bild ist von Lauren Donovan – vielen Dank!)