Da mich das Thema „Outcomes“ derzeit öfters auf verschiedenen Ebenen im Unternehmen begleitet, habe ich mir am Wochenende die Zeit genommen und das Buch „Outcomes Over Output: Why customers behaviour is the key metric for Business success“ von Josh Seiden gelesen. Hier meine persönlichen Highlights:

Part I – Was sind Outcomes?

Es wird oft angenommen, dass das „Bearbeiten von Aufgaben“ gleichbedeutend mit „Fortschritt“ ist und das „Ausliefern von Features“ mit „fertig sein“. Doch unsere Welt ist übersät mit Features, die zwar wie vorgesehen funktionieren, aber den Kunden keinen echten Mehrwert bieten. Wenn also Features nicht automatisch Kundennutzen liefern, dann sollten wir sie auch nicht im Zentrum unseres Planungsprozesses sehen. Stattdessen sollten wir das Ziel haben, so wenig wie möglich zu tun (Output), um den erwarteten Nutzen (Outcome) zu erreichen. (#eliminatewaste)

Outcomes als Ziel zu setzen klingt einfach, kann in der Praxis jedoch eine Herausforderung sein. Es gilt eine geeignete Balance zwischen Detailtiefe und Oberflächlichkeit zu finden. Ein Ansatz besteht darin, den Schwerpunkt auf das Kundenverhalten zu legen und zu reflektieren, wie eine Änderung dieses Verhaltens die Geschäftsergebnisse positiv beeinflussen kann. Durch die Fokussierung auf Outcomes in der Kommunikation wird (Entwicklungs-) Teams die Flexibilität gegeben, eigenständig den effizientesten Weg zu identifizieren, um ein Kundenproblem zu adressieren und Kundennutzen zu stiften.

Grundsätzlich können Teams auf unterschiedliche Weise geführt werden:

1. Managing Outputs: sage dem Team genau welches Feature zu tun ist
   → das ist in der Praxis oft zu spezifisch (und verhindert u. A. Innovation aus den Teams heraus)
2. Managing Impacts: sage dem Team genau welchen Impact sie erreichen sollen (z. B. Umsatzziel X)
   → das ist in der Praxis oft zu unspezifisch
3. Managing Outcomes: sage ihnen genau welches spezifisches Kundenverhalten zu lösen ist
   → richtige Balance (schärft den Fokus darauf Wert zu generieren)

Experiment ~ Minimum Viable Product

Wie finden wir heraus, dass ein Output tatsächlich den erwünschten Outcome bewirkt? Meistens können wir das im Vorfeld schlicht und ergreifend nicht wissen. Daher ist es hilfreich mit Experimenten zu arbeiten. Diese sollten so gestaltet und technisch so unkompliziert umsetzbar und auslieferbar sein (#CI/CD), dass sie problemlos an ausgewählte Kunden ausgeliefert werden können, um zeitnah Feedback zu erhalten.

Der Autor beschreibt Experimente mit dem Begriff des „Minimum Viable Product“ (MVP). Für ihn stellt ein MVP nicht die Version 1.0 eines Produktes dar. Stattdessen deutet er den Begriff MVP als kleinstmögliches „Teil“, dass getan werden kann, um herauszufinden, ob eine aufgestellte Hypothese korrekt ist. Eine Hypothese stellt in diesem Kontext eine Idee dar, mit welchem Output wir einen gewünschten Outcome erreichen können. Durch das definieren von Outcomes im Bezug auf Kundenverhalten wird eine kunden- und nutzerzentrierte Arbeitsweise gefördert.

Part II – Outcomes verwenden

Outcomes sind Dinge die Menschen tun. Daher sind sie sowohl beobachtbar als auch messbar, wodurch sie sich als Management-Werkzeug geeignet sind. Zwei Sachverhalte müssen wir uns hierfür vor Augen halten:

1. Outcomes sind „Verhalten von Menschen“ die unsere Geschäftsergebnisse steuern
2. Wir müssen verstehen, was es ist, dass unsere Kunden tun, wodurch unsere Geschäftsergebnisse beeinflusst werden (beste Produkteinstellung, beste Dokumentation, bestes Gesamtpaket, schneller Einstieg, …)

Indikatoren

Um die Zielerreichen unsere Outcomes zu messen, können uns Indikatoren helfen. Zwei Indikatoren sind sehr verbreitet und gilt es zu unterscheiden (siehe auch Artikel auf digitaleneuordnung.de).

Lagging Indicator

Beim Langging Indikator handelt es sich um eine Kennzahl, welche das Verhalten der Vergangenheit quantifiziert. Die Kennzahl hinkt daher der aktuellen Situation hinterher und hat somit wenig Vorhersage-Potential. Beispiele sind: Umsatz, Rendite, wie oft hat ein Kunde ein Produkt gekauft, wie war die Performance im Team etc.

Leading Indicator / Frühindikatoren

Frühindikatoren sind Kennzahlen, welche einem Verhalten vorausgehen. Sie können direkt beeinflusst werden, wodurch auch kurzfristige Änderungen sichtbar werden. Dadurch, dass sie auf die Gegenwart und Zukunft gerichtet sind, sind sie hilfreich, um gewünschte Entwicklung aktiv zu managen. Da sie oftmals schwer zu greifen sind, loht es sich, mit Hypothesen (s. U.) zu arbeiten. Dabei kann es hilfreich sein, das Verhalten von Kunden als Anhaltspunkte für Frühindikatoren zu nutzen (z. B. Anzahl der Klicks in Newsletter)

Hypothesen

Um zu evaluieren, ob unser Output zu dem gewünschten Outcome führt, können wir mit Hypothesen arbeiten. Diese bestehen immer aus zwei Bestandteilen:

1. Was glauben wir?
2. Welche Beweise benötigen wir, um unseren Glauben zu stützen oder zu widerlegen?

Ein Beispiel kann wie folgt aussehen:

• Wir glauben, dass wenn die Anzahl der „Shares“ in Sozialen Medien zu der Produkt X steigt, mehr Kunden unsere neue Produkt kaufen werden.
• Wir werden wissen, dass wir Recht haben, wenn wir eine Korrelation sehen zwischen „Shares“ und Anzahl der Käufe von Produkt X.

Es gibt ein enges Zusammenspiel zwischen Outcome, Hypothese und Experiment. In der Regel geben wir unser Ziel als Outcome an. Ein Team bekommt dann den Auftrag, zu überlegen, wie dieser Outcome erreicht werden kann – es bildet sich eine Hypothese. Um diese Hypothese zu verifizieren benötigen wir ein oder mehrere Experimente.

Es gibt Fragen, die uns dabei helfen Outcomes richtig zu nutzen und zu ermitteln (der Autor nennt sie die magischen Fragen):

• Was ist das Verhalten der Nutzer und Kunden, welches unser Geschäft voran bringt?
  → Das ist der Outcome den wir erreichen möchten
• Wie bekommen wir Menschen dazu, mehr von diesem Verhalten zu zeigen?→ Das sind der Output (Features, Anpassungen von Richtlinien etc.) den wir umsetzen, um den gewünschten Outcome zu erreichen
• Woher wissen wir, dass wir Recht haben?
  → Aufdecken der Dynamik des Systems sowie der Tests und Metriken, die wir nutzen, um unseren Fortschritt zu messen

Wie fängt man am besten an mit Outcomes zu arbeiten?

In den meisten Fällen wird nicht mit Outcomes geplant sondern mit konkreten Outputs. Für Führungskräfte die mit Outcomes beginnen möchten, gibt es eine einfache Frage die als Initialzündung verwendet werden kann:

• Welches (Kunden-/Nutzer-/Angestellten-) Verhalten hat diese Initiative bewirkt, welche unseren Geschäftserfolg stützt?
• oder: Welche neuen Verhalten hat deine Arbeit bewirkt, die unseren Geschäftserfolg stützt?

Objective Key Results

Durch den Fokus auf Outcomes erhalten wir ein Potential für bessere Objective Key Results (OKR). Viele Teams verfehlen den Zweck von OKRs, in dem sie den Output nehmen und daraus OKRs abbilden – das geht am Ziel und der Intention von OKRs vorbei! Durch das Ausdrücken von Key Results hingegen als messbares Kundenverhalten (Outcomes), bekommt man meistens ganz automatisch gut formulierte OKRs.

Teil III – Outcome-basierte Planung

Für die Kommunikation mit Kunden und anderen Abteilungen wird oft mit Roadmaps gearbeitet. Diese bestehen meist aus einer Liste an Features und Projekten, welche die umsetzenden Teams (oder im ungünstigen Fall deren Manager) versprochen haben zu einer gegebenen Zeit zu liefern. Roadmaps haben dabei die wichtige Aufgabe, den Unternehmen zu helfen die Ungewissheit zu managen. Dabei sollen Fragen beantwortet werden wie: „An was werden wir arbeiten?“, „Was werden wir ausliefern?“, „Wann können wir den Output X (Feature, Capability, Produkt) erwarten?“ Diese Fragen sind alle valide. Sie führen nur meistens zu der Problematik, dass die Antworten darauf meistens nur Vermutungen, Fiktion oder gar Lügen sind.

Eine Lösung stellen „Outcome-basierte Roadmaps“ dar. Umso größer die Unsicherheit ist, dass ein Output ein gewünschtes Outcome erzielt, umso hilfreicher ist es die Roadmap nach den Outcomes zu planen. Dabei sollte der Fokus nicht auf einem einzelnen Outcome liegen sondern ein Set an Outcomes erstellt werden. Hilfreich kann hierfür das Modell der Customer Journey sein, welches dabei hilft Nutzerverhalten zu visualisieren (alternativ: Impact Mapping oder Outcomes Mapping).

Teil IV – Outcome-orientiertes Organisieren

Ein häufiges Problem in vielen (großen) Unternehmen ist ihre Organisationsstruktur, die nicht primär auf die Generierung von Outcomes ausgerichtet ist. Stattdessen liegt der Schwerpunkt (einzelner Abteilungen) oft auf dem „Tun von Dingen“ (Output), was eine Ausrichtung auf tatsächliche Ergebnisse und Wertbeiträge (Outcomes) vernachlässigt:

• Entwicklung – Code (Output)
• Qualitätssicherung – Tests (Output)
• Technische Doku – Text (Output)
• Support, Vertrieb, …

Dabei steht der Kunde an einem Ende und die Umsetzung erfolgt am anderen Ende. Wenn wir herausfinden wollen, wie wir einem Kunden helfen können, brauchen wir frühzeitig Feedback, um den Prozess und damit die Richtung notfalls korrigieren zu können. Das erfordert frühzeitige Zusammenarbeit zwischen den Abteilungen.

Das Managen der Stakeholder-Erwartungen stellt eine Herausforderung dar, wenn der Fokus sich stärker auf den Outcome als auf den Output richtet. Sie sind es meistens gewohnt und brauchen es auch für ihre Prozesse einen genauen Zeitpunkt und einen festen Satz an Features geliefert zu bekommen.

Wann sind wir aber fertig, wenn wir nun Outcomes in den Fokus rücken: wir hören auf an einem Thema zu arbeiten, wenn wir genug Fortschritt gemacht haben, um zufrieden zu sein. Wann wird das sein? Entweder wir legen uns auf konkrete Zahlen fest (z. B. Anzahl der Klicks erreicht N) oder wir leben mit unscharfen Antworten

HBR.com hat beim Wechsel von Output- zu Outcome-basiertem Arbeiten den Backlog komplett geleert: „Ehrlich, wir hätten die Tickets sowieso nicht gemacht. Wir haben nichts verloren außer die falsche Hoffnung, dass das Ticket irgendwann gemacht wird.“

Priorisierung

Der Fokus auf Output macht es schwierig Aufgaben zu priorisieren. Wenn wir nicht wissen, welches Feature welchen Outcome bewirkt, wie sollen wir dann priorisieren?

Risiko beim Wechsel zu Outcomes

Im Buch wird von HBR.com berichtet, welche die Stakeholder aufforderten, beim Verfassen von neuen Tickets immer den gewünschten Outcome zu formulieren. Hierfür wirde die Ticketeingabemaske um das Feld „WAS“ erweitert. In dieser sollte geschrieben werden was erreicht werden sollte und wie die zugrundeliegende Hypothese für das gewünschte Feature lautet. Diese Umstellung der Denkweise (WAS statt nur WIE) und den zusätzlichen Aufwand waren viele Stakeholder nicht gewohnt.

„Es ist für alle schwer gedanklich von der konkreten Welt mit Features zu der abstrakten Welt mit Outcomes wechseln.“

Kritische Stakeholder haben sich zurückgelassen gefühlt: bisher haben sie immer den Eindruck gehabt genau zu wissen woran gearbeitet wird (Output). Outcomes sind hingegen abstrakt und du es wird nicht immer gewusst, was genau gemacht wird. Daher wirkt die neue Denkweise zunächst einerseits wie ein Kontrollverlust. Andererseits sind die Leute die herausfinden was zu tun ist (Outcome), nicht länger die Personen, die ein Ergebnis realisieren (Output generieren) – die Verantwortlichkeiten werden separiert.

Man muss offen dafür sein zu scheitern und ebenfalls offen dafür sein darüber zu sprechen!

Teil V – Outcomes für die Transformation

Outcomes sind nicht nur für Produkte hilfreich sondern auch bei der Anpassung der Art und Weise wie wir arbeiten – um die Organisation zu transformieren. Hier funktioniert das selbe Denkmuster: Wie können wir das Verhalten der Mitarbeiter so verändern, dass wir bessere Geschäftsergebnisse erzielen?

„Outcomes based thinking is, in fact, the key to transformation.“

Bei der Outcome-basierten Transformation gilt es zu beachten:

• Deine Kollegen sind deine Kunden.
• Alles ist ein Outcome.
• Alles ist ein Experiment.

Wenn man versucht eine Organisation zu transformieren, versucht man die Art und Weise, wie eine Organisation arbeitet, zu ändern. Es geht also darum das Verhalten der Kollegen zu ändern. Die Grundlage hierfür ist es, die Ansichten, Motivationen dieser und die selbst beabsichtigte Verhaltensänderung zu verstehen. Das Ausdrücken der Veränderungen in Outcomes erlaubt es Veränderungsprogramme zielgerichtet durchzuführen.

Das Verhalten von einer Organisation zu ändern ist eine schwierige Aufgabe, die nicht einfach gelöst werden kann, indem man sie am Reisbrett entwickelt. Stattdessen profitiert sie von einem handlungsorientierten Ansatz (Experimenten). Man muss etwas versuchen und wenn es wirkt weiterverfolgen. Wenn nicht, dann startet man das nächste Experiment.

Resume

Das Buch ist nicht nur wegen seiner knappen Seitenanzahl kurzweilig zu lesen. Es gibt interessante Denkanstöße dazu wie Produkte und Projekte gesteuert werden können, um am Markt erfolgreich zu sein. Das Beispiel mit HBR.com hat nicht ganz meinen Nerv getroffen aber mit etwas Abstraktionsvermögen kann man die Inhalte wunderbar auf den eigenen Kontext projizieren.