
MVP, Sellable oder Lovable: Warum alle vom MVP reden und trotzdem aneinander vorbeireden
Auch interessant

Woran man merkt, dass die Produktentwicklung klemmt

So haben wir unsere Werte definiert

Empathische Führungspersonen und wie man sie rekrutiert
Es gibt Begriffe, die in der Produktentwicklung so selbstverständlich fallen, dass kaum jemand innehält und fragt, ob eigentlich alle dasselbe damit meinen. MVP, also das Minimal Viable Product, ist dafür das beste Beispiel. Kaum ein anderer Ausdruck taucht so zuverlässig in Planungsrunden auf, und kaum ein anderer sorgt so verlässlich für Reibung, sobald es konkret wird.
Besonders deutlich wurde mir das in einem Projekt, das in einer klassischen Wasserfall-Falle feststeckte, mit langer Entwicklungszeit, ohne Zwischenfeedback aus dem Markt und ohne etwas Verkaufbares in Sicht. Während die Entwicklungsseite unter MVP ganz selbstverständlich verstand, endlich etwas Testbares zu liefern, wartete die Produktseite nach all den Monaten ebenso selbstverständlich auf etwas, das sich verkaufen lässt. Das waren zwei Erwartungshaltungen, die sich an einem einzigen Wort entzündeten, ohne dass irgendjemand etwas falsch gemacht hätte. Man hatte nur nie gemeinsam geklärt, was dieses Wort überhaupt bedeuten soll.
Dass daraus Frust entsteht, ist wenig überraschend. Spannender finde ich die Frage, warum ausgerechnet dieser eine Begriff so anfällig für Missverständnisse ist, und was sich dagegen tun lässt.
Warum der Begriff von Anfang an uneindeutig war
Ein Teil der Antwort liegt darin, dass das MVP nicht einen Ursprung hat, sondern zwei, und dass sich diese beiden widersprechen. Geprägt wurde der Begriff 2001 von Frank Robinson, der darunter ein fertiges, funktionierendes Produkt verstand, das den Ertrag im Verhältnis zum Risiko für Anbieter und Kundschaft maximiert. Bekannt gemacht hat den Begriff allerdings jemand anderes: Eric Ries beschrieb das MVP 2011 in "The Lean Startup" als "die Version eines neuen Produkts, die es einem Team erlaubt, mit dem geringsten Aufwand ein Maximum an validiertem Lernen über die Kundschaft zu sammeln". Bei Robinson ist das MVP also ein Produkt, bei Ries ein Experiment, und genau zwischen diesen beiden Polen verlief die Bruchlinie in meinem Projekt.
Dass es sich dabei nicht um einen subjektiven Eindruck handelt, sondern um eine strukturelle Schwäche des Begriffs, zeigt ein Blick in die Forschung. Valentina Lenarduzzi und Davide Taibi haben 2016 in einer systematischen Mapping-Studie die in der Fachliteratur gebräuchlichen MVP-Definitionen zusammengetragen und festgestellt, dass diese deutlich voneinander abweichen. Was sich über die Quellen hinweg wiederholt, sind lediglich drei Bausteine, nämlich ein minimaler Funktionsumfang, Kundenfeedback und minimaler Aufwand. Alles Übrige variiert. Wer beim MVP also Eindeutigkeit erwartet, erwartet etwas, das der Begriff schlicht nie besessen hat.
Was Marty Cagan am Wort Produkt stört
Noch einen Schritt weiter geht Marty Cagan, der nicht nur die Uneindeutigkeit beklagt, sondern den Begriff selbst für einen Teil des Problems hält. Sein Einwand richtet sich gegen das Wort "Product", weil es Teams dazu verleitet, etwas in Produktqualität zu bauen, obwohl sie eigentlich nur lernen wollen. In seinem Buch "Inspired" bringt er das auf die Formel "The MVP should be a prototype, not a product", also die Feststellung, dass ein echtes Produkt zu bauen, nur um zu lernen, Verschwendung sei und damit das Gegenteil des schlanken Vorgehens, das eigentlich gemeint ist.
Konsequenterweise spricht Cagan lieber von einem MVP-Test als von einem MVP. Ein tragfähiges, also "viable" Produkt ist für ihn nämlich eine hohe Hürde, weil Menschen sich aktiv dafür entscheiden müssen, es zu nutzen oder zu kaufen, weil sie damit zurechtkommen müssen und weil das Team es mit den vorhandenen Mitteln liefern können muss. Ein roher Lernbaustein erfüllt das nicht und sollte deshalb auch nicht Produkt heißen. Überträgt man diesen Gedanken auf mein Beispiel, dann entzündete sich der Konflikt an genau dem Wort, an dem Cagan sich stört. Hätte die eine Seite von einem Test und die andere von einem verkaufbaren Produkt gesprochen, wäre der Unterschied von Anfang an sichtbar gewesen.
Was geholfen hat, waren greifbare Begriffe
Aufgelöst haben wir die Situation schließlich mit einem Modell von Henrik Kniberg, das er 2016 im Crisp-Blog vorgestellt hat. Statt eines einzigen, überfrachteten MVP schlägt er drei greifbare Zustände vor, nämlich das Earliest Testable, das Earliest Usable und das Earliest Lovable Product. Berühmt geworden ist dazu seine Skizze, in der ein Produkt eben nicht vom einzelnen Reifen über die Karosserie zum fertigen Auto wächst, sondern vom Skateboard über den Roller bis zum Motorrad, sodass in jeder Stufe bereits etwas Nutzbares vorhanden ist.
Der Charme dieser drei Stufen liegt darin, dass sie genau das trennen, worüber in meinem Projekt gestritten wurde:
- Earliest Testable ist die erste Version, mit der Nutzer:innen sinnvoll interagieren können, wobei das Lernen im Mittelpunkt steht und nicht der Verkauf.
- Earliest Usable, oft auch Sellable genannt, bietet einem relevanten Teil der Nutzer:innen bereits einen konkreten Mehrwert und lässt sich im Alltag einsetzen oder verkaufen, auch wenn sie noch nicht vollständig ausgereift ist.
- Earliest Lovable ist schließlich die Version, die Nutzer:innen nicht nur verwenden, sondern bewusst bevorzugen und aktiv weiterempfehlen.
Interessant ist, dass Kniberg diese Begriffe nicht aus dem Nichts erfunden, sondern eine ältere Diskussion gebündelt hat. Das "Sellable" hat seine Wurzel im Minimum Marketable Feature, das Mark Denne und Jane Cleland-Huang bereits 2003 in "Software by Numbers" beschrieben haben, also im kleinsten Baustein, der der Kundschaft echten Wert liefert. Das "Lovable" wiederum greift den Gedanken des Minimum Lovable Product auf, der bereits Anfang der 2010er Jahre in der Agile-Szene kursierte und ab 2013 vor allem durch Brian de Haaff und später Laurence McCahill populär wurde, mit dem Fokus auf Begeisterung statt bloßer Machbarkeit. Was Knibergs Modell so alltagstauglich macht, ist, dass es diese Stränge in eine gemeinsame, greifbare Sprache übersetzt.
Warum das Konzept im Grunde zweitrangig ist
Nach diesem Projekt bin ich überzeugt, dass es am Ende gar nicht so entscheidend ist, welches Modell ein Team wählt. Ob man beim MVP nach Ries bleibt, mit Cagan lieber vom MVP-Test spricht oder die drei Stufen nach Kniberg nutzt, jedes dieser Vokabulare funktioniert für sich genommen. Entscheidend ist vielmehr, dass alle im Team dasselbe darunter verstehen, und dass jemand hellhörig wird, sobald mit denselben Worten unterschiedliche Dinge gemeint sind.
Der Aufwand dafür ist erstaunlich klein, wenn man bedenkt, was auf dem Spiel steht. Ein gemeinsames Vokabular mit greifbaren Begriffen kostet ein Gespräch zu Projektbeginn, kein zusätzliches Tool und keine neue Methode. Was es einspart, ist genau der Frust aus meinem Beispiel, also Monate Arbeit an einem Ziel, das zwei Seiten die ganze Zeit unterschiedlich im Kopf hatten.
Quellen
- Robinson, F. (2001): Prägung des Begriffs Minimum Viable Product, SyncDev. Überblick bei SKMurphy.
- Ries, E. (2011): "The Lean Startup". Definition und Prinzip des validierten Lernens, theleanstartup.com.
- Lenarduzzi, V. & Taibi, D. (2016): "MVP Explained: A Systematic Mapping Study on the Definitions of Minimal Viable Product". 42nd Euromicro Conference on Software Engineering and Advanced Applications (SEAA), S. 112–119. Volltext im Forschungsportal der Universität Tampere.
- Cagan, M. (2018): "Inspired: How to Create Tech Products Customers Love", 2. Auflage. Zitat "The MVP should be a prototype, not a product". Ergänzend Silicon Valley Product Group und Viable Product vs. Minimal Product.
- Kniberg, H. (2016): "Making sense of MVP – and why I prefer Earliest Testable/Usable/Lovable", Crisp's Blog, 25.01.2016.
- Denne, M. & Cleland-Huang, J. (2003): "Software by Numbers: Low-Risk, High-Return Development". Minimum Marketable Feature, siehe Agile Alliance Glossar.
- Minimum Lovable Product: Begriff kursierte bereits Anfang der 2010er Jahre in der Agile-Szene, popularisiert ab 2013 durch Brian de Haaff und später Laurence McCahill (2014). Überblick bei Aha! und The Happy Startup School.
Neugierig?
Vereinbart ein kurzes Kennenlerngespräch mit uns oder schreibt uns eine Mail und lasst uns über spannende Projekte reden.
office@heartcoded-software.de