Hypothesen vertesten - aber bitte ohne Confirmation Bias

Produktentwicklung ist ein komplexes Unterfangen, weil wir nie genau wissen können, welche Änderungen am Produkt sich wie auf den Wert auswirken. Product Owner arbeiten deshalb hypothesengetrieben und formulieren Annahmen, die sie durch möglichst kleine Experimente schnell und unkompliziert vertesten können.

Dabei ist es wichtig, die Annahmen richtig zu formulieren und bei der Vertestung darauf zu achten, dass man sich das Ergebnis nicht am Ende schöner rechnet, als es wirklich ist. Grund dafür ist häufig der Confirmation Bias oder Bestätigungsfehler.

Was es damit auf sich hat und wie wir ihn vermeiden können, das beschreibe ich in diesem Artikel.

Wozu arbeiten wir noch mal agil?

Aber erst mal eine kurze Wiederholung: wozu ist dieses agile Arbeiten gleich wieder da? Der Duden beschreibt für das Wort “agil” zwei Bedeutungen¹

1. von großer Beweglichkeit zeugend; regsam und wendig
2. zügig, da schrittweise erfolgend und dabei transparent und flexibel

Spannend für mich ist, dass der Duden für die erste Bedeutung allgemeine Beispiele wie “eine agile Geschäftsfrau” oder einen agilen Körper thematisiert, bei der zweiten Bedeutung aber mit “agiles Projektmanagement” oder “agile Softwareentwicklung” sehr spezielle Beispiele aus einer bestimmten Domäne - nämlich der, in der ich mich meistens bewege - vorschlägt. Das ist für mich ein Zeichen, dass die erste Bedeutung die ältere und weiter verbreitete ist und die zweite vermutlich erst im Zuge der letzten dreißig Jahre hinzugekommen ist.

Warum sollten wir also von großer Beweglichkeit, regsam und wendig sein? Im Kontext der Organisationen, mit denen ich arbeite, ist die Antwort sehr einfach: weil sich das Umfeld bewegt und wir uns deshalb mitbewegen müssen.

Und warum bewegt sich das Umfeld? Weil sich Anforderungen, Wünsche und Bedarfe ändern und deshalb viele Produkte einem stetigen Wandel unterworfen sind. Aber auch, weil die Grenzen des Möglichen kontinuierlich verschoben werden. Viele Produkte, die wir heute ganz selbstverständlich einsetzen und Lösungen, die wir aus unserem täglichen Leben nicht mehr wegdenken können, gab es vor nicht all zu langer Zeit noch gar nicht. Beispiele gefällig?

• Navigieren mit Karte und Kompass
• Telefonieren an festen Orten mit Telefonnummern, die man entweder im Kopf hatte oder in einem Buch nachgeschlagen hat
• Einkaufen entweder in einem Geschäft oder mit Hilfe eines 800 Seiten starken Katalogs, der zwei Mal im Jahr veröffentlicht wurde
• Überrascht werden von Postsendungen, weil man nicht online dem Auslieferfahrzeug zuschauen konnte
• Medien, die man gekauft hat und die man danach unabhängig vom Verkäufer konsumieren konnte

Weil sich also unser Markt, unsere Kunden, aber auch die sonstige Welt um uns herum so schnell verändert, müssen wir beweglich genug sein, um mit dieser Veränderung Schritt halten zu können. Bei den meisten Veränderungen können wir allerdings nicht zweifelsfrei erkennen, welche Lösung am Ende die beste für den veränderten Kontexts ist. Deshalb ist es notwendig, Veränderungen schrittweise vorzunehmen. In der agilen Produktentwicklung nutzen wir dazu unter Anderem Hypothesen, um unsere Annahmen zu formulieren und das erwartete Verhalten festzuhalten. Danach können wir ein Experiment starten, um diese Hypothesen zu vertesten und zu überprüfen, ob unsere Annahmen korrekt waren.

Was ist der Confirmation Bias?

Genau hier macht uns aber der Bestätigungsfehler oder Confirmation Bias einen Strich durch die Rechnung. Es fällt uns nämlich leichter, “Informationen so zu ermitteln, auszuwählen und zu interpretieren, dass diese die eigenen Erwartungen erfüllen (bestätigen).”² Das bedeutet, dass wir den Ergebnissen aus unseren Experimenten oft nicht objektiv gegenüber stehen, sondern sie auf eine Art und Weise interpretieren, die unsere ursprüngliche Annahme stützt. Gleichzeitig ignorieren wir vielleicht Ergebnisse, die diese Annahme widerlegen könnten.

Auch hier ein Beispiel? Daniel und ich waren von 2020 bis 2025 Mitgründer und aktive Treiber der Kohlekumpels GmbH, einem impact-getriebenen Startup. In dieser Zeit haben wir zwei Geschäftsmodelle vertestet, um Pflanzenkohle zu einem relevanten Faktor in der Bekämpfung der Klimakrise zu machen und sind vermutlich unzählige Male dem Bestätigungsfehler aufgesessen. Hier mal zwei konkrete Beispiele.

Während der Entwicklung unseres ersten Geschäftsmodells - ein B2B2C Geschäftsmodell, bei dem wir klimapositive Produkte an Konsument:innen vertreiben wollten - haben wir im Herbst 2021 entschieden, einen Webshop für den Vertrieb unserer Produkte zu starten. Wir wollten das Weihnachtsgeschäft 2021 mitnehmen und haben uns ein Ziel an Kunden, Bestellungen und Umsätzen überlegt. Zugegeben, es waren ein paar weniger Bestellungen als gedacht, aber es haben Leute bei uns bestellt. Gut, das waren viele Menschen aus unserem direkten Umfeld, aber die Anderen können uns ja noch nicht kennen.

Drei Jahre später - wir hatten unser erstes Geschäftsmodell aufgegeben - haben wir uns an einem B2C Geschäftsmodell versucht und Unternehmen adressiert, die im Rahmen der eigenen Nachhaltigkeitsbemühungen einen echten und langfristigen Impact leisten wollen. Wir wussten, dass unsere Preise für die gebundene Menge CO₂ nicht mit denen konventioneller Kompensationsmaßnahmen (z.B. Bäume pflanzen) mithalten können und haben deshalb die weiteren positiven Effekte, z.B. die Dauer der Senkenleistung oder die Vorteile für den Boden, in den Vordergrund gehoben. Wir haben mit Leuten aus dem Pflanzenkohleumfeld gesprochen, aber auch mit Nachhaltigkeitsexperten und Nachhaltigkeitsmanagern aus Organisationen, die bereits viel Erfahrung in ihrem Bereich haben. Viele dieser Menschen haben uns in unserer Idee bestärkt und uns Mut gemacht, das Produkt zu entwickeln und zu vermarkten. Leider haben wir es trotz großer Bemühungen nicht geschafft, einen echten Kunden für unser Produkt zu finden.

Beide Anekdoten sind schöne Beispiele für den Confirmation Bias. Wir haben die Ergebnisse, die unsere Annahmen stützen, stärker gewichtet als diejenigen, die uns evtl. einbremsen würden, weil sie signalisieren, dass unsere Annahmen falsch sind. Dass wir den Bestätigungsfehler als Experten für agile Produktentwicklung kannten und versucht haben, zu berücksichtigen, hat uns leider nicht geholfen, ihn zu verhindern. Es braucht also nicht nur ein Bewusstsein dafür, dass es diesen Fehler gibt, sondern auch eine Strategie, wie wir ihn verhindern.

Wie verhindern wir den Bestätigungsfehler effektiv?

Und diese Strategie hat die Wissenschaft bereits entdeckt und wir können uns dort bedienen. Dabei werde ich die Begrifflichkeiten nicht in der wissenschaftlich notwendigen Schärfe verwenden. Mir geht es hier nicht um wissenschaftliche Forschung, sondern um Produktentwicklung; deshalb ist die hemdsärmlige Verwendung der Vorgehensweise aus meiner Sicht in Ordnung. ;)

Hypothesen formulieren

Es fängt schon bei den eigenen Annahmen an: was versuchen wir zu erreichen und auf welches Ergebnis hoffen wir? Sobald wir hierüber Klarheit haben, können wir darüber nachdenken, woran wir erkennen würden, dass diese Annahmen falsch sind. Dabei reicht es nicht, allgemein zu bleiben; überleg Dir konkrete Messwerte und Grenzwerte, an denen Du festmachen kannst, dass Du auf dem Holzweg bist.

An den Kohlekumpels Beispielen oben hätten wir also beim Shop explizit darauf achten sollen, welche Kund:innen wir nicht persönlich kennen und wir hätten speziell mit denen ins Gespräch gehen müssen, um über ihren Kauf zu sprechen. Oder wir hätten versuchen können, Kunden, die wir mit unserem Shop gar nicht erst erreichen, anzusprechen. Beim zweiten Geschäftsmodell hätten wir uns mehr mit Organisationen unterhalten müssen, die Nachhaltigkeit als lästige Pflicht sehen und nicht als Teil ihrer Unternehmensidentität. Wir hätten unsere Zielgruppen und ihre Herausforderungen umfassender kennen lernen müssen und nicht nur die wohlwollende Blase, in der wir uns bewegt haben.

Es kommt also darauf an, die eigenen Annahmen umfangreicher zu hinterfragen:

• Was erwarten oder erhoffen wir?
• Welchen Effekt erwarten wir auf die Veränderung?
• Wie messen wir diesen Effekt?
• Welchen Grenzwert muss die Messung überschreiten, damit wir davon ausgehen können, wir lägen richtig?

Diesen Teil der Hypothesenformulierung solltest Du im Optimalfall auch jetzt schon haben.

Noch interessanter wird es deshalb, wenn Du Dir explizit überlegst, wie es aussehen würde, falls Du falsch liegst:

• Was passiert, wenn die Annahme falsch ist?
• Wie erkennen wir das so schnell wie möglich?

In der Statistik ist das die Nullhypothese, also die Annahme, dass unsere Veränderung keinen Effekt hervorrufen wird, den wir uns wünschen.

Experimente durchführen

Mit den sauber formulierten Annahmen steigen wir jetzt in die Vertestung ein. Wir entwickeln also üblicherweise einen Teil des Produkts bzw. der Lösung und wollen herausfinden, ob wir richtig liegen.

Dazu planen wir den kleinsten vorstellbaren Schritt, der es uns ermöglicht, die Annahmen zu überprüfen. Hätten wir also bei den Kohlekumpels vor Eröffnung des Shops Konsument:innen befragt, mit denen wir nichts zu tun haben, ob unsere Produkte für sie relevant sind und ob sie diese online kaufen würden, wäre das ein sehr leichtgewichtiges Experiment gewesen. Und wenn genügend Menschen Interesse gezeigt hätten, hätten wir ein nächstes Experiment durchgeführt, um zu schauen, ob aus diesem “ich würde” auch ein “ich werde” und schließlich ein “ich habe” wird.

Wir reihen also Experimente wie in der Wissenschaft aneinander und lassen uns von den Ergebnissen des letzten Versuchs zum nächsten treiben.

Ergebnisse auswerten

Der wichtigste Schritt ist bei jedem Experiment der Letzte: die Auswertung der Ergebnisse. Hier ist es sehr leicht, trotz aller guter Vorarbeit doch noch der Versuchung nachzugeben, die Ergebnisse zu optimistisch zu sehen.

Gerade beim zweiten Geschäftsmodell haben wir außerhalb unserer wohlwollenden Kontakte von Anfang an wenig Resonanz bei potenziellen Kunden erhalten. Wir haben das aber auf Anlaufschwierigkeiten geschoben und uns immer wieder gegenseitig versichert, dass das schon besser wird. Wurde es aber nicht, und so haben wir am Ende einige Monat Arbeit in ein Produkt gesteckt, das wir nicht erfolgreich vermarkten konnten.

Deshalb ist es so wichtig, sich die Grenzwerte für Erfolg und Misserfolg bereits vor dem Experiment zu überlegen. Das ist schwierig und manchmal hat man keine gute Basis, um diese Werte zu definieren. Sind fünf Bestellungen in einer Woche viel oder wenig? Sind drei Neukunden von außerhalb der eigenen Kontakte pro Woche gut oder schlecht? Das weiß keiner, aber wenn Du Dir im Vorhinein nicht überlegst, welche Zahl(en) Du erreichen musst, damit Du selbst gegenüber Deinen geschäftlichen Zielen das als Erfolg werten würdest, ist es im Nachhinein zu einfach, das Ergebnis einfach zu akzeptieren und den nächsten Schritt zu gehen.

Auswirkungen auf Backlog und Entwicklung

Viele Product Owner (bzw. die Organisationen, in denen sie arbeiten) möchten mit ihren Annahmen richtig liegen. Schließlich sind sie die Expert:innen für ihren Markt, ihre Kund:innen und ihr Produkt. Da diese aber zu einem gewissen Grad unvorhersehbar sind, brauchen wir eine andere Herangehensweise: weg von “auf dem richtigen Weg sein” und hin zu “weniger lang in die falsche Richtung laufen”.

Das fängt schon beim Product Backlog Management an. In der Diskussion mit Stakeholdern, (potenziellen) Kunden und Anwendern, aber auch den Entwicklern, kannst Du als Product Owner bereits über die Nullhypothesen sprechen und über Metriken und Grenzwerte, die Erfolg bzw. Misserfolg einer Annahme signalisieren.

Diese Annahmen, Metriken und Grenzwerte gehören dann natürlich auch als Teil Deiner Product Backlog Items ins Product Backlog. Pack die Annahmen in die Beschreibung und die Metriken mit ihren Grenzwerten in die Akzeptanzkriterien. Und mach Deine Experimente klein: lieber ein leichtgewichtiges Experiment, dass Dich nur zwei bis drei Tage kostet, als zu lange in ein nicht wertschöpfendes Thema zu investieren.

Auch in der Entwicklung sollten die Hypothesen sichtbar sein. Entwickler sollten auf unsicheren Annahmen basierende Funktionalität so bauen, dass sie leicht veränderbar ist und auch gut wieder entfernt werden kann. Vielleicht lohnt es sich sogar, bei sehr frühen Experimenten technische Schulden strategisch aufzunehmen, um nicht zu viel in die Entwicklung einer Funktionalität zu investieren, die am Ende nicht weiter verfolgt wird.

Sinnvoll eingesetzt sind Hypothesen und auf ihnen aufbauende Experimente grundlegende Bausteine einer beweglichen, wendigen und zügigen Produktentwicklung, ganz wie der Duden sie beschreibt. ;)