Mythos Scheitern – fünf Fragen, die A/B Tests Dir NICHT beantworten

Kategorien: PRODUKTMANAGEMENT

Auf dem Weg hin zur besseren Lösung ist das Scheitern unverzichtbar. Wenn wir das Neue entdecken wollen, müssen wir mutig ausprobieren. Je mehr desto besser. Manchmal klappt es, manchmal nicht. Mit jedem Experiment wächst das Wissen, wir lernen dazu. Jedoch, scheitern alleine wird nicht reichen. Ab und zu muss auch was gelingen. Die agile Methode des Trial-and-Error zielt auf das Gelingen und Liefern. Scheitern ist nur Mittel zum Zweck. 

Für den Produktmanager ist jedes Experiment eine Investition. Damit das Verhältnis von Aufwand und Nutzen passt, sollten die Experimente gut durchdacht und sauber ausgeführt werden. Klar ist, die Suche nach der besseren Lösung braucht mehr, als die Bereitschaft zum Experiment.

Die mit Abstand populärste Methode für das Testen und Experimentieren sind A/B Tests. Eine einfache Idee: eine Nutzergruppe A wird mit der Nutzergruppe B verglichen. Der einzige Unterschied, Gruppe A nutzt eine Produktvariante, Gruppe B nicht. 

Auf diese Weise vermisst Spotify, die Wirkungen von UI-Elementen, AirBnB den Booking Prozess und Facebook, die Time-On-Site. Google berichtete bereits 2009 von mehr 12.000 Tests pro Jahr an der Nutzergruppe. Seitdem hat sich viel getan -ziemlich sicher, dass wir 2021 in jedem Online-Moment auf Google, Amazon & Co. Teilnehmer eines der unzähligen Experimente sind. Das Testen-Bewerten-Verbessern ist der Normalzustand, nicht die Ausnahme. 

A/B Testing ist ein Handwerk, statistisches Wissen und Werkzeuge unverzichtbar für die Umsetzung. Die Berechnung von Stichprobenumfang, Konfidenzintervallen und p-Werten erfordert Augenmaß und Erfahrung. Leicht verliert man den Überblick im Methodendschungel aus Metriken, Grafiken und Signifikanzen. 

  • „Wie wichtig ist das Detail?“ A/B eignen sich gut, um in kleinen Schritten lokale Veränderungen zu testen. Deutlich schwieriger wird es, wenn die Fragestellung komplex ist und sich nicht auf ein Detail reduzieren lässt. Ein Beispiel dafür: „40 Shades of Blue“ – Google testete die Wirkung von 40 unterschiedlichen Blautönen auf die Click-Through-Rates ihrer Werbe-Links. Das erstaunliche Ergebnis dieses Detailtests: mehr als 200 Millionen Dollar Werbeerlöse lagen zwischen den verschiedenen Farb-Varianten. Wenig überraschend, die Web Designer und Usability Experten waren nicht begeistert. Ein schlüssiges, ganzheitliches UX-Desgin braucht mehr als eine Optimierung von UI – Details. Ohne Design-Konzept droht die Frankenstein-UI, ein Sammelsurium aus Einzelteilen.  
  • „Welche Experimente sind notwendig?“ Bei komplexen Fragestellungen wächst die Anzahl der notwendigen Tests rapide an. Schon das Testen einer scheinbar simplen Änderung in der Nutzerschnittstelle, mit bspw. vier Farben, drei Textvarianten und zwei möglichen Positionen resultiert in 24 Testvarianten (4*3*2). Welches Experiment ist notwendig, welches verzichtbar? Wie werden die unabhängigen Testgruppen zusammengestellt, um signifikante Ergebnisse zu erhalten? Die Versuchung ist groß den Aufwand zu reduzieren, indem Testszenarien ignoriert und Testgruppen vermischt werden. Die Gefahr dabei, aufwändige Experimente die nur wenig belastbare Erkenntnisse liefern. 
  • „Kennen wir unsere Nutzer?“ A/B Tests liefern eine statistische Beschreibung der beobachteten Effekte – eine Erklärung liefert das statistische Material nicht. Für die Produktgestaltung ist das ein Problem, schließlich wollen wir verstehen, warum die Nutzer unsere Lösung verwenden. Ein Beispiel dafür: die Suchmaschinen wie Google und Bing verbessern kontinuierlich ihre Algorithmen – A/B Testing ist dabei unverzichtbar. Wie jedoch lassen sich die Test-Ergebnisse interpretieren? Ist die erhöhte Nutzeraktivität wirklich ein Zeichen dafür, dass die Suchergebnisse besser geworden sind? Oder ist es nicht andersherum – ein schlechtes Suchergebnis zwingt die Nutzer mehr Zeit mit der Suche zu verbringen? Die A/B Ergebnisse geben darauf keine Antwort.
  • „Können wir den Test-Ergebnissen trauen?“ A/B Tests machen Fehler. Die Wahrscheinlichkeit eines Fehlers lässt ich sogar berechnen. Mit Hilfe von Konfidenzintervallen lässt sich die Aussagekraft vermessen. Jedoch verdecken diese statistischen Maße die Qualität der Gesamtaussage. Je mehr Tests durchgeführt werden, desto unwahrscheinlicher ist es, dass wir kein -scheinbar- signifikantes Ergebnis finden. Mit einen Konfidenzlevel von 95% beträgt die Fehlerwahrscheinlichkeit 5%. Das bedeutet, das eines von 20 Ergebnisse einen False Positive meldet, also eine fälschliche Bestätigung liefert. Anders ausgedrückt, wer viel misst, misst viel Mist.
  • „Was machen wir mit den Ergebnissen?“ A/B Tests liefern nicht nur Testergebnisse, ebenso interessant, die Ausgangsdaten und Verläufe des Experiments. Wie entwickelt sich die Metrik im Zeitverlauf – ansteigend, abfallend, schwankend? Erst der Blick auf die Testverläufe zeigt ob die Ergebnisse belastbar sind. Die aggregierten Test-Ergebnisse verdecken leicht Unterschiede zwischen Gruppen, Orten und Zeitpunkten. 

Agiles Produktmanagement ohne A/B Testing? Zumindest im digitalen B2C Geschäft, schwer vorstellbar. Die Vorteile für das Produktmanagement sind offensichtlich. Die Entwicklung neuer Features lassen sich auf diese Weise an den Kundenwünschen ausrichten. Ebenso wichtig, A/B Tests helfen beim Roll-Out der Lösung. Ein schrittweises Einführen, Testen und Verbessern reduziert das Risiko. Damit das gelingt, sind drei Aspekte wichtig:

  • Führung durch Product Vision & Goal – das Ganze ist mehr als die Summe seiner Einzelteile. Ein Zielbild ist notwendig, um die Details im Zusammenhang zu bewerten. Eine gute Produktvision ist mehr als ein messbares, testbares Ziel. Die Vision lebt von Verständlichkeit, Ambition und Attraktivität.  Eine kompakte überzeugende Schilderung des Leitbildes ist ein Führungsinstrument, dass dem Team Orientierung gibt. Was ist wichtig, was nicht? 
  • Management sicherstellen – komplexe A/B Testszenarien benötigen Planung und Steuerung. Die viele Software Tools am Markt erzeugen leicht den Eindruck A/B Testing sei vor allem ein technisches Thema. Leider braucht es mehr als ein Tool, um Dutzende von Testszenarien sauber zu koordinieren. Die Auswahl der Stichproben, die Steuerung der Testphase, die Verdichtung der Ergebnisse – als dies benötigt jemanden der sich darum kümmert. 
  • Analyse Kompetenz entwickeln – die Arbeit mit den Testergebnisse ist genauso wichtig wie das Design des Testaufbaus. Dabei geht es nicht um komplizierte Datenanalysen oder Weltklasse-Grafiken. Viel wichtiger, eine handwerklich saubere, neugierige Sicht auf die Rohdaten. Die einfache „explorative Datenanalyse“ gehört in den Werkzeugkoffer des Produktmanagers. Wichtig dabei, die Arbeit mit Tools und Metriken muss konzeptbasiert geschehen. Konkret bedeutet dies, Hypothesen und Metriken werden vor der Durchführung festgelegt – nicht danach. 

A/B Tests sind ein wunderbares Werkzeug. Das Experiment die zentrale Quelle in der Arbeit an der innovativen Lösung. „Suchend finden wir das Bessere“ so der Grundgedanke der wissenschaftlichen Methode. Nie war es einfacher, empirisch an Produkten und Lösungen zu arbeiten. Umso wichtiger, das mächtige Werkzeug handwerklich sauber einzusetzen. 

Links

https://www.optimizely.com/optimization-glossary/ab-testing/

http://ai.stanford.edu/~ronnyk/puzzlingOutcomesInControlledExperiments.pdf

https://www.theguardian.com/technology/2014/feb/05/why-google-engineers-designers

Books

Product Management’s Sacred Seven, Autoren: Detroja, Mehta, Agashe, 2020

Product Analytics: Applied Data Science Techniques for Actionable Consumer Insights; Autor: Joanne Rodrigues, 2020

 Jan Schneider ist Berater und Trainer für das agile Management. Seit vielen Jahren begleitet er Teams und Organisationen bei der Arbeit an Produkten, Projekten und Prozessen. Er unterstützt als freiberuflicher Experte bei der Entwicklung von Kompetenzen, dem Transfer von Erfahrungen und der Gestaltung von Lernprozessen. Weitere Infos finden Sie unter www.c43p.de


    Schreibe einen Kommentar

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