Wie man unnötigen Aufwand in Startups vermeidet

Eines sollte ganz klar sein: unnötigen Aufwand zu dulden ist Verschwendung. Unnötiger Aufwand hat es ja sogar schon im Namen. Er ist unnötig. Demzufolge kann man sich das auch nicht erlauben als Startup. Die Ressourcen sind knapp und Verschwendung senkt die Chance tatsächlich bis zu einem nachhaltigen Unternehmen kommen zu können. Das führt zu einer Reihe außergewöhnlicher Maßnahmen mit durchschlagendem Erfolg. Sogar in Innovationsteams größerer Unternehmen sollte das Budget künstlich beschränkt werden, um eine ähnliche Situation zu erreichen. Not macht nämlich erfinderisch und die Techniken, die ich gleich vorstellen werde, sind wirklich praktisch.

Nur leider werden sie oft erst durchgesetzt, wenn es wirklich dringend nötig ist. Leute sind zu sehr an gewöhnliche Taktiken gewöhnt, als dass sie sich einfach auf Knopfdruck ändern können. Sie müssen erst mal ihre eigenen Startup-Muskeln trainieren, bevor sie mit maximaler Effizienz die jetzt beschriebenen Taktiken anwenden können. Und diesen Aufwand macht man sich nun mal leider erst, wenn es nötig ist.

Hat man einen Überfluss an Ressourcen braucht man nicht auf unnötigen Aufwand achten. Da überwiegt die Chance doch mal ein Goldstück in all den Seitenbemühungen zu finden. Aber genau das ist hier nicht der Fall. Man muss unbedingt 100% aller Bemühungen auf die wichtigsten Aspekte lenken, um unnötigen Aufwand zu vermeiden und die größtmöglichen Chancen zu haben ein nachhaltiges Unternehmen aufzubauen, bevor die Ressourcen aufgebraucht sind. Dann ist schließlich die Chance vorbei, die du hattest. Pech gehabt.

unnötigen Aufwand vermeiden

Es gibt viele Möglichkeiten unnötigen Aufwand zu betreiben. Ich werde hier die Hauptmöglichkeiten beschreiben, die du hast, um ihn zu reduzieren. Werden sie erfolgreich implementiert, hast du schon eine Menge unnötigen Aufwand eliminiert.

Lernen

Es gibt eine Sache, die offensichtlich die größte Verschwendung von allen ist: Ein ganzes Produkt erschaffen, das niemand will. Man steckt vielleicht monatelange Arbeit in die Konzeption, Umsetzung und Perfektion eines Produktes, nur um dann Herauszufinden, dass Grundlegende Hypothesen, auf denen du deinen Plan aufgebaut hast, gar nicht stimmen.

Besser man ist sich dieser Hypothesen von Anfang an bewusst und testet als aller erstes, mit geringstmöglicher Aufwand-Investition ihren Wahrheitsgehalt. Sehr oft geht das super einfach ohne das tatsächliche Erschaffen eines Produktes und dann ist man schon gleich an einem Level angekommen, an dem man ganz klar weiß, woran man ist. Halten die Hypothesen nicht, was sie voraussagen, kann man sich jetzt schon eine neue Strategie überlegen (und sie testen!). Sind sie tatsächlich korrekt, kann man beruhigt mit dem jetzt nicht mehr unnötigen Aufwand der Produkterschaffung beginnen. Von Anfang an Hypothesen testen ist unumgänglich

Das ist aber nicht die Hauptlehre aus diesem Beispiel. Vor allem geht es mir darum generell den Fokus auf Feedback und Lernen zu lenken. Je mehr man mit dem Markt interagiert, desto mehr lernt man dazu. Desto stärker beruhen alle Bemühungen auf tatsächlichem Wissen und nicht nur Vermutungen. Hervorragend um unnötigen Aufwand zu vermeiden.

Man sollte also den Lernfortschritt einzelner Personen, aber vor allem der Teams und des gesamten Unternehmens messen. Diese Umstellung von der Messung von Produktivität auf den Lernfortschritt ist vielleicht schwierig und erfordert eine Eingewöhnungsphase, aber es macht eines besser als alles andere: Fokussierung der Bemühungen auf die wichtigste aller Aktivitäten: Lernen. Wenn nur der Lernfortschritt bewertet wird, ist es das, was die Leute zu optimieren versuchen. Produktivität ist dann logischerweise ein Nebenprodukt. (Anmerkung: auch Widerlegungen von Hypothesen müssen als Lernfortschritt zählen, sonst werden wichtige Risiken möglicherweise nicht eingegangen und essentielle Informationen bleiben unbekannt.)

Hypothesen an erster Stelle

Im ersten Beispiel hat jemand ein ganzes Produkt gebaut und dann gemerkt, dass es niemand braucht. Die Situation, in der einzelne Features gebaut werden, weil man sie halt mal ausprobieren will, ist ähnlich. Unnötiger Aufwand, sobald man merkt, dass es niemand will. Und daraus lernen wird man vermutlich nicht allzu viel. Was wollte man nochmal damit überprüfen?

Derartigen Aufwand kann man es aber auch gar nicht so einfach vermeiden. Man muss irgendetwas bauen, um die vielen Hypothesen zu testen, die noch unbeantwortet sind, wenn die Grundhypothesen schon validiert wurden. (Hauptfrage: Wie können wir die Motorwerte optimieren?)

Die Hauptvorgehensweise sollte aber nun mal eine andere sein: Zuerst wird eine Hypothese zum Überprüfen ausgewählt, dann wird der Aufwand hineingesteckt entsprechende Features zu bauen und die Hypothese zu validieren. Hier war der Aufwand dann auch gerechtfertigt, wenn sich die Hypothese als falsch herausstellt. Man hat schließlich nur ein MVP erschaffen und daraus gelernt.

Durch ein solches System wird also jeglicher Aufwand auf die Validierung von Hypothesen fokussiert. Eine sehr hilfreiche Tatsache. Man sollte aber noch einen Schritt weiter gehen: Sobald man die Anzahl der Hypothesen, die gleichzeitig bearbeitet werden, künstlich beschränkt erreicht man zwei hilfreiche Effekte: Zum einen werden jetzt 100% der Bemühungen auf die wichtigsten Hypothesen gelenkt, zum anderen wird das Hypothesen-Test-System optimiert, um es schneller durchlaufen zu können.

den Zyklus optimieren

Das geschieht auf verschiedenen Ebenen. Zum einen gibt es oft eine Menge Verbesserungsmöglichkeiten auf der Ebene der Teilaspekte, zum anderen muss die Optimierung unbedingt auf der obersten Ebene des Zyklus stattfinden.

Zum Beispiel sagt ja schon der Name des MVP worum es hier geht: Beschränkung auf die Mindestmenge der zum erfolgreichen Durchführen des Experiments nötigen Aspekte. Jeglicher weiterer Aufwand, der nicht dabei hilft die Hypothese zu überprüfen ist Verschwendung. Die einzige Ausnahme darf in gewissem Rahmen die Vermeidung von Entwicklungsschulden sein. (Also schlampiges Arbeiten, um jetzt schneller zu sein, was aber in Zukunft einen deutlich höheren Ausbesserungsaufwand einfordert.) Man kann qualitatives Arbeiten nicht gegen Zeit eintauschen. Das holt einen später immer wieder ein.

Wie schon gesagt, muss man aber aufpassen, dass man nicht die einzelnen Aspekte des Bauen-Messen-Lernen-Zyklus optimiert, sondern seine Gesamtheit. Es ist vielleicht kontra-intuitiv, aber das sind nun mal zwei verschiedene Dinge und nur die zweite Variante führt zur kürzestmöglichen Gesamtzeit. Und genau die es nun mal, die einen Einfluss darauf hat, wie viele Hypothesen man letztendlich testen kann in dem langen Weg bis zum funktionierenden Produkt. Die Beschleunigung dieses Zyklus ist auch bekannt als das Antrainieren von Startup-Muskeln: Grundsätzlich gilt hier: dieser Aufwand lohnt sich auf jeden Fall.

auf einer höheren Ebene

Abschließend möchte ich noch eine Möglichkeit der Vermeidung von unnötigem Aufwand aufzeigen: einen Termin für das Meeting festlegen, in dem entschieden wird, ob eine Kehrtwende nötig ist oder ob auf Basis der aktuellen Annahmen tatsächlich ein nachhaltiges Unternehmen erreichbar ist. Macht man das nicht, wird es aufgrund seiner Schwierigkeit unbewusst immer weiter hinausgeschoben und dabei noch schwieriger. Sollte man sich aber für eine Kehrtwende entscheiden, wird jeder wünschen, man hätte es früher gemacht. Auch die gesamten zusätzlichen Bemühungen, die aus der Verschiebung des Termins entstanden sind, kann man dann als unnötig zählen, auch wenn sie einem vermutlich noch ein paar hilfreiche Informationen eingebracht haben.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.