Entscheidungen zu treffen ist Kernbestandteil von Führung. Auf Basis von Erfahrung oder manchmal schlicht dem Bauchgefühl (gern lieber als Intuition betitelt) wird sich für oder gegen etwas entschieden. Der Einfluss größerer Entscheidungen lässt sich sicherlich in der P&L ablesen. Die ganzen kleinen bis mittleren Entscheidungen können aber nur schlecht validiert werden, weil so viele davon gleichzeitig getroffen werden und sich gegenseitig beeinflussen.
Hier hilft ein sauber aufgesetztes und in der Unternehmenskultur verankertes AB-Testing. Im ersten Schritt werden Hypothesen gebildet, die sich dann in Testvarianten widerspiegeln. Durch paralleles Ausspielen lässt sich dann bestenfalls die am besten performende Variante ermitteln. Oder eben auch nicht, sofern die Hypothesen nicht gegriffen haben. So oder so eine wertvolle Erkenntnis zum Verständnis vom User Verhalten. Und in Summe ein großer Schritt in Richtung datengetriebener Führungskultur.
Aber was bedeutet das nun für die Führungskraft?
1. Weg von Top-Down-Entscheidungen
Zentrale Entscheidungen nach persönlichen Vorlieben oder Erwartungshaltungen (liebevoll “Geschmäckle” genannt) kann und sollte es nicht mehr geben. Ideen können natürlich jederzeit platziert werden – so wie von allen anderen auch.
Die einzige Möglichkeit zur Einflussnahme auf die AB-Tests kann ggf. die Priorisierung des Testing-Backlogs sein – zumindest solange es sich um eine zentrale CRO Unit über alle Business Domänen handelt und Ressourcen knapp sind.
2. Dezentralisierung des Knowhows
Testideen und -hypothesen sollten bestenfalls vom Product Team selbst kommen, das für die jeweilige Domäne verantwortlich ist – da sie ja letztendlich die Spezialisten auf dem Thema sind. Das setzt eine gewisse Dezentralisierung des Knowhows voraus.
Als Führungskraft sollte die Hoheit über die Domäne anerkannt und gefördert werden. Schließlich können Spezialisten immer fundiertere Erkenntnisse aufweisen als Generalisten.
3. Team Empowerment
Um das dezentralisierte Knowhow aus den Teams “hochzuspülen” muss das Team natürlich auch enabelt werden – das bedeutet für die Führungskraft zum einen Aufbau einer klaren Prozesspipeline für Testideen, aber vor allem der Knowhow-Aufbau zum Thema Hypothesendesign.
4. Do. Fail. Learn. Repeat.
Funktionieren kann das ganze nur, wenn Fehler nicht als Fehler, sondern als Erkenntnis verstanden werden. Stichwort Fehlerkultur.
Die Führungskraft ist in der Pflicht, Fehler explizit zu würdigen und zu forcieren, die daraus entstehenden Lerneffekte ermitteln und kommunizieren zu lassen. Dabei darf natürlich nicht die Erwartungshaltung bestehen, dass Testing ausschließlich Sieger hervorbringt. Und man im schlimmsten Fall die Daten so lange dreht und wendet, bis man ein kleines Segment gefunden hat, wo der eigentlich negativ signifikante Test dann doch noch positiv gedeutet werden kann.
5. Validierung am User
Insbesondere in der Produktentwicklung sollte AB-Testing dafür genutzt werden, Features vorab am User zu vertesten – und hierbei in Kauf zu nehmen, dass man die eine oder andere Schleife mehr dreht. Das wirkt sich oftmals negativ auf die Roadmap aus. Solche “Validierungs-Loops” sollten aber immer gedanklich mit eingeplant werden.
Und zum Schluss – Testing macht Spaß und so sollte es auch gelebt werden! Da darf gern auch mal die eine oder andere Wette auf des Testergebnis abgeschlossen werden.
