Gute Experimente im Lean Umfeld – warum Geschwindigkeit wichtiger ist als gutes Experimentdesign

Wie, hat er gerade wirklich gesagt, dass das Experimentdesign unwichtig ist? Und das als “Lean wholesale nba jerseys Startup” Fan? Gewagte These…
Ok, so krass ist es natürlich nicht wirklich, also einige Richtlinien sollte man schon grob verfolgen, um ergebnisorientiert zu bleiben. Die Aussage ist mehr: Denkt nicht so viel über das Experiment selbst nach, sondern erhöht die Schlagzahl, bzw. verkürzt die Zeit um ein Experiment zu entwerfen und umzusetzen…

Um die Pointe vorweg zu nehmen: Viele Teams, Gründer und Startups versuchen zwar mittlerweile ihre Annahmen zu testen, aber der Versuch dabei Offering perfekt zu sein bremst viele aus… Ich gebe zu, auch ich bin schon in diese Falle getappt, aber echtes “Lean” Denken zeichnet sich eben durch Pragmatismus aus, und nicht durch theoretische Perfektion (und wer mich kennt, der grinst jetzt, da es eben eine meiner eigenen Schwachstellen ist…). Im Prinzip lässt sich folgendes Konzept zur Produktentwicklung von “Lean Startup” auch auf Experimente übertragen: Wenn du ein Produkt dann veröffentlichst wenn du denkst, es ist reif, dann hast du es zu spät veröffentlicht. Und jetzt einfach Produkt durch Experiment ersetzen… Jetzt fragen sich sicher einige von euch: Aber wie sehen dann gute Experimente aus und was heisst Schlagzahl erhöhen?

Naja, nachdem ich nun hoffentlich eure Aufmerksamkeit als “Marktschreier” bekommen hab ;-), möchte ich euch im nachfolgenden Artikel mal meine persönliche Ansicht zu Experimentdesign und deren Umsetzung näher bringen. Es ist eine Kombination aus eigenen Erfahrungen, Erkenntnissen aus Workshops, aus LeanCamps etc. und ich hoffe, es gibt dem ein oder anderen von euch einen neuen Blickwinkel.

Was sind die (aus meiner Sicht) wichtigsten Leitlinien für gute Experimente?

Generell ist es ein wichtiger erster Schritt sich zu überlegen, welche aktuelle Annahme, die man über seine Kunden / Zielgruppe hat, überprüft werden soll. Diese Annahme muss dann klar formuliert und ein entsprechender Test definiert werden. Nachfolgend meine Kriterien für gutes Experimentdesign um mal eine “einfache Basis” zu schaffen.

Zielsetzung zuerst

Wie ihr sicher schon im Kontext von Lean Startup gehört habt, baut quasi jeder Schritt, jede Iteration auf dem Zyklus “Build-Measure-Learn” auf. Auch bei Experimenten ist das so und bedeutet sozusagen: Experiment aufsetzen (Build), Ergebnis messen (Measure) und Something Schlussfolgerung ziehen (Learn).

Build Measure learn - Credits go to Eric Ries

Build-Measure-Learn
http://theleanstartup.com/principles

Um ein gutes Experiment aufzubauen, sollte man sich aber zunächst die Frage stellen, was man denn lernen möchte, und wie man entsprechende Einsichten gewinnen / messen kann. Mit dieser Zielsetzung gilt es dann das Experiment (die Umfrage, o.Ä.) aufzubauen. Im Prinzip ist der Aufbau als “what do we want to learn” -> “what Lean to expect and measure” -> “what to build to achieve that / gain insights”.

Atomare Annahmen

Atomar bedeutet in diesem Fall unabhängig von anderen Annahmen.

Ein Beispiel für eine nicht atomare Annahme wäre: “Meine Kunden nutzen ihr Smartphone jeden Tag und machen darüber Online-Banking.”

Natürlich ist es aus eigener Sicht wahrscheinlicher, dass Menschen, die ihr Smartphone jeden Tag nutzen auch Online-Banking darüber machen, aber noch lange nicht sicher und schon gar nicht implizit wahr… Es sind zwei Annahmen, die man überprüfen muss (natürlich nur wenn beide Voraussetzungen wichtig für das eigene Produkt sind).

Besser wäre die “atomare” Annahme: “Meine Kunden nutzen ihr Smartphone jeden Tag mindestens 1 mal”. Hier hat man keine Abhängigkeit und kann sauber testen, da es wenige Störvariablen gibt. (Mal maker abgesehen davon, dass der Besitz eines Smartphones unter gewissen Umständen schon eine ungeprüfte Annahme sein kann… Seid ihr Smartphone App Entwickler, dann würde ich das getrost als Basis voraussetzen ;-))

Quantifizierbares Kriterium setzen

Dieser Punkt ist etwas abhängig von eurer aktuellen Projektphase. Je nachdem ob ihr gerade einfach zunächst einen Markt / ein Thema verstehen wollt, oder ob ihr eine sehr konkrete Unterannahme verifizieren wollt, ist das Kriterium zum Teil (so möchte ich das jetzt mal bezeichnen) “fester”, zum Teil “weicher”.

Ein weiches Kriterium wäre z.B. “Es müssen mindestens 30% meiner Kunden täglich ihr Social Media auf ihrem Smartphone nutzen.”, denn die 30% sind im Normalfall selbst nur eine grobe Schätzung, ab wann man mit einem Ergebnis zufrieden wäre. Auch kann “Social Media nutzen” sehr unterschiedlich ausfallen – vom passiven Scrollen und lesen bis hin zum Posten im 2 Stunden Rhythmus. Hier ist es entscheidend darüber nachzudenken, was für eure Idee / euer Produkt wirklich wichtig ist…

Ein konkretes Beispiel für ein festeres Entscheidungskriterium wäre z.B. “Mein Kunde postet täglich mindestens 3 mal auf Facebook ein Bild seiner Katze” – hier ist genau spezifiziert, welchen Kanal euer Kunde nutzt, die Anzahl der Posts an einem Tag sowie was genau er postet.

Natürlich sind zu testende Faktoren nicht nur auf das Verhalten beschränkt, auch andere Rahmendaten sollten überprüft cheap nfl jerseys werden, wie beispielsweise Charakteristika der Zielgruppe (demographische Daten, etc.).

Bei einem Workshop, dem LeanCamp in Stuttgart (Grüße an Daniel Bartel auf diesem Wege, ist immer wieder eine Reise wert! [1]) fiel dabei folgender Satz: “Only test the unknown!” – und soll bedeuten: Testet nicht jeden kleinen Punkt, manche Dinge sind definitiv bekannt und mit echten Fakten belegt.

Auf jeden Fall bringt euch das Setzen von Kriterien einen direkten Vergleichspunkt mit eurer Erwartung und dient dann zur Orientierung und für euer zukünftiges Vorgehen im Projekt.

Build for learning

Dies gilt natürlich vor allem am Anfang eines Projekts / Startups. Jeder Test sollte so aufgebaut werden, dass man MINDESTENS das gesetzte Kriterium verifizieren bzw. falsifizieren kann. Idealerweise aber baut man sein Experiment so auf, dass es einem weitere Einsichten in die potentielle Zielgruppe gibt und beispielsweise weitere Probleme, genutzte Umwege etc. aufdeckt, sollte die eigene Annahme “falsifiziert” werden. Hier ergeben sich oftmals die größten Chancen um die eigene Idee in die richtige / profitable Richtung zu lenken.

Aus diesem Grund finde ich es auch sehr sinnvoll sehr früh sogenannte “Customer Interviews” zu führen. In diesen geht es, wie viele von euch wissen werden, vor allem darum die potentielle Zielgruppe kennenzulernen, und möglichst nicht zu beeinflussen. Nur dadurch kann man sicherstellen, dass einem nicht nur erzählt wird, was man hören möchte… (Weitere Infos zu Customer Interview findet ihr im Link von am Ende des Artikels [2]. Möchtet ihr weitere Infos dazu, schreibt mir oder hinterlasst einen Kommentar, dann gibts dazu mal einen separaten Post auf Deutsch.)

Deadline setzen

Menschen neigen sehr gerne dazu “Recht haben zu wollen” (und ich bin leider keine Ausnahme). Diese Tendenz verleitet aber vor allem bei der Durchführung von euren Experimenten einfach entsprechend lange Zeit verstreichen zu lassen, denn “es könnte ja noch klappen”… Versucht in eurer Einschätzung bis wann ihr ein entsprechend aussagefähiges Ergebnis haben werdet so ehrlich zu euch zu sein wie möglich. Lieber ihr setzt eine zu kurze Deadline und kommt dann bei der Auswertung zum Schluss, dass es so knapp war, dass ihr dem Test noch einen Tag / eine Woche etc. gebt. Hier sollte es aber wirklich knapp gewesen sein, sonst lügt man sich gerne wieder etwas in die Tasche.

Was ist eine gute Zeitspanne?

Dies ist mal wieder etwas abhängig davon, in welcher Phase ihr mit eurem Produkt seid und welche Zielgruppe ihr habt (also wie leicht ihr diese erreicht). Steht ihr noch am Anfang, so kann ein Test (z.B. eine Umfrage) innerhalb von Stunden bzw. 1-2 Tagen umgesetzt werden. Seid ihr schon soweit ein potentielles Produkt an den verifizierten Bedarf eurer Kunden anzupassen, können einzelne Umsetzungen auch mehrere Wochen laufen, abhängig davon wie viele eurer Kunden euch in welcher Zeit Feedback geben können. Es gibt also keine direkte Faustformel, jedoch sollten eure Deadlines vor allem in der Frühphase eher kurz gesetzt sein.

Was muss nach der Durchführung beachtet werden?

Zunächst muss natürlich betrachtet werden, welches Ergebnis durch euer Experiment geliefert wurde. Wertet aus, was ihr durch Beobachtungen, Aussagen, Verhaltensweisen etc. gelernt habt und vergleicht es mit dem erwarteten Ergebnis. Ein “Mehr-Augen-Prinzip” bewahrt euch vor einem zu subjektiven Blick, und ihr solltet das möglichst immer in einem Team machen. Fragt euch, wie weit seid ihr vom erwarteten Ergebnis entfernt, wieso ist das so und was könnt ihr nun für wholesale nfl jerseys Schlüsse ziehen? Vielleicht kommt ihr sogar 2016 zu der Entscheidung, dass der eingeschlagene Weg wohl nicht funktioniert, weil z.B. das erwartete Ergebnis nur 1 mal anstelle von erwarteten 10 mal eingetreten ist. Seht das hier nicht als “Fehlschlag”, sondern viel mehr als euer “Budget-Retter”. Je früher ihr in einem Projekt herausfindet, dass ein Weg nicht funktioniert bzw. ein erwarteter Bedarf nicht da ist, desto mehr Kopfschmerzen und Geld spart ihr auf lange Sicht. Das lässt sich so im Zweifel auch Vorgesetzten, Team- aber auch Familienmitgliedern leichter erklären.

Aber es gilt nicht nur die Ergebnisse des Experiments auszuwerten – und hier trennt sich oft die Spreu vom Weizen. Zu oft betrachten Innovationsteams und Startups nur . Ich finde es aber ebenso wichtig das Experiment selbst zu hinterfragen! Habt ihr einen Test so aufgebaut wie ich oben beschrieben habe, also mit “what do we want to learn” als Zielsetzung, dann könnt ihr jetzt auch gut überprüfen, ob dieses Lernziel erreicht wurde. Konntet ihr nicht die erwarteten Schlüsse ziehen (unabhängig ob ihr eure Annahme verifiziert habt, oder nicht), dann war das Experiment nicht gut aufgebaut. Überprüft dann, ob es eventuell Sinn macht, den Test neu zu entwerfen, und schaut, wie ihr ihn eventuell verbessern könnt. Vielleicht zeigt sich aber auch, dass das Experiment einfach später zum Einsatz kommen sollte, und es gilt eine ganz andere Annahme zu prüfen…

Zu guter letzt…

… möchte ich euch noch eine nette Analogie weitergeben, die ich ebenfalls während eines LeanCamps aufgeschnappt habe. Sie stammt von Tristan Kromer [3], einem Startup-Coach und Berater – und ist meiner Ansicht sehr treffend: Ein Produkt “lean” und durch Experimente auf Fakten basierend aufzubauen ist wie Ruderboot fahren. Wichtig ist schnell und rhythmisch zu paddeln (die Experimente durchzuführen), denn erst wenn das Boot in Bewegung ist, kann in eine Richtung gesteuert werden.

——————————————–

ONE HOUR TASK

——————————————–

Und wieder einmal möchte ich euch direkt auffordern, Dinge in die Tat umzusetzen! Machen statt nur konsumieren. Also was könnt ihr innerhalb einer Stunde erreichen?

  1. Nehmt euren aktuellen Projektstatus (oder ein Phantasieprodukt), und sucht euch eure aktuell wichtigste Annahme, die ihr über ein Experiment überprüfen möchtet. (10 Min. Bedenkzeit)
  2. Formuliert die Annahme möglichst atomar. (siehe oben, ca. 15 Min.)
  3. Was würde euch garantieren, dass diese Annahme korrekt oder inkorrekt ist? (Setzt ein möglich festes Kriterium, 10 Min.)
  4. Was wäre aus eurer Sicht die einfachste Herangehensweise um dies zu testen? Schreibt grob das Experiment / den Test auf, den ihr durchführen würdet und inwiefern er das entsprechende Feedback liefern würde. (15 Min)
  5. Setzt ein Datum, bis wann ihr das entsprechende Ergebnis herausbekommen wollt. (5 Min.)
  6. Wenn ihr euch traut und der Inhalt nicht geheim ist, postet euere Annahme und das Experiment hier (5 Min.), ich gebe dann direktes Feedback dazu, falls möglich.

Also, ich freu mich über eure Kommentare 6 / E-Mails und sage mal schön “Happy Experimenting”!

 

Links:

[1] Homepage von Daniel Bartel

[2] Customer Interview Leifaden von Justin Wilcox (Englisch)

[3] Homepage von Tristan Kromer

Comments

One Response

  1. Great write up! Thanks for mentioning me and giving me an excuse to practice my German. 🙂

Schreibe einen Kommentar

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