Output vs. Outcome

In diesem Artikel zeige ich Dir, wie Du Dein Team mit drei hilfreichen Tools dabei unterstützen kannst, besser zwischen Output und Outcome zu unterscheiden.

Im letzten Teil des Artikels gehe ich näher auf die Rolle von Outcome und Output in den agilen Frameworks Scrum, Objectives & Key Results und Evidence-Based Management ein.

Eigentlich ist der Unterschied zwischen Output und Outcome ziemlich simpel. Nichtsdestotrotz werden sie in der Praxis sehr häufig verwechselt. (Zu den Gründen, warum das so ist, gehe ich weiter unten genauer ein.)

Die meisten Unternehmen fokussieren sich in ihrem Tun fast ausschließlich auf ihren eigenen Output. Dadurch verlieren sie jedoch den Blick auf ihre Nutzer und Kunden. Sie beginnen dann, um sich selbst zu kreisen und versuchen, das Maximum an Output zu erzeugen. Zeitgleich wissen sie jedoch gar nicht, ob der maximierte Output auch das eigentlich gewünschte Ergebnis (Outcome) beim Kunden erzeugt.

Nokia hat als Handy-Hersteller nicht den Anschluss verloren, weil das Unternehmen zu wenig Handys hergestellt hat oder weil Menschen aufgehört haben, Handys zu nutzen.

Das Problem mit Output und Outcome liegt darin begründet, dass sie nicht direkt miteinander gekoppelt sind. Ob ein konkreter Output wirklich den gewünschten Outcome erzeugt, entscheiden Deine Nutzer. Deine Nutzer und Kunden interessieren sich nicht für den Output Deiner Organisation, sondern nur für den Outcome, den sie ermöglichen.

Bevor ich jedoch genauer auf die Unterschiede zwischen Output und Outcome eingehe und Dir zeige, wie Du den Fokus Deines Unternehmens (wieder) stärker auf den Outcome lenkst, müssen wir noch zwei weitere Begriffe klären, die eng mit Output und Outcome in Verbindung stehen: Input und Impact.

Input ist das, was Deine Organisation benötigt oder unternimmt, um einen Output zu generieren. In der Regel sind das zeitliche, menschliche oder finanzielle Ressourcen. Aber auch geschäftliche Partnerschaften oder sogar eigene Tätigkeiten und Aktivitäten können einen notwendigen Input darstellen, um einen Output zu generieren.

Zwischen Input und Output besteht eine direkte Verbindung. Denn wir können ja sofort erkennen, ob ein bestimmter Input auch den gewünschten Output erzielt.

Impact hingegen steht noch eine Stufe über dem Outcome, den Du erzielen möchtest. Häufig kannst Du lesen, dass Impact der langfristige oder nachhaltige Nutzen für Deine Organisation sei. (Beispielsweise findest Du das so im Blog von Mooncamp oder DigitaleNeuordnung wieder.)

Diese Perspektive ist sicherlich nicht grundsätzlich falsch, aber ich möchte Dir hier eine andere Definition von Impact bieten:

Impact ist die Wirkung, die ein Outcome auf den Main Job Deiner Kunden hat.

Warum glaube ich, dass das wichtig ist? Nun, Input, Output, Outcome und Impact bauen aufeinander auf. Und Impact steht ganz oben auf dieser Leiter. Wenn Du nun Deine eigenen Geschäftsinteressen ganz oben verortest, dann zielt alles, was darunter verortet ist, eben genau darauf ab.

Customer-Driven Innovation setzt jedoch Deine Kunden ins Zentrum Deines Denkens.

Impact muss daher darin bestehen, das Leben Deiner Nutzer und Kunden auf den nächsten Level zu bringen! (Und nicht Dein eigenes Unternehmen.)

Wenn Du so möchtest, ist ein bestimmtes Outcome immer nur ein kleiner Teilausschnitt eines großen Ganzen. Darüber stehen ultimative Ziele oder Aufgaben, die Menschen mit der Nutzung von Produkten verfolgen. Diese ultimative Aufgabe ist der sogenannte Main Job.

Zusammenfassend lassen sich die Reihenfolge und die Verbindungen zwischen Input, Output, Outcome und Impact abbilden wie hier rechts zu sehen.

Beachte, dass die Verbindungen umso indirekter und unsicherer werden, je höher sie sich auf auf dieser Darstellung befinden.

Während die Verbindung zwischen Input und Output sehr direkt ist, ist das bei Output und Outcome nicht mehr der Fall. Ob ein Outcome wirklich einen Impact bei Deinem Kunden erzielt ist noch sehr viel ungewisser.

Um in Deiner Organisation oder Deinem Team dabei zu helfen, besser zwischen Output und Outcome zu unterscheiden, existieren drei sehr hilfreiche Tools, die ich Dir hier vorstellen möchte.

Ein erster Schritt, um Deinem Team dabei zu helfen, besser zwischen Output und Outcome zu unterscheiden, ist die sogenannte Impact Ladder.

Dabei nutzt Du die bereits oben vorgestellte Abfolge von Main Job, Outcome & Output und notierst sie auf einem (digitalen) Whiteboard. Lediglich das Element Input kannst Du dabei durch Dein Produkt oder Deinen Service ersetzen.

Du kannst die Impact Ladder entweder alleine oder gemeinsam mit Deinem Team erarbeiten. Beides kann je nach Situation sinnvoll sein.

Solltest Du Schwierigkeiten mit der Impact Ladder haben, liegt das meistens daran, dass Du Dein Customer Segment (noch) nicht gut genug kennst und nicht weißt, was der Main Job Deiner Zielgruppe ist. (Schließlich kannst Du nur wissen, welche Outcomes wichtig sind, wenn Du weißt, was die wichtigste Aufgabe für Dein Customer Segment ist.

Hier siehst Du das Beispiel einer Impact Ladder für eine Softwarefirma, die eine Navigations-App herstellt.

Der Main Job des Customer Segments ist: Zuverlässig von A nach B gelangen. Ein mögliches Outcome könnte deshalb sein, Routen, die häufig genutzt werden, schnell und einfach wiederzufinden. Der dazu notwendige Output, der dieses Outcome ermöglicht, könnte ein neues Feature Deines Produktes (Navigations-App) sein.

Natürlich sind in der Impact Ladder noch weitere Abstufungen bzw. Sprossen denkbar, falls es Dir hilft, Deine Kunden besser zu verstehen.

Nutze die Impact Ladder, um mit Deinem Customer Segment ins Gespräch zu gehen! Ist Zuverlässigkeit wirklich besonders wichtig für sie? Oder geht es ihnen eher um Geschwindigkeit? Vielleicht sind für ein anderes Customer Segment weder Zuverlässigkeit noch Geschwindigkeit besonders relevant, sondern die schönste Route. All das erfährst Du jedoch nur dann, wenn Du mit Deinem Customer Segment ins Gespräch gehst.

Wie bereits erwähnt ist die Verbindung zwischen Output und Outcome indirekt. Du weißt eben nicht, ob ein Output (neues Feature) auch wirklich den gewünschten Outcome erzeugt. Nachdem Du Deine Impact Ladder erstellt hast, lohnt es sich daher im zweiten Schritt, eine Hypothese zu formulieren. Denn Hypothesen verdeutlichen, dass die Erreichung des Outcomes durch einen Output zunächst eine reine Annahme darstellt. Und diese Annahme bestätigst Du am besten durch messbare Ergebnisse.

Der Grundaufbau einer Hypothese lautet daher wie folgt:

Wir glauben, dass wir durch [Output] erreichen, dass [Outcome].

Wir wissen, dass das wahr ist, wenn wir [Kriterium] sehen.

Besonders durch die Formulierung “Wir glauben, dass…” wird deutlich, dass Output und Outcome nicht direkt miteinander verbunden sind. Achte auch darauf, dass sich das Kriterium auf den Outcome bezieht und nicht auf den Output!

Auch die von Dir formulierten Hypothesen kannst Du in Deiner Impact Ladder festhalten. Am besten positionierst Du sie dabei zwischen den einzelnen Stufen, die Du dort abgebildet hast. Achte darauf, dass Du Dich gemeinsam mit Deinem Team auf messbare Kriterien einigst, anhand derer Ihr feststellt, ob Eure Hypothese bestätigt oder widerlegt ist.

Für unser Beispiel könnte die Hypothese etwa folgendermaßen lauten:

Wir glauben, dass wir durch unser Feature Routen-Favoriten erreichen, dass unsere Nutzer schnell und einfach häufig benutzte Routen wiederfinden.

Wir wissen, dass das wahr ist, wenn wir sehen, dass unsere Nutzer weniger als 1 Sekunden benötigen, eine bereits genutzte Route auszuwählen und in 90 % dieser Fälle der Routen-Favorit genutzt wird.

Neben der Impact Ladder und Hypothesen steht Dir für die bessere Unterscheidung von Output und Outcome noch ein drittes Tool zur Verfügung: Der Key Value Indicator.

Der Key Value Indicator (KVI) ist eine Metrik, mit der Du misst, wie gut es Deinem Produkt (oder sogar Deinem gesamten Unternehmen) gelingt, den Main Job Deines Customer Segments zu erfüllen.

Amazon misst beispielsweise die Zeit, die alle Pakete im Durchschnitt benötigen, bis sie beim Kunden ankommen. Und je kürzer diese Zeitspanne ist, desto besser erfüllt Amazon den Main Job ihrer Kunden (Schnelle Lieferung).

Relevant ist also nicht der Output (“Wie kurz ist die Zeitspanne, in der wir Pakete an Kunden versenden?”), sondern der Main Job der Kunden (“Wie lange dauert es, bis das Paket auch wirklich bei mir ankommt?”)

Für unser Beispiel mit der Navigations-App könnte der Key Value Indicator lauten:

Die tatsächliche Fahrzeit jeder Route unterscheidet sich maximal 5 % von der geschätzten Fahrtzeit zu Fahrtbeginn.

Soviel von meiner Seite zur Unterscheidung zwischen Output und Outcome. Ich hoffe, ich habe Dir mit diesen drei Tools dabei helfen können, die beiden Begrifflichkeiten besser voneinander zu trennen.

Vielleicht nutzt Du in Deiner täglichen Praxis Objective & Key Results, Scrum oder sogar Evidence-Based Management. In dem Fall habe ich zu diesen agilen Methoden noch ein paar weitere hilfreiche Tipps für Dich.

Auch beim OKR-Framework kommt es immer wieder zu Diskussionen, ob mit Key Results Output oder Outcome gemessen werden sollte. Im Blog von Workpath findest Du darüber hinaus noch eine eindeutige Sowohl-als-auch-Meinung zu diesem Thema. Persönlich bin ich der Ansicht, dass Du Dir keinen Gefallen damit tust, wenn Du mit Key Results Output messbar machst. Schließlich heißen sie ja Key Results und nicht Key Output.

Einzige Ausnahme: Wenn ein übergeordnetes OKR existiert, das den gewünschten Outcome misst, und das untergeordnete OKR zahlt darauf ein. In diesem Fall ist es häufig auch praktikabel, über die untergeordneten Key Results Output zu messen. Allerdings solltest Du in diesem Fall nachhalten, ob die Erreichung des untergeordneten OKR auch wirklich einen Effekt auf das übergeordnete OKR hat. (Stichwort “Hypothese”)

Key Results sollten (wann immer möglich) so verwendet werden, dass sie messen, wann das Objective erreicht wurde. Und nicht, was dafür zu tun ist, um es zu erreichen. Wenn Du so möchtest, sind Objectives & Key Results nur zwei unterschiedliche Seiten ein und derselben Medaille. Das Objective ist das angestrebte Ziel und die dazugehörigen Key Results bieten messbare Kriterien, wann Ihr es als erreicht ansehen möchtet.

Einerseits sind Key Results, die Outcome messen, ein Nachteil. Denn nur weil Ihr Euch im OKR-Planning auf bestimmte Key Results geeinigt hat, wisst Ihr ja nicht automatisch, was Ihr tun müsst, um sie zu erreichen. (Häufig ist auch genau das der Grund, warum Key Results formuliert werden, die Output messen.)

Andererseits sind sie jedoch auch ein Vorteil. Denn sie ermöglichen Deinem Team Kurswechsel, ohne dass Ihr Euer Ziel (bzw. die Key Results) verändern müsst. Dein Team kann seinen Output während des OKR-Quartals vollkommen verändern und immer noch den gleichen Outcome anstreben.

Um also nicht vollkommen orientierungslos aus Eurem OKR-Planning zu kommen, lohnt es sich, neben Key Results zusätzlich OKR-Initiativen zu planen. OKR Initiativen sind der Output Eures Teams, mit dessen Hilfe Ihr den Outcome (Eure Key Results) erreichen möchtet.

Während des Quartals habt Ihr dadurch sogar die Möglichkeit, Eure ORK-Initiativen aufzugeben und etwas anderes auszuprobieren, falls Ihr feststellt, dass sie keinen Einfluss auf die von Euch angestrebten Key Results haben.

Auch hier gilt wieder das gleiche Prinzip: Dass Eure OKR-Initiative Euer Key Result positiv beeinflusst, ist zunächst nicht mehr als eine Hypothese.

Auch in Scrum wird der Nutzen für Kunden groß geschrieben. Denn der grundsätzliche Gedanke ist es ja, am Ende jedes Sprints ein nutzbares Produkt zu liefern, das Wert für die Nutzer stiftet. Neben der Definition of Done und dem Increment spielen dabei sowohl das Produktziel als auch das Sprintziel eine wichtige Rolle. Und wie bei OKR stellt sich die Frage, ob sie Output oder Outcome formulieren sollten.

Laut Scrum Guide beschreibt das Produktziel einen zukünftigen Zustand Deines Produktes. Es hilft Dir als Produkt Owner dabei, die Priorisierung im Product Backlog festzulegen. Darüber hinaus sollte es klar kommunizieren, warum dieses Ziel wichtig für Deine Kunden ist und deshalb outcome-orientiert sein.

Sofern Du in Deinem Scrum Team auch OKR nutzt, kann auch Euer aktuelles Objective Euer Produktziel sein!

Auch Sprintziele können grundsätzlich Outcome kommunizieren. Allerdings gibt es hier ein kleines Problem: Dein Scrum Team möchte zum Ende des Sprint wissen, ob es sein Sprintziel auch erreicht hat.

Natürlich ist es gut und sinnvoll, Eure Stakeholder und Kunden in Eure Sprint Review einzuladen, um Feedback zu erhalten. Aber nur, weil Ihr dort viel positives Feedback erhaltet, wisst Ihr deshalb noch lange nicht, ob Euer neues Increment wirklich Nutzen für Eure Kunden stiftet. Das findet Ihr erst heraus, wenn Euer neues Feature auch tatsächlich genutzt wird. Daraus folgt jedoch auch, dass Ihr erst nach der Sprint Review wisst, ob Eure Nutzer das Feature verwenden.

Wenn Ihr Euer Sprintziel also Outcome formuliert, dann erzeugt das eine gewisse Verzögerung. In der Review selbst ist unklar, ob es erreicht wurde oder nicht. Es ist deshalb durchaus sinnvoll, mit dem Sprintziel Output zu formulieren, um am Ende des Sprints zu wissen, ob das Ziel erreicht wurde.

Gleichzeitig ist es dann natürlich wichtig, den gewünschten Outcome über das Produktziel zu definieren. Ob das erreichte Sprintziel (Output) tatsächlich eine Wirkung auf das Produktziel (Outcome) hat, ist natürlich wieder eine Hypothese.

Neben Sprint- und Produktziel sind die oben bereits erwähnten Feature-Hypothesen hilfreich, um die Brücke von Output zu Outcome zu schlagen. Sie verbinden dann sozusagen Dein Sprintziel mit dem übergeordneten Produktziel und legen klare Messkriterien fest.

Falls Du vorhast, Evidence-Based Management (EBM) zu verwenden (oder es bereits in Deinem Unternehmen genutzt wird), ist der Fall ein klein wenig komplizierter. EBM ist im Aufbau nämlich sowohl mit Scrum als auch mit OKR kompatibel.

Eine wichtige Rolle spielen hier die Begriffe Immediate Goal, Intermediate Goal und Strategic Goal. Nutzt Du sie gemeinsam mit OKR oder Scrum stehen Dir dabei verschiedene Kombinationsmöglichkeiten zur Verfügung, die ich hier einmal in einer Tabelle zusammengestellt habe:

Die Begriffe Produktvision, Midterm Goal (Moal) und OKR-Initiative sind nicht “offizieller Teil” der jeweiligen Frameworks, sondern lediglich eine häufig genutzte (und sinnvolle) Ergänzung. Es steht Dir frei, sie zu nutzen, aber Du kannst sie genauso gut weglassen, falls Dir das besser gefällt.

Ich hoffe, ich konnte Dir mit der Impact Ladder, dem Key Value Indicator und dem Hypothesis Progression Framework drei hilfreiche Werkzeuge an die Hand geben, die es Dir und Deinem Team leichter machen, zwischen Output und Outcome zu unterscheiden. Und ich hoffe natürlich auch, dass meine Tipps zu OKR, Scrum und EBM ebenfalls hilfreich für Dich waren, falls Ihr diese Methoden und Frameworks in Eurem Unternehmen nutzt.

Falls bei Dir noch Fragen offen geblieben sein sollten, schreib mir gerne einen Kommentar unten auf dieser Seite! Ich freu mich über jegliche Anregungen, Fragen, Ideen und Kritik.