Wachstumsexperiment-Design: Hypothese bis MDE bis Readout

Das erste Mal, dass ich einen „Gewinner" ausgeliefert habe, der uns 3% der Trials gekostet hat, war ein Preisseiten-CTA-Test. Drei Tage, 240 Besucher, Variante B um 6,2% oben. Der PM schickte das Trophäen-Emoji auf Slack. Zwei Wochen später sah unser wöchentliches Trial-Volumen merkwürdig aus, ich rechnete nochmals nach, und der ursprüngliche „Gewinner" lag die ganze Zeit innerhalb des Rauschbands. Wir hatten nichts ausgeliefert, außer einem Quartal Roadmap, das auf einem Bauchgefühl basierte.

Das ist der Job, ehrlich gesagt. Nicht das Testen. Der Teil, sich nicht täuschen zu lassen.

Dieser Leitfaden ist das Playbook, das ich mir für Tag eins gewünscht hätte: wie man eine Hypothese schreibt, die tatsächlich widerlegt werden kann, wie man die Stichprobengrößen-Mathematik auf einem Bierdeckel macht, wie man zwischen ICE und RICE wählt, ohne sich selbst anzulügen, und wie man ein Readout schreibt, das Ihr CFO tatsächlich öffnet. Wenn Sie eine Sache daraus mitnehmen, dann diese: Der Test ist nicht das Lieferobjekt. Das Readout ist es. In den meisten Quartalen sind das 4 Readouts, nicht 40.

Warum die meisten B2B-Experimente scheitern

Ich habe in den letzten Jahren vielleicht 60 Growth-Experimente über SaaS- und PLG-Unternehmen hinweg geprüft. Die Fehlermodi konzentrieren sich auf fünf Dinge, und vier davon werden entschieden, bevor der Test live geht.

1. Von Anfang an unterversorgt. Das Team führt einen 5-tägigen Test mit 800 Nutzern bei einer 8-prozentigen Baseline-Conversion durch, sieht eine 0,4 Prozentpunkte Steigerung und nennt es einen Gewinner. Der tatsächliche MDE bei dieser Stichprobengröße liegt bei etwa 3 Prozentpunkten relativ zur Baseline. Alles darunter ist statistisch nicht von Münzwürfen zu unterscheiden. Sie haben kein schlechtes Experiment durchgeführt. Sie haben einen Test durchgeführt, der nicht in der Lage war, den erhofften Effekt zu erkennen.

2. Hypothese als Aufgabenliste formuliert. „Wir werden eine neue Überschrift auf der Preisseite testen." Das ist keine Hypothese. Eine Hypothese sagt voraus, was sich ändert, um wie viel, für wen und warum. Wenn Ihre Hypothese durch die Daten nicht falsifiziert werden kann, wird der Test eine Geschichte produzieren, egal was passiert.

3. Kein Rollback-Plan. Variante wird ausgeliefert, Conversion fällt um 4%, niemand übernimmt die Rollback-Entscheidung, die Variante läuft weitere 6 Wochen, weil „wir mehr Daten wollen". Sie brauchen keine weiteren Daten. Sie brauchen eine vorab registrierte Stopping-Regel.

4. Keine primäre Metrik vorab registriert. Nach drei Tagen ist die Conversion flach, aber die Zeit auf der Seite ist um 22% gestiegen, also ist plötzlich die Zeit auf der Seite die Metrik. Das hat einen Namen: HARKing (Hypothesizing After Results are Known). Jedes Team tut es. Jedes Team, das es tut, produziert unzuverlässige Readouts.

5. Der PM schaut sich das Diagramm an Tag 3 an. Peeking. Sequential Testing existiert genau dafür, und die meisten Teams verwenden es nicht. Ein Standard-Fixed-Horizon-Test verliert seine statistischen Garantien in dem Moment, in dem Sie Entscheidungen auf Basis von Zwischenblicken treffen.

Die ersten vier werden durch eine Hypothesenvorlage gelöst. Der fünfte wird durch einen Stichprobengrößenrechner und die Disziplin gelöst, das Dashboard in Ruhe zu lassen.

Die Hypothesenvorlage

Kopieren Sie das. Fügen Sie es in den Experiment-Tracker Ihres Teams ein. Machen Sie es zur einzigen Vorlage, die irgendjemand verwenden darf.

EXPERIMENT: [Kurzname, z. B. „Preisseiten-Social-Proof-Block"]

PROBLEM (was wir in den Daten beobachtet haben):
  Wir sehen Verhalten X in Segment Y. Konkret:
  - Datenpunkt 1: [aus Analytics, Support-Tickets, Sales-Calls, qualitativ]
  - Datenpunkt 2: [bestätigend oder triangulierend]

VORHERGESAGTE ÄNDERUNG (was wir tun werden, für wen):
  Für [Segment] werden wir [Änderung vornehmen], weil [Mechanismus, den wir für wirksam halten].

ERFOLGSMETRIK:
  Primär:  [eine Metrik, mit aktuellem Baseline-Wert]
  Guardrail 1: [darf sich nicht schlechter als X entwickeln]
  Guardrail 2: [darf sich nicht schlechter als Y entwickeln]

MDE (der kleinste Effekt, auf den wir reagieren würden):
  Wir müssen eine relative Steigerung von [N%] auf der Primärmetrik erkennen.
  Darunter lohnt sich die Änderung nicht (Engineering-Kosten / Markenrisiko / Fokus).

STICHPROBENGRÖSSE & LAUFZEIT:
  Pro Arm: [N] Nutzer
  Geschätzte Laufzeit bei aktuellem Traffic: [N Wochen]

ROLLBACK-KRITERIEN:
  Wir beenden die Variante sofort, wenn:
  - Die Primärmetrik sich um mehr als [X] verschlechtert
  - Ein Guardrail seinen Schwellenwert für mehr als 48h überschreitet
  - Engineering einen P0/P1-Bug findet

ENTSCHEIDUNGSDATUM: [ein echtes Datum, nicht „wenn wir genug Daten haben"]
VERANTWORTLICHE PERSON: [eine Person]

Zwei Hinweise. Erstens, die MDE-Zeile ist kein Wunsch. Sie ist der Schwellenwert, unterhalb dessen Sie die Änderung sowieso nicht ausliefern würden, selbst wenn sie „real" wäre. Wenn eine 1,5-prozentige Steigerung bei der Aktivierung die Wartungskosten des dauerhaften Beibehaltens der Variante im Code nicht rechtfertigt, ist 1,5% nicht Ihr MDE. Ihr MDE ist die Zahl, die tatsächlich die Kosten übersteigt. Seien Sie dort ehrlich.

Zweitens, das Entscheidungsdatum beendet mehr Zombie-Tests als alles andere in dieser Vorlage. Ohne es läuft jeder Test ewig.

MDE-Mathematik auf dem Bierdeckel

Hier ist die Formel, die ich für die Planung verwende, gegen die ein echter Statistiker leichte Einwände hätte, die aber innerhalb von 10% der Wahrheit liegt und schnell genug ist, dass Sie sie tatsächlich verwenden werden:

n pro Arm  ca.  16 × p × (1 - p) / MDE²

Dabei ist:

• p Ihre Baseline-Conversion-Rate (als Dezimalzahl, z. B. 0,08 für 8%)
• MDE die absolute Steigerung, die Sie erkennen möchten (als Dezimalzahl, z. B. 0,008 für eine Bewegung von 8,0% auf 8,8%, was einer relativen Steigerung von 10% entspricht)
• 16 beinhaltet 80% Power und 95% Konfidenz (zweiseitig)

Das ist alles. Keine Software erforderlich. Rechnen wir ein echtes Beispiel durch.

Durchgerechnetes Beispiel: 8-prozentige Trial-zu-bezahlt-Conversion

Ihr B2B SaaS hat 600 wöchentliche Anmeldungen. Trial-zu-bezahlt liegt bei 8% (p = 0,08). Sie möchten eine relative Steigerung von 10% erkennen, also eine absolute Bewegung von 8,0% auf 8,8% (MDE = 0,008).

n pro Arm  =  16 × 0,08 × 0,92 / (0,008)²
           =  16 × 0,0736 / 0,000064
           =  1,1776 / 0,000064
           ca. 18.400 Nutzer pro Arm

Zwei Arme = 36.800 Nutzer. Bei 600 Anmeldungen/Woche, 50/50 auf den Test aufgeteilt, sind das ungefähr 6 bis 8 Wochen Traffic für ein Experiment. Nicht 5 Tage.

Wenn Sie eine relative Steigerung von 25% erkennen möchten (8,0% auf 10,0%), wird die Mathematik freundlicher:

n pro Arm  =  16 × 0,08 × 0,92 / (0,02)²
           =  1,1776 / 0,0004
           ca. 2.944 pro Arm

Etwa 6.000 Nutzer insgesamt. Bei 600/Woche, ca. 2 Wochen. Der Haken: 25% relative Steigerungen bei Trial-zu-bezahlt sind in reifen B2B-Funneln grundsätzlich Einhorn-Ergebnisse. Sie bekommen ein oder zwei pro Jahr, wenn Sie gut sind. Die meisten echten Gewinne liegen bei 3 bis 8% relativ, was bedeutet, dass die meisten Tests Monate Traffic benötigen, keine Tage.

Das ist der Teil, den niemand hören möchte: Ihr Funnel bewegt sich nicht um 25%, also müssen Ihre Experimente für die Steigerungen konzipiert sein, die tatsächlich existieren. Das übersehen und jeder Test wird zu einem Rorschach-Test.

Wann „wir lassen es einfach länger laufen" falsch ist

Wenn ein Test von Anfang an unterversorgt war, behebt längeres Laufen bei Fixed-Horizon-Einstellungen das Problem nicht. Es bläht Ihre False-Positive-Rate auf, weil Sie effektiv Peeking betreiben. Wenn Sie wirklich Flexibilität bei der Laufzeit benötigen, wechseln Sie zu:

• Sequential Testing (msPRT, immer gültige p-values): ermöglicht frühes Beenden oder Verlängerung, ohne die Mathematik zu brechen. Statsig, GrowthBook und Eppo unterstützen dies nativ.
• CUPED (Varianzreduzierung durch Vor-Experiment-Daten): kann die erforderliche Stichprobengröße um 30 bis 50% bei Metriken mit starkem Vorzeitraum-Signal reduzieren. Es lohnt sich, dies bei jedem wichtigen Test einzuschalten.

Versuchen Sie nicht, diese selbst zu implementieren. Verwenden Sie die Plattform.

Häufige Diagnosen nach Namen kennen

Wenn Sie den Fehlermodus benennen können, können Sie in einem Readout-Review dagegen argumentieren. Die fünf, die ich am häufigsten sehe:

• HARKing: Die Metrik nach dem Ergebnis auswählen. Gelöst durch Vorabregistrierung von Primär- und Guardrail-Metriken vor dem Start.
• Peeking: Entscheidungen auf Basis von Zwischenblicken bei Fixed-Horizon-Tests treffen. Gelöst durch Sequential Testing oder dadurch, tatsächlich nicht zu schauen, bis das Entscheidungsdatum kommt.
• Neuheitseffekt: Die Variante gewinnt zwei Wochen, weil sie neu ist, dann sinkt sie. Gelöst durch Verlängerung der Tests bei UI-Änderungen und Beobachtung des Verhaltens ab Woche 3.
• Simpsons Paradoxon: Die Variante gewinnt insgesamt, verliert aber in jedem Segment, weil sich die Mischung verschoben hat. Gelöst durch immer vorab segmentierte Readouts (neu vs. wiederkehrend, nach Plan, nach Quelle).
• Survivorship Bias in Kohorten-Metriken: „Kundenbindung in Woche 4" nur bei Nutzern zu messen, die es bis Woche 4 geschafft haben, bläht die Zahl auf. Gelöst durch Verankerung der Kohorten beim Eintrittsereignis.

Priorisierung: ICE vs. RICE vs. PIE

Drei Frameworks, etwas unterschiedliche Zutaten, alle lügen Sie auf unterschiedliche Weise an.

Meine ehrliche Einschätzung: ICE ist in Ordnung für ein 2-Personen-Team und lügt für ein 20-Personen-Team. Wenn das Team klein genug ist, dass alle jedes Dokument gelesen haben, ist ICE nur eine Art, ein Gespräch aufzuschreiben, das man ohnehin geführt hätte. Sobald das Team groß genug ist, dass der ICE-Score das einzige Artefakt ist, das ein Stakeholder liest, manipuliert jeder PM ihn.

Die Falle bei allen dreien: Sie bewerten Ihre eigenen Experimente. Owner gewichten Confidence bei ihren eigenen Ideen zu hoch. Engineers gewichten Ease bei fremden Ideen zu niedrig. Der Score wird zum Stellvertreter für Büropolitik.

Was ich stattdessen in größerem Maßstab verwende: eine Confidence x Reach 2x2 ohne Mathematik. Oben rechts (hohes Vertrauen, hohe Reichweite) wird jetzt ausgeliefert. Oben links (hohes Vertrauen, geringe Reichweite) wird ausgeliefert, wenn es günstig ist. Unten rechts (geringes Vertrauen, hohe Reichweite) wird zu einer bezahlten Forschungsinvestition. Wir finanzieren den Test auf Basis des Lernwerts, nicht der erwarteten Steigerung. Unten links stirbt. Wöchentlich überprüft, in einem 30-minütigen Meeting, mit dem Head of Growth, der den Stift hält.

Es ist keine Zahl. Es ist ein Erzwingungsmechanismus für ehrliche Gespräche.

WIP-Limit: maximal 3 bis 5 laufende Tests

Für die meisten B2B-Teams unter 500 Mitarbeitern ist die richtige Anzahl gleichzeitiger Experimente 3 bis 5. Darüber hinaus fressen Sie Ihren eigenen Traffic, Ihre Interaktionseffekte werden nicht mehr nachvollziehbar, und Ihr Team kann den Readouts nicht wirklich Aufmerksamkeit schenken. Die Einschränkung ist nicht die Engineering-Geschwindigkeit. Es sind Traffic und Aufmerksamkeit.

Das Readout-Dokument (das ist das eigentliche Lieferobjekt)

Jeder ausgelieferte, beendete oder unklare Test erhält ein einseitiges Readout. Kein Dashboard. Ein Dokument. Für immer im selben Ordner gespeichert.

READOUT: [Experimentname]
ZEITRAUM: [Start] bis [Ende]
VERANTWORTLICHE PERSON: [Name]
STATUS: Ausgeliefert / Beendet / Unklar

WAS AUSGELIEFERT WURDE
  Variante B hat [X] durch [Y] auf [Seite/Ablauf] ersetzt, für [Segment], von [Datum] bis [Datum].

WAS WIR GEMESSEN HABEN
  Primär:     [Metrik] -- Kontrollgruppe [N], Variante [N], Delta [+X% / -Y%], p = [N], KI [N, N]
  Guardrail 1: [Metrik] -- flat / Schwellenwert überschritten
  Guardrail 2: [Metrik] -- flat / Schwellenwert überschritten
  Stichprobe: [N pro Arm] -- konzipiert für [MDE]% relativer Steigerung

WAS WIR GELERNT HABEN
  - Ergebnisinterpretation in 2 bis 3 Sätzen. Kein „Das haben wir gerockt." Ja: „Trial-zu-bezahlt
    bewegte sich um +4,2% (KI 1,1 bis 7,3%), innerhalb unseres vorab registrierten MDE von 4%,
    also liefern wir aus."
  - Segmentaufschlüsselungen: [wo der Effekt am stärksten / schwächsten war]
  - Irgendwas Merkwürdiges: [Neuheitssignal? Guardrail-Rauschen? Datenqualität?]

WAS ALS NÄCHSTES PASSIERT
  - Auslieferungs- / Hold-out-Plan für Variante
  - Folgetests (maximal 2)
  - Alles, was Engineering, Produkt oder Design Aufmerksamkeit braucht

WORAN WIR UNS GEIRRT HABEN
  Ein Satz. Das, was wir zu Beginn glaubten und was die Daten widerlegt hat (oder nicht bestätigt hat).

Die „woran wir uns geirrt haben"-Zeile ist die Geheimwaffe. Sie tut drei Dinge:

1. Baut Teamvertrauen auf. Führungskräfte sehen, dass Sie Verluste nicht als Gewinne verpacken.
2. Kumuliert Erkenntnisse. Nach einem Jahr hat man 30+ „woran wir uns geirrt haben"-Zeilen, und Muster entstehen („Wir überschätzen ständig den Impact von Preisseiten-Änderungen").
3. Kalibriert künftige Confidence-Scores. Ihre Annahmen werden schärfer.

Wenn Ihre Readouts keine „wir haben uns geirrt"-Zeile für mindestens 60% der abgeschlossenen Tests haben, testen Sie entweder nur sichere Dinge oder schreiben Sie die Geschichte um. Beide Varianten sind schlecht.

Woher der Hypothesenrückstand kommt

Eine Test-Pipeline verhungert, wenn das Team keine strukturierte Methode zur Ideenfindung hat. Fünf Quellen, denen ich vertraue, in ungefähr absteigender Signalstärke:

1. Funnel-Unterschiede: Segment X konvertiert beim gleichen Schritt halb so gut wie Segment Y. Herausfinden, warum. Hier liegen die größten, am besten verteidigbaren Gewinne.
2. Qualitative Interviews: 5 abgewanderte Kunden, aufgezeichnet, transkribiert. Sie werden dieselbe Reibung in 3 davon hören. Diese Reibung ist Ihre nächste Hypothese.
3. Sales-Call-Aufnahmen: Gong oder Chorus ist eine Goldmine. Nach „ich wünschte, es könnte" oder „was mich verwirrt hat" suchen. Jedes davon ist eine Hypothese mit voreingebautem Vertrauen.
4. Support-Tickets: gleiche Idee, weiter unten im Funnel. Nach Thema clustern. Der größte Cluster ist oft ein 2-Wochen-Engineering-Fix, der die Aktivierung mehr steigert als die letzten 6 Tests zusammen.
5. Wettbewerber-Analysen: nützlich, aber gefährlich. Sie gewichten Neuheit zu stark. Diese standardmäßig als geringe Confidence kennzeichnen.

Jede Idee gegen die Hypothesenvorlage bewerten, bevor sie in die Priorisierungswarteschlange kommt. Wenn Sie den Problemabschnitt nicht mit zwei echten Datenpunkten füllen können, ist die Idee nicht bereit. Sie ist eine Vermutung. Zurück zur Recherche schicken.

Zombie-Experimente beenden

Jedes Growth-Team, das ich gesehen habe, hat sie: Tests, die noch Traffic an eine Variante liefern, die niemand betreut, hinter einem Flag, das sich niemand erinnert, auf einer Seite, die niemand prüft. Drei Regeln:

• Die 90-Tage-Regel. Wenn ein Test mehr als 90 Tage live ist, ohne ein Readout, wird er standardmäßig beim nächsten Quartals-Review beendet. Keine Ausnahmen für „wir warten auf mehr Daten." Wenn ein Test 4 Monate braucht, um Signifikanz zu erreichen, war er beim Start unterversorgt, und die richtige Antwort ist, ihn zu stoppen und neu zu gestalten.
• Quartalsweise Graveyard-Review. Einmal pro Quartal jeden aktiven Flag in der Experimentierungsplattform prüfen. Jedem eine verantwortliche Person und ein Readout-Dokument zuordnen. Alles ohne Betreuer wird auf die Kontrollgruppe zurückgesetzt und der Flag aus der Codebase gelöscht.
• Das „liefert noch Traffic"-Audit. Die Liste aller experiment-berechtigten URLs abrufen und mit aktiven Tests in der Plattform abgleichen. Jede Lücke ist entweder ein Konfigurationsfehler oder ein Zombie. Beide beheben.

Das Team, das dieses Audit ehrlich durchführt, wird feststellen, dass 30 bis 40% seiner „aktiven" Tests totes Gewicht sind. Sie zu beenden, gibt Traffic und Aufmerksamkeit für Tests frei, die tatsächlich lernen können.

Die eigentliche Aufgabe des Growth IC

Ich schließe, wo ich begonnen habe. Die Aufgabe des IC ist nicht, mehr Tests auszuliefern. Es ist, mehr Erkenntnisse auszuliefern. In den meisten Quartalen sind das 4 gut gestaltete, ordentlich konzipierte, ehrlich readout-te Tests, nicht 40 Achselzucken.

Eine gute Experimentierpraxis sieht von außen langsam aus. Das Team führt 3 Tests durch, nicht 30. Die Hälfte der Readouts sagt „wir haben uns geirrt." Der PM, der Peeking verteidigt, erhält Widerspruch. Der CFO öffnet das Readout-Dokument tatsächlich und stellt eine Frage zur Guardrail-Metrik.

Das ist der Job, der funktioniert. Die Trophäen auf Slack kommen später, und sie sind echt, weil die Mathematik echt war.

Mehr erfahren

• Growth Marketing Manager Stellenbeschreibung
• PLG-Funnel-Diagnose für den Growth IC
• Aktivierungsmetrik-Auswahl: Die eine Zahl bestimmen
• Eine Kohortenbindungskurve lesen, ohne sich selbst anzulügen