24 Aug

Lean: Du kannst den Markt nicht früh genug testen

Wir haben nicht früh genug mit dem Testen begonnen! Vor einiger Zeit haben wir ein MVP für ein Outsourcing-Tool gestartet. Beim zusammenstellen der Landingpage wurde uns klar: Wir hätten noch früher veröffentlichen sollen.

Die Situation: In früheren Projekten hatten wir gelernt, nicht von Anfang an auf die 100%-Lösung zu setzen. Nicht erst eine Anwendung bis ins letzte Detail reifen lassen und danach veröffentlichen. Für das Outsourcing-Tool hatten wir zwar einen MVP (einfach gesagt unsere 70%-Lösung), das wir in etwa drei Monaten entwickeln konnten und damit die Lesson-Learned von vorherigen Projekten umsetzten. Doch sollte sich herausstellen: Auch das war wieder nicht früh genug.

Die Psychologie dahinter ist interessant. Obwohl ich mich intensiv mit Lean, Build-Meassure-Learn, Genchi Genbutsu, Customer Discovery, Actionable vs. Vanitymetriken beschäftigte, fiel mir nicht direkt auf, dass wir vor der dreimonatigen MVP-Entwicklung, doch erst noch weitere, passgenauere Smoketests hätten durchführen sollen. Denn auch drei Monate sind schon eine lange Zeit.

Smoketests sind Tests, die man nur mit einer Landingpage durchführt, ohne überhaupt einen Prototypen, ein MVP oder gar das fertige Produkt zu haben. Wir haben das gemacht, indem wir Landingpages erstellt haben und, wie Facebookpost, eine kleine Gruppe dort hinleiteten. Doch gingen wir dort noch von einer anderen Kernfunktion unserer Anwendung aus. Der Nutzen war damit ebenfalls ein Anderer.

Ganz konkret: Die Idee war es (sie liegt derzeit übrigens auf Eis) ein Tool zu entwickeln, mit dem man gewisse Aufgabenabläufe erstellen kann (z.B. Text schreiben, Text korrigieren, Bild zu Text finden, Text auf Blog veröffentlichen) und diese Aufgabenketten dann automatisiert an die entsprechenden Assistenten, Texter etc. delegiert werden.

Und dazu erstellen wir eben die Landingpages, auf die wir kleine Grüppchen von Facebookusern brachten und uns anschauten, welcher Anteil von ihnen über einen Launch informiert werden wollte. Die Rate (die Konversionsrate) von etwa 9% konnten wir damals messen.

Durch weitere Kundeninterviews und Recherche fanden wir heraus, dass die Struktur dieser Idee zu komplex war, um sie einem breiteren Publikum verständlich zu machen. Wir wandelten diese Idee also recht massiv ab, sodass unser Tool vorerst keine Ketten, sondern einfach einzelne Aufgaben annehmen und durchführen sollte (z.B. Webseite auf Datenschutz prüfen). Wir „pivotierten“ also, um es in der Sprache der Lean-Startupwelt auszudrücken.

Zu dem Zeitpunkt begangen wir zwei Fehler: Wir gingen erstens gedankenlos davon aus, dass die Zahlen der Landingpages aus der ersten Version nicht anders für die zweite Version sein würden. Wir dachten einfach nicht darüber nach und hatten nicht auf dem Radar, dass sich diese Einstiegszahlen ja bereits ändern werden. Aus der Retrospektive absolut klar.

Das war der erste Fehler. Der zweite Fehler war, dass wir nie die Kanäle dazu testeten. Das heißt Kanäle wie Facebook Ads, Blogartikel, Suchmaschinenmarketing testeten wir nicht auf die Landingpages die wir hatten und offensichtlich auch nicht mit der neuen Version. Sprich: Wir prüften nie, mit welchen Kanal wir genügend Leute zu einem annehmbaren Preis auf unsere Landigpages bringen werden können, um überhaupt später auch mit einer aussagekräftigen Verprobung des MVPs beginnen zu können.

Nach einiger Zeit konnten wir die Konversionsraten zum Glück wieder auf ein recht gutes Niveau bringen: 8% im Sommer, 9% im November. Das passt auch mit den Erfahrungswerten von Eric Ries zusammen: Grockit gründete vor Jahren eine Plattform um eine Brücke zwischen E-Learning und Multi-Player-Spielen im Internet zu schlagen. Sie hatten als sie starteten eine Registrierungsrate von 5%. Nach Testrunden dann 17% und letztlich sagenhafte 42%!

Auch die drei Monate MVP-Entwicklung hätten wir abkürzen können. Denn wie sich herausstellte kamen die Nutzer zuerst nur bis zu den ersten Screens, stöberten ein wenig in den verfügbaren Dienstleistungen und schauten sich Details dazu an. Das bedeutet: Wir hätte bereits ohne das Buchungssystem im Hintergrund erste Testresultate erhalten können, indem wir mit mit dem noch halbfertigen Prototypen das Testen begonnen hätten.

Erst nach der MVP-Entwicklung die Landingpage zu erstellen, die sehr wahrscheinlich für mindestens einen Monat ohnehin das Einzige ist, was die meisten Kunden je besuchen werden ohne sich zu registrieren. Mit dem Prototypen können wir jetzt immerhin konkrete Funktionen vorführen: Animation des Dienstleistermatchings, Screenshots, Videos. Aber hätte es da zwingend gebraucht um Resultate zu erhalten. Im Gegenteil. Hätte wir ohne Detailsmaterial eine Konversionsrate von 6 oder 7 Prozent erreichen können, hätten wir eine Rate von >7% nahezu sicher ohnehin erwarten können.

Zusammengefasst heißt das: Zuerst hätten wir das neue Modell nochmal als Landingpage mit Dummygrafiken vom Tools (sogenannten Mockups) testen sollen. Und das mit den echten Kanälen. Wir hätten die Ansprache und die Landing bereits iterieren sollen. Sprich: Immer wieder Feedback holen, Dinge probieren, Zielgruppe ändern, bis wir einen Weg gefunden hätten Kosten/Konversion in ein gutes Gleichgewicht zu bringen. Erst dann hätten wir einen Prototypen bauen sollen, der erstmal nur die rudimentären Funktionen anbietet, noch ohne Checkout, als Kauf oder Buchungsprozess im Hintergrund. Und erst wenn wir eine nennenswerte Gruppengröße, eine Kohorte identifiziert hätten, die tatsächlich in den Kaufprozess gehen würde, hätten wir das MVP abschließen sollen.

Dadurch hätten wir testen können, ob wir uns auf dem richtigen Weg befinden, bevor wir den letzten Monat in die Entwicklung der Hintergrundlogik investierten.

So hieß es daher bangen, weil die Ergebnisse nun einfach aus dem Nichts kamen. Und die können Aussagen: „Was ihr da macht, überzeugt niemanden. Das müsst ihr wieder radikal ändern.“

Derzeit konzentrieren wir uns auf die Entwicklungsdientleistungen mit Kehrwasser, sodass unser Outsourcing-Tool erstmal auf Eis liegt. Es ist schade. Wir beginnen gerade, es für interne Prozesse einzusetzen. Vielleicht ergibt sich daraus ein weiteres Pivot. Wer weiß.

Schreibe einen Kommentar

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