Kaum ein Begriff ist in den letzten Jahren in der Softwareentwicklung so überstrapaziert worden wie der des MVP. Das Minimum Viable Product ist mal Heilsbringer, mal Fluch und wird allzu gerne instrumentalisiert, um für und wider alles Mögliche zu argumentieren. Da wird ebenso leichtfertig technische Schuld auf sich genommen wie nur halbherzig getestet: „Es ist ja erst mal nur ein MVP.“
Es ist Zeit aufzuräumen, kritisch auf Kontext und Anwendungsfall zu blicken und für mehr Klarheit zu sorgen. Deshalb beleuchtet dieser Artikel unterschiedliche Spielarten von MVPs. Ziel ist es, besser beurteilen zu können, welches MVP welchem Zweck dient, um ihn aus seinem zwangsverordneten Selbstzweck zu befreien.
Der große MVP-Schwindel und warum es trotzdem helfen kann, kleine Schritte zu machen
„Es ist ja erst mal nur ein MVP.“ So klingt das dann, wenn es zunächst mal nur „minimum“ und trotzdem „viable“ sein soll. Gefühlt jede Entwicklung, an der ich in den letzten Jahren mitgewirkt habe, hatte als Ziel ein MVP, und nur in den seltensten Fällen hatten alle Beteiligten das gleiche Verständnis, was damit gemeint sein könnte. Und eben dieses gemeinsame Verständnis ist essenziell, wenn komplexe Softwareprodukte innerhalb von einem Team gestaltet, umgesetzt und betrieben werden sollen.
Ein MVP wird oft Projektionsfläche für persönliche Ziele und Motive
So wird das MVP – gerade wegen seiner unklaren Definition – zu einer wunderbaren Projektionsfläche für allerlei persönliche Ziele und Motive. Übereifrige Product Owner argumentieren Qualitätsdiskussionen weg, um mehr Features umgesetzt zu bekommen. Teams nehmen bereitwilliger technische Schuld auf sich, die dann ja später noch beglichen werden kann. Stakeholder und Management drücken Budgets – es ist ja erst mal nur ein MVP.
Spätestens zum Launch kommt dann das böse Erwachen, ein doch irgendwie eher maximaler Scope, dafür aber Qualitätsprobleme bei Sicherheit, Skalierbarkeit und Gebrauchstauglichkeit. Dazu kommt noch eine handvoll fragwürdiger architektonischer Entscheidungen, und aufgrund der beschriebenen Probleme gerät das gute Stück dann nach dem Launch allzu schnell in Vergessenheit oder wird achselzuckend unter dem allseits beliebten Motto “Software ist halt kompliziert” als unabwendbarer Schicksalsschlag hingenommen.
Aber muss das sein? Und hätte nicht ein besseres gemeinsames Verständnis von dem, was es zu erreichen gilt und was sich hinter den drei kleinen Buchstaben für eine Bedeutung verbirgt, dafür gesorgt, zielgerichteter und erfolgreicher unterwegs zu sein? Vermutlich schon – und nicht zuletzt aus diesem Grund folgen hier jetzt Begriffsklärung und Grundlagenforschung, um den Missverständnissen und Projektionen auf die Spur zu kommen.
3 unterschiedliche MVP-Definitionen
Die “MVP to earn”-Definition
Starten wir doch gleich mal mit der Bedeutung unserer schicken Abkürzung:
- Minimum (soweit eigentlich klar)
- Viable (schon etwas komplizierter)
- Product (sollte klar sein, möchte man meinen)
Das Minimale scheint unstrittig. Es geht darum, etwas Kleines zu produzieren. Nur: Die Botschaft kommt oft nicht an. Nicht das Budget oder der Aufwand sollen minimal sein, sondern das Produkt.
Und damit noch nicht genug. Die Viability gestaltet sich in der Übersetzung äußerst vieldeutig. Einige gültige Bedeutungen des Wörtchens sind:
- Durchführbar
- Brauchbar
- Gangbar
- Lebensfähig
- Wachstumsfähig
Ein ordentliches Spektrum an möglichen Bedeutungen. Was genau in unserem Kontext damit gemeint sein könnte und wie sich der Begriff definiert, wird klarer, wenn wir auf IDEO’s immer noch gültige und gute Definition der Schnittmenge an Eigenschaften blicken, die Produkte erfolgreich machen:
- Desirability - What’s the unique value proposition? Do people want this product or service? Does it make sense for them?
- Viability - Can we build a sustainable business? What has to be true for this business to work? What are the costs? How will you pay for it?
- Feasibility - Does this work? Is it functionally possible in the foreseeable future?
So interpretiert steht das viable also vor allem für Wirtschaftlichkeit und damit für die Dimension Business/Organisation im ebenso beliebten wie praktikablen Dreieck der Kräfteverhältnisse in der Entwicklung digitaler Produkte.
Das MVP sollte also nach dieser Interpretation in der Lage sein, wirtschaftlichen Erfolg zu erzielen. Damit deckt sich die Definition mit der von Frank Robinson, dem Vater des Begriffs MVP, der bereits in den frühen 00er Jahren postulierte:
"The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers."
Frank Robinson, Co-Founder und Präsent bei SyncDev
Ein solches MVP kann am Markt erfolgreich sein, ist aber in der agilen Denktradition, aus der Robinson entstammt, so gut priorisiert und auf sein Wesentliches reduziert, das tatsächlich nur das minimum an Funktionalität umgesetzt wurde, um diesen Erfolg zu gewährleisten. Allein schon um den Erfolg am Markt nicht zu gefährden, sollte in diesem Zusammenhang auch klar sein, dass es wenig Sinn macht, allzu große Kompromisse bei der Qualität einzugehen, sondern dass jede der Produkteigenschaften, die es in den Scope geschafft hat, für sich genommen qualitativ hochwertig sein muss.
Die erste iPhone Generation setzte auf Qualität und Schnelligkeit
Bestes Beispiel für diese teilweise sehr erfolgreiche Strategie: das erste iPhone. Vermeintliche Kernfunktionalitäten wie Copy/Paste von Texten oder die Möglichkeit, als Nutzer weitere Software zu installieren, wurden bewusst zum Launch ausgespart, um schneller am Markt zu sein.
Keinerlei Kompromisse wurden jedoch bei der Qualität hinsichtlich Nutzerführung, Nutzererlebnis, Skalierbarkeit, Performance etc. gemacht.
Aus meiner Sicht ist bei jeglicher Produktentwicklung, die auf einen schnellen Markteintritt abzielt, diese Strategie bis heute die erfolgreichste: Scope reduzieren, einige wenige Begeisterungsmerkmale hervorheben und auf gar keinen Fall Kompromisse bei der Qualität zulassen. Damit sind zumindest aus Produktentwicklungsperspektive die Grundlagen für einen erfolgreichen Markteintritt geschaffen.
Die „MVP to learn“-Definition
Soweit so super. Das Problem ist nur, dass es neben der Definition von Robinson, die auf IDEOs Überlegungen zu erfolgreichen Produkten fußt, eine zweite Definition gibt, die zwar auch erfolgreiche Produkte im Sinn hat, aber eine gänzlich andere Strategie verfolgt. So beschreibt Eric Ries zehn Jahre nach Robinson das MVP in seinem Buch „The Lean Startup“ als:
...that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Eric Ries, Autor von The Lean Startup
Es geht also nicht um Umsatz, sondern ums Lernen und möglichst schnelle Generieren von Insights zur eigenen Produktidee. Die Mittel dafür sind deutlich vielfältiger als die reine Entwicklung, denn es gilt die alte Weisheit, dass die teuerste Möglichkeit, eine Idee zu überprüfen, ist, sie umzusetzen. So lassen sich erste Annahmen mit Landingpage-MVPs überprüfen, um zu testen, ob überhaupt eine zahlungsbereite Zielgruppe vorhanden ist.
Dropbox testet das Marktpotenzial vor dem Livegang
Das klassische Beispiel in diesem Bereich ist dropbox, die mit ihrer Landingpage lange vor Fertigstellung des Produkts angefangen haben, E-Mails von potenziellen Kunden einzusammeln, um das Marktpotenzial für sich bewerten zu können.
Es geht Ries also weniger um die Viability (also die Wirtschaftlichkeit) als darum, Wege zu identifizieren, die Produktidee in allen drei Dimensionen (Viability, Feasability, Desireability) zu überprüfen und dadurch zu einer informierteren Strategie zu gelangen.
Hier gilt vor allem ein guter Umgang mit Daten und deren Belastbarkeit. Nur, wer gut und sauber Fragen definiert, erhebt und auswertet, wird auch zu tatsächlichen Erkenntnissen kommen. Und manchmal braucht eine Produktidee keinen erfolgreichen Landingpage-Test, sondern einfach nur ein bisschen Geduld, um zu reifen.
Nichtsdestotrotz: MVPs to learn sind im Idealfall viele kleine Schritte auf dem Weg zum ersten MVP to earn.
Die „MVP to burn“-Definition
Was es nur eben braucht, ist eine Klarheit aller Beteiligten, ob Teammitglieder oder Stakeholder, welche Ziele gerade mit welcher Methode verfolgt werden. Sonst wird weder to learn noch to earn gebaut, sondern – wie Rainer Sax am Rande der IA-Konferenz in Berlin mal so treffend anmerkte – to burn. Und das wäre dann ja doch besser zu vermeiden. Oder wir halten es mit Henrik Kniberg, der in einer Meditation über seine berühmte Illustration von Skateboards, Autos und Fahrrädern, mal sehr schön geschrieben hat:
Avoid the term MVP. Be more explicit about what you’re actually talking about. Earliest testable/usable/lovable is just one example, use whatever terms are least confusing to your stakeholders.
Henrik Kniberg, Owner & Agile Coach bei Crisp
Gemeinsame Definition vor Projektstart erarbeiten
Als kleinen Tipp aus der Praxis kann es helfen, Teammitglieder und Stakeholder im Rahmen z.B. eines Kick-Offs oder Auftragsklärungs-Workshops mit MVPs assoziierte Ziele in eine Rangreihenfolge bringen zu lassen, um zu klären, welche Art von MVP denn nun zu bauen ist. Das klappt mit Haftnotizen genauso so gut wie mit Remote-Tools wie Miro oder Mural.
Fazit
Mit einem gemeinsamen Verständnis und klaren Zielen klappt es dann auch mit bei der Entwicklung von Produkten. Zudem steigt damit die Wahrscheinlichkeit, dass MVPs einen Zweck verfolgen, anstatt zum Selbstzweck und damit zum sinnentleerten Business-Ritual zu werden. Insofern – viel Spaß und Erfolg bei der nächsten MVP-Entwicklung!
