Lean Startup - einfach gründen oder wie?

Der traditionelle Weg der Unternehmensgründung ist meist sehr linear - zuerst muss ein Businessplan erstellt und das nötige Geld beschafft werden, bevor dann im Nachgang der strategische Plan umgesetzt wird und die tatsächliche Reaktion des Marktes beurteilt werden kann. Dieser Ansatz eignet sich besonders gut für bereits etablierte Unternehmen mit der Absicht, neue Geschäftsbereiche zu erschließen. Oft merkt man jedoch erst in der entscheidenden Phase des Markteintritts, ob die zuvor entwickelte Idee oder das Geschäftsmodell auch wettbewerbsfähig sind. Kann sich das Geschäftsmodell am Markt dann doch nicht durchsetzen, hat ein Unternehmen bereits viel Geld und Ressourcen verloren. Der Ansatz des Lean Startups setzt auf eine radikale Orientierung an dem Markt. Im Wesentlichen wird eine Geschäftsidee durch einen MVP schnell auf den Markt gebracht und anschließend immer wieder getreu dem Zyklus “Build-Measure-Learn” angepasst. Also einfach gründen oder wie?

Steve Blank kam nach der Ableistung seines Militärdienstes 1976 ins Silicon Valley und arbeitete dort für ein Startup, dass die Einhaltung von internationalen Verträgen während des kalten Krieges durch technische Überwachung prüfte. Er war einer der ersten Unternehmer, der erkannte, dass Startups keine kleineren Versionen von großen Unternehmen sind, sondern sich vielmehr in einem Prozess auf der Suche nach einem passenden Geschäftsmodell befinden. Er gilt als der Erfinder der Lean-Startup-Methode. Er befasste sich insbesondere mit der Entwicklung adäquater Werkzeuge und Konzepte, die Startups bei der Findung eines Geschäftsmodells unterstützen und sich wesentlich von den klassischen betriebswirtschaftlichen Methoden unterscheiden.

Eric Ries, der selbst erfolgreicher Tech Gründer und Softwareentwickler ist, diskutierte zunächst die Grundlagen und Konzepte der Methode ausführlich auf seinem Blog und veröffentlichte dann im Jahr 2012 sein Buch “The Lean Startup”, durch welches die Methoden und Werkzeuge weltweite Bekanntheit erlangten. Mittlerweile sind die Grundlagen der Lean-Startup-Methode sogar Bestandteil der Lehrpläne wirtschaftswissenschaftlicher Studiengänge.

Hauptbestandteil des Zykluses ist der von Blank beschriebene Prozess des “Customer Development”, bei dem während der Findung des Geschäftsmodells die ideale Kundengruppe erst entdeckt wird. Dieser Prozess wird getreu einer agilen Arbeitsweise immer wieder durchlebt auch, wenn das Produkt oder die Dienstleistung bereits erfolgreich auf dem Markt ist. Dropbox, Airbnb oder Twitter sind nicht zuletzt wegen dieses Ansatzes heute so erfolgreich.



Build. Die erste Phase beschreibt den Bau und die weitere Anpassung eines Minimum Viable Product (kurz: MVP). Ziel ist es unter minimalem Zeit- und Ressourcenaufwand ein schlankes Produkt oder eine Dienstleistung zu kreieren. Das MVP ist der zentrale Ausgangspunkt, um deine Annahmen über Markt und Nutzer schnellstmöglich einem Realitätscheck zu unterziehen. Natürlich solltest Du dich im Vorhinein vorab durch Interviews und Marktanalysen intensiv mit den Bedürfnissen deiner Zielgruppe auseinandersetzen. Oftmals fällt gerade dieser erste Schritt Gründern und Produktteams besonders schwer, da die Annahme in den Köpfen herrscht nur ein perfektes, ausgefeiltes Produkt mit einer Mannigfaltigkeit an Funktionalitäten wird am Markt überleben. Der Zeitaufwand soll jedoch durch die Lean Startup Methode initial so heruntergeschraubt werden, dass im Nachhinein aufgrund tatsächlicher Marktreaktionen genug Ressourcen zur Verfügung stehen, um die Features zu entwickeln, die der Kunde tatsächlich braucht.

Measure. In diesem Schritt möchtest Du nun prüfen, ob deine über die Zielgruppe und Markt getroffenen Annahmen der Realität entsprechen. Wichtig ist, dass Du dir genau überlegst welche Aktionen und Handlungen der Kunden Du messen willst und welche Handlungsoptionen aufgrund der gesammelten Daten bestehen.

Learn. Das Lernen aus den gesammelten Daten steht im Vordergrund der dritten Phase. Idealerweise hast Du im Vorfeld mit deinem Team definiert, welche Datenpunkte zu einer Widerlegung getroffener Annahmen führen. Anschließend werden aufgrund der Erkenntnisse wieder neue Annahmen evaluiert, die als Grundlage für den Entwurf des nächsten MVPs dienen. In manchen Fällen können die gewonnen Erkenntnisse auch zu einer grundlegend oder radikal neuen Ausrichtung des Produktes oder Geschäftsmodells führen (Pivot). Die dritte Phase ist also keineswegs eine letzte, abschließende Phase, es handelt sich vielmehr um einen andauernden Prozess aus “Build-Measure-Learn” in Dauerschleife.

Realitätscheck statt Glaskugel

Häufig entwickeln Produktteams eine Vielzahl von Szenarien über die Akzeptanz des Produkts bei dem Endkunden. Dabei sollte die Zeit vielmehr die Schaffung von Mechanismen zum automatischen Testen der Kundenakzeptanz investiert werden. So kann das tatsächliche Kundenfeedback zu einem Prototyp (MVP) gemessen werden und die Erkenntnisse in der nächsten Built Phase berücksichtigt werden.

Focus statt Multitasking

Dein Team sollte sich temporär auf ein MVP konzentrieren, statt Gefahr zu laufen sich durch Multitasking und divergierende Zielgruppen zu verzetteln. Hier kann es auch hilfreich sein das gesamte Team in einer neutralen Umgebung zusammenzubringen.

Kürzere Intervalle für Meetings

Wenn Teams agil arbeiten, kommen sie meist täglich einmal zusammen, um über den Projektfortschritt und neue Erkenntnisse zu sprechen. Gerade in der initialen Gründungsphase kann es hilfreich sein solche Meetings mehrmals täglich stattfinden zu lassen, um eine realistische Verteilung des Arbeitspensums zu ermöglichen.

Überschätze dich nicht

Gerade zu Projektbeginn neigt man oft dazu die eigene Produktivität zu überschätzen, was einer realistischen Projektplanung im Wege steht. Es sollte hier in Abstimmung etwa mit dem Entwicklerteam eine realistische pace bestimmt werden. Bei Bugs können Werkzeuge wie Pair Programming hilfreich sein.

Kernanforderungen

Konzentriere dich bei der Entwicklung des MVPs auf die innovativen Kernfunktionalitäten deines Produkts und nutze für alle unwesentlichen Funktionen vorhandene Frameworks und bestehenden Open Source Code.

Teamspirit

Gerade bei dem Bau eines Prototypen kommt es auf die Leistungen des gesamten Teams an. Kultiviere hier passende Rituale für dein Team, um den Teamspirit zu erhöhen. Du kannst auch den Kunden von Anfang an als Product Owner mit ins Boot holen. So hat er die Möglichkeit mit seinen Entscheidungen unmittelbar Einfluss auf das Produkt zu nehmen. Eine andere Möglichkeit ist es den Kunden zumindest regelmäßig in die Meetings mit einzubeziehen, sodass falsche Annahmen frühzeitig identifiziert werden können.