Output vs. Outcome

Die Unterscheidung zwischen Output vs. Outcome spielt beim agilen Arbeiten ein zentrale Rolle. Zum einen erzeugt Komplexität einen Kontext, in dem die Verbindung zwischen Output und Outcome alles andere als gewiss ist. Zum anderen gelingt Selbstorganisation in agilen Teams nur dann, wenn Ziele ergebnis- bzw. outcome-orientiert formuliert werden. Das wird ganz besonders dann spürbar, wenn Deine Organisation damit beginnt, ihre strategischen Ziele mit Hilfe von OKR zu formulieren.

In diesem Artikel erfährst Du deshalb alles Wissenswerte über den Unterschied zwischen Output vs. Outcome sowie den Zusammenhang mit den Begriffen Input und Impact. Außerdem stelle ich Dir mit der Impact Ladder, dem Hypothesis Progression Framework und dem Key Value Indicator drei Tools vor, mit deren Hilfe Du besser zwischen Output und Outcome unterscheiden kannst.

Zum Schluss gehe ich noch einmal auf die Besonderheiten für einige agile Methoden ein und zeige Dir, welche Rolle Output & Outcome bei OKR, Scrum und EBM spielen.

Im Grunde 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.)

Output kannst Du also direkt und meist unmittelbar beeinflussen. Den Outcome hingegen kannst Du nur indirekt (über den Output) erreichen. Die Wirkung tritt außerdem oft verzögert ein.

Viele Unternehmen und Organisationen fokussieren sich in ihrem Tun fast ausschließlich auf ihren Output. Dadurch verlieren sie jedoch den Blick auf ihre Nutzer und Kunden und die eigentliche Wirkung, die sie erzielen möchten. Oft beginnen sie dann, um sich selbst zu kreisen und versuchen, das Maximum an Output zu erzeugen. Gleichzeitig achten sie jedoch nicht darauf, ob dieser maximierte Output auch das eigentlich gewünschte Ergebnis (Outcome) bei ihren Nutzern 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 grundsätzliche Problem dabei liegt darin begründet, dass Output und Outcome nicht direkt miteinander gekoppelt sind. Denn ob ein konkreter Output wirklich den von Dir gewünschten Outcome erzeugt, entscheiden Deine Nutzer.

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

Input ist das, was Du benötigst oder unternimmst, um einen Output zu generieren. In der Regel sind das zeitliche, menschliche oder finanzielle Ressourcen. Aber auch Partnerschaften oder sogar Tätigkeiten und Aktivitäten können einen notwendigen Input darstellen, um einen Output zu generieren.

Das Besondere am Verhältnis zwischen Input und Output ist, dass es sehr direkt und offensichtlich ist.

Deshalb kannst Du recht leicht einschätzen, ob ein Input auch zum gewünschten Output führt.

Investierst Du mehr Zeit ins Schreiben von Blogartikeln, wirst Du pro Monat auch mehr Blogartikel veröffentlichen können.

Impact hingegen steht noch eine Stufe über dem Outcome, den Du erzielen möchtest. Oft 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 meiner Ansicht nach ist Impact der langfristige oder nachhaltige Nutzen für Deine Kunden & Nutzer.

Deshalb möchte ich Dir hier eine andere Definition von Impact bieten:

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

Der Main JTBD ist dabei so etwas wie die Hauptaufgabe oder wichtigste Aufgabe Deiner Kunden und Nutzer. Bezogen auf unser Beispiel Internetblog bedeutet das:

Ob Dein Internetblog diesen Impact wirklich erzeugt, entscheiden natürlich Deine Leser.

Ob Du erfolgreich darin bist, diesen Nutzen zu stiften, erkennst Du daran, ob Deine Leser regelmäßig wiederkehren. (Weil sie Deinen Blog als nützliche Quelle für Informationen betrachten.)

Zusammenfassend lassen sich die Abfolge und die Verbindungen zwischen Input, Output, Outcome und Impact für unser Internetblog-Beispiel deshalb so abbilden wie hier zu sehen.

Beachte, dass die Verbindungen umso indirekter und unsicherer werden, je weiter rechts sie sich in 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 Deinen Kunden und Nutzern erzielt, ist noch sehr viel ungewisser.

Glücklicherweise existieren drei sehr hilfreiche Tools, die Dich und Deine Organisation dabei unterstützen, besser zwischen Output und Outcome zu unterscheiden.

Ein erster Schritt, um Deiner Organisation dabei zu helfen, besser zwischen Output und Outcome zu unterscheiden, ist die sogenannte Impact Ladder aus dem Agile Leadership Toolkit von Peter Koning.

Dabei nutzt Du die bereits oben vorgestellte Abfolge von Input, Output, Outcome und Impact und notierst sie (vertikal) auf einem (digitalen) Whiteboard. Ganz oben auf der Impact Ladder notierst Du den Main JTBD Deiner Zielgruppe

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 JTBD Deiner Zielgruppe ist. (Schließlich kannst Du nur wissen, welche Outcomes wichtig sind, wenn Du weißt, was die wichtigste Aufgabe für Deine Nutzer ist.)

Wie bereits erwähnt ist die Verbindung zwischen Output und Outcome nicht immer offensichtlich. Du weißt eben nicht, ob ein Output (neue Blogartikel) auch wirklich den gewünschten Outcome (mehr Besucher auf Deiner Webseite) erzeugt. Noch kannst Du Dir sicher sein, ob Du dadurch den Anteil wiederkehrender Besucher (Impact) steigern kannst.

Nachdem Du Deine Impact Ladder erstellt hast, lohnt es sich deshalb im zweiten Schritt, Hypothesenn zu formulieren. Denn Hypothesen verdeutlichen, dass die Erreichung des Outcomes durch einen Output zunächst eine reine Annahme darstellt. Und diese Annahme bestätigst (oder widerlegst) 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.

Oder bezogen auf die Verbindung zwischen Outcome und Impact:

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

Wir wissen, das 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 messbare 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. Stelle sicher, dass Du Dich gemeinsam mit Deinem Team auf messbare Kriterien einigst, anhand derer Ihr feststellen möchtet, 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 neue Blogartikel zum Thema OKR erreichen, dass mehr Leser sich für unsere Webseite interessieren.

Wir wissen, dass das wahr ist, wenn wir sehen, dass unsere Besucherzahlen in dieser Blogkategorie von 100 auf 1.000 steigen.

Neben der Impact Ladder und dem HPF existiert noch ein drittes, sehr hilfreiches Werkzeug für den Umgang mit Output, Outcome und Impact: der sogenannte 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 JTBD 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 JTBD ihrer Kunden (schnelle Lieferung).

In unserem Beispiel vom Internetblog ist der KVI der prozentuale Anteil wiederkehrender Leser pro Monat.

Zum Schluss möchte ich noch auf die Rolle eingehen, die die Unterscheidung zwischen Output und Outcome in agilen Frameworks spielt. Insbesondere bei OKR, Scrum und Evidence-Based Management.

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 von Dir gewünschten Outcome misst, und das untergeordnete OKR zahlt darauf ein. In diesem Fall ist es manchmal auch praktikabel, über die Key Results eines „untergeordneten Objectives“ den 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, natürlich 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 einen Kurswechsel, ohne dass Ihr Euer Ziel (bzw. die Key Results) dazu verändern müsst. Dein Team kann seinen Output während des OKR-Zyklus 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 OKR-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 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 von Scrum ist es ja, am Ende jedes Sprints ein nutzbares Produkt zu liefern, das Wert für Deine Nutzer stiftet. Dabei spielt 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 definieren. 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 Inkrement 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 dann 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.

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, dann stehen Dir dabei verschiedene Kombinationsmöglichkeiten zur Verfügung, die ich hier einmal in einer Tabelle für Dich 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 diesem Artikel den Unterschied zwischen Output und Outcome näher bringen. Mit den drei Tools Impact Ladder, Key Value Indicator und dem Hypothesis Progression Framework hast nun außerdem drei wirklich hilfreiche Werkzeuge an der Hand, zwischen Output und Outcome zu unterscheiden.

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 zum Thema Output vs. Outcome.