Anmerkung der Redaktion: Im ersten Artikel der Reihe hat Ash Maurya die ersten Iterationen auf dem Weg zur Etablierung seines Lean-Stack-Prozesses beschrieben und ist auf das Konzept der Vision-Produkt-Strategie-Pyramide als Inspirationsquelle eingegangen.
Version 3: Der Lean Stack
Die Vision-Produkt-Strategie-Pyramide (siehe <Teil 1 des Artikels>) ist nicht nur ein gutes Modell, sie kann auch in einen fließenden Prozess eingeflochten werden, indem ein visuelles Kontrollsystem auf jeder Stufe der Pyramide etabliert wird. Genau das habe ich beim Lean Stack getan.
Die Visions-Schicht – Lean Canvas
Die unterste Schicht des Stacks ist Ihre Vision oder das Warum, und das lässt sich nach wie vor am besten mit dem Lean Canvas einfangen. Hier geht es darum, die aktuell beste Schätzung in Sachen Realisierung eines funktionierenden Geschäftsmodells zu dokumentieren.
Die Strategie-Schicht – Strategy-and-Risks-Board
Die mittlere Schicht ist der Kitt, der die unterste und die oberste Schicht verbindet und der in meinen vorherigen Ansätzen gefehlt hat. Diese Schicht hilft, die große Vision auf einen Implementierungsplan (Strategie) herunterzubrechen, der sowohl auf dem Studium bestehender Analogs/Antilogs als auch auf Gesprächen über Risiken mit dem Team, Stakeholdern, Beratern, Kunden und sogar Konkurrenten basiert.
Das Analogs/Antilogs-Framework ist ein Konzept, das Randy Komisar und John Mullins in ihrem Buch “Getting to Plan B” beschrieben haben. In meinem nächsten Blog-Post werde ich darauf eingehen.
Risiken werden einfach auf einem Kanban-Board abgebildet: Die Priorisierung erfolgt im Backlog-Bereich, im weiteren Verlauf ziehen sie dann konkrete Arbeiten (Experimente) nach sich.
Die Produkt-Schicht – Validiertes Learning-Board
Die oberste Schicht des Stacks soll die aktuelle Arbeit abbilden, die erforderlich ist, um das Produkt zu erschaffen und die Vision zu realisieren.
Ich halte diese Arbeit auf einem validierten Learning-Board fest, das dem Feature-Kanban-Board gleicht, aber ein paar zusätzliche Optimierungen enthält. Zum einen ist es so generalisiert, dass es alle Arten von Produkten unterstützt (und nicht nur Software), indem der Flow explizit in diese vier Stadien des Meta-Iterationsmusters aufgebrochen ist:
- Problem verstehen: Bevor Sie eine Lösung definieren können, müssen Sie den Kunden und das Problem verstehen.
- Lösung definieren: Definieren Sie die Lösung zuerst mithilfe einer Demo, statt hastig direkt an der Umsetzung der Lösung zu arbeiten.
- Qualitative Validierung: Validieren Sie die Lösung auf einer kleinen Skala.
- Quantitative Verifizierung: Verifizieren Sie die Skalen für die Lösung.
Doch die große Veränderung ist hier, dass sowohl das Produkt als auch die Experimente auf demselben Board modelliert werden können, das zweigeteilt ist und auf dem horizontale Swimlanes implementiert sind. Wer mehr über Kanban-Boards wissen möchte, dem sei David Andersons Klassiker Kanban als tolle Grundlage empfohlen.
Die obere Reihe bildet den Produktstatus ab. Ein "Produkt" auf dem Board kann durch ein Minimum Viable Product (MVP), ein Minimum Marketable Feature (MVF) oder ein entsprechendes Sub-Produkt repräsentiert werden. Das Produkt kann sich nicht in mehreren Stadien gleichzeitig befinden. Jedes Stadium hat exakt definierte Exit-Kriterien (wie Anzahl der Interviews, Lernziel oder ein Zeitfenster), die auf der Produktkarte festgehalten sind.
Für jedes Produkt kann eine beliebige Anzahl von Experimenten durchgeführt werden, die in einer horizontalen Swimlane für das entsprechende Produkt platziert werden. Jedes Experiment hat eine klar definierte falsifizierbare Hypothese und optional eine Timebox-Beschränkung und durchläuft den Build-Measure-Learn-Zyklus, der durch Spalten gleichen Namens abgebildet wird.
Die Build-Spalte repräsentiert die Definition und das Setup-Stadium des Experiments und enthält oft Dinge wie Programmierung, Landing-Page-Entwicklung, Mockups, Interviews, Interview-Script-Erstellung usw.
Im dem Moment, in dem das Experiment mindestens einem Kunden gezeigt wird, wird die Karte ins Measure-Stadium bewegt.
Sind genügend Daten gesammelt oder die Zeitvorgabe erreicht, wandert die Karte ins Learn-Stadium, wo sie je nach den Kriterien der falsifizierbaren Hypothese entweder als validiert oder als nicht validiert markiert wird.
Und all die Aufgaben im Zusammenhang mit den Experimenten?
Obwohl es konzeptionell möglich ist, auf einer weiteren Ebene auch Aufgaben abzubilden, ist es grundsätzlich ratsam, mehr als zwei Ebenen zu vermeiden, da das Board sonst zu hektisch wird. Außerdem sieht das Lean-Startup-Konzept vor, dass die Entwicklung durch Lernen und nicht durch die Umsetzung gemessen wird. Auch deswegen ist es besser, die Umsetzung vom Board fernzuhalten.
Wir tracken unsere Aufgaben auf einem separaten Task-Board (ebenfalls Kanban), das Verweise auf die Experimente enthält, doch an dieser Stelle würden Details zu weit führen.
Der Lean Stack in Aktion
Das waren eine Menge Informationen für einen einzelnen Artikel. Im nächsten Beitrag gehe ich darauf ein, wie diese Boards verknüpft werden können, und zeige den Lean Stack in Aktion, indem ich eines meiner eigenen Produkte als Beispiel heranziehe.
