MVP steht für Minimum Viable Product. Gemeint ist eine bewusst begrenzte, aber nutzbare Produktversion, mit der zentrale Annahmen über Problem, Nutzen, Nutzerverhalten oder Geschäftsmodell früh mit realen Nutzern überprüft werden können. Ein MVP ist damit ein Lerninstrument und nicht einfach eine unfertige Billigversion eines Produkts.
Was ist ein MVP?
Der Begriff Minimum Viable Product wird häufig missverstanden als „erste Version mit möglichst wenig Funktionen“. Der eigentliche Wert liegt jedoch im Lernen: Welche zentrale Annahme soll mit einer real nutzbaren Version überprüft werden?
Ein MVP sollte deshalb nicht nur minimal sein, sondern viable – also ausreichend nutzbar, um aus realem Verhalten oder Feedback eine sinnvolle Erkenntnis zu gewinnen.
Fachliche Einordnung: MVP in Software-Startups
Die wissenschaftliche Literatur zeigt, dass MVPs in der Praxis unterschiedliche Rollen einnehmen. Duc und Abrahamsson untersuchten frühe Software-Startups und beschrieben MVPs unter anderem als Prototyping- und Boundary-Spanning-Artefakte zwischen verschiedenen Stakeholdern.
Weitere empirische Arbeiten zu Software-Startups zeigen, dass MVP-Entwicklung stark von Kontext, Team und Lernlogik geprägt ist. Damit gibt es nicht die eine universelle MVP-Ausprägung.
MVP, Prototyp und Proof of Concept
Die Begriffe werden häufig vermischt:
- Proof of Concept (PoC): prüft primär technische Machbarkeit.
- Prototyp: kann Nutzung, Interaktion oder Design simulieren und muss nicht produktiv betrieben werden.
- MVP: soll eine zentrale Produkt- oder Nutzungsannahme unter realistischeren Bedingungen testen.
Ein klickbarer Design-Prototyp kann für eine konkrete Lernfrage sogar geeigneter sein als ein programmiertes MVP. Die Form sollte der Hypothese folgen.
Wie beginnt man mit einem guten MVP?
Nicht mit einer Featureliste, sondern mit einer Annahme:
„Servicekunden laden Prüfberichte selbstständig über ein Portal herunter, wenn die Dokumente dort zuverlässig nach Auftrag strukturiert verfügbar sind.“
Daraus lässt sich ableiten, welche minimale Funktion tatsächlich erforderlich ist. Funktionen wie Chat, individuelle Dashboards oder komplexe Benachrichtigungen sind für diese Hypothese zunächst möglicherweise irrelevant.
Was bedeutet „Minimum“?
Minimum ist kontextabhängig. Bei einer internen Anwendung kann ein begrenzter Nutzerkreis und ein manueller Hintergrundprozess akzeptabel sein. In einem regulierten oder sicherheitskritischen Umfeld dürfen Datenschutz, Zugriffsschutz oder Prüfpflichten dagegen nicht als „spätere Extras“ behandelt werden.
Ein MVP darf Funktionen reduzieren, aber nicht notwendige Qualitäts- und Sicherheitsanforderungen ignorieren.
Der häufigste Fehler: MVP als billige Version
Wenn kein Lernziel definiert ist, entsteht leicht ein schlecht ausgestattetes Produkt statt eines Experiments. Dann werden Nutzer mit geringer Qualität konfrontiert, ohne dass klar ist, welche Hypothese eigentlich geprüft wird.
Ein weiterer Fehler ist Feature Creep: Aus Angst, die erste Version sei „zu klein“, werden immer mehr Anforderungen aufgenommen. Dadurch verschiebt sich Feedback nach hinten und der MVP-Gedanke verliert seinen Zweck.
MVP in etablierten Unternehmen
Auch außerhalb von Startups kann der Ansatz sinnvoll sein. Eine interne Anwendung kann zunächst nur einen klaren Kernprozess für ein Team abbilden. Nach realer Nutzung werden Rollen, Ausnahmen und Erweiterungen priorisiert.
Der Begriff sollte allerdings nicht als Ausrede für fehlendes Requirements Engineering dienen. Gerade die Hypothese, Systemgrenze und Erfolgskriterien müssen klar sein.
Wie misst man ein MVP?
Die Metrik folgt der Hypothese. Beispiele:
- Nutzer schließen einen Prozess ohne Unterstützung ab.
- Bearbeitungszeit sinkt.
- bestimmte Funktion wird wiederholt genutzt.
- Kunden sind bereit, für den Nutzen zu zahlen.
- eine technische Architektur erfüllt einen definierten Durchsatz.
Downloads oder Logins allein sind häufig zu schwach, wenn sie die eigentliche Annahme nicht beantworten.
Das MVP braucht eine Abbruch- oder Lernentscheidung
Vor dem Test sollte klar sein, welche Beobachtung zu welcher Entscheidung führt. Sonst wird selbst ein schwaches Ergebnis leicht nachträglich positiv interpretiert. Ein MVP ist wertvoll, wenn es eine Entscheidung ermöglicht: weiter investieren, Hypothese verändern, Zielgruppe neu bewerten oder Ansatz beenden.
Diese Entscheidungslogik trennt ein experimentelles MVP von einer bloßen „Version 0.1“, die unabhängig vom Feedback ohnehin weitergebaut wird.
Fazit
Ein MVP ist ein Werkzeug zum Lernen unter Unsicherheit. Eine gute MVP-Strategie reduziert nicht wahllos Funktionen, sondern fokussiert auf die kleinste belastbare Umsetzung einer wichtigen Hypothese. Für Softwareprojekte kann das Time-to-Value verkürzen und Fehlentwicklungen früher sichtbar machen.
Passende Leistungen von Wils Solutions
Häufige Fragen
Wofür steht MVP?
MVP steht für Minimum Viable Product.
Ist ein MVP einfach eine unfertige Software?
Nein. Ein MVP sollte bewusst begrenzt, aber ausreichend nutzbar sein, um eine konkrete Annahme mit realen Nutzern oder im realen Prozess zu testen.
Was ist der Unterschied zwischen MVP und Prototyp?
Ein Prototyp kann eine Idee simulieren. Ein MVP zielt typischerweise darauf, eine zentrale Produkt- oder Nutzungshypothese unter realistischeren Bedingungen zu überprüfen.
Braucht ein MVP Requirements Engineering?
Ja, zumindest in fokussierter Form. Lernziel, Nutzer, Kernprozess, Risiken und Erfolgskriterien müssen klar sein.