Die Mystik rund um “Minimum Viable Product”

In dieser Woche gab es auf LinkedIn eine schwungvolle Diskussion zum Konzept des Minimum Viable Product (MVP), die ich hier noch einmal Revue passieren lassen und dabei meine Sicht darstellen möchte.

Danke an Gerrit Beine, der mich mit seinem Kommentar im initialen Beitrag auf LinkedIn überhaupt erst auf diese Diskussion aufmerksam gemacht hat.

Folgendes Bild, mit der Aussage, dass Option 3 die Ideen hinter dem Konzept des MVPs am besten darstellt, war “Stein des Anstoßes” für mich. Ich habe daraufhin interveniert und gemeint, dass Option 2 für mich eher zu den Gedanken eines MVPs passen.

Meine Sicht möchte ich nun darlegen und erläutern.

Bei Option 2 steht der Kunde mit seinen „Jobs-to-b-done“ im Fokus, in diesem Kontext zum Beispiel “Mobilsein”, bei Option 3 das Produkt, “ein Auto besitzen wollen”. Damit ist Option 3 nach innen gerichtet, also auf “Angebot” eines Unternehmens. Option 2 ist streng auf “Nachfrage” des Kunden ausgerichtet.

Die Idee hinter dem Konstrukt des MVPs ist es, dass Unternehmen sich konsequent auf den Kunden einlassen und ihm helfen, besser seine Probleme zu lösen oder seine Wünsche zu befriedigen. Also sollte im Unternehmen nicht davon ausgegangen werden, ein bestimmtes Produkt bauen zu wollen, sondern eher Kundenprobleme mittels Produkte oder Services zu lösen.

In der Diskussion auf LinkedIn wurde dann auch die These in den Raum gestellt, dass man schon ein bisschen denken sollte, bevor man mit dem Bau eines Produktes loslegt. Es wurde postuliert, dass bei Option 2 die Anforderungen der Kunden wohl noch nicht so klar definiert wären und man deshalb zwischen Roller und Auto schwanken würde.

Von welchen Anforderungen sprechen wir denn hier? Die Anforderungen an ein zu erstellendes Produkt? Richtig, diese Anforderungen können auch nicht klar sein. Deshalb gibt es ja auch die Idee des MVP, jedenfalls so wie ich es verstehe.

Wenn ich das Endprodukt bereits kenne, kann ich auch einen zukünftigen Kunden fragen, der mir das dann ganz genau beschreiben kann. Der Kunde würde mir wahrscheinlich bei Option 3 ganz genau das rechte Auto beschreiben können. Also warum sollte ich mich dann von links nach rechts über mehrere Iterationsschritte zu einem Endprodukt entlang hangeln. Das kostet unnötig Zeit und Geld. In diesen Situationen benötige ich das Konzept des MVPs nicht. Dann kann ich es mir leichter machen.

Möchte der Kunde ein Auto, dann frage ich ihn genau, wie es aussehen und was es können sollte (Option 3). Dann baue ich das Ding. So entstehen aber keine Innovationen. So wird immer nur das in die Welt gebracht, was es bereits gibt. In manchen Konstellationen ist genau das der “richtige” Weg. Das mag ich gar nicht bestreiten. Nur benötigt man dann nicht das Konzept eines MVPs in vollem Umfang.

Ein MVP kommt dann zum Tragen, wenn ich noch keine Lösung, und damit kein Produkt oder Service, zu einem Kundenproblem im Kopf habe. Und der Kunde auch nicht. Das Kundenproblem könnte hier sein: “Ich möchte jederzeit so schnell und kostengünstig wie möglich von A nach B gelangen!”. Dann muss ich, auf die Abbildung geschaut, von links nach rechts Erfahrung und Wissen aufbauen, um bestmöglich die Kunden zu bedienen. Ich fokussiere mich dann auf die Aufgaben der Kunden und auf keine Lösung in Form eines Produktes oder Services. Dieses entsteht erst im Laufe des Prozesses.

Beim MVP bauen die iterativ erstellten Produkte nicht unbedingt aufeinander auf. Ich kann nicht davon ausgehen, dass ich das Produkt aus Iteration n-1 komplett oder teilweise in das Produkt der Iteration n einfließen lassen kann.

In jedem Iterationsschritt sollte man natürlich eine valide Idee haben und damit ein Produkt oder Service erstellen, welches das Kundenproblem löst. Die Lösung sollte halt nur mit jedem Schritt besser werden. Und dabei können komplett neue Produkte oder Services herauskommen, die nicht aufeinander aufbauen.

In meinen Augen darf im Konzept des MVPs nicht von rechts nach links gedacht werden, nach dem Motto, ich weiß was am Ende rauskommen soll. Dann zerlege ich die Abarbeitungsschritte in n Iterationen und baue n Teilprodukte. Im Konzept des MVPs sollte konsequent von links nach rechts gedacht werden. Im Iterationsschritt n sollte ich genau wissen, wie das Produkt ausschaut und dieses sollte auch das Kundenproblem lösen. Ich weiß aber noch nicht, wie das Produkt im Iterationsschritt n+1 ausschaut. Denn wenn ich das wüsste könnte ich ja Iterationsschritt n überspringen und gleich dieses Produkt bauen.

Damit wird bei Option 2 auch nicht zwischen Roller und Auto hin und her gependelt, um noch einmal auf die angebrachte Kritik zu sprechen zu kommen. Im Rahmen der LinkedIn Diskussion wurde in diesem Sinne das Vorgehen kritisiert, dass nämlich noch zu schwammig gedacht, sondern einfach mal losgelegt wurde. Da bin ich anderer Meinung. Das Auto war noch gar nicht im Lösungsraum vorhanden, als der Roller gebaut wurde. Deshalb würde ich die einzelnen Iterationsschritte im Bild gerne deutlicher hervorheben.

Das Bild baut sich von oben nach unten sukzessive auf. Ich habe nicht gleich das ganze Bild mit allen Iterationsschritten im Kopf. Iterationsschritt n mit einer Lösung durchdenke ich erst, wenn die Lösung aus Schritt n-1 mit dem Kunden getestet wurde. Dann wird Feedback eingebaut und die Lösung für Schritt n durchdacht.

In dem Moment, wo mir das Auto in den Sinn kommt, könnte ich natürlich denken: “Shit, hätte ich das früher gewusst. Dann hätte ich den Roller nicht bauen müssen.” Nach dem Motto: Hinterher ist man immer schlauer. Wir sollten aber nicht vergessen, dass der Roller inkl. des Feedbacks der Kunden wahrscheinlich erst dazu geführt hat, dass ich auf das Auto als Lösung gekommen bin.

Mit diesen Gedanken ist dann auch klar, dass ich gar nicht wissen kann, mit welcher Option ich Kundenprobleme löse. Spinnt man das erste Bild in diesem Beitrag weiter kann auch Option 3 in Option 2 übergehen, nämlich dann, wenn ich im Iterationsschritt 5 ganz vom Auto wegkomme, da ich merke, dass ein anderes Produkt die Probleme besser lösen kann. Deshalb gehe ich, je größer der Handlungsraum der Kunden wird, immer von Option 2 aus. Wenn ich mich dann immer noch in der Option 3 bis zu einem gewissen Zeitpunkt befinde ist das fein, da ich dann keine Pfadabhängigkeiten auflösen musste. Das kann ich aber vorher nie wissen.

Option 3 stellt sehr eindrucksvoll diese angesprochene Pfadabhängigkeit dar, in denen unsere großen Automobilhersteller gerade stecken. Sie bauen Autos. Punkt. Komme was wolle. Und genau diese Pfadabhängigkeit kostet Wettbewerbsfähigkeit. Um diese Pfadabhängigkeit aufzulösen müssten sie zu Option 2 übergehen. Sie müssten Dinge sein lassen, nämlich Autos zu bauen, und nicht auf Gedeih und Verderb immer weiter machen, dann zu Lasten ihrer Wettbewerbs- und Lebensfähigkeit.

Beim Aufzeigen dieser Herausforderungen können die Ideen rund um MVP helfen, aber nur wenn diese Ideen auch passfähig interpretiert werden. Vielleicht ist es mir ja mit diesem Beitrag ein wenig gelungen, zumindest meine Sicht klar darzulegen.

1 Star2 Stars3 Stars4 Stars5 Stars (5 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading ... Loading ...
Teilen Sie diesen Beitrag gerne auf Ihren sozialen Kanälen: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Facebook
  • LinkedIn
  • Twitter
  • XING
This entry was posted in Modellierung and tagged . Bookmark the permalink.

3 Responses to Die Mystik rund um “Minimum Viable Product”

  1. Danke für den Denkanstoß! Auch ich bin zuerst in die Falle der Bilder getappt! Die besteht darin, dass man meint, dass eines der drei Bilder die Entwicklung mittels MVP und Inkrementen am besten darstellt. Aber das stimmt nicht.

    Keines der Bilder stellt inkrementelle Entwicklung dar. Es sind alles Blicke in den Rückspiegel. Sie können nur in der Rückschau gemalt werden – und dann tendiert man zu dem Bild, das für die geringste Verschwendung steht.

    Das ist irreal! Real ist, das man am Anfang steht, also ganz links und nichts rechts vor sich hat. Man hat links zu Beginn einer Entwicklung nur eine mehr oder weniger klare Vorstellung von irgendetwas rechts. Die Darstellungen sind insofern reduziert, als dass sie nicht zwischen Vorstellung und Produkt unterscheiden. Diese Co-Evolution wird ausgeblendet. Sie ist aber entscheidend, würde ich sagen.

    Auf das Beispiel bezogen: Am Anfang ist eine Idee von „Ich möchte mich bequem auf Rädern fortbewegen können.“ oder so. Wie kann diese Idee visualsiert werden? Keine Ahnung. Nur eines scheint mir klar: Ein einzelnes Rad wäre dann tatsächlich nicht ein erstes Inkrement 😉 Aber sowohl ein Roller wie ein Auto wie ein Segway wie eine Seifenkiste könnten ein erstes Inkrement darstellen.

    Und dann macht die weitere Entwicklung weiter, wo sie von der Differenz der Implementation und der nun auch weiterentwickelten Vorstellung hingezogen wird. Vielleicht war das erste Inkrement wirklich ein Roller. Nun merkt der Kunde, dass er lieber sitzen möchte bei der Fortbewegung. Dann also als nächstes eine Seifenkiste. Dann merkt der Kunde, dass er nicht nur den Berg runter bequem sitzend rollen will. Also ist als nächstes ein Kettcar dran. Dann merkt der Kunde, dass sitzen und treten nicht bequem ist. Also ein GoKart. Usw. usf.

    Inkrementelle Entwicklung lässt sich von der Spannung ziehen, die im Kontrast zwischen Vorstellung und Implementation existiert. Die Geradlinigkeit, die in den Bildern steckt, ist ihr fremd.

    • Hallo Ralf,

      ganz lieben Dank für Deine Reaktion. Ich bin ganz bei Dir. Deshalb habe ich das Originalbild abgewandelt und das zweite Bild gemalt, wo deutlich werden soll, dass ich in Iterationsschritt n ein mögliches Produkt des Iterationsschrittes n+1 noch gar nicht denken kann.

      BG, Conny

  2. Ich komme spät zu der Party und gebe ganz offen zu, dass ich ein Fan von der Option 3 bin. Der Begriff MVP ist mir zum ersten Mal in Eric Ries’ Buch “The Lean Startup” begegnet. Für Ries ist das MVP die Verifikation einer konkreten Produktidee. Das wäre nicht das Fahrrrad, sondern der rudimentäre LKW. Um auf diese Idee zu kommen, arbeitet Ries gedanklich von rechts nach links:

    “Although we write the feedback loop as Build-Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn, use innovation accounting to figure out what we need to measure to know if we are gaining validated learning, and then figure out what product we need to build to run that experiment and get that measurement.”

    Falls das MVP scheitert, gibt einen Pivot, also ein anderes Produkt, was verifiziert wird. Ist das MVP erfolgreich, wird es zu Version 1 weiterentwickelt, dem echten vermarktungsfähigen Produkt.

    Zu Automobilbranche: Sie müssen, genau wie Ries es schreibt, mit der Frage starten: “Was wollen wir jetzt lernen?”

Leave a Reply to André Claaßen Cancel reply

Your email address will not be published. Required fields are marked *