Management-Zusammenfassung dieses Beitrags:
Das Minimum Viable Product (MVP, englisch Minimum Viable Product) wird im Systems oder → Software Engineering und in der → Softwareentwicklung eingesetzt, um vor dem eigentlichen Produkt ein Vorprodukt zu erstellen, welches aber bereits Nutzen generiert.
In diesem Beitrag wird eine Beschreibung des Minimum Viable Products geliefert.
Das Minimum Viable Product (MVP, englisch Minimum Viable Product; ältere Bezeichnung auch: Minimal Viable Product) dient der Erstellung von “marktfähigen” Produkten, die in kurzer Zeit hergestellt werden können, aber dennoch Wert für den Kunden bringen. Dies dient dazu, das Risiko einer Entwicklung an dem Kunden(nutzen) vorbei zu reduzieren.
1. Einleitung und Grundlagen
1.1 Definitionen
Das → PMI definiert /PBG21‑d/:
“Minimum Viable Product / Minimum Viable Product (MVP). Ein Konzept zur Festlegung von Inhalt und Umfang der ersten Auslieferung einer Lösung an Kunden, indem es die Mindestanzahl an Features oder Mindestanforderungen identifiziert, die einen Wert darstellt.”
In der Wikipedia steht zum MVP /#Wiki-Minimum-Viable-Product/:
“Ein Minimum Viable Product (MVP), wörtlich ein “minimal brauchbares oder existenzfähiges Produkt”, ist die erste minimal funktionsfähige Iteration eines Produkts, die dazu dient, möglichst schnell aus Nutzerfeedback zu lernen und so Fehlentwicklungen an den Anforderungen der Nutzer vorbei zu verhindern. Wichtig in diesem Zusammenhang ist, dass die Iteration einen ersten “brauchbaren” Nutzen bietet, sodass die Nutzer das Produkt auch einsetzen.”
Bei Pfeifer wird definiert /Pfeifer21/:
“Ein Minimum Viable Product (MVP), übersetzbar mit “minimal (über)lebensfähiges Produkt”, ist ein Produkt, das im Rahmen seiner Entwicklung gerade den Reifegrad überschritten hat, die für den Nutzer relevante(n) Basisfunktionalität(en) zu erfüllen.”
1.2 Charakterisierung
In Abbildung 1 ist eine Charakterisierung des Minimum Viable Products dargestellt.
Abbildung 1: Charakterisierung des Minimum Viable Products
2. Vom Minimum Viable Product zum fertigen Gesamtprodukt
Das Minimum Viable Product liefert zwar — per Definition — Nutzen, ist aber noch kein fertiges Gesamtprodukt. In der Regel fehlen noch Funktionen / Features, die dann dem MVP hinzugefügt werden. Diese müssen dann nach und nach hinzugefügt werden. Bei der Planung des MVPs reicht es aber zunächst aus, die notwendigen Features zu erfassen und den einzelnen Releases zuzuordnen — es entsteht eine Art → Releaseplan (Abbildung 2).
Abbildung 2: Das Minimum Viable Product und der Releaseplan
In der Nach-MVP-Phase können dann die weiteren Features dem MVP hinzugefügt werden (Abbildung 3), sodass das komplette Produkt entsteht.
Abbildung 3: Das Minimum Viable Product und der Releaseplan nach MVP-Release
3. Anmerkungen zum Minimum Viable Product
Das Minimum Viable Product wird herangezogen, um schnell zu einem vorzeigbaren Ergebnis zu gelangen. Dabei wird häufig nur auf das Ergebnis, nicht aber auf das Vorgehen zum Ergebnis geachtet; in der Folge verkommt das MVP zu einem “Marketingbegriff”.
Grundsätzliche Anmerkungen zu MVP:
- Vielfach werden Prototypen anstatt MVPs eingesetzt. Dies ist durchaus sinnvoll, denn Prototypen können marktfähige Eigenschaften besitzen. Aber: Wegwerf-Prototypen können nicht als MVP verwendet werden
- Auf die Überprüfung des MVPs nach “Freigabe” wird in der Praxis häufig verzichtet; hierdurch wird der Nutzen des Vorgehens stark verringert, denn es werden keine Ableitungen für das weitere Vorgehen vorgenommen, die für weitere Projekte oder MVPs herangezogen werden könnten
- Mit dem MVP müssen unbedingt auch die Entwicklungsprozesse und ‑tools festgelegt werden, denn nach dem MVP geht es mit der Entwicklung des Voll-Produkts weiter, es werden dann weitere Features hinzugefügt. Wenn dann noch größere Änderungen an dem Entwicklungsrahmen vorgenommen werden müssen, wird die Entwicklung (unnötig) risikobehaftet
- Der Umfang des MVPs muss vorab festgelegt werden, ansonsten liegen die → Ziele und das Vorgehen nicht fest; das MVP verkommt zum “Moving Target”
- Wenn das MVP in nur einem Release oder sehr wenigen Sprints erreicht werden kann, wird in der agilen Welt auch von Spikes gesprochen
Folgende Fehlannahmen oder fehlerhafte Vorgehensweisen im Zusammenhang mit MVPs sind in der Praxis häufig zu finden:
- “Ein MVP muss vorab nicht geplant werden” — diese Aussage ist falsch. Der Umfang eines MVP sollte unbedingt vorab festgelegt werden. Das MVP ist nicht der “Nachfolger der Zuruf-Entwicklung”. Beim MVP werden häufig Releases verwendet, die eine (abgeschlossene) Iteration enthalten
- “Das Entwickeln mit einen MVP reduziert die Kosten” — diese Aussage stimmt so nicht. Wenn das Entwicklungsziel und der Weg dahin klar ist, so kostet der Zwischenschritt über das MVP zusätzlichen → Aufwand, es werden die Kosten erhöht
- “Wir erstellen erst den MVP und schauen dann weiter” — diese Aussage ist kurios. Man sollte vorab wissen, wie man aus dem MVP ein größeres Produkt erstellt, denn ansonsten droht die Gefahr, nur einen “Wegwerf-Prototypen” zu entwickeln
Wenn ein Me-Too-Produkt (Nachahmerprodukt) oder ein Nachfolgeprodukt erstellt werden soll, so muss genau überlegt werden, was ein MVP sein könnte: In der Regel muss dann zumindest der Produktumfang des Konkurrenz- oder Vorgängerprodukts erreicht werden. Ansonsten wäre ein Mehrwert für den potenziellen Kunden nicht gegeben.
Weiterhin muss das eigene Vertriebs- und Marketingumfeld bei der Erstellung berücksichtigt oder eingebunden werden. Ansonsten können beispielsweise folgende vertriebliche Probleme auftreten:
- Der Vertrieb / das Marketing hat Kunden eine neue Version des Produkts mit gewissen Features zu einem vereinbarten → Zeitpunkt versprochen. Dies ist der Produktentwicklung aber nicht bekannt, dass MVP berücksichtigt diese Features nicht, der vereinbarte Zeitpunkt verstreicht und die Kunden erhalten die vereinbarten Features nicht
- Es wird das MVP nach außen den Kunden gegenüber kommuniziert — oder sogar beim Produkt selbst vermerkt, dass es sich um ein MVP handelt. Die Kunden möchten aber kein “Vorab-Produkt”, da sie wissen, dass ein “Voll-Produkt” noch zeitnah kommen wird
Literatur
- /PBG17/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sixth Edition 2017, ISBN 978–1‑62825–184‑5
- /PBG17‑d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sechste Ausgabe 2017, ISBN 978–1‑62825–188‑3
- /Pfeifer21/ Tilo Pfeifer, Robert Schmitt: Masing Handbuch → Qualitätsmanagement, Hanser, München 7. Auflage 2021, ISBN 978–3‑446–46230‑4
- /Ries11/ Eric Ries: The → Lean Startup. How Constant Innovation Creates Radically Successful Businesses, Crown Business, New York 2011, ISBN 978–0‑307–88789‑4
- /Ries12/ Eric Ries: Lean Startup: Schnell, risikolos und erfolgreich Unternehmen gründen, Redline, München 2012, ISBN 978–3‑86881–333‑3
Weblinks
- /#Wiki-Minimum-Viable-Product/ Minimum Viable Product in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 18.11.2023 © Peterjohann Consulting, 2005–2024
