Illustration: Eine Person steht vor einer bunten Auswahl von Optionen, die im Kreis angeordnet sind.
Agile

Mit Behavioral Economics als Product Owner bessere Entscheidungen treffen

Lesezeit
12 ​​min

In diesem Blogartikel möchte ich die Erkenntnisse der sogenannten Behavioral Economics nutzen, um auf Fallstricke im Alltag eines Product Owners aufmerksam zu machen und Ideen zu teilen, wie wir diesen begegnen können.

Product Owner treffen eine Vielzahl an Entscheidungen: Passt die Priorisierung meiner Product Backlog Items nach wie vor oder haben sich die Rahmenbedingungen am Markt verändert, sodass ich umpriorisieren muss? Welche Features plane ich für das nächste Release? Sollte ich bald wieder ein User Shadowing durchführen? Sind wir auf einem guten Weg, unser Produktziel zu erreichen oder müssen wir unsere Strategie nochmals überdenken?

Es gibt eine Vielzahl an Methoden und Frameworks, die dabei helfen, solch knifflige Fragestellungen strukturiert anzugehen, um zu einer nachvollziehbaren Entscheidung zu gelangen. Doch auch wenn wir an unsere Objektivität glauben, sind unsere Entscheidungen nicht immer rational – in den meisten Fällen sind sie sogar das Gegenteil.

Die Irrationalität unserer Produktentscheidungen

Lange Zeit wurde in den Wirtschaftswissenschaften auf das Menschenbild des Homo oeconomicus zurückgegriffen, um grundlegende Zusammenhänge in der Theorie zu veranschaulichen. Der Homo oeconomicus beschreibt ein ausschließlich rational handelndes Wesen, das Entscheidungen zugunsten der eigenen Wertmaximierung fällt.

Jedoch geriet dieses Menschenbild mit den Erkenntnissen aus Psychologie und Neurowissenschaften zunehmend in Kritik. Spätestens seit Daniel Kahnemans Bestseller „Thinking, Fast and Slow“ (2011) dürfte uns klar sein, dass die meisten unserer Entscheidungen intuitiv und unbewusst gefällt werden.

Und das ist auch gut so, denn im Schnitt treffen wir über 35,000 Entscheidungen jeden Tag. Wenn wir über jede Entscheidung aktiv nachdenken müssten, würden wir zusammenbrechen.Illustration: Menschen stehen im Zentrum eines Kreises aus angedeuteten User Interfaces.

In seinem Buch unterteilt Kahnemann die menschliche Entscheidungsfindung in zwei Systeme: System 1 (intuitiv, emotional, schnell, unbewusst) und System 2 (rational, langsam, bewusst).

In den meisten Fällen befindet sich unser Gehirn im Energiesparmodus und folgt unserem intuitiven System 1. Unser Autopilot reicht aus, wenn wir beispielsweise „2+2 = ?“ ausrechnen oder auf einer leeren Straße Auto fahren. In kniffligen Fällen zieht unser Hirn jedoch unser System 2 hinzu, beispielsweise wenn wir eine komplexe Rechenaufgabe lösen müssen oder in einer engen Parklücke einparken.

Eindrücke und Emotionen aus System 1 sind der Input für unser System 2, das daraufhin scheinbar bewusste Entscheidungen generiert. Obwohl wir uns als rationale Wesen sehen, zeigt sich, dass in 95 % der Fälle unser System 1 die Oberhand hat.

Unser System 1 ist jedoch nicht perfekt – im Gegenteil. Um Energie zu sparen und schnell zu einer Entscheidung zu gelangen, verwendet unser System 1 Heuristiken oder auch Abkürzungen. Diese beruhen auf persönlichen Erfahrungen, Vereinfachungen und Daumenregeln in Hinblick auf ein Problem. Oft fokussieren wir uns hierbei aber nur auf einen Teilaspekt eines komplexen Problems und sind dadurch affin für kognitive Verzerrungen (Biases), die unsere Entscheidungen unbewusst maßgeblich beeinflussen. (Stonehouse 2021)

Beispiele aus dem Alltag eines Product Owners und wie wir damit umgehen können.

Availability Heuristic

In seinem Buch „PsyConversion“ beschreibt Philipp Spreer die Availability Heuristic als den Effekt, dass wir Ereignissen, für die unser System 1 schnell ein passendes Beispiel in unserer Erinnerung findet, einen hohen Wert beimessen, ohne dass dies unbedingt stimmen muss. Ein häufig genanntes Beispiel ist die Flugangst: Obwohl statistisch gesehen Flugzeuge extrem selten abstürzten, sind diese Ereignisse durch die hohe mediale Präsenz bei vielen Menschen sehr präsent. Dadurch überschätzen sie die Wahrscheinlichkeit eines Absturzes.

Als Product Owner sind uns unterschiedliche Dinge sehr präsent. Beispielsweise erinnert man sich sehr gut an den Absturz der Produktivumgebung, weil das Telefon danach ununterbrochen klingelte. Auch die lebhafte Erzählung einer Nutzerin, wie sie einen Fehler gemacht hat, weil das System die Filter seitenübergreifend speichert, bleibt stärker in Erinnerung als eine flüchtig gelesene Mail mit einer anderen Bitte. Wenn ich als Product Owner über die kommenden Features oder deren konkrete Ausgestaltung nachdenke, fallen mir diese Situationen wahrscheinlich direkt ein und andere rücken in den Hintergrund.

Illustration: Ein Mann schaut auf eine Auswahl von Hinweisen und Kommentaren eines angedeuteten User Interfaces.

Um Verzerrungen aufzudecken, kann es hilfreich sein, sich die Datenlage genau anzusehen: Wie häufig ist das System im letzten Jahr wirklich abgestürzt? Hat noch jemand Schwierigkeiten mit den Filtern gemeldet oder ist es ein Einzelfall?

Ebenso kann es helfen, nochmals Zeit in die Problemanalyse zu investieren, bevor wir uns für eine Lösungsidee entscheiden. Hier kann uns beispielsweise der Opportunity-Solution-Tree von Teresa Torres weiterhelfen. Der Tree hilft uns bei der strukturierten Entwicklung mehrerer Lösungsmöglichkeiten für ein spezifisches Problem und beugt somit unvorteilhaften Produktentscheidungen vor. Dabei priorisiert man verschiedene Opportunities (Probleme/Bedürfnisse) im Hinblick auf das gewünschte Outcome und sammelt erst im Anschluss Lösungsideen. Schnell wird man merken, dass die erste Lösung, die einem eingefallen ist, nur eine von vielen ist.

Status Quo Bias

Der Mensch ist ein Gewohnheitstier, getreu dem Motto „Das haben wir schon immer so gemacht“. Gewohnheiten reduzieren Komplexität, stiften Sicherheit und vermeiden, dass wir eine getroffene, falsche Entscheidung schmerzlich widerrufen müssen. Deswegen haben wir die Neigung, den aktuellen Zustand aufrechterhalten zu wollen. (Spreer 2018)

Als Product Owner sind wir oft Teil eines größeren Unternehmens, in dem feste Denkstrukturen, Prozesse und Vorgehensweisen vorherrschen. Beispielsweise gibt es hier häufig die Vorgabe, dass der Kontakt zu Endnutzer:innen erst nach Freigabe oder nur an bestimmten Testing-Tagen stattfinden darf.

Aber auch als Product Owner bringt man Gewohnheiten mit. Beispielsweise entscheidet man sich dafür, den Entwickler:innen feste Lösungen für die Umsetzung vorzugeben, anstatt gemeinsame Brainstormings durchzuführen.

Obwohl Gewohnheiten uns oft Zeit und Stress ersparen, können wir durch sie auch wichtige Chancen verpassen. Wenn wir als Product Owner in unserem Umfeld Veränderung vorantreiben wollen, können wir beispielsweise die Veränderung in einen positiven Rahmen setzen. Anstatt zu sagen „Das Vorgehen ist schlecht, weil …“, könnte man beginnen mit „Das Vorgehen hat uns bis hierher gut gedient, nur haben sich die Rahmenbedingungen verändert.“.

Um unsere eigenen Gewohnheiten zu durchbrechen, können wir mit schrittweisen, kleinen Veränderungen beginnen, die man mit dem Team in der Retrospektive beleuchten kann. Wenn man beispielsweise das kreative Potenzial seiner Teammitglieder stärker nutzen möchte, kann man mit einzelnen Workshops/Kreativ-Sessions beginnen und sich schrittweise einer fortlaufenden Co-Creation annähern.

Confirmation Bias

Nachdem wir eine Entscheidung getroffen haben, tendieren wir dazu, uns nur auf bestätigende Informationen zu fokussieren bzw. Informationen im Sinne dieser Entscheidung auszulegen. System 1 versucht seine Entscheidung zu rechtfertigen und Inkonsistenzen zu vermeiden, sodass System 2 nicht aktiviert werden muss, um die Entscheidung nochmals rational zu bewerten. (Spreer 2018).

Als Product Owner treffen wir viele Entscheidungen und manchmal auch die falsche. Agile Methoden helfen uns dabei, unseren Weg innerhalb kurzer Zeit, basierend auf den neuesten Erkenntnissen, anzupassen. Inspect & Adapt ist hier das Stichwort. Allerdings ist es an dieser Stelle verlockend, in User Testings nur auf bestätigende Evidenz zu hören oder die Faktenlage so zu interpretieren, dass sie die eigene Entscheidung unterstützt. Irgendwie schmerzt es uns, getane Arbeit wieder wegzuwerfen, auch wenn es die sinnvollere Entscheidung wäre. Häufig bauen wir stattdessen noch „drumherum“, in der Hoffnung, es ändert die grundlegende Situation.

Das Problem begegnet uns häufig vor der Delivery, schon in der Discovery-Phase. Ed Catmull sagte bereits: „Discovery, by definition means that you don’t know the answer when you start“. Es klingt so einfach, aber welcher Product Owner hat sich noch nie in eine Idee verliebt und sich für deren Umsetzung entschieden, bevor die Discovery ernsthaft begonnen hat?

Es gibt hierbei verschiedene Wege, wie wir diesen Situationen begegnen können. Ein sehr wichtiger Faktor ist die Etablierung einer konstruktiven Fehlerkultur. Basis hierfür ist ein offenes, vertrauensvolles und konstruktives Umfeld. Dies senkt die Hürde, über Fehler offen zu sprechen. Feste Austauschformate, in denen bewusst nur über Fehler gesprochen wird, können helfen.

Ebenso ist es wichtig, Entscheidungen unter Einbezug von Daten und Fakten zu beleuchten. Hier kann es helfen, diese Beurteilung gemeinsam mit neutralen Kolleg:innen vorzunehmen, um einen unvoreingenommenen Blick auf die vorliegenden Daten zu werfen.

Der wichtigste und wohl schwierigste Tipp an dieser Stelle ist, sich selbst kritisch zu hinterfragen. Nur, wenn man ehrlich zu sich selbst ist, eigene Ideen verwirft und fehlerhafte Entscheidungen eingesteht, kann man in Zukunft gute Produktentscheidungen treffen. Selbstreflexion ist ein Prozess und bedarf stetiger Übung.

Liking

Liking beschreibt die menschliche Tendenz, schneller von Menschen überzeugt zu sein, die wir sympathisch finden. Sympathie entsteht mitunter durch Ähnlichkeit zu uns selbst, Lob bzw. Anerkennung oder durch Kontakt/Kooperation (bei gemeinsamer Zielerreichung). (Spreer 2018)

Als Product Owner sind wir täglich im Austausch mit vielen Menschen: mit Kund:innen, Stakeholdern oder unserem Team. Von diesen Menschen nehmen wir Feedback und Impulse auf, gehen auf ausgewählte Wünsche und Bedürfnisse ein und rechtfertigen vor ihnen unsere Produktentscheidungen. Unsere Entscheidungen können nicht alle Beteiligten zufriedenstellen.

Und wer kennt diese Situationen nicht: Wir gehen mit einem Stakeholder mittags essen, weil wir uns auch privat gut verstehen und wir erhalten eine „Könntest du nicht schnell im nächsten Sprint mal …“-Anfrage. Und wer hat sich noch nicht bei dem Gedanken ertappt „Für diesen Stakeholder baue ich sicherlich so schnell kein Feature mehr ein, nachdem er uns in der letzten Präsentation vor allen kritisiert hat“, unabhängig davon, ob der Impuls valide ist? Oder beim User Shadowing erkennen wir uns selbst wieder in einem „das hätte auch mir passieren können“. Wir fühlen den Bedarf in dieser Situation viel intensiver als solche in anderen Situationen, mit denen wir nicht räsonieren.

Product Owner sind soziale Wesen und das ist auch gut so. Um den oben genannten Situationen bewusster zu begegnen, kann man beispielsweise neue Ideen oder Pain Points objektiver bewerten, beispielsweise mit Hilfe einer Nutzwertanalyse. So fällt man sein Urteil unabhängig vom Ideengeber oder der Identifikation mit einer Situation. Zudem kann man bei der Teamzusammensetzung oder Sparring darauf achten, mit Personen zu arbeiten, die ganz anders sind als man selbst, von denen man weiß, dass man ehrliches Feedback bekommt. Mit einem offenen Mindset und diversen Teamzusammensetzungen kommen die besten Ideen zustande.

Key Takeaways

Die oben genannten Effekte sind nur wenige von sehr vielen Beispielen, die uns im Alltag als Product Owner begegnen. Wir müssen uns an dieser Stelle bewusst machen, dass auch Product Owner keine rein rationalen Wesen sind, die immer die objektiv beste Entscheidung treffen. Und das ist auch gut so: Eine gute Intuition ist ein sehr wertvoller Begleiter, der es uns erlaubt, einzigartige, mutige und kreative Entscheidungen zu treffen.

Trotzdem hilft es uns in vielen Situationen, nochmals einen Schritt zurückzugehen und uns selbst sowie unsere Entscheidungen zu reflektieren. Dabei gibt es nicht den einen Moment zur Selbstreflexion. Große Ereignisse, wie beispielsweise das Scheitern eines Produktes, aber auch kleine Ereignisse, wie beispielsweise die Entscheidung für oder gegen ein Product Backlog Item, können eine Gelegenheit sein, über die einzelnen Biases nacheinander nachzudenken.

Wir werden mit Sicherheit Entscheidungen finden, die wir heute anders treffen würden. Aber daraus zu lernen und in Zukunft ein besseres Gespür für eine eigene Entscheidungsfindung zu entwickeln, ist der Schlüssel zu einer ausgewogenen Entscheidungskultur, welche unerlässlich für vorteilhafte Produktentscheidungen ist.

Quellen

Adults Make More Than 35,000 Decisions Per Day. Here Are 4 Ways to Prevent Mental Burnout (Zak, Heidi, 2020) https://www.inc.com/heidi-zak/adults-make-more-than-35000-decisions-per-day-here-are-4-ways-to-prevent-mental-burnout.html

Fast & Slow Thinking: Out System 1 & System 2 Brains https://www.linkedin.com/pulse/fast-slow-thinking-our-system-1-2-brains-andy-stonehouse/?trk=read_related_article-card_title (Andy Stonehouse, 2021)

Homo oeconomicus https://www.bpb.de/kurz-knapp/lexika/lexikon-der-wirtschaft/19635/homo-oeconomicus/ (Bundeszentrale für politische Bildung, 2016)

PsyConversion: 101 Behavior Patterns für eine bessere User Experience und höhere Conversion-Rate im E-Commerce (Philipp Spreer, 2018).

System 1 and 2: Thinking fast? Slow Down https://neurofied.com/thinking-fast-slow-down-system-1-and-2/ (Philip Jordanov, 2018)

Thinking, Fast and Slow (Daniel Kahneman, 2011)

Hat dir der Beitrag gefallen?

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Ähnliche Artikel