Rezension: Outcomes over Outputs

Lesedauer 6 Minuten

Let’s Talk about value – so lässt sich das kleine Buch Outcomes over Outputs von Joshua Seiden zusammenfassen. Wer kennt nicht das Phänomen: Unternehmen machen Dinge, aber Wert schöpfen sie mehr als Nebenprodukt. Das widerspricht ziemlich jeder Theorie über Unternehmen und Kapital, doch ist oft die Realität.

Von Ressourcen zu Wertzuwachs: Das Modell

Dies will Joshua Seiden mit seinem Buch Outcomes over Outputs ändern. Der Titel verrät seine Idee: Unternehmen sollten sich mehr auf Outcomes statt Outputs konzentrieren, also auf Verhaltensänderung von Kunden, Nutzern oder Mitarbeitern, statt auf die greifbaren Artefakte der Arbeit wie Features. Doch was hat das mit der Tätigkeit eines Unternehmens zu tun?

Ursprung in der Entwicklungshilfe

Dazu bedient sich Outcomes over Outputs an einem Modell aus der Entwicklungshilfe, die Ressourcen, Aktivitäten, Outputs, Outcomes und Wirkungsebene unterscheidet:

• Ressourcen sind die Mittel, die für Aktivitäten nötig werden.
• Aktivitäten sind die Aktionen, die Ressourcen in Output verwandeln.
• Outputs sind die direkten Ergebnisse der Aktivitäten.
• Outcomes sind die Verhaltensänderungen, die der Output hervorruft.
• Diese Outcomes führen auf der Wirkungsebene zu einem Mehrwert.

Um die Elemente seines Modells zu verdeutlichen, zieht Seiden ein klassisches Beispiel aus der Entwicklungshilfe heran: den Bau eines Brunnens. Dabei werden Arbeitskraft, finanzielle Mittel und Werkzeuge als Ressourcen eingesetzt. Als Aktivität muss zuerst ein geeigneter Ort gefunden und dann der Brunnen gebaut werden. Der Output ist der neue Brunnen. Der Outcome ist, dass die Bewohner des Dorfs Trinkwasser in ihrer Heimat haben. Auf Wirkungsebene sparen die Bewohner Zeit, weil sie nicht mehr zum entfernten Brunnen laufen müssen und sich mit anderen Dingen beschäftigen können.

Was läuft in Unternehmen falsch?

In Unternehmen denken Stakeholder und Top-Management an den Wert des Unternehmens und versuchen ihn zu erhöhen, indem die vertriebenen Produkte mehr Gewinn erwirtschaften. Das mittlere Management kümmert sich um Ressourcen, Aktivitäten der Mitarbeiter und hergestellte „Artefakte“ – doch niemand redet darüber, wie diese Wert schaffen. In der Softwarebranche führt das zu unnötigen Features, die in immer schnelleren Zyklen entwickelt werden, ohne dass diese einen Einfluss auf das Ergebnis des Unternehmens hat. Einen Backlog abarbeiten ist nicht das gleiche wie Fortschritt machen. Features schaffen nicht automatisch Mehrwert für den Kunden.

Outcomes over Outputs setzt dort an und schiebt die Outcomes dazwischen. Diese verbinden die erarbeiteten Artefakte mit dem Ergebnis des Unternehmens.

Auf Unternehmen angewandt

Bei Joshua Seidens Ansatz identifiziert das Management neue Verhaltensweisen der Kunden, die Wert für das Unternehmen schaffen. Diese gewünschten Outcomes nutzen dann Teams als Auftrag. Eine längere Verweildauer auf der Website könnte ein Outcome sein; oder mehr Abonnements für den Newsletter.

Umsetzung von Outcomes over Outputs

Seiden möchte Teams den Auftrag erteilen bestimmte Outcomes zu liefern und nicht Features. Dann entscheiden Teams selbst, wie sie diese Ergebnisse erreichen. Dafür brauchen sie aber eine Umgebung, in der sie experimentieren und Fehler machen dürfen. Die Frage ist also: Wie können Teams in diesem neuen Rahmen gut arbeiten und die richtigen Entscheidungen treffen?

Outcomes sind Handlungen, die wir beobachten und messen können. Sie sind unsere Indikatoren, dass unser Output zu den gewünschten Verhaltensänderung und damit zu Business Value führt.

Doch wenn Teams und Unternehmen nicht mehr an Features, sondern an Value Creation denken, bekommen wir ein Problem: Woher wissen wir, was wirklich Werte schafft? Wir wissen es nicht, ohne Hypothesen, Daten und Experimente. Letztere brauchen wir, wenn vorliegende Daten nicht ausreichen. Für ein Experiment brauchen wir ein MVP – die kleinste Handlung oder Ding, um zu sehen, ob unsere Vermutung wahr ist.

Um Outcomes als Ziel zu nutzen, müssen Teams Methoden entwickeln die gewünschten Outcomes zu messen. Nur so können sie feststellen, ob ihre Arbeit zu den gewünschten Veränderungen führt und zum Geschäftserfolg beiträgt.

Drei Fragen helfen in Outcomes zu denken

Joshua Seiden beschreibt in Outcomes over Outputs drei Fragen, die helfen in Outcomes zu denken:

1. Welche Verhaltensweisen unserer Nutzer und Kunden führen zu mehr Ergebnis für das Unternehmen? (Das sind die Outcomes, die wir schaffen wollen)
2. Wie bringen wir die Leute dazu mehr von diesen Verhaltensweisen zu tun? (Das sind die Outputs, die wir brauchen)
3. Woher wissen wir, dass wir Recht haben? (Das zeigt die Dynamik des Systems, die Tests und die Metriken, die wir überwachen sollten)

Wieso Outcomes und nicht Wert?

Wieso sollen wir über Outcomes reden, wenn das Ziel eigentlich der Wert ist? Auch darauf weiß Seiden eine Antwort: Ziele auf Wirkungsebene sind zu komplex, um für unsere Teams von Nutzen zu sein. Stattdessen müssen wir Teams an Outcomes arbeiten lassen – kleineren, überschaubareren Zielen, die in ihrer Gesamtheit die gewünschte Wirkung erzielen. Hier kommt ein weiterer Punkt zu tragen. Ein Outcome wird nicht das Ergebnis eines Unternehmens substanziell ändern. Das bewirken mehrere Outcomes zusammen. Genauso reicht ein Output meist nicht aus Verhaltensweisen der Zielgruppe grundlegend zu ändern, aber mehrere schon. Daher ist die Definition von Outcomes Aufgabe des Managements.

Auch für physische Produkte, …

Obwohl der Autor aus der digitalen Welt mit ihren Vorurteilen gegen physische Produkte stammt, lässt sich sein Ansatz auch auf diese übertragen. In der Weltsicht unterscheidet sich Software grundsätzlich von anderen Gütern, da sie nicht produziert wird. Bei Software ist nie klar, wann sie fertig ist. Im Gegensatz ist ein Auto fertig, wenn es vom Band rollt.

Doch wenn wir die Entwicklung des Autos betrachten, stehen wir vor ähnlichen Problemen. Wann die Entwicklung des Autos fertig? Welche Features braucht das Modell? Können wir die Montage vereinfachen und wenn ja, wo ist der Punkt, ab dem es keinen Sinn mehr macht?

Ein Beispiel ist die Entwicklung des Porsche Cayenne. Die Designer haben untersucht, wie ein Getränkehalter gestaltet sein muss, damit Kunden mehr dafür zahlen. Diese Herangehensweise spiegelt genau die outcome-zentrierten Überlegungen wider, die Seiden in seinem Buch beschreibt.

…aber nicht für alles

Seidens Management-Ansatz ist trotzdem nicht für alles geeignet. In der Produktion sollten Outputs das Maß sein. Ob ein Produkt das Richtige ist, entscheidet nicht das Werk, sondern muss in der Entwicklung geklärt sein – am besten schon vor dem Entwicklungsstart.

Verpasste Chance

Leider behandelt Seiden in Outcomes over Outputs einen Aspekt nicht: Die Verbindung von Ressourcen und gewünschten Outcomes. Das Managements könnte den Teams Ressourcen zuteilen, um Outcomes zu priorisieren – dies ist klassisches Portfoliomanagement durch budgetieren. Diese Verknüpfung von Ressourcenmanagement und Outcome-Orientierung sollte helfen den vorgestellten Ansatz in die Praxis zu übertragen.

Fazit

Das Buch ist kurz und gut lesbar. Die Länge reicht völlig, um die Idee einzuführen und zu erklären. Ich hatte nie das Gefühl, dass ein Kapitel zum Füllen da ist oder noch ein Ratgeberteil hinten dran musste. Die auf dem Cover angegebenen 40 Minuten Lesezeit habe ich allerdings gerissen – ohne über das gelesene nachzudenken machbar, aber das ist nicht Sinn des Buchs.

Wer eine Schritt für Schritt Anleitung für das Management von Projekten und Produkten sucht, findet diese in Outcomes over Outputs nicht. Joshua Seiden beschreibt ein Framework für eine andere Art, Entwicklungsteams, Marketing und Design zu beauftragen. Das Buch enthält zwei Kapitel mit Praxisbeispielen über die Einführung des Frameworks in Unternehmen, aber mehr als die Erkenntnis, dass Veränderung nicht einfach ist, liefern diese nicht.

So bleibt als Fazit, dass Outcomes over Outputs ein wertvolles Buch ist, um Gespräche in Unternehmen mehr Richtung Wertschöpfung zu lenken, als stumpf den Output zu managen.

Der Autor: Joshua Seiden

Joshua Seiden ist ein auf agile Organisationen spezialisierter Autor, Berater, Designer, und Coach. Seine Arbeit hat Unternehmen wie Johnson & Johnson, JP Morgan Chase und American Express beeinflusst. Er hat als Autor an „Lean UX“ mitgearbeitet, dem Standardwerk im Bereich User Experience.