Outcome vs Output - Flucht aus der Feature Factory!

Vielleicht ist dir in letzter Zeit aufgefallen, dass der Unterschied von Output und Outcome im Produktmanagement in aller Munde ist. In diesem Artikel wollen wir uns heute einmal anschauen, was genau die beiden Begriffe bedeuten und wie du mit dem Bewusstsein für dieses Thema die Produktivität deines Teams dramatisch steigern kannst!

Product Delivery

Vielleicht ist dir in letzter Zeit aufgefallen, dass der Unterschied von Output und Outcome im Produktmanagement in aller Munde ist. Also wollen wir uns heute einmal anschauen, was genau die beiden Begriffe bedeuten und wie du mit dem Bewusstsein für dieses Thema die Produktivität deines Teams dramatisch steigern kannst!

Was sind Outcome und Output?

Die beiden Begriffe lassen sich super durch das einfache Beispiel erklären, das Sebastian im Video anspricht. Stell dir einen Bogenschützen vor, der seine Pfeile auf eine Zielscheibe schießt.

• Die Anzahl der verschossenen Pfeile ist in diesem Falle der Output des Bogenschützen, das Ergebnis einer konkreten Aktivität.
• Die Pfeile, die tatsächlich ins Schwarze getroffen haben, sind der Outcome des Bogenschützen.

Im Alltag von uns Produktmanager:innen sind die gelieferten Features die Pfeile, die der Bogenschütze schießt, also der Output. Der Outcome ist der Impact, welchen ein Feature am Ende für die Kund:innen wirklich hat.

Warum sind Outcome und Output wichtig für dich als Produktmanager:in?

Werde dir in erster Linie über die Unterscheidung der beiden Begriffe bewusst. Viele Menschen werden in ihrem Berufsleben darauf getrimmt, besonders viel zu produzieren und zu liefern. Dabei wird oft vergessen, was das tatsächliche Ergebnis dieser vielen Arbeit am Ende sein soll.

Genau deswegen ist es besonders wichtig, dass du aufmerksam den gewünschten Impact im Auge behältst. Ein messbarer Outcome aus deinem Output schafft Klarheit und hilft deinem Team, deutlich produktiver zu werden, mehr Wert beim Kunden zu schaffen.

So arbeitest du Outcome-orientiert

Um Outcome-orientiert zu arbeiten, musst du natürlich wissen, welchen Outcome du überhaupt anstrebst. Das Ziel deines Unternehmens kann beispielsweise sein, eure Bestandskund:innen zu halten. In messbaren Zahlen, also als KPI, wäre das die Reduktion des Churns.

Ein OKR-Framework kann dabei helfen, den Outcome zu messen, indem es die Rolle von Output und Outcome bei der Messung von Key Results klar definiert.

Ist das Ziel klar, kann dein Team klassisch mit verschiedenen Lösungen experimentieren und ausprobieren, wie es eine messbare Verbesserung der festgelegten KPI erreicht. So kannst du dich auf die Features konzentrieren, die wirklich ins Schwarze treffen.

1.    Mache den Outcome messbar

Ob der Outcome in deinem Unternehmen bereits messbar gemacht wird, ist ein Indikator dafür, ob die Organisation Output- oder Outcome-fokussiert ist. Für ersteres verwendet Thomas die passenden Ausdrücke ‚Output-Organisation‘ und ‚Feature-Factory‘.

„Wenn ich einfach nur liefere, ohne hinterher zu messen.“

Key results können dabei helfen, den Erfolg von Outcomes zu messen. Sie sind ein wesentlicher Bestandteil von OKRs und ermöglichen es, zu bestimmen, wann ein Ziel erreicht ist und wie es sich auf die Ergebnisse auswirkt.

Wenn das bei dir der Fall ist, überlege gemeinsam mit deinen Stakeholdern, was das Ziel für euch als Organisation ist und wie du und dein Team in diese Ziele einzahlen kannst. Das solltet ihr mit sinnvollen KPIs verknüpfen, damit ihr messbar euer Produkt verbessern könnt.

Mit dieser Basis kannst du vor und nach ausrollen eines Features messen und Zahlen vergleichen – so kannst du zuverlässig sagen, ob ihr den gewünschten Outcome erzielt habt. Diese Zahlen können dir auch in der Kommunikation mit internen Stakeholdern helfen, wie z.B. deiner Chef:in.

2.    Gute Outcomes statt viel Output

Egal, ob deine Organisation noch Output- oder bereits Outcome-orientiert arbeitet, werde dir als Produktmanager:in bewusst, welchen Nutzen die Features (Output) wirklich bringen und wie sie dich näher an deine Ziele (Outcome) bringen.

Frage dich:

• Bei welchen Backlog Items sind wir uns schon recht sicher, dass unsere Kunden dieses Feature wirklich brauchen (Validierung)
• Für alle anderen Backlog Items: Kann ich den IMPACT beim Kunden schon vorher testen, sodass ich nur stark validierte Feature entwickeln muss?

Als Faustformel von Thomas heißt das:

„Ich möchte möglichst viel Outcome pro Output generieren.“

Heißt auf gut Deutsch: Entwickle wirklich nur gut validierte Feature!

Das Wichtigste in Kürze

• Outcome steht für den Impact deines Produkts bei den Kund:innen.
• Output steht für den Aufwand, welchen dein Team benötigt, um den gewünschten Outcome zu erreichen.
• Miss und vergleiche deine Zahlen vor und nach einer Implementierung, um zu sehen, ob du den gewünschten Impact wirklich erreichst und die tatsächlichen Veränderungen sichtbar werden.
• Dein Team arbeitet erheblich effizienter, wenn es weniger Output kreieren muss, um den tatsächlichen Outcome zu erreichen.

‍

‍