Das GOLEAN-Framework für Wachstum (Teil 2)

Im ersten Teil dieses Artikels hat der Autor erläutert, warum der Build-Measure-Learn-Zyklus allein nicht ausreicht, um systematisch auf Wachstum hinzuarbeiten, und mit GOLEAN ein Framework eingeführt, das den Zyklus um zusätzliche Schritte der Modellierung, Planung und Systematisierung erweitert. Dieser zweite Teil knüpft nahtlos an diese Überlegungen an.

Leverage - Welches sind die Hebel für Wachstum?

Theoretisch können wir den Output unserer Kundenfabrik steigern, indem wir gleichzeitig alle fünf Schritte in dem Blueprint optimieren. Die Realität ist ganz anders.

Erstens kann es ein großer Ressourcen- und Fokus-Abfluss sein, alles auf einmal zu optimieren. Nicht alle Flaschenhälse werden einen gleichen ROI haben, und selbst die, die stark anfangen, werden mit der Zeit schließlich weniger ergiebig sein.

Aber wichtiger ist, dass es die Dinge tatsächlich schlimmer machen kann, alles zugleich zu optimieren. Unsere Kundenfabrik ist ein System aus verzahnten Schritten, und einfach einen lokalen Schritt zu optimieren, führt nicht immer zu einem globalen Zuwachs des Durchsatzes.

Hier sind ein paar schnelle Beispiele:

  • Die Vertriebskonversion durch aggressive Closing-Taktiken zu steigern, könnte mit der Zeit eine höhere Kundenunzufriedenheit und Abwanderung nach sich ziehen.
  • Das Bindung im Hinblick auf das Produkt zu steigern, könnte darauf hinauslaufen, dass so viel Wert kostenfrei geboten wird, dass die Users vergessen, etwas von uns zu kaufen.

Statt alles zugleich zu optimieren, geht es im Leverage-Schritt darum, den Schlüsselhebel, den einzelnen Dominostein oder den einzelnen Flaschenhals zu finden, der die größten Auswirkungen auf unser Geschäftsmodell zeitigen wird, wenn wir ihn anpacken.

Wir müssen nicht raten, sondern können diese Hebel methodisch aufdecken, indem wir Systemdenken anwenden – oder genauer gesagt: indem wir uns auf die Schritte fokussieren, die Eliyahu Goldratt in seiner bahnbrechenden Engpasstheorie (Theory of Constraints) beschrieben hat.

Statt unser Team in Abteilungen aufzuspezialisieren, denen dann jeweils eine dieser Metriken gehört, sollte das gesamte Team (oder mehrere kleine Teams) an einem einzelnen Engpass arbeiten, bis er behoben ist. Dann identifizieren wir den nächsten Engpass und wiederholen das Ganze.

Das mag ineffizient erscheinen, ist es aber nicht. Engpässe leben im Problemraum, nicht im Lösungsraum. Der Fokus des Teams auf eine einzelne Beschränkung wird nicht nur eine Lösung hervorbringen, sondern viele mögliche Lösungen mit großen Auswirkungen.

Diese Problem/Solution-Vorschläge können auf einem Validierungsplan von einer Seite Umfang eingefangen werden – eine effektive Vorlage für das Generieren und Teilen von Ideen.

Dann priorisieren wir diese Validierungspläne und testen sie mithilfe des nächsten Schritts: dem Experimentieren.

Der alte Weg, dies zu tun:

  • Alles optimieren
  • Ein unendlich großes Backlog mit vielen kleinen und großen Ideen
  • Jede Menge verschwendeter Aufwand und Mangel an Fokus

Der neue Weg, dies zu tun:

  • Fokussierung jeweils immer nur auf eine Beschränkung
  • Eine priorisierte Liste mit Ideen, abgebildet auf einem einseitigen Validierungsplan
  • Mehr Fluss und Bewegung in Richtung right action, right time

Experiment - Große Ideen schnell testen

Das ist das Stadium, in dem der Build-Measure-Learn-Kreislauf wirklich glänzt. Ich habe hier schon eine Menge dazu geschrieben, wie wir große Ideen mithilfe kleiner, schneller, additiver Experimente testen. Deshalb will ich mich jetzt auf die Notwendigkeit fokussieren, einen regelmäßigen Rhythmus für das Durchführen von Experimenten zu etablieren.

Viele Leute entwickeln Experimente unterschiedlicher Größe (klein, mittel, groß), was es schwieriger macht, sie zu tracken. Stattdessen befürworte ich es, mit immer gleich großen Experimenten zu arbeiten, indem sie in getimeboxte Sprints von z.B. zwei Wochen eingepasst werden. Natürlich passen nicht alle Ideen in die Experiment-Timebox. Größentechnische Variabilität über unsere Ideen hinweg erreichen wir, indem wir unserem übergreifenden Validierungsplan ein anderes, breiteres Zeitfenster auferlegen. Dieses kann zwischen 30 und 90 Tagen variieren.

Experimente zu timeboxen, erfordert Kreativität und verkürzt die Feedbackschleife, aber am wichtigsten: Es forciert Aktionen.

Analyze - Was sind die Auswirkungen auf das Geschäftsmodell?

Das Analysestadium mag ziemlich nach dem Learn-Stadium im Build-Measure-Learn-Zyklus klingen. Der Unterschied liegt im Umfang. Während Lernen auf der Ebene eines individuellen Experiments operiert, kann das Analysieren über mehrere Experimente hinweg operieren und wird auf der Ebene der Strategie und/oder des Geschäftsmodells angewendet.

Wenn unser Team beispielsweise mit zwei möglichen (aber gleichsam exklusiven) Lösungen für einen Engpass ankommt, könnten wir uns dazu entschließen, sie parallel in Split-Tests zu bearbeiten. Wir würden das Analysestadium nutzen, um unsere Learnings über beide Experimente hinweg in einer einzelnen Lösung zusammenzuführen, die uns vorwärts bringt.

Next Actions - Wie systematisieren wir das Gelernte?

Es gibt einen Unterschied zwischen dem, was wir aus einem Experiment lernen und dem, was wir dann mit dem Gelernten anfangen. Fürs Lernen bekommt man kein goldenes Sternchen, sondern dafür, das Gelernte in Geschäftsmodell-Resultate zu transformieren. Dies erfordert, das Gelernte über die Organisation hinweg zu systematisieren, damit es wiederholt und skaliert werden kann. In diesem Stadium geht es darum, diese Art von Entscheidungen zu treffen.

Beispielsweise könnten wir eine Preisverankerungs-Technik nehmen, die in unseren Kundeninterviews funktioniert hat, und sie in unsere Vertriebs-Trainings hinein systematisieren. Oder wir könnten uns im Fall eines fehlgeschlagenen Experiments oder nicht eindeutiger Daten dafür entscheiden, ein neues Lernexperiment durchzuführen, um Antworten zu finden. Oder wir haben einen Engpass beseitigt und würden nun die nächste Beschränkung identifizieren, ein neues Ziel setzen und den Prozess wiederholen.

Wo können Sie mehr lernen?

Das war eine Ansicht aus 1.000 Metern Höhe auf das GOLEAN-Framework. Ich entlasse Sie mit einem Blick auf die täglichen Aktivitäten, sodass Sie mal sehen, wie das in Aktion aussieht.

Wenn Sie hier tiefer einsteigen möchten: Ich beschäftige mich mit diesem Framework in meinem Buch Scaling Lean. Sie können hier ein Exemplar bestellen.

Dieser Artikel wurde im Original am 12. Oktober 2016 unter dem Titel The GOLEAN Framework for Growth von Ash Maurya veröffentlicht. Ash Maurya gehört zu den führenden Köpfen der internationalen Gründerszene und ist einer der renommiertesten Experten für Lean Startup und Customer Development. Die Website seines Unternehmens LEANSTACK und seinen Blog erreichen Sie unter http://leanstack.com. Mehr Fachartikel bietet unser Lean-Special.

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar