Über unsMediaKontaktImpressum
Heiko Stapf 11. August 2020

Kognitive Verzerrungen – Wir machen uns die Welt, wie sie uns gefällt

Wie unser Gehirn uns Probleme in der Produktentwicklung bereitet und was wir dagegen tun können

Dieser Artikel beschreibt die Wirkung von kognitiven Verzerrungen in der Produktentwicklung. Kognitive Verzerrungen sind Mechanismen in unserem Gehirn, die uns dabei helfen, schnell und ohne Nachzudenken auf Gefahren zu reagieren. Was evolutionsbiologisch überlebenswichtig ist (z. B. bei Flucht vor gefährlichen Tieren), führt in der Produktentwicklung zu unerwünschten Resultaten.

Der Artikel beleuchtet kognitive Verzerrungen und mögliche Auswirkungen auf die Produktentwicklung und gibt Tipps und Tricks, wie diese vermieden oder manchmal genutzt werden können.

Eine Anekdote

Thomas (Name v. d. Red. geändert) ist Produktmanager bei einem großen Konzern. Seit einiger Zeit treibt den Konzern eine neue Produktidee um. Thomas ist davon begeistert. Er erstellt eine Studie zu Wirtschaftlichkeit und Marktpotential. Da es sich um ein neues Produkt handelt, gibt es diese Zahlen nicht direkt für sein Produkt, aber er findet ausreichend Studien und Informationen aus der Produktdomäne und ähnlichen Vorhaben. Das Ergebnis ist vielversprechend, das Marktpotential riesig, die Zahlen scheinen eindeutig.

Die Produktentwicklung kann beginnen und nicht nur die – denn auf Grund der sehr guten Zahlen investiert der Konzern frühzeitig in "Company Building", stellt viele neue Mitarbeiter ein und baut sogar ein neues Gebäude. Vier Jahre später (die Entwicklung dauerte etwas länger) geht das Produkt geht an den Markt. Doch die Verkaufszahlen bleiben deutlich hinter den prognostizierten Zahlen zurück.

Als das Problem immer offensichtlicher wird, beschließt Thomas seine Marktbetrachtung zu überprüfen. Nach kurzer Zeit findet er den Fehler. Sein Marktvolumen basierte zwar auf einer Zahl für seine Produktkategorie, allerdings enthielt die Produktkategorie zusätzliche (sehr häufige) Produkte in der Quellstudie. Thomas hatte (im übertragenen Sinne) seinen spezialisierten Feinkostladen mit den Bedarfszahlen für Allgemeine Lebensmittelläden geplant.

Wie konnte er diesen Fehler nur übersehen? Thomas (und seine Kollegen) wurde Opfer einer kognitiven Verzerrung: dem "Bestätigungs-Bias".

Was sind kognitive Verzerrungen (Biases)?

Kognitive Verzerrungen haben ihre Ursachen in der Evolutionsgeschichte der Menschheit. Wie beschrieben, handelt es sich um Abkürzungen im Gehirn, die schnelle Reaktion ermöglichen. D. h., trafen Menschen auf ein gefährliches Tier, haben die überlebt, die möglichst schnell erkennen konnten, dass es an der Zeit war, wegzurennen. Menschen, die erst über das Für und Wider nachdachten, haben diese Begegnung meist nicht überlebt. Evolutionsbiologisch haben sich die Menschen durchgesetzt, die diese Abkürzung möglich schnell abrufen konnten.

Und heute?

Heute erforscht die Psychologie weit über 150 solcher Abkürzungen. Waren die kognitiven Verzerrungen im Hinblick auf Begegnung mit gefährlichen Tieren sehr sinnvoll, so können sie uns heute Probleme bereiten. Auch in der Produktentwicklung. Dies lässt sich an der wichtigsten und bekanntesten kognitiven Verzerrung, dem so genannten Confirmation Bias (Bestätigungsverzerrung) leicht erklären.

Der Confirmation Bias (Bestätigungsbias)

Der amerikanische Investor Warren Buffet sagte einmal "Der Mensch ist am besten darin, neue Informationen so zu interpretieren, dass seine bestehenden Auffassungen intakt bleiben". Diese Tatsache kann mit einem einfachen kleinen psychologischen Experiment nachvollzogen werden: Die Probanden sollen anhand von Beispielen die Regel hinter der Zahlenkombination 2-4-8 herausfinden. Hierzu können sie neue Beispiele nennen, wie zum Beispiel 4-8-16. Sie erhalten daraufhin Feedback, ob das neue Triple der Regel entspricht. Sobald sie der Meinung sind, sie hätten die Regel erkannt, können sie lösen.

Das Spannende ist die präferierte Vorgehensweise der Probanden. Anhand des Beispiels überlegen sie sich eine Regel, z. B. Verdopplung. Danach werden ein bis zwei zur vermuteten Regel passende Triplets eingereicht. Das Feedback ist positiv, die Regel damit gefunden… oder auch nicht.

Die wenigsten Probanten reichen Beispiele ein, die der vermuteten Regel widersprechen würden. Zum Beispiel die Zahlenfolge 2-3-4, wenn die vermutete Regel eine Verdopplung ist.

Dieser Test wurde in kontrollierten Umgebungen durchgeführt und kann auf der Webseite der New York Times durchgeführt werden. Die New York Times hat festgestellt, dass 77 Prozent der Probanden lösen, ohne ein einziges Nein gehört zu haben. Aber nur 9 Prozent der Probanden haben mehr als drei Neins gehört.

Warum ist das so?

Der Mensch sucht Bestätigung und Sicherheit. Kommt eine bestehende Auffassung ins Wanken, so verursacht dies Stress. Diesem Stress möchte sich der Mensch gerne entziehen. D. h. der Mensch passt unterbewusst neue Informationen in sein bestehendes Weltbild ein, bzw. stellt in diesem Fall die Fragen so, dass sein Weltbild bestätigt wird.

Wieso ist das eine Gefahr für die Produktentwicklung?

Thomas' "Feinkostladen" ist ein Beispiel für den Bestätigungsbias in der Produktentwicklung. Die Informationen schienen zu passen und bestätigten das Vorhaben. Das notwendige Hinterfragen und Überprüfen fand nicht statt, da es das bestehende Weltbild in Frage gestellt hätte. Zu groß war der Wunsch, dass die Zahlen stimmen.

Wie kann der Confirmation Bias umgangen werden?

Ein Hinweis darauf liefert uns der Schriftsteller Arthur Quiller Couch mit seinem Zitat "Murder you Darlings" ("töte deine Lieblinge"). In diesem Fall sind die "Lieblinge" die Aussagen oder Glaubenssätze, die normalerweise nicht angefasst werden. Wir empfehlen, sich die wichtigsten Glaubenssätze aufzuschreiben, und diese sehr nachdrücklich zu hinterfragen, bzw. mit Experimenten zu validieren oder zu falsifizieren.

Die häufig gehörte Aussage "Unser Kunde macht das schon immer so - wir kennen unseren Kunden" ist ein deutliches Alarmsignal, genau diese Überlegungen zu hinterfragen. Zum Beispiel durch Kundenbeobachtung.

Damit wir diese Unwissenheit nicht vergessen, empfehlen wir, Product-Backlog-Einträge als Hypothesen zu formulieren. Z. B. in der Form:

  • Wir vermuten, dass <Vermutung>
  • Wir überprüfen diese Vermutung in dem wir <Experiment>
  • Wir messen <Metrik>
  • Unsere Vermutung trifft zu, wenn <Erfolgskriterium>

Durch die Formulierung in Hypothesen wird deutlich, dass es sich um eine Vermutung handelt. Die Diskussion der Metrik und des passenden Erfolgskriteriums sorgt dafür, dass wir uns intensiv mit unserer Vermutung und deren Überprüfung beschäftigen.

Der Survivor Bias

Im ersten Weltkrieg gab es den Versuch der Royal Air Force, ihre Flugzeuge besser zu panzern. Es wurden Untersuchungen gestartet, wo die Flugzeuge am häufigsten getroffen wurden. Daraufhin wurden die entsprechenden Stellen verstärkt – ohne messbares Ergebnis.

Was war passiert? Die Untersuchung wurden an den Flugzeugen vorgenommen, die vom Einsatz zurück kamen. Nicht untersucht wurden die Flugzeuge, die abgeschossen wurden. D. h. die Stellen die verstärkt wurden, waren die Stellen, die nicht zum Absturz des Flugzeuges geführt haben. Dieser Fokus auf die Überlebenden wird der Survivor Bias genannt.

Wie macht sich der Survivor Bias in der Produktentwicklung bemerkbar?

Zum Beispiel, indem wir dazu tendieren, Kunden zu befragen und zwar nicht die Kunden, die nicht unsere Kunden geworden sind. Oder indem wir Methoden (z. B. Spotify-Modell) von anderen Firmen kopieren, von denen wir wissen, dass sie damit erfolgreich waren, aber wir wissen nicht, wie viele Firmen es trotz dieser Methoden nicht geschafft haben.

Ein weiteres schönes Beispiel, ist eine Firma, die zur Verbesserung des Bewerbungsprozesses Mitarbeiter befragt hat, die neu im Unternehmen waren. Damit haben sie genau die Personen befragt, für die der Bewerbungsprozess erfolgreich war. Um den Surviver Bias zu umgehen, hätte es zusätzlich eine Befragung der Personen geben müssen, die nicht Mitarbeiter geworden sind.

In einer Diskussion mit einem Kunden kamen wir auf die Probleme von "traditionellen" Filialbanken. Diese haben lange nicht die Notwendigkeit erkannt, ihre Dienstleistungen zu digitalisieren – schließlich haben ihre Kunden das nicht gefordert. Das Problem ist allerdings, dass es sich bei den Filialbankkunden um eine kontinuierlich kleiner werdende Bevölkerungsgruppe handelt. Die Gruppe der digital affinen Menschen wurde nicht Kunde der Filialbanken. Die Filialbank sah dies nicht, da sie aufgrund des Survivor Biases nur ihre Bestandskunden im Blick hatte. Für die Filialbanken ist es daher ein wichtiger Schritt, sich bewusst mit den Nichtkunden – in diesem Fall den digital affinen Banknutzern – auseinanderzusetzen, um dem Survivor Bias entgegenzuwirken.

Wie können wir mit dem Survivor Bias umgehen?

Es ist extrem wichtig in der Produktentwicklung auf die Personen zu schauen, die nicht zum Kunden wurden:

  • Wo verlieren wir zum Beispiel unsere Webshop-Kunden?
  • Wo verlieren wir in der Akquise-Kunden?
  • Welche Gründe gibt es dafür?
  • Welche Hindernisse für Kunden gibt es?
  • Welche Bedürfnisse adressieren wir nur ungenügend?

Methodisch hilft hier die Erstellung von Personas mit besonderem Blick auf Personas außerhalb der bereits bestehenden Kundengruppe. Die Betrachtung verschiedener Kontexte, wie sie in der Jobs-to-be-done-Methode (JTBD) beschrieben wird, kann zusätzliche wertvolle Perspektiven eröffnen [1].

Die intensive Beschäftigung mit den Nicht-Überlebenden bzw. den Nicht-Kunden ergibt viele neue, spannende und wertvolle Erkenntnisse.

Implicit Bias

Der Implicit Bias besagt, dass wir von den Eigenschaften einer Bevölkerungsgruppe (meist der eigenen und/oder gesellschaftlich dominanten) implizit auf eine andere Bevölkerungsgruppe schließen. Was dies zur Folge hat, können wir an vielen Beispielen sehen. Ein Beispiel sind die Warteschlangen vor Frauentoiletten in öffentlichen Gebäuden, während auf der Männerseite oftmals freie Kapazitäten vorhanden sind. Das Problem? Die meist männlichen Architekten haben implizit die gleiche "Verrichtungszeit" für Männer und Frauen angenommen und die gleiche Fläche für Toiletten zur Verfügung gestellt. Mit dem Ergebnis: Schlangen vor den Frauentoiletten, freie Kapazitäten bei den Männern.

Die Lösung: mehr Toilettenkapazitäten für die Frauen.

Für den Implicit Bias gibt es viele weitere Beispiele aus der Produktentwicklung:

  • Das Vernachlässigen von Barrierefreiheit,
  • die meist jüngeren und gut sehenden Entwickler nutzen zu kleine Schriften im Benutzer Interface,
  • People of Color, denen der automatische Seifenspender keine Seife spendet, weil das System nur von Weißen getestet wurde oder
  • Fotokorrektur-Software, die aus schwarzen Menschen weiße Menschen macht, weil die KI nur mit den Fotos von weißen Menschen trainiert wurde.

Wie können wir mit dem Implicit Bias umgehen?

Neben regelmäßigen Tests hilft hier ein möglichst diverses Team, bzw. wenn dies nicht möglich sein sollte, muss bei den Prototypen und Tests darauf geachtet werden, dass eine möglichst diverse Gruppe das Produkt testet. Wir empfehlen auch aus anderen Gründen ein möglichst diverses Entwicklungs-Team.

Der Ikea-Effekt

Wer schon mal ein Ikea-Regal (auch andere Möbelfirmen sind möglich) zusammengebaut hat, ist ziemlich sicher "Opfer" dieses Bias geworden. Der Ikea-Effekt besagt, dass wir etwas, in das wir eigene Arbeit investiert haben, einen höheren Wert zuweisen, als etwas, in das wir keine eigene Arbeit investiert haben. Im Falle des Regals bedeutet dies: nachdem wir es mit großem Aufwand aufgebaut haben, nachdem wir die Anleitung mühsam entziffert haben, nachdem wir nochmal zum Möbelhaus mussten, weil etwas gefehlt hat. Egal wie krumm und schief es am Ende ist: dieses Regal hat für uns einen höheren Wert als ein vergleichbares, eventuell sogar korrekt zusammengebautes, Regal.

Auswirkungen des IKEA-Effekts in der Produktentwicklung

Der Ikea-Effekt macht sich an vielen Stellen bemerkbar. Er beginnt bereits im Planungsprozess. So steigt mit jeder Stunde, die in die Planung oder das Refinement eines Features gesteckt wird, der gefühlte Wert dieses Features für das beteiligte Team. Dies führt so weit, dass Features entwickelt werden, von denen klar ist, dass sie keinen Wert für den Nutzer haben oder kaum benutzt werden, nur weil hat man bereits "so viel Energie, Zeit und Geld in die Erarbeitung investiert, das Feature können wir jetzt nicht einfach weglassen".

Merke: Ist ein Feature erst einmal länger besprochen oder sogar entwickelt worden, so sinkt die Wahrscheinlichkeit, dass dieses Feature wieder aus dem Produkt Backlog oder aus dem Produkt entfernt wird. Auch wenn die Nutzungszahlen eine andere Sprache sprechen.

Wie können wir mit dem Ikea-Effekt umgehen?

Ein Prinzip aus dem Agilen Manifest lautet "Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell" [2]. Übertragen auf den Ikea-Effekt bedeutet das, dass so wenig wie möglich Planungsarbeit oder sogar Entwicklungsarbeit in ein Feature fließen sollte, solange wir nicht wissen, ob dieses Feature einen unwiderstehlichen Wert für den Kunden schafft.

Grundsätzlich bedeutet das, dass wir für die Überprüfung von Hypothesen eine möglichst schlanke Vorgehensweise benötigen. Hier kommt die kontinuierliche Product Discovery mit effektiven und effizienten Prototypen ins Spiel. Allerdings beobachten wir häufig, dass diese Prototypen zu aufwändig sind, meist durch ein MVP ersetzt werden und alleine die Diskussion, was nun in das MVP gehört und was nicht, bereits den Ikea-Effekt triggert.

Wir benötigen Prototypen, die mit extrem einfachen Mitteln extrem schnell die Erfahrung mit dem Produkt für den Nutzer simulieren.

Der Story Bias

Glücklicherweise gibt es auch Biases, die wir nutzbringend für uns einsetzen können: Hierzu gehört z. B. der Story Bias. Der Story Bias besagt, dass sich Menschen Informationen, die in Form einer Geschichte "erzählt" werden, besser merken können. Diesen Effekt kennt man vielleicht von Gedächtnistraining und kann mit diesem einfachen Beispiel verdeutlicht werden:

  • Variante 1: Die Königin starb. Kurze Zeit später starb der König.
  • Variante 2: Die Königin starb. Aus Trauer darüber starb kurze Zeit später der König.

Obwohl Variante 2 eine Information mehr enthält, können sich Menschen diese Variante besser merken.

In der Produktentwicklung können wir uns diesen Bias zunutze machen, in dem wir die Storytelling-Technik anwenden. Das heißt, wir beschreiben nicht einfach das Feature X, sondern erzählen die Geschichte, wie unser Nutzer mit Feature X sein Problem löst. In der Geschichtsform können sich Kunden, Stakeholder und Entwickler diese Information besser merken und sich besser mit ihr identifizieren. Ein einfaches, aber wirksames Mittel.

Zusammenfassung: Iterative Produktentwicklung mit Product Discovery

Die vielen Biases und deren Folgen für die Produktentwicklung sind ein wichtiges Argument für eine iterative Vorgehensweise in der Produktentwicklung und für die Notwendigkeit von kontinuierlichen, schnellen Experimenten und Tests. Diese Situation hat Marty Cagan mit den folgenden Aussage klar formuliert: "Eine der größten Verschwendungsformen ist es, ein Feature oder Produkt zu designen, zu entwickeln, zu testen und auszuliefern, nur um herauszufinden, dass es nicht das ist, was benötigt wird" [3].

Als Ausweg beschreibt Marty Cagan die Methode "Product Discovery" wie folgt: "Product Discovery ist eine Serie von schnellen Experimenten, hauptsächlich mit Prototypen. Product Discovery versetzt uns in die Lage, effektive Lösungen für die Probleme zu finden, die unser Team lösen soll. Lösungen, die wertvoll, gewünscht, benutzbar und machbar sind" [3].

Diese Experimente und Tests im Rahmen einer kontinuierlichen Product Discovery helfen uns immer wieder, unsere Annahmen zu überprüfen, Tests zu machen und Biases zu identifizieren.

Hierzu sind folgende Ideen hilfreich:

  • Formuliere Hypothesen, um die Unsicherheit transparent zu machen.
  • Hinterfrage regelmäßig und kritisch Aussagen und Glaubenssätze.
  • Führe regelmäßig Experimente (meist anhand von einfachen, schnell entwickelten Prototypen) durch, um die Hypothesen zu überprüfen.
  • "Get Out of Building" – Suche den frühen und häufigen Kontakt mit den Kunden, Nicht-Kunden und der Realität außerhalb der "Büroblase".
  • Nutze User Experience und Product Discovery als kontinuierliche Begleiter der Produktentwicklung (nicht vor- oder ausgelagert).
  • Erstelle Personas und untersuche deren Kontexte.
  • Beschäftige Dich intensiv mit den richtigen Metriken.
  • Arbeite mit möglichst diversen Teams (Fachlichkeit, Geschlecht, Ethnie, Demographie). Diese sorgen für unterschiedliche Perspektiven und bessere Ergebnisse.
  • Etabliere extrem kurze Feedbackschleifen zum Kunden.
  • Prüfe nicht nur eine Idee oder Lösung für ein Problem, sondern teste verschiedene Alternativen.
  • Entwickle Produkteigenschaften über mehrere Iterationen hinweg.
  • Achte dabei auf folgende vier Punkte: Kundenwert, Machbarkeit, Nutzbarkeit und Geschäftswert.

Mit diesen Ideen machen wir es den Biases schwer, sich in unserem Produkt einzunisten.

Autor

Heiko Stapf

Heiko Stapf ist Certified Scrum Trainer. Sein besonderes Interesse gilt der Entwicklung innovativer Produkte und Dienstleistungen und der Rolle des Product Owners in Scrum.
>> Weiterlesen
Das könnte Sie auch interessieren

Kommentare (0)

Neuen Kommentar schreiben