Was macht die Rolle des Product-Owners eigentlich aus?
Entscheiden.
Gleichzeitig drehen sich viele Diskussionen immer nur um Backlog-Management-Tools oder darum, wie Roadmaps erstellt oder User-Stories formuliert werden.
Sollten Product-Owner nicht stattdessen lieber ihre Entscheidungsfähigkeiten trainieren?
Wie komme ich darauf?
Stell dir vor, du kündigst deinen Job, um eine neue Stelle bei einem anderen Unternehmen anzutreten. Die Stelle ist großartig. Deine Kollegen sind nett. Die Arbeit erfüllt dich. Und am Ende des Jahres wirst du sogar befördert.
War es eine gute Entscheidung, deinen Job zu kündigen und die neue Stelle anzutreten?
Nun stell dir abermals vor, du kündigst deinen Job, um eine neue Stelle anzutreten. Die neue Position entpuppt sich aber als Fehltritt. Deine Kollegen sind intrigant. Du fühlst dich unwohl. Und zum Ablauf der Probezeit wirst du entlassen.
Ich frage dich wieder: War es eine gute Entscheidung, deinen Job zu kündigen und die neue Stelle anzutreten?
Dieses Beispiel stammt von Annie Duke. Annie ist ehemalige World-Series-of-Poker-Champion und Autorin des Buches „Thinking in Bets“. Das Problem an diesem Beispiel ist, dass uns Annie in keinem der beiden Fälle aussagekräftige Informationen über den Prozess gegeben hat, der zu der Entscheidung geführt hat. Lies dir die beiden Beispiele nochmals durch. Du wirst lediglich zwei Informationen finden: Zum einen eine nüchterne und fast identische Beschreibung dessen, was in die Entscheidung eingeflossen ist. Zum anderen, wie die Entscheidung ausgefallen ist. Können wir daraus schließen, dass die Kündigung im ersten Fall eine gute Entscheidung und im zweiten Fall eine schlechte Entscheidung war?
Nein. Es ist ein typisches Beispiel für ein Phänomen, das Annie als „Resulting“ – also die Bewertung einer Entscheidung allein anhand ihres Ausgangs – bezeichnet.
Der Erfolg professioneller Pokerspieler hängt davon ab, wie gut sie entscheiden.
Deshalb tun sie gut daran, „Resulting“ zu vermeiden.
Im Kapitel „The Buddy System“ schreibt Annie, dass Pokerspieler deshalb ihre Spiele mit anderen Pokerspielern besprechen. Dabei gilt eine eiserne Regel: Es wird niemals das Ergebnis des Pokerspiels genannt. Stattdessen werden Entscheidungsverläufe analysiert. Die Teilnehmer dieser Runden hinterfragen Annahmen, beleuchten verwendete Daten und decken kognitive Verzerrungen auf. Sie stellen sich die Fragen: Welche Ziele wurden verfolgt? Welche Alternativen wurden erwogen? Wo lauern unbewusste Biases?
Es geht darum, Feedback zum Entscheidungsprozess zu geben, aber nicht zum Ergebnis. Denn damit lässt sich trainieren, in Zukunft besser zu entscheiden.
Willst du deine Entscheidungsfähigkeiten trainieren und verbessern?
Dann kannst du dir viel von professionellen Pokerspielern und Annies Arbeit abschauen. Und bevor du jetzt denkst: Ich bin Product-Owner und kein Spieler – lass mich dich fragen:
Besteht darin wirklich ein so großer Unterschied?
Ich denke, der Unterschied ist geringer, als viele glauben. Am Ende vereint die Entscheidung, welcher Eintrag im Backlog priorisiert wird, und die Frage, welche Karte gespielt wird, doch das Gleiche: Es ist eine Entscheidung, die getroffen wird, obwohl uns nicht alle Informationen bekannt sind. Du kannst niemals zu 100 % sicher sein, dass die Kunden das neue Feature annehmen werden, – genauso wenig weißt du, was deine Gegner für ein Blatt auf der Hand haben.
Nachdem wir das geklärt haben, will ich dir 5 Werkzeuge verraten, die du nutzen kannst, um deine Entscheidungen zu überprüfen. Ich empfehle dir, dies nicht allein zu machen – lade dazu andere Product-Owner ein und starte mit ihnen einen „Decision Pod“, in dem ihr euch gegenseitig zu euren Entscheidungsprozessen Feedback gebt. Natürlich kannst du die Werkzeuge auch direkt beim Treffen einer Entscheidung einsetzen.
Diese 5 Werkzeuge können euch dabei helfen.
Werkzeug 1: Delegation-Matrix – Wer sollte involviert sein?
Die richtige Anzahl an Personen beeinflusst die Qualität der Entscheidung.
Um die Anzahl zu bestimmen, hilft dir die Delegation-Matrix. Die Matrix hilft dir zu erkennen: Welche Entscheidungen solltest du delegieren? Welche solltest du selbst treffen? Und wobei solltest du vorab beraten oder gar zusammen entscheiden?
Hier die Delegation-Matrix im Detail:
Vertikale Achse: Risiko der Entscheidung
Wie viel Risiko birgt die Entscheidung? Das Risiko reicht hierbei von umkehrbar bis unumkehrbar:
- Umkehrbares Risiko: Diese Entscheidungen sind einfach rückgängig zu machen.
- Unumkehrbares Risiko: Diese Entscheidungen sind nicht mehr rückgängig zu machen. Einmal getroffen, musst du mit den Konsequenzen langfristig leben.
Horizontale Achse: Grad der benötigten Unterstützung
Wie viel Zustimmung und Unterstützung von den Beteiligten oder Betroffenen ist erforderlich, um die Entscheidung erfolgreich umzusetzen? Hierbei reicht der Grad der benötigten Unterstützung von wenig bis viel:
- Es ist weder Unterstützung noch Zustimmung oder Akzeptanz der Betroffenen notwendig.
- Die Mitarbeit und das Engagement vieler Personen werden benötigt und es braucht viel Akzeptanz und Zustimmung der Betroffenen.
Unterteilen wir die beiden Achsen jeweils in zwei Hälften, ergeben sich vier Quadranten. Sie helfen dir zu bestimmen, ob du die richtige Anzahl an Personen für deine Entscheidung involviert hast. Lass uns einige Beispiele betrachten:
- Erst beraten und dann entscheiden: die Reihenfolge des Product-Backlogs
- Zusammenarbeiten: die Definition eines Sprint-Ziels im Sprint-Planning
- Einfach die Entscheidung treffen: Stakeholder zum Sprint-Review einladen
- Delegieren: die Erarbeitung und Beschreibung von Einträgen des Product-Backlogs
Ein weiteres Werkzeug bei Entscheidungen ist es, die Vor- und Nachteile abzuwägen. Die gute Pro-und-Kontra-Liste. Im Produktmanagement nennen wir das:
Werkzeug 2: „Compare and Contrast“ – Welche Optionen gibt es?
Baruch Fischhoff, Professor an der Carnegie Mellon University, hat zusammen mit seinen Kollegen 105 Mädchen im Teenageralter befragt, welche Entscheidungen sie in der jüngsten Vergangenheit getroffen haben. Dabei fiel ihm etwas Merkwürdiges auf.
Wenn du so tickst wie ich, denkst du bei Entscheidungen an Situationen, in denen du zwischen zwei oder mehr Möglichkeiten wählen musst. Will ich heute Pizza oder Nudeln essen? Welche Schuhe ziehe ich zur Arbeit an? Nehme ich das Auto, den Bus oder mein Fahrrad?
Allerdings hatten die Entscheidungen der Teenager selten diese Wahlmöglichkeit. Als Baruch Fischhoff diesem Phänomen auf den Grund ging, erkannte er, dass die meisten Entscheidungen der Teenager Entscheidungen ohne echte Alternativen waren. Also Entscheidungen der Art:
„Ich entscheide, ob ich heute zur Schule gehe oder nicht.“
Fischhoff bezeichnet diese Art von Entscheidung als „Ob-oder-ob-nicht“-Entscheidung – und sie machte 65 % aller Entscheidungen der Teenager aus. Was ist das Problem mit „Ob-oder-ob-nicht“-Entscheidungen?
Sie schränken die Perspektive stark ein. Im Gegensatz zu „Compare and Contrast“-Entscheidungen. Hierbei fragen wir nicht: „Machen wir’s oder nicht?“, sondern stellen mehrere Handlungsoptionen systematisch gegenüber und wägen sie ab.
Die Vorteile dieses Vorgehens ähneln dem der Pro-und-Kontra-Liste:
- Breiterer Blickwinkel: Wir vermeiden Tunneldenken und entdecken alternative Lösungswege.
- Risikominimierung: Durch das direkte Vergleichen lassen sich Stärken und Schwächen jeder Option transparenter bewerten.
- Bessere Priorisierung: Statt eine Idee blind zu verfolgen, entscheiden wir auf Basis qualitativer und quantitativer Kriterien, welche Lösung aktuell den höchsten Mehrwert bietet.
Der letzte Punkt ist besonders wichtig:
Da wir im Produktmanagement nie perfekte Informationen haben, wird es niemals die eine beste Entscheidung geben können. Stattdessen bedeutet „beste“ deshalb: die beste unter allen Optionen, die zur Verfügung stehen. Und deshalb kommen wir nur dann zu einer besseren Entscheidung, wenn wir mehr Optionen in Erwägung ziehen.
Nochmal in anderen Worten ausgedrückt:
Die Güte einer Entscheidung wird durch die Anzahl der Optionen maßgeblich mitbestimmt.
Hierzu ein Beispiel:
Nehmen wir an, du identifizierst den Bedarf, die Suchfunktion in der App zu verbessern. Statt sofort mit „Autocomplete“ zu starten, überlegst du mit deinem Scrum Team weitere Optionen: eine KI-basierte Autocomplete-Funktion, eine Filterleiste nach Kategorien und eine verbesserte, manuelle Suchsyntax. Im Workshop mit Stakeholdern und in Nutzertests vergleicht ihr Aufwand, potenziellen Nutzen und technische Machbarkeit. Am Ende entscheidet ihr euch für die Filterleiste, weil sie schnell implementierbar ist, messbar den meisten Mehrwert liefert und als Basis für spätere KI-Features dient.
Im Leben eines Product-Owners gibt es jedoch Situationen, in denen „Compare and Contrast“-Entscheidungen wie gerade versagen. Was uns zum nächsten Werkzeug bringt:
Werkzeug 3: High-Stakes-Entscheidungen – Was sind die Vorteile, was die Nachteile?
Ein Beispiel:
- Option 1: Die Entwicklung eines neuen Features wird wahrscheinlich einen zusätzlichen Umsatz von 50.000 EUR erzeugen, da wahrscheinlich 5 % mehr Neukunden gewonnen werden. Die geschätzten Entwicklungskosten für das Feature betragen 10 Arbeitstage.
- Option 2: Wird ein wichtiges Compliance-Feature bis zum Ende des Monats nicht entwickelt und veröffentlicht, wird wahrscheinlich eine Strafe von 25.000 EUR fällig. Die geschätzten Entwicklungskosten betragen ebenfalls 10 Arbeitstage.
Wenn du nur 10 Arbeitstage zu verplanen hast, welche Option würdest du wählen? Entscheidest du dich für die wahrscheinliche Umsatzsteigerung oder versuchst du, die Strafe zu vermeiden?
Ich weiß, was du denkst:
Selbst wenn wir eine Wahl haben, sind beide Optionen schlecht. Auf der Pro-und-Kontra-Liste steht jeweils ein Kontra für beide Optionen. Blöd, oder?
In dieser Situation hilft es, eine Entscheidung erst mal als das zu erkennen, was sie ist:
Ein Dilemma.
Und jetzt gilt es – wenn du eine bessere Entscheidung treffen willst –, über Alternativen zu Option A und B nachzudenken. Neue Optionen zu finden, die weder die Nachteile von Option A noch von Option B haben, ist der anerkannte Weg, einem Dilemma zu entkommen.
Nach der Dilemma-Theorie gibt es hierfür drei Wege:
- Wir können beides wählen: Entscheidung für Option A und B. Hierzu gehören nicht nur der Kompromiss, sondern auch der Scheingegensatz, die übersummative Verbindung, die paradoxe Verbindung usw.
- Wir können keines wählen: Entscheidung, weder Option A noch Option B zu wählen. Durch die Änderung des Kontexts verlieren Option A und B ihre strikte Geltung.
- Wir wählen keine der bisherigen und auch keine weiteren Optionen: Der Kontext des ursprünglichen Dilemmas wird ganz verlassen und erfordert keine Entscheidung mehr, sondern löst sich auf.
Lass uns hierzu ein Beispiel aus „Der Herr der Ringe“ betrachten:
Beim Rat von Elrond in Bruchtal steht die Gemeinschaft vor einem scheinbar unlösbaren Dilemma.
- Option A: den Ring nach Gondor bringen, um ihn mit militärischer Macht zu verteidigen.
- Option B: ihn weit entfernt zu verstecken, in der Hoffnung, dass Sauron ihn nie findet.
Beide Optionen bergen große Risiken – die eine führt zur direkten Konfrontation mit einer übermächtigen Streitkraft, die andere birgt die Gefahr, dass der Ring irgendwann entdeckt und missbraucht wird.
Die Lösung? Weder Option A noch B. Stattdessen schlägt Gandalf vor, den Ring ins Herz des Feindeslandes zu bringen – nach Mordor –, um ihn dort zu vernichten. Eine neue Option entsteht, indem der gesamte Kontext des Denkens verändert wird: weg von Verteidigung oder Verstecken, hin zur aktiven Zerstörung des Problems an der Wurzel.
Nun genug von Zwergen, Elben und Menschen – und wieder zurück zu Entscheidungen.
Werkzeug 4: Eisenhower-Matrix – Welche Priorität hat es?
Bisher haben dir die Werkzeuge geholfen, diese Fragen zu beantworten:
- Wer sollte involviert sein?
- Welche Optionen gibt es?
- Was sind die Vorteile, was die Nachteile?
Was fehlt noch? Natürlich: Wie wichtig ist die Entscheidung?
Hierbei hilft dir die Eisenhower-Matrix:
Hier die Quadranten mit einem Beispiel erklärt:
- Quadrant 1: Niedrige Wichtigkeit & niedrige Dringlichkeit. Aufgaben ohne strategischen Mehrwert und ohne Zeitdruck – hier genügt oft ein schnelles „Einfach die Entscheidung treffen“, z. B. das Einladen von Stakeholdern zum Sprint-Review.
- Quadrant 2: Niedrige Wichtigkeit & hohe Dringlichkeit. Dringende, aber unkritische Tätigkeiten delegierst du am besten – etwa die Erarbeitung und Beschreibung von Einträgen im Product-Backlog.
- Quadrant 3: Hohe Wichtigkeit & niedrige Dringlichkeit. Strategisch wertvolle Themen ohne akuten Zeitdruck werden zunächst mit den Stakeholdern beraten und dann entschieden – zum Beispiel die Priorisierung und Reihenfolge des Product-Backlogs.
- Quadrant 4: Hohe Wichtigkeit & hohe Dringlichkeit. Kritische Entscheidungen mit unmittelbarem Handlungsbedarf fallen unter „Zusammenarbeiten“, etwa die gemeinsame Definition des Sprint-Ziels im Sprint-Planning.
Werkzeug 5: „Two-Way Door“ – Wann muss entschieden werden?
Nicht jede Entscheidung muss sofort getroffen werden.
Manchmal kannst du dir mit der Entscheidung auch Zeit lassen. Aber es gibt auch Entscheidungen, bei denen du keine Minute länger warten solltest. Wann ist also der richtige Zeitpunkt für eine Entscheidung?
Hierfür gibt es ein gutes Vorgehen. Es geht auf Jeff Bezos zurück. Er erklärt es mit dieser Metapher: Einige Entscheidungen sind wie Türen. Sie können in beide Richtungen geöffnet werden. Diese Entscheidungen sind leichter rückgängig zu machen. Im Gegensatz dazu gibt es „One-Way Door“-Entscheidungen, die – sobald sie getroffen sind – nicht leicht rückgängig gemacht werden können. Daraus lässt sich die Handlungsempfehlung ableiten:
- Handelt es sich bei der Entscheidung um eine Two-Way-Door-Entscheidung? Dann entscheide sofort.
- Handelt es sich hingegen um eine One-Way-Door-Entscheidung? Dann solltest du dir für die Entscheidung Zeit lassen und sorgfältig abwägen – oder deine Entscheidung im Vorfeld mit schnellem Experimentieren und Testen absichern.
Hier ein Beispiel:
- One-Way-Door: Ein Product-Owner entscheidet, die komplette App-Architektur von einem monolithischen System auf eine Microservices-Architektur umzustellen.
- Two-Way-Door: Ein Scrum Team möchte die App-Performance verbessern. Deshalb entscheidet sich der Product-Owner des Teams dafür, mittels Feature-Flags eine neue Caching-Strategie einzuführen. Wenn sich Ladezeit oder Fehlerrate verschlechtern sollten, kann das Team das Flag einfach zurückschalten – alles ohne großen Roll-out-Aufwand. So behält das Team weiterhin seine Entwicklungsgeschwindigkeit und Flexibilität bei, ohne schwerwiegende Folgen für die Nutzer.
Was du als Product-Owner noch beherrschen solltest
Sicher Entscheidungen zu treffen ist nur eine von sechs Fähigkeiten, die erfolgreiche Product-Owner auszeichnen. Die anderen fünf lauten:
- Kundenwünsche zu erkennen und zu beschreiben
- Eine Vision zu entwickeln und zu kommunizieren
- Mit Experimenten und Tests Risiken frühzeitig zu minimieren
- Mit Stakeholdern zu kollaborieren
- Unterstützer für seine Produktidee zu gewinnen
Willst du diese Fähigkeiten nicht im Alleinstudium erlernen oder verbessern? Dann empfehle ich dir den Besuch des „Professional Scrum Product Owner – Advanced“-Trainings.
198 Product-Owner sind Peters und meiner Empfehlung in den letzten Jahren bereits gefolgt.