0 0 Votes
Artikel-Rating

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

  • Die Impact Ladder hilft Dir dabei, zwischen Impact, Output und Outcome trennen.

  • Mit dem Hypothesis Progression Framework (HPF) lernst Du, Hypothesen zu formulieren, mit deren Hilfe Du eine Brücke zwischen Output und Outcome schlägst.

  • Der Key Value Indicator unterstützt Dich dabei, den Impact Deines täglichen Tuns, messbar zu machen.

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.

Der Unterschied zwischen Outcome und Output

Eigentlich ist der Unterschied zwischen Outcome und Output 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 ist das konkrete Ergebnis vorangegangener Aktivitäten. Wenn Dein Unternehmen eine Navigations-App produziert, dann ist eben diese App der Output Deines Unternehmens. Auch ein neues Feature für diese App ist lediglich Output. Jede Value Proposition ist (nur) Output.

  • Outcome hingegen ist die Wirkung, die Du bei Deinen Nutzern und Kunden mit einem Output erzielen willst. Beispielsweise könnte es ein Outcome Deiner Navi-App sein, Deinen Kunden dabei zu helfen, zuverlässig die kürzeste Route von A nach B zu finden.

Warum ist der Unterschied wichtig?

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 Outcome und Output 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.

Input & Impact

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 Outcome und Output in Verbindung stehen: Input und Impact.

Input

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.

  • Auf dem Business Model Canvas wird der notwendige Input, um ein Produkt oder Service (Output) bereitzustellen über die drei Elemente Key Resources, Key Activities und Key Partnerships dargestellt. Mit ihrer Hilfe bildest Du die sogenannte Feasibility Deines Geschäftsmodells ab.

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.

Desirability Feasibility Viability auf dem Business Model Canvas

Impact

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

Was ist ein Main Job?

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.

  • Der Main Job, den Spotify für seine Kunden erfüllt, ist “Musik hören”.
  • Der Main Job eines Handys ist “Mit Menschen Informationen und Erlebnisse teilen”.
  • Der Main Job meiner Kunden ist “Die eigenen Kunden besser verstehen”.

Input, Output, Outcome & Impact im Überblick

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.

Input Output Outcome Impact

Tools zur Unterscheidung von Output und Outcome

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.

  • Die Impact Ladder

  • Das Hypothesis Progression Framework (HPF)

  • Der Key Value Indicator

Mit der Impact Ladder zwischen Impact, Outcome & Output unterscheiden

Ein erster Schritt, um Deinem Team dabei zu helfen, besser zwischen Outcome und Output 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.

Impact Ladder

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.

Methoden und Tools, die weiterhelfen

  • Nutze Jobs to Be Done, um besser zu verstehen, was die Jobs, Pains & Gains Deines Customer Segments sind.

  • Greife dabei insbesondere auf Discovery Tests zurück, um mehr über Deine Zielgruppe zu erfahren!

  • Halte Deine Erkenntnisse aus der JTBD-Methodik auf einem Value Proposition Canvas fest, um Deine Erkenntnisse zu organisieren.

Beispiel für eine Impact Ladder

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.

Impact Ladder Beispiel

Sprich mit Deinen Kunden!

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.

Mit Hypothesen die Brücke vom Output zum Outcome bilden

Wie bereits erwähnt ist die Verbindung zwischen Outcome und Output 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.

Mit Hypothesen die Brücke von Output zu Outcome schlagen

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.

  • Falls Du Hypothesen noch gewinnbringender nutzen möchtest, kannst Du für die Unterscheidung zwischen Output und Outcome auch sogenannte Feature-Hypothesen verwenden. Wie das geht, erfährst Du in meinem Artikel Hypothesen formulieren.

  • Falls Dir der obige Blogartikel nicht umfangreich genug ist, empfehle ich Dir das Customer-Driven Playbook, in dem das Hypothesis Progression Framework detailliert vorgestellt wird.

Mit dem Key Value Indicator Impact messbar machen

Neben der Impact Ladder und Hypothesen steht Dir für die bessere Unterscheidung von Outcome und Output 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?”)

Key Value Indicator

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.

Outcome und Output in OKR, Scrum und Evidence-Based Management

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.

Outcome und Output im OKR-Framework

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: Es existiert ein übergeordnetes OKR, 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”)

Gute Key Results formulieren Outcome

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.

OKR-Initiativen beschreiben Output

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.

OKR Initiativen

Outcome und Output in Scrum

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 Outcome oder Output formulieren sollten.

Produktziel

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!

Sprintziel

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, dass 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.

Feature

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.

Sprintziel - Produktziel - Feature-Hypothese

Outcome und Output im Evidence-Based Management

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:

Evidence-Based Management Scrum OKR (Variante 1) OKR (Variante 2)
Strategic Goal Produktvision*
(Outcome oder Impact)
Moal*
(Outcome oder Impact)
Intermediate Goal Produktziel (Outcome) Moal*
(Outcome oder Impact)
OKR (Outcome)
Immediate Goal Sprintziel (Output) OKR (Outcome) OKR-Initiative* (Output)

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.

  • Mehr Informationen zu Immediate, Intermediate und Strategic Goals erfährst Du in meinem Artikel über das Evidence-Based Management Framework.

Fazit zu Outcome & Output

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 Outcome und Output 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.