Wo Produkt endet und Growth beginnt: den Loop zwischen Features, Funnels und Feedback schließen

Produkt und Growth sind ein Loop, kein Staffellauf

In den meisten kleinen Softwarefirmen, die ich kennenlerne, funktioniert Wachstum wie ein Staffellauf. Das Marketing läuft die erste Runde und übergibt eine Anmeldung. Das Produkt läuft die zweite Runde und gibt ein Feature zurück. Für die Lücke dazwischen ist niemand zuständig, und genau dort gehen die meisten Menschen verloren.

Brian Balfour, Casey Winters, Kevin Kwok und Andrew Chen haben das Problem 2018 in ihrem Essay über Growth Loops genau benannt. Wer rund um einen Funnel plant, schreiben sie, behandelt Produktstrategie und Akquisestrategie in getrennten Silos: Das Marketing ist für die Akquise zuständig, das Produkt für die Retention.¹

Die Rechnung hinter Loops, die Verstärkung und den Multiplikator, habe ich schon im Growth Flywheel durchgerechnet, den Funnel selbst im Pirate Metrics Framework. In diesem Artikel geht es um die Produktseite desselben Loops. Zwei Fragen. Welche Features erzeugen einen Loop, statt nur im Produkt zu stehen? Und wie entscheidet das, was Nutzer tun, darüber, was als Nächstes gebaut wird?

Durch den ganzen Artikel begleitet uns ein erfundenes Unternehmen. Schichtfink ist eine App für Dienst und Schichtpläne in unabhängigen Cafés und Bäckereien, betrieben von einem Entwickler namens Jonas in Köln, unter schichtfink.example. Nach einer kostenlosen Testphase von 14 Tagen kostet sie 29 € im Monat pro Betrieb. Die Firma gibt es nicht, und jede Zahl ist ausgedacht, damit ich jeden Rechenschritt zeigen kann.

Beispiel: Jonas' Staffellauf in Zahlen

Im September gibt Jonas 9.000 € für Anzeigen aus. Sie bringen 600 Anmeldungen zur Testphase, eine Anmeldung kostet also $9.000 / 600 = 15$ €. Von den 600 Testphasen werden 60 zu zahlenden Betrieben, eine Rate von Testphase zu Abo von $60 / 600 = 10\ \%$, und ein zahlender Betrieb kostet $9.000 / 60 = 150$ €.

Der Marketingbericht sagt: 600 Anmeldungen zu je 15 €, das sieht gut aus. Der Produktbericht sagt: drei Features ausgeliefert, das sieht auch gut aus. Keiner der beiden Berichte erwähnt die 540 Betriebe, die Schichtfink ausprobiert haben und wieder gegangen sind. In dieser Lücke spielt der Rest dieses Artikels.

Ein Feature wird zum Loop, wenn sein Ergebnis jemand Neues erreicht

Die meisten Features dienen der Person, die sie benutzt. Ein paar tun mehr: Was sie erzeugen, landet vor einem Menschen, der vom Produkt noch nie gehört hat. In diesem Moment wird aus einem Feature ein Loop.

Balfour formuliert den allgemeinen Gedanken in seinem Essay über Product Channel Fit: Produkte werden so gebaut, dass sie zu Kanälen passen, nicht umgekehrt, und Kanäle verbiegen sich nicht, um zu Produkten zu passen.² Für ein Produkt, das sich über seine Nutzer verbreiten soll, zählt er auf, was es braucht: einen schnellen Weg zum ersten Nutzen, ein breites Wertversprechen und am besten ein Netzwerk, das das Produkt besser macht.²

Kevin Kwoks Analyse des Designwerkzeugs Figma zeigt, wie das als Feature aussieht. Ein Design zu teilen ist so einfach wie einen Link zu verschicken, jeder kann ihn im Browser öffnen, und je mehr Designer das Werkzeug nutzen, desto mehr Menschen ohne Designberuf ziehen sie mit hinein, mit denen sie zusammenarbeiten.³ Das Feature ist ein Link. Der Loop sind alle, die ihn öffnen.

Die Verstärkung eines solchen Loops hat dieselben drei Teile wie die jedes anderen Loops. Die vollständige Herleitung steht im Growth Flywheel, hier nur die Kurzform:

$$g = s \times i \times c$$

Dabei ist $g$ die Verstärkung des Loops, also die Neukunden, die ein Neukunde pro Durchlauf bringt. $s$ ist der Anteil der Kunden, die das Feature so nutzen, dass es jemand Neues erreicht. $i$ ist die Zahl der neuen Menschen, die jeder von ihnen erreicht. $c$ ist der Anteil dieser Menschen, der zu Kunden wird. Jede dieser Größen ist eine einfache Rate, Ereignisse geteilt durch Gelegenheiten. Grundlagen: Verhältnisse und Raten

Auf der Produktseite ist jeder Buchstabe eine Designentscheidung: ob das Feature genutzt wird, wie viele Menschen sein Ergebnis sehen und was sie danach tun können.

Beispiel: der veröffentlichte Dienstplan

Jeder Betrieb kann seinen Wochenplan in Schichtfink als Link veröffentlichen, den das Team auf dem Handy öffnet. Unten auf jeder Planseite steht eine Zeile: Dienstpläne von Schichtfink, erstell einen für deinen Betrieb.

Von den 60 Betrieben, die im September zahlende Kunden wurden, haben 45 einen Planlink veröffentlicht, also $s = 45 / 60 = 0{,}75$. Jeden veröffentlichten Plan öffnen im Schnitt acht Leute aus dem Team, also $i = 8$. Das sind $45 \times 8 = 360$ Beschäftigte, die die Zeile gesehen haben. Manche von ihnen führen ein zweites Café oder leiten dort die Schichten, und im Folgemonat kamen über diese Zeile im Schnitt 3,6 neue zahlende Betriebe, also $c = 3{,}6 / 360 = 0{,}01$.

Die Verstärkung ist $g = 0{,}75 \times 8 \times 0{,}01 = 0{,}06$. Je 100 zahlende Betriebe bringen sechs weitere.

Dann ändert Jonas eine Sache. Aus der Zeile wird ein Button, "diesen Plan für meinen Betrieb nutzen", der eine Testphase mit demselben Aufbau öffnet, schon ausgefüllt. Der Anteil, der zu Kunden wird, verdoppelt sich auf $c = 0{,}02$, und die Verstärkung verdoppelt sich auf $g = 0{,}75 \times 8 \times 0{,}02 = 0{,}12$.

Der Flywheel Artikel zeigt, dass ein Loop unter eins die bezahlten Kunden mit $\frac{1}{1-g}$ multipliziert, der Summe einer schrumpfenden Reihe. Grundlagen: Zinseszins Für Jonas' 60 bezahlte Betriebe im Monat sind das $60 / 0{,}94 = 63{,}8$ im Monat vor der Änderung und $60 / 0{,}88 = 68{,}2$ danach. Vier Betriebe mehr im Monat, für einen Button. Nichts Spektakuläres, aber es zahlt sich in jedem Monat aus, in dem es das Produkt gibt.

Die besten Loops erreichen Menschen, die für viele entscheiden

Nicht jeder, der das Ergebnis eines Features sieht, ist gleich viel wert. Eine Kellnerin, die die Zeile unter dem Plan sieht, entscheidet für niemanden. Wer 40 Betriebe berät, entscheidet für 40 mit, oder hat zumindest Einfluss auf sie. Wenn ich in einem Produkt nach Loops suche, verfolge ich das Ergebnis jedes Features und frage, wer es bekommt und für wie viele andere diese Person spricht.

Beispiel: der Lohnexport

Schichtfink hat einen Lohnexport, eine monatliche Datei mit den geleisteten Stunden. Jonas fällt auf, wohin sie geht: Die meisten Betriebe schicken sie an ihre Steuerkanzlei, und Kanzleien mit Schwerpunkt Gastronomie betreuen meist viele Betriebe.

Von den 60 neuen zahlenden Betrieben schicken 30 den Export an eine Kanzlei, also $s = 0{,}5$. Jeder schickt ihn an eine Kanzlei, also $i = 1$. Jonas ergänzt die Exportdatei um eine kurze Zeile mit einem Link zu einer kostenlosen Kanzleiansicht, die die Stunden aller Schichtfink Mandanten einer Kanzlei an einem Ort zeigt. In den folgenden Monaten bringt eine von fünf Kanzleien, die einen Export bekommen, einen weiteren Betrieb, weil sie Schichtfink einem Mandanten empfiehlt, der seine Pläne noch in Tabellen führt, also $c = 0{,}2$.

Die Verstärkung dieses zweiten Loops ist $g = 0{,}5 \times 1 \times 0{,}2 = 0{,}10$. Eine erreichte Kanzlei ist weit mehr wert als acht Leute aus dem Team: Der Loop über das Team braucht 360 Menschen für das, was der Loop über die Kanzleien mit 30 schafft.

Weil die beiden Loops verschiedene Menschen erreichen, addieren sich ihre Verstärkungen, auf etwa $0{,}12 + 0{,}10 = 0{,}22$ für dieselben 60 Betriebe. Das ist eine grobe Summe, denn ein Betrieb, den beide Loops finden, zählt nur einmal. Ein Feature, das ohnehin auf dem Schreibtisch einer Kanzlei landet, ist der günstigste Loop, den Jonas je bauen wird.

Nicht jedes Feature sollte ein Loop sein

Schief geht diese Idee, wenn jedes Feature einen Teilen Button bekommt, jeder Bildschirm ein "Empfiehl uns weiter" und das Produkt sich anfühlt wie ein Werbeprospekt. Balfours eigene Liste erklärt, warum das selten funktioniert: Der Kanal braucht einen schnellen Weg zum ersten Nutzen und ein breites Wertversprechen, und ein Teilen Button liefert keins von beidem.²

Die meisten Features sollten eine leise Aufgabe erfüllen: das Produkt wert machen, dass man es behält. Ein Feature, das einen Betrieb ein weiteres Jahr hält, verdient seinen Platz, ohne je jemand Neues zu erreichen. Die Frage für jedes Feature ist einfach. Erreicht sein Ergebnis von selbst jemand Neues, so wie ein Plan das Team erreicht und ein Export die Kanzlei? Dann gestalte es für den Loop. Wenn nicht, gestalte es für die Person, die es benutzt, und lass den Teilen Button weg.

Ein Beispiel: Das Urlaubskonto in Schichtfink zeigt allen im Team, wie viele Urlaubstage sie noch haben. Sein Ergebnis bleibt im Betrieb. Also beurteilt Jonas das Urlaubskonto nur nach einer Zahl, nämlich ob Betriebe, die es nutzen, länger bleiben, und überlässt die Wachstumsarbeit dem Plan und dem Export.

Die Aktivierung ist der Moment, in dem der Loop anlaufen kann

Ein Loop dreht sich nur für Kunden, die an den Punkt kommen, an dem das Produkt seine Arbeit tut. Vor diesem Punkt entsteht nichts, also erreicht auch nichts irgendjemanden. Dieser Punkt heißt Aktivierung, in den Pirate Metrics die Stufe Activation: das erste Mal, dass ein neuer Nutzer den Nutzen bekommt, den das Produkt verspricht. Für Schichtfink ist das ein veröffentlichter Plan, denn erst dann sieht das Team ihn, und erst dann tut die Zeile darunter überhaupt etwas.

Die Aktivierung muss vorher festgelegt werden, als ein zählbares Ereignis. Jonas' Definition: Ein Betrieb hat innerhalb von drei Tagen nach der Anmeldung einen Plan mit mindestens drei Beschäftigten veröffentlicht. Die Aktivierungsrate ist dann eine einfache Rate:

$$a = \frac{n_{\text{aktiviert}}}{n_{\text{Testphasen}}}$$

Dabei ist $a$ die Aktivierungsrate, $n_{\text{aktiviert}}$ die Zahl der Testphasen, die das Aktivierungsereignis in der vorgesehenen Zeit erreicht haben, und $n_{\text{Testphasen}}$ die Zahl der Testphasen, die im selben Zeitraum begonnen haben. Grundlagen: Verhältnisse und Raten

Beispiel: wohin die 600 Testphasen im September gingen

Jonas verfolgt die 600 Testphasen aus dem September durch die Schritte bis zum veröffentlichten Plan:

• 600 haben eine Testphase begonnen.
• 390 haben mindestens drei Beschäftigte angelegt.
• 270 haben einen ersten Plan gebaut.
• 150 haben ihn innerhalb von drei Tagen veröffentlicht. Das sind die aktivierten Betriebe.
• 60 wurden zu zahlenden Betrieben.

Die Aktivierungsrate ist $a = 150 / 600 = 25\ \%$. Drei Viertel der Testphasen sind nie an den Punkt gekommen, an dem Schichtfink irgendetwas tut.

Auf der waagerechten Achse stehen die Schritte der Testphase in ihrer Reihenfolge. Auf der senkrechten Achse steht die Zahl der Betriebe, die den jeweiligen Schritt erreicht haben. Der größte einzelne Verlust ist gleich der erste: 210 Betriebe zwischen dem Beginn der Testphase und dem Anlegen des Teams. Daraus folgt: Die wertvollste Produktarbeit liegt meist beim ersten Schritt, der Menschen verliert, nicht beim letzten Bildschirm vor der Zahlung.

Silent Churn ist der Kunde, der auf dem Papier nie geht

Nicht jede Abwanderung zeigt sich als Kündigung. In einer Testphase drücken die meisten, die gehen, nie auf irgendetwas. Sie haben sich angemeldet, sich umgesehen, den Moment des Nutzens nicht erreicht und sind einfach nicht wiedergekommen. Ich nenne das Silent Churn, die stille Abwanderung. In keinem Kündigungsbericht taucht sie auf, denn gekündigt wurde ja nichts.

Im September hatte Jonas 450 Testphasen, die nie aktiviert haben, und keine davon hat ihm gesagt, warum. Ein Dashboard mit Anmeldungen und Kündigungen hätte ein gesundes Produkt gezeigt.

Die Signale stecken meist in den eigenen Ereignissen des Produkts, wenn jemand hinschaut:

Signal	Was es nahelegt	Was ich zuerst versuche
Einrichtung begonnen, nicht beendet	Verloren vor jedem Nutzen	Den ersten Erfolg kleiner machen
Nur eine Sitzung	Nichts hat sie zurückgeholt	Einen Grund geben, morgen wiederzukommen
Wichtigstes Feature nie geöffnet	Sein Nutzen ist unklar	Es dorthin legen, wo sie ohnehin sind
Testphase endet ohne Aktion	Eine passive Testphase	Eine hilfreiche Nachricht mitten in der Testphase

All das stammt aus einfachen Produktereignissen, für die eine Einwilligung vorliegt: ein Schritt abgeschlossen, ein Bildschirm geöffnet. Sitzungsaufzeichnungen oder Heatmaps nutze ich dafür nicht. Eine Frage, die sich weder mit einem gezählten Ereignis noch mit einer Nachfrage bei einem Menschen beantworten lässt, braucht auch keine Aufzeichnung seines Bildschirms.

Ein Beispiel: Von Jonas' 210 Testphasen, die am ersten Schritt verloren gingen, hatten 160 die Seite für das Team geöffnet und sie verlassen, ohne jemanden anzulegen. Ein Rätsel ist das nicht. Acht Namen, Telefonnummern und Vertragsstunden in ein Formular zu tippen ist lästig. Wie Jonas herausfindet, ob das wirklich der Grund ist, zeigt der nächste Abschnitt.

Von der Testphase zum Abo: Vergleiche aktivierte Betriebe mit dem Rest

Der alte Reflex ist, an der Bezahlseite um die Conversion zu kämpfen. Nach meiner Erfahrung ist die Entscheidung Tage vorher gefallen, bei der Aktivierung. Du siehst das in Jonas' Zahlen, wenn du die Testphasen in zwei Gruppen teilst und eine bedingte Frage stellst: Welcher Anteil der Aktivierten hat bezahlt, und welcher Anteil der Übrigen? Die Regel dahinter ist die bedingte Wahrscheinlichkeit:

$$P(\text{bezahlt} \mid \text{aktiviert}) = \frac{P(\text{bezahlt} \cap \text{aktiviert})}{P(\text{aktiviert})}$$

Dabei ist $P(\text{bezahlt} \mid \text{aktiviert})$ die Wahrscheinlichkeit, dass eine Testphase zum Abo wird, wenn sie aktiviert hat. $P(\text{bezahlt} \cap \text{aktiviert})$ ist die Wahrscheinlichkeit, dass eine Testphase sowohl aktiviert als auch bezahlt hat, und $P(\text{aktiviert})$ die Wahrscheinlichkeit, dass eine Testphase aktiviert hat, also die Aktivierungsrate $a$ von oben. Grundlagen: Wahrscheinlichkeit

Beispiel: zwei sehr verschiedene Testphasen

Von den 60 zahlenden Betrieben hatten 51 aktiviert und neun nicht. Also:

$$P(\text{bezahlt} \mid \text{aktiviert}) = \frac{51 / 600}{150 / 600} = \frac{51}{150} = 34\ \%$$

Dabei ist $51 / 600$ der Wert von $P(\text{bezahlt} \cap \text{aktiviert})$, der Anteil aller Testphasen, die aktiviert und bezahlt haben, und $150 / 600$ ist $P(\text{aktiviert})$, die Aktivierungsrate. Dieselbe Regel für die 450 Testphasen, die nie einen Plan veröffentlicht haben, ergibt $P(\text{bezahlt} \mid \text{nicht aktiviert}) = 9 / 450 = 2\ \%$. Grundlagen: Wahrscheinlichkeit Ein Betrieb, der aktiviert hat, hat also 17 Mal so oft bezahlt.

Jetzt die ehrliche Einschränkung. Das beweist nicht, dass die Aktivierung die Zahlung verursacht. Eine Cafébesitzerin, die ohnehin überzeugt ist, veröffentlicht einen Plan und zahlt, und sie hätte auch so gezahlt. Korrelation ist keine Kausalität, wie Grundlagen: Korrelation erklärt. Die Aufteilung sagt Jonas, wo er hinschauen soll. Erst ein Test, weiter unten in diesem Artikel, sagt ihm, ob mehr aktivierte Betriebe tatsächlich mehr zahlende bringen.

Gemeinsame Definitionen, damit alle dasselbe zählen

Der Staffellauf vom Anfang lebt von unscharfen Wörtern. Das Marketing sagt "Lead", das Produkt sagt "aktiver Nutzer", und die beiden Zahlen begegnen sich nie. Die Lösung ist langweilig und sie funktioniert: Schreib eine kurze Liste von Definitionen auf, einige dich einmal darauf und lass jeden Bericht sie verwenden.

Mit diesen dreien fange ich an, hier für Schichtfink formuliert:

Begriff	Jonas' Definition
Aktivierter Betrieb	Plan mit mindestens drei Beschäftigten innerhalb von drei Tagen veröffentlicht
Product Qualified Lead (PQL)	Aktiviert, und hat einen zweiten Wochenplan veröffentlicht
Bereit für ein Upgrade	Zwei oder mehr Standorte angelegt, oder die Preisseite für mehrere Standorte angesehen

Ein Product Qualified Lead (PQL) ist einfach eine Testphase, deren Verhalten im Produkt sagt, dass sie wahrscheinlich kauft, im Unterschied zu einem Lead, der nur ein Formular ausgefüllt hat.

Beispiel: die Schnäppchenkampagne, die teurer war

Im Oktober fährt Jonas zwei Kampagnen mit je 3.000 €. Kampagne A, eine breit gestreute Social Media Anzeige, bringt 300 Testphasen zu je 10 €. Kampagne B, eine Suchanzeige auf "Dienstplan für Cafés", bringt 120 Testphasen zu je 25 €. Nach den Kosten pro Anmeldung gewinnt A klar.

Nach der gemeinsamen Definition nicht. Von den 300 Testphasen aus A aktivieren 15 %, also 45 Betriebe, zu $3.000 / 45 = 66{,}67$ € pro aktiviertem Betrieb. Von den 120 aus B aktivieren 45 %, also 54 Betriebe, zu $3.000 / 54 = 55{,}56$ € pro aktiviertem Betrieb. Sobald alle das zählen, worauf es ankommt, ist B die günstigere Kampagne. Und weil aktivierte Betriebe die sind, die zahlen und Pläne veröffentlichen, speist B auch den Loop stärker.

Feedback entscheidet, was gebaut wird, weil die meisten Ideen scheitern

Bis hierher lief der Loop vom Produkt zum Wachstum: Features, die sich verbreiten, und eine Aktivierung, die die Verbreitung in Gang setzt. Die andere Hälfte läuft zurück: Was Nutzer tun und sagen, entscheidet darüber, was gebaut wird. Diese Hälfte zählt, weil Teams ihre eigenen Ideen schlecht beurteilen.

Den besten Beleg, den ich kenne, liefern Leute, die es messen konnten. In einem begutachteten Fachaufsatz von 2013 berichten Ron Kohavi und Kollegen bei Microsoft, dass nur ein Drittel der dort getesteten Ideen die Kennzahl oder die Kennzahlen verbessert hat, für die sie gedacht waren, und dass Erfolg in gut optimierten Produkten wie ihrer Suchmaschine Bing noch schwerer zu finden ist.⁴ Derselbe Aufsatz empfiehlt einen Trichter für Ideen: oben viele Ideen, ausgedünnt mit Methoden, die wenig kosten, etwa vorstellen und Entwürfe begutachten, und vollständige kontrollierte Experimente nur für die wenigen, die übrig bleiben, weil es teuer ist, jede Idee gut genug für einen Test zu bauen.⁴

Eine Trefferquote von eins zu drei macht aus jedem Feature eine Wette, und eine Wette hat einen Erwartungswert:

$$E[X] = \sum_i p_i\, x_i$$

Dabei ist $E[X]$ der Erwartungswert der Wette, $p_i$ die Wahrscheinlichkeit des Ergebnisses $i$ und $x_i$ das, was das Ergebnis $i$ wert ist. Die Summe läuft über alle möglichen Ergebnisse. Grundlagen: Erwartungswert

Beispiel: das Feature zum Schichttausch

Jonas will einen Schichttausch bauen: Beschäftigte tauschen Schichten in der App, und die Chefin bestätigt mit einem Tippen. Das würde sechs Wochen seiner Zeit kosten, die er mit 1.000 € pro Woche ansetzt, also 6.000 €. Wenn es funktioniert, schätzt er seinen Wert im nächsten Jahr auf 12.000 €, durch Betriebe, die aktivieren und bleiben. Wenn nicht, ist es nichts wert.

Eine eigene Trefferquote hat Jonas noch nicht, also leiht er sich das eine Drittel von Microsoft als Ausgangspunkt. Das ist eine geliehene Basisrate, kein Naturgesetz, und er sollte sie durch seine eigene ersetzen, sobald er ein paar Features nachgezählt hat.

$$E[X] = \tfrac{1}{3} \times 12.000 + \tfrac{2}{3} \times 0 = 4.000$$

Dabei sind $\tfrac{1}{3}$ und $\tfrac{2}{3}$ die Wahrscheinlichkeiten $p_i$ für Erfolg und Misserfolg, und 12.000 € und 0 € die Werte $x_i$ der beiden Ergebnisse, das Ergebnis also 4.000 €. Grundlagen: Erwartungswert Erwartete 4.000 € gegen sichere 6.000 € Bauzeit sind ein erwarteter Verlust von 2.000 €.

Also macht Jonas die Wette kleiner, statt auf bessere Chancen zu hoffen. Eine Woche lang, für 1.000 € seiner Zeit, baut er einen Button "Tausch für diese Schicht anfragen", der ihm die Anfrage schickt, und er erledigt den Tausch von Hand. Wenn die Betriebe ihn nutzen, baut er das richtige Feature. Die erwarteten Kosten sind jetzt $1.000 + \tfrac{1}{3} \times 6.000 = 3.000$ €, gegen dieselben erwarteten 4.000 €, ein Plus von etwa 1.000 €. Die Idee ist dieselbe. Nur der Weg, es herauszufinden, kostet weniger.

Frag die, die gehen, und lass ihre Antworten den Backlog ordnen

Ereignisse zeigen dir, wo Menschen aufgehört haben. Warum, zeigen sie nicht. Für das Warum ist das günstigste Werkzeug in der Software eine Frage, im richtigen Moment gestellt, an die Menschen, die gegangen sind.

Jonas stellt eine einzige freiwillige Frage auf die Kündigungsseite und auf die Seite, die in der App erscheint, wenn die Testphase endet: Was hat dich aufgehalten? Eine Auswahl mit einem Freitextfeld. In die Mail zum Ende der Testphase schreibt er die Frage nur für die, die dem beim Anmelden zugestimmt haben. Der Bundesgerichtshof hat 2018 entschieden, dass auch eine Kundenzufriedenheitsbefragung per Mail in aller Regel Werbung ist, und für Werbung per Mail gelten die Regeln, die im Growth Flywheel stehen.⁵

Ein Beispiel: Im Oktober antworten 40, die gegangen sind. 17 sagen, die Einrichtung hat zu lange gedauert. Neun sagen, ihr Team würde keine weitere App benutzen. Sechs nennen den Preis. Fünf vermissen ein Urlaubskonto. Drei nennen andere Gründe. Zusammen mit den 160 Testphasen, die die Seite für das Team abgebrochen haben, zeigt die erste Antwort zweimal auf dieselbe Stelle. In Jonas' Backlog stand der Schichttausch ganz oben. Die Gegangenen setzen stattdessen den Import des Teams nach oben: Liste aus einer Tabelle einfügen, und die Seite für das Team füllt sich von selbst. Der rückt nach oben. Der Schichttausch, schon auf seine Version für eine Woche geschrumpft, wartet.

Teste die Änderung, bevor du ihr glaubst

Jonas baut den Import in einer Woche. Jetzt muss er wissen, ob er wirkt, und der ehrliche Weg ist ein kontrollierter Test: Die Hälfte der neuen Testphasen bekommt den Import, die andere nicht, zufällig ausgewählt, und die Aktivierungsraten werden verglichen. Die Methode im Detail steht in Statistische Tests: Stichprobengröße, Lift und vollfaktorielle Designs. Für ein kleines Produkt ist die erste Frage, ob sich der Test überhaupt durchführen lässt.

Wie viele Testphasen jede Hälfte braucht, hängt davon ab, wie groß die Änderung ist, die du erkennen willst:

$$n = \frac{(z_{\alpha/2} + z_{\beta})^2 \left[p_1(1-p_1) + p_2(1-p_2)\right]}{(p_1 - p_2)^2}$$

Dabei ist $n$ die Zahl der Testphasen, die jede Hälfte braucht, $z_{\alpha/2}$ ist 1,96 für ein Signifikanzniveau von 5 %, $z_{\beta}$ ist 0,84 für eine Teststärke von 80 %, $p_1$ ist die Aktivierungsrate ohne die Änderung und $p_2$ die Aktivierungsrate, die du mit ihr erkennen können willst. Grundlagen: Stichprobengröße

Beispiel: Kann Jonas das überhaupt testen?

Um einen Anstieg der Aktivierung von 25 % auf 35 % zu erkennen:

$$n = \frac{(1{,}96 + 0{,}84)^2 \left[0{,}25 \times 0{,}75 + 0{,}35 \times 0{,}65\right]}{(0{,}35 - 0{,}25)^2} = \frac{7{,}84 \times 0{,}415}{0{,}01} = 325{,}4$$

Dabei sind $1{,}96$ und $0{,}84$ die Werte $z_{\alpha/2}$ und $z_{\beta}$, $0{,}25$ ist $p_1$, die heutige Aktivierungsrate, $0{,}35$ ist $p_2$, die Rate, die er erkennen will, und $325{,}4$ ist $n$, die Testphasen pro Hälfte. Grundlagen: Stichprobengröße

Das sind 326 Testphasen pro Hälfte, 652 insgesamt, etwas mehr als ein Monat bei 600 Testphasen im Monat. Machbar.

Um einen Anstieg von 25 % auf 28 % zu erkennen, ergibt dieselbe Formel etwa 3.390 Testphasen pro Hälfte, 6.780 insgesamt, mehr als elf Monate Testphasen. Nicht machbar, jedenfalls nicht für eine Änderung, über die er in diesem Quartal entscheiden will.

Das ist die stille Regel für kleine Produkte: Teste große Änderungen, keine kleinen. Ein Produkt mit 600 Testphasen im Monat lernt nichts aus einer neuen Buttonfarbe, aber sehr viel daraus, einen ganzen Schritt der Einrichtung zu streichen. Wie viele Daten jede Art von Frage braucht, rechne ich in Wie viele Daten brauchst du wirklich? durch.

Nach fünf Wochen haben von den 326 Testphasen ohne Import 82 aktiviert, 25,2 %, und von den 326 mit Import 117, 35,9 %. Der Test für zwei Anteile aus Grundlagen: Hypothesentests nutzt die gemeinsame Rate $(82 + 117) / 652 = 30{,}5\ \%$, einen Standardfehler von $\sqrt{0{,}305 \times 0{,}695 \times \left(\frac{1}{326} + \frac{1}{326}\right)} = 0{,}036$ und einen Unterschied von $0{,}359 - 0{,}252 = 0{,}107$, also $z = 0{,}107 / 0{,}036 = 2{,}98$, mit einem zweiseitigen p Wert von etwa $0{,}003$. Der Import bleibt, für alle.

Und weil die Aktivierung den Loop über den Plan in Gang setzt, hebt das Feature, das bei der Aktivierung gewonnen hat, auch $s$ in der Verstärkung des Loops. Das ist der ganze Artikel in einer Änderung: Das Feedback hat das Feature ausgewählt, der Test hat es bestätigt, und der Loop dreht sich ein wenig schneller.

Was ein Shop davon übernehmen kann

Dieselbe Logik gilt im eCommerce, wo das Produkt aus Paket, Seite und Kundenkonto besteht. Welcher Teil dessen, was ein Shop erzeugt, erreicht jemand Neues?

Die Geschenknachricht ist der klarste Fall. Sie ist ein Feature im Checkout, und ihr Ergebnis landet in den Händen von jemandem, der den Shop nicht ausgesucht hat.

Ein Beispiel: Ein Geschenkeshop in Freiburg verschickt 2.000 Bestellungen im Monat, und 600 davon tragen eine Geschenknachricht. Auf der Karte für die Beschenkten steht eine Zeile, "umtauschen oder selbst etwas aussuchen", mit einem Link. Wenn 5 % der Beschenkten ihm folgen und eine von vier dieser Personen bestellt, sind das $600 \times 0{,}05 \times 0{,}25 = 7{,}5$ Neukunden im Monat, aus einem Feature, das der Shop schon hatte. Empfehlungskarten, Bewertungen und die Regeln, die in Deutschland dafür gelten, stehen im Growth Flywheel, Wiederkäufe in Loyalität: die drei R und Earn und Burn.

Der wöchentliche Rhythmus, der den Loop schließt

Werkzeuge schließen den Loop nicht. Eine Gewohnheit schon: ein kurzes wöchentliches Treffen mit festen Fragen, damit die Entscheidung von der Antwort abhängt und nicht davon, wer am besten argumentiert.

Von oben gelesen: Die Woche beginnt mit dem Zählen, nach den gemeinsamen Definitionen, dann kommt das Zuhören bei denen, die gegangen sind, dann die Tests. Die eine Entscheidung in der Mitte ist die, die gern übersprungen wird. Ein Test, der die geplante Stichprobengröße nicht erreicht hat, ist nicht fertig, egal wie gut er an einem Dienstag aussieht.

Ein Beispiel: Jonas' Runde dauert 30 Minuten am Montag. Diese Woche zeigt sie: 148 Testphasen, 49 aktiviert (33 %), der Import hält sich. Fünf Gegangene, drei davon wegen des Preises für Betriebe mit mehr als einem Standort. Kein Test ist fällig. Die Entscheidung: einen Preis für zwei Standorte skizzieren und ihn fünf der Betriebe zeigen, die das gesagt haben, bevor irgendetwas gebaut wird.

Die Grenze zwischen Produkt und Growth war nie eine Staffelübergabe. Sie ist ein Loop, und er läuft in beide Richtungen. Features, die ihr Ergebnis vor jemand Neues bringen, tragen das Produkt nach außen. Was Nutzer tun und sagen, trägt die Entscheidungen zurück nach innen. Zähl beides, teste die großen Änderungen und halte die Wetten klein. Berühmt macht der Loop niemanden. Aber er macht jede Woche ein bisschen weniger zum Ratespiel als die letzte.

Footnotes

1. Brian Balfour, Casey Winters, Kevin Kwok und Andrew Chen, Growth loops are the new funnels, Reforge, 31. Juli 2018, https://www.reforge.com/blog/growth-loops

2. Brian Balfour, Product channel fit will make or break your growth strategy, brianbalfour.com, 12. Juli 2017, https://brianbalfour.com/essays/product-channel-fit-for-growth

3. Kevin Kwok, Why Figma wins, kwokchain.com, 19. Juni 2020, https://kwokchain.com/2020/06/19/why-figma-wins/

4. Ron Kohavi, Alex Deng, Brian Frasca, Toby Walker, Ya Xu und Nils Pohlmann, Online controlled experiments at large scale, Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD 2013), Seiten 1168 bis 1176, https://exp-platform.com/Documents/2013%20controlledExperimentsAtScale.pdf

5. Bundesgerichtshof, Urteil vom 10. Juli 2018, VI ZR 225/17, Rn. 24, dejure.org, https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=BGH&Datum=10.07.2018&Aktenzeichen=VI%20ZR%20225/17