Auch wenn man schon geschafft hat, in einem Startup den Fokus auf das Lernen zu verschieben, gibt es immer noch unterschiedlich richtige Ansätze die täglichen Aktivitäten anzugehen. Die beste Variante, bei der unnötige Bemühungen, die nicht zu relevantem Lernfortschritt führen, vollständig vermieden werden nenne ich: Hypothese veranlasst Bemühungen.
Das beschreibt sozusagen die korrekte Kausalitätskette, die dahinter steht. Man kann nämlich entweder etwas erschaffen, und danach im Augenblick formulierte (aber natürlich schon länger als wahr vermutete) Hypothesen testen, was vermutlich öfter eine Enttäuschung darstellt. Oder man überlegt sich eben erst fertig formulierte Hypothesen, auf denen die Geschäftsidee basiert und beginnt danach erst mit den Bemühungen, die mit dem geringstmöglichen Aufwand die Hypothese validieren können. Die Verschwendung im ersten Fall ist ganz klar und besonders im Falle der Widerlegung offensichtlich: Zum einen ist die Hypothese möglicherweise gar nicht so relevant für den Gesamterfolg gewesen. Zum anderen hätte man die Hypothese vermutlich auch mit deutlich weniger Aufwand validieren können.
Es geht also wie immer im Startup um die Vermeidung unnötiger Bemühung (und hierbei Verwendung von Ressourcen wie Arbeitszeit). Grundsätzlich gilt dabei: Alles, was nicht direkt beim lernen hilft, ist unnötig. Features, die keine Hypothesen bestätigen, da sie nicht Teil der Kernfunktionalität sind und in ihrer Abwesenheit auch nicht höchst unangenehm auffallen, werden einfach weggelassen. Um so etwas kann man sich später immer noch kümmern.
Aber solange die Geschäftsidee noch nicht bewiesen ist (bzw. eine funktionierende Geschäftsidee gefunden wurde), ist das die einzige erlaubte Herangehensweise. Man hat nur eine begrenzte Zeit, nutze sie, um die wirklich wichtigen Dinge herauszufinden und dann entsprechend zu handeln. Sogar „ausgewachsene“ Unternehmen sollten den Fokus auf das dazulernen nie loslassen. Man kann den Markt immer noch besser kennen, die eigene Herangehensweise noch weiter optimieren, den Wachstumsmotor ölen, usw. Darauf zu verzichten bedeutet Stagnation, es wie gewohnt weiterzuführen bedeutet vorbereitet sein, wenn mal wieder Innovation gebraucht wird. In der heutigen Welt gibt es keine Dinge mehr, die du einmal aufbauen und dann den Rest deines Lebens die Früchte ernten kannst, weil sich nichts grundlegendes verändert und es einfach weiter-funktioniert.
Innovation wird eben am besten erreicht, in dem man alles andere einfach weglässt. Und der schlankeste Ansatz ist eben eindeutig der, bei dem die Hypothese zuerst kommt und dann das Produkt.
der falsche Ansatz
Ich hab es zwar eben schon mal angedeutet, aber eine kleine Elaboration hilft vielleicht das Konzept noch besser zu verstehen:
Hier beginnt man mit einer Idee für ein tolles neues Feature. „Lass uns Feature X ausprobieren, das kommt bestimmt super an.“, heißt es und schon stürzt man sich in die Arbeit. Gewisse Zeit später ist es endlich fertig poliert und man ist bereit es zu veröffentlichen. „Halt, warte. Normalerweise machen wir doch immer auch noch Tests.“ Okay, die gewöhnlichen Split-Tests werden eben auch durchgeführt. Was lernt man dabei? Ob Feature X in seiner Gesamtheit die Werte verbessert oder nicht. Wenn ja, nehmen wir halt. Wenn nein, noch offensichtlichere Verschwendung von Aufwand. Und in beiden Fällen:
War die Hypothese überhaupt relevant? Für die meisten neuen Ideen gilt nicht wirklich, dass sie eine zentrale Rolle in der Geschäftsidee einnehmen. Irrelevante Hypothesen kann man später immer noch testen, wenn man unbedingt will. Besonders zu Beginn ist es aber wichtig etwas über die Hypothesen herauszufinden, auf denen alles andere beruht. Stellen sie sich als inkorrekt heraus, hat man dann vielleicht noch die Kapazitäten für eine Kehrtwende in eine besser funktionierende Richtung.
Und ganz davon abgesehen, hätte man diese Hypothese bestimmt auch sehr viel Aufwands-effizienter testen können. MVP ist das Stichwort.
Hypothese veranlasst Bemühungen
Das ist jetzt der richtige Ansatz: Zuerst kommt eine Hypothese, die man testen will – vermutlich weil sie zentral für das Gelingen der Geschäftsidee ist. Danach werden Überlegungen angestellt, um die simpelste Möglichkeit zu finden, die Hypothese zu testen. Vielleicht bedeutet das ein MVP zu bauen, oft lässt sich das Experiment aber auch direkt durchführen. Vielleicht reicht anrufen und nachfragen, vielleicht hast du die nötigen Voraussetzungen schon erschaffen und musst sie jetzt nur noch entsprechend anwenden.
Wie auch immer, auf die Durchführung eines möglichst unaufwendigen Experiments zur Validierung der Hypothese kommt es an. Stellt sie sich als falsch heraus, hat man das zum Glück jetzt schon herausgefunden. Ist sie korrekt, kann man beruhigt die nächsten Hypothesen testen.
Denn das ist genau das, was man machen wird: Immer weiter Hypothesen testen, die Teil der Geschäftsidee sind, und dabei schon ein MVP des Produktes errichten, weil unsere Fähigkeit das Problem für die Kunden zufriedenstellend zu lösen natürlich auch eine der Hypothesen ist. Ist die Geschäftsidee dann in ihrer Gesamtheit validiert, kann man endlich ruhigen Gewissens größere Ressourcen in die Fertigstellung und den anschließenden gewöhnlichen Verkauf des Produkts stecken.
Bei diesem Ansatz testet man also die weitreichendsten Hypothesen zuerst. Man holt sich zuerst das relevante Wissen, um so schnell wie möglich die wichtigen Entscheidungen treffen zu können: führt der aktuelle Weg in eine funktionierende Richtung oder muss ich mich nach einem neuen umschauen?
Optimierung des Vorgehens
Die Vorstellung des richtigen Vorgehens ist mit der Reihenfolge der Aspekte (erst Hypothese, dann Experiment designen + evtl. MVP bauen) noch nicht abgeschlossen. Es fehlt noch eine wichtige Komponente, die das gesamte Vorgehen optimiert und die Konzentration auf die allerwichtigsten Hypothesen zuerst gewährleistet. Der Trick: beschränke die Anzahl „aktiver“ Hypothesen in jedem Schritt des Zyklus.
Hierfür muss ich natürlich nochmal kurz den Zyklus aufdröseln:
Am Anfang steht die Warteschlange für Hypothesen, die als nächstes getestet werden werden. Hierein werden neue Hypothesen aufgenommen, die getestet werden sollen, und hieraus wird die nächste Hypothese ausgewählt, wenn man bereit ist, sich ein Experiment zu überlegen.
Als zweites steht der Bereich der Designphase. Hier befinden sich alle Hypothesen an deren Experiment gerade gearbeitet wird, die aber noch nicht bereit sind an der echten Welt ausprobiert zu werden. Vielleicht muss noch ein MVP gebaut werden, vielleicht muss sogar erst noch das beste Vorgehen gefunden werden. Ganz egal. Noch nicht Test-bereit, aber schon in Bearbeitung? Hierher bitte.
Und im dritten Bereich werden die Hypothesen gesammelt, deren Experimente gerade laufen und fleißig Daten produzieren. Am Ende dieser Phase ist die Hypothese dann validiert und kann in der Ablage für alles bisher gelernte niedergelegt werden. Hurra.
Durch eine Beschränkung der Menge an Hypothesen, die sich im jeden Bereich befinden dürfen, auf zum Beispiel 2 (oder mehr, je mehr separat arbeitende Teams es gibt) erreicht man dann 2 wichtige Effekte: Zum einen werden bereits ausgewählte Hypothesen schneller abgeschlossen, damit endlich platz für neues ist. Zum anderen werden ganz gezielt die wichtigsten Hypothesen zuerst in die Warteschlange aufgenommen.
Hierdurch wird die Gesamtheit aller Bemühungen auf das allerwichtigste konzentriert: die Validierung der zentralsten Hypothesen.