Der Lean Stack (Teil 4)

Anmerkung der Redaktion: Im dritten Teil der Artikelreihe ist Ash Maurya tiefer in den Flow seines Lean-Stack-Prozesses eingedrungen.

Wenig überraschend drehen sich die meisten Fragen, die mich in diesem Zusammenhang erreichen, um die Funktionsweise des Lean-Stack-Boards. Ich will sie also beantworten:

Frage: Wie erstelle ich eine Karte für ein Produkt, wenn ich Problem- und Solution-Interviews durchführen will?

Die Produktkarte ist nur ein Platzhalter für die Idee, die Sie zu implementieren planen. Alles, was Sie brauchen, ist ein Label, um die Idee oder das Konzept zu identifizieren. (Sie können das Label auch später noch ändern.) Das nimmt eine Lösungsdefinition oder einen Beitrag zur Umsetzung nicht vorweg. Sie können höchstens beim Finden eines passenden Namens etwas ins Straucheln geraten, wenn Sie gerade ziellos nach Ideen fischen wollen, die eine Implementierung lohnen würden. Aber selbst dann können Sie dieses Produkt ja einfach "Expedition: Fischen nach Ideen" nennen.

In der Praxis werden Sie mit der Zeit in ein Stadium kommen, in dem Sie bereits eine recht gute Ahnung vom Problem, von den Kunden und vielleicht sogar von der möglichen Lösung haben. Statt Ihnen Tipps zu geben, wie Sie Ihr Produkt nennen könnten, sollte ich eigentlich mehr Energie darauf verwenden, Ihnen auszureden, ihm vorzeitig tatsächlich einen Namen zu geben – und etliche Anläufe mit der Suche nach Domain-Namen und der Logo-Entwicklung zu verbringen.

Frage: Was ist ein Minimum Viable Feature (MVF)? In welcher Beziehung steht es zu einem MVP? Woher weiß ich, was ich nutzen soll?

Die Produktkarte soll eine Produkteinheit abbilden, die an Kunden ausgeliefert wird. Die erste Produkteinheit, die Sie ausliefern, ist Ihr Minimum Viable Product (MVP).

In meinem letzten Artikel habe ich von einem Continuous-Deployment-Prozess gesprochen, wie den, den wir nutzen: Nach dem MVP werden immer wieder Produkteinheiten als individuelle Features ausgeliefert. Da jedoch nicht jeder nach dieser Methode deployt, könnte eine allgemeinere Herangehensweise die sein, mit Minimum Viable Releases (MVR) zu arbeiten, wobei das MVP Release 1.0 ist. Ein Release ist dabei ein einzelnes Feature (MVP) oder eine Sammlung von Features.

Zusätzlich zum MVP und den MVRs kann die Produktkarte genutzt werden, um mehrere ähnliche Produkte auf demselben Board zu repräsentieren. Bei Spark59 nutzen wir einen einzigen Lean Stack zur Abbildung der vielen Tool-, Content- und Coaching-Produkte, die wir entwickeln.

Frage: Wie wird der Lebenszyklus eines Produkts über die vier Stadien am Board hinweg abgebildet?

Nach der Entwicklung einiger Produkte habe ich festgestellt, dass der Lean-Weg darin besteht, dass der Prozess von der Idee zum MVP derselbe ist/sein sollte wie der vom MVP zum Release 2.0, zu 3.0 usw. Andernfalls ist es schnell passiert, dass man den Kunden nicht mehr zuhört und in die falsche Richtung marschiert.

Bei der Ideenentwicklung würde dieser Prozess diese Schritte beinhalten:

  1. Ein Problem finden, dass es wert ist, gelöst zu werden, indem man das Problem (und die Kunden) versteht
  2. Eine mögliche Lösung oder ein mögliches MVP definieren
  3. Das MVP auf kleiner Skala testen
  4. Ausskalieren

Spätere Releases folgen ähnlichen Stadien:

  1. Ein Follow-on-Problem finden, dass sich zu lösen lohnt und das das Release rechtfertigt
  2. Mögliche Lösungen oder Features definieren, die das Release bilden
  3. Das Release über einen partiellen Rollout auf kleiner Skala testen
  4. Voller Rollout des Releases

Frage: Wo werden Details zu Produkten und Experimenten abgebildet?
Eine Kanban-Karte hat den Zweck, den Arbeitsfluss zu visualisieren und zu kommunizieren. Die Karte ist zu klein, um alle Details eines Produkts oder Experiments darauf festzuhalten. Also platzieren wir auf ihr nur die wirklich kritischen Informationen.

  • Für ein Produkt: Identifizierung (Name) und Exit-Kriterien für das spezifische Stadium
  • Für ein Experiment: Identifizierung (normalerweise ein kurzer aktionsbasierter Name wie “Problem-Interviews durchführen”) und eine Liste mit einer oder mehreren falsifizierbaren Hypothese(n).
  • Für ein Risiko oder Problem: Üblicherweise Identifizierung mithilfe einer Frage wie "Können wir für dieses Produkt 100 Dollar im Monat verlangen?"

Würde es sich um ein Online-Tool handeln, wären mit dem Öffnen der Karte mehr Details zu sehen. Wir implementieren das heute, indem wir einen einseitigen A3-Report nutzen. A3-Reports (benannt nach dem internationalen Papierformatstandard) werden bei Toyota extensiv für eine Reihe von Problemlösungsinitiativen genutzt, die den Herausforderungen in einem Startup sehr nahe kommen.

Während meiner Bemühungen, A3-Reports zu kapieren, habe ich eine interessante Parallele zwischen den vier Stadien des Iterations-Meta-Musters und den vier Stadien des Deming-Kreises Plan, Do, Check, Act entdeckt (PDCA). Aber das ist ein eigenes Wespennest, in das ich in einem künftigen Blog-Post mal hineinstechen werde.

The Lean Stack in Action

Zeit, sich eine konkrete Fallstudie anzusehen.

Nun sind Sie am Zug

Im Lean-Denken wird ein Prozess nicht von oben verordnet und ist auch nicht in Stein gemeißelt, sondern eher ein lebendiges Produkt, dass den Leuten gehört, die daran arbeiten.

Wie Lean Canvas steht auch Lean Stack unter der Creative-Commons-Lizenz. Sie können die Lean-Stack-MVP-Poster hier downloaden oder bestellen.

Wie es von hier aus weitergeht, liegt ganz bei Ihnen!

Dieser Artikel wurde im Original am 27. Juni 2012 unter dem Titel The Lean Stack – Part 2 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. Seinen Weblog finden Sie unter www.ashmaurya.com. Die Website seines Unternehmens Spark59 erreichen Sie unter http://spark59.com. Mehr Fachartikel bietet unser Lean-Special.