Lean Startup & Problem-Hypothesen
Last updated
Last updated
Traditionell hat man oft ein neues Produkt lange im stillen Kämmerlein geplant, dann vollständig mit allen Funktionen entwickelt und anschließend in den Markt eingeführt.
Das Durchlaufen dieses Prozesses hat nicht selten länger als ein Jahr gedauert. Der Ansatz setzt aber voraus, dass man den Markt und die zukünftigen Nutzer perfekt einschätzen kann und schon vor dem Start alle Informationen hat, z.B. wer der Kunde ist, was seine Bedürfnisse sind, und wie er mit dem neuen Produkt umgehen wird.
Das trifft leider in der heutigen Welt und besonders bei der Entwicklung von innovativen Produkten nur sehr selten zu. Und so ist es sehr oft passiert, dass nach Fertigstellung des Produkts gezeigt hat, dass die Nutzer das Produkt nicht annehmen und viel Zeit und Geld in der Entwicklung verschwendet wurde. Deswegen hat sich in den letzten Jahren ein alternativer und flexiblerer Ansatz durchgesetzt: Lean Startup.
Mit den Prinzipien von Lean Startup kann man seine Idee schnell und kostengünstig testen und validieren, ob das geplante Produkt funktioniert und in diesem Prozess von seinen Nutzern lernen. Anstatt viel Zeit (und eventuell sogar Geld) in die Entwicklung des vollständig funktionsfähigen Produkts zu stecken, baut man mit möglichst geringen Mitteln nur eine abgespeckte Version des Produkts, die aber die Kernfunktionalität bzw. Funktionsweise beinhaltet und stellt sie Nutzern zur Verfügung, um zu schauen, ob es das anvisierte Problem der Nutzer löst. Dieses abgespeckte Produkte wird im Umfeld von Lean Startup als Minimum Viable Product (MVP) bezeichnet.
Ein Grundsatz von Lean Startup ist, dass alles, was man über die Nutzer und deren Umgang mit dem zukünftigen Produkt glaubt, nur Hypothesen sind. Wir nehmen an, dass die Nutzer ein bestimmtes Problem mit bestehenden Lösung haben und ihnen unsere Lösung viel besser gefällt und es genau das ist, was sie brauchen - wir wissen es aber nicht. Mit dem MVP möchten wir möglichst schnell und kostengünstig testen, ob die Kernhypothesen, die wir annehmen, stimmen und das Produkt echten Nutzern in die Hand geben.
Durch das Feedback der Nutzer kann man schnell lernen, ob die Idee des neuen Produkts funktioniert und daraufhin das Produkt verbessern und erneut testen. So ergibt sich ein kontinuierlicher, iterativer Zyklus aus Bauen, Testen und Lernen mit dessen Hilfe man nutzerorientiert das Produkt entwickelt, das Geschäftsmodell testet und nicht Gefahr läuft, Produkte am Nutzer vorbei zu entwickeln.
Es hat sich gezeigt, dass die Startups bzw. Produktenwicklungsteams am erfolgreichsten sind, die die Durchlaufzeit dieses Zykluses möglichst gering halten und nur wenige Wochen oder sogar Tage brauchen, um neue Hypothesen zu testen und aus dem Nutzerfeedback zu lernen.
Das MVP muss keine vollständig programmierte App, ein fertiges Produkt oder eine perfekt durchdefinierte Dienstleistung sein. Selbst wenn du zum Beispiel eine App bauen möchtest, muss es nichtmal digital sein. Um beispielsweise die Kernhypothesen einer neuen Jobplattform zu testen, und herauszufinden, wie Studenten einen Job bewerten und auswählen, reicht es schon, Jobanzeigen aus der eigenen Stadt im Internet herauszusuchen und Studenten in der Mensa einer Universität anzusprechen und mit ihnen den Prozess einer Jobsuche zu durchlaufen. Durch diesen Prozess lernt man enorm viel über das Verhalten der Nutzer, und ob die eigenen Annahmen stimmen.
Bevor wir starten, konkret etwas zu bauen, ist es sinnvoll erstmal festzuhalten, was gebaut werden soll. Dies in wenigen Sätzen auszuformulieren hilft euch nicht nur dabei konkreter zu werden, sondern schafft auch etwas Beständiges, das man weiterentwickeln kann. Es dient zudem dazu eine Diskussionsbasis zu haben. Das wichtigste beim Erschaffungsprozess ist der Austausch mit anderen Personen, die euch unterstützen können, oder die sogar euer zukünftiges Produkt kaufen würden. Ihr Feedback hilft euch dabei, die Idee kontinuierlich zu verbessern.
Ihr habt wahrscheinlich bereits eine Idee für ein Produkt oder eine Dienstleistung.
Als erstes ist es wichtig, dass ihr wisst was ihr bauen möchtet und warum ihr das machen möchtet. Alle neuen Produkte, Dienstleistungen oder Applikationen starten nicht mit der Lösung und verschiedenen Funktionen von dieser, sondern mit einem Problem: Warum möchtet ihr dieses Produkt entwickeln und warum sollten andere Menschen es benutzen.
Sagen wir zum Beispiel ihr möchtet eine Jobplattform für Student:innen entwickeln: Was stört euch an aktuellen Lösungen, in denen Student:innen Jobs finden können? Haben vielleicht auch Freunde von euch das Problem? Wie sieht dieses genau aus?
Aufgabe 1: Schreibt das Problem, das ihr lösen möchtet, in wenigen Sätzen auf. Probiert dabei möglichst gut zu spezifizieren, wer die Personen sind, die dieses Problem haben, und warum bereits bestehende Ansätze das Problem nicht gut lösen.
Beispiel: Studierende in fast allen Fachbereichen suchen nach Möglichkeiten neben dem Studium Geld zu verdienen und praktische Erfahrungen zu sammeln. Da die Unternehmen bei den großen Job-Portalen pro Anzeige viel Geld bezahlen müssen, werden dort Student:innen Jobs oft gar nicht ausgeschrieben und eher direkt an der Universität an schwarzen Brettern oder über einzelne Professoren beworben. So haben Student:innen nur Zugriff auf eine kleine Auswahl von Jobangebote, die relevant für sie sind und verpassen vielleicht das richtige Angebot.
Beim Lean Startup Ansatz gehen wir davon aus, dass alles was wir glauben zu wissen, nur Hypothesen sind. In unserem Beispiel haben wir angenommen, dass viele Student:innen nach Möglichkeiten suchen, um neben dem Studium Geld zu verdienen und praktische Erfahrung zu sammeln. Wenn wir diese Annahme nicht validieren, sondern sofort ein Produkt bauen, dann können wir in Schwierigkeiten kommen: Stimmt die Problem-Annahme nicht auf dessen Basis wir alles aufgebaut haben, bauen wir ein Produkt, was für unsere Zielgruppe kein Problem löst und sie deshalb keinen Grund sehen es zu nutzen. Wir haben viel Zeit (und vielleicht Geld) umsonst in ein Produkt gesteckt. Deswegen ist es wichtig, früh Hypothesen zu validieren und im ersten Schritt für sich zu erkennen, dass es nur Hypothesen von denen man nicht 100% sicher ist, dass sie stimmen.
Aufgabe 2: Überführt euer Problem in Hypothesen. Wenn ihr Hypothesen schon in Gesprächen mit (potentiellen) Kunden validiert habt, könnt ihr das gerne dazu schreiben.
Beispiel Hypothesen:
Studierende in fast allen Fachbereichen suchen nach Möglichkeiten neben dem Studium Geld zu verdienen
Studierende in fast allen Fachbereichen suchen nach Möglichkeiten neben dem Studium praktische Erfahrung in der Berufswelt zu sammeln.
Unternehmen meiden große Jobplattformen für Studentenjobs, weil diese zu teuer sind.
Unternehmen bewerben Studentenjobs ausschließlich über schwarze Bretter an Universtitäten oder direkt über Professoren
...
Der nächste Schritt ist nun, diese Hypothesen zu bestätigen oder zu verwerfen, indem z.B. in unserem Beispiel das Gespräch mit Studierenden und Unternehmen gesucht wird, und geschaut wird, ob das Problem in der Form wirklich existiert. Wie man das am besten macht, werden wir in der nächsten Woche behandeln.
Eine weitere Möglichkeit Probleme und potenzielle Kundeninteressen sichtbar zu machen ist das Value Proposition Canvas. Inwiefern macht ihr die Welt eurer Kunden besser ("Gains") und welche "Schmerzen" ("Pains") nehmt ihr ihnen ab.
In diesem Beitrag wird das Value Proposition Canvas nochmal in der Tiefe erklärt:
Aufgabe 3: Füllt die rechte Seite des Value Proposition Canvas in eurem Team Canvas auf eurer Notion Teamseite aus. Mit der linken Seite befassen wir uns, sobald das Problem bzw. die Probleme weiter validiert wurden.
Bei den Startup-Teams, die wir in der Starterkitchen betreuen, haben wir gelernt, dass Verbindlichkeit, Zielsetzung und Selbstreflektion wichtige Bestandteile des Lernprozesses sind und mit ausschlaggebend für den Erfolg von Startups ist. Deshalb bitten wir euch, einen Report pro Kapitel zu erstellen, bei dem ihr eure Fortschritte dokumentiert. Wenn ihr ein Team von mehreren Personen seid, macht euch gerne einen gemeinsamen Termin, an dem ihr den Report zusammen ausfüllt und eure Woche plant. Posted in den Report im opencampus chat.
Wenn ihr Teil der Starterkitchen oder einer Opencampus Lehrveranstaltung seid, folgt bitte den Anweisungen eurer Mentor:innen wie ihr den Weekly Report teilen sollt. Aktuell funktioniert der Report über die Teamseite.
