Wer für eine neue Software ein MVP definieren will, muss zuerst eine Frage benennen, die sich mit der ersten Version beantworten lässt. Genau diese Frage fehlt in den meisten Scoping-Workshops, die stattdessen mit einer Featureliste beginnen. Der Unternehmer und Autor Eric Ries hat den Begriff in seinem Buch The Lean Startup geprägt und das MVP als die Version definiert, die mit minimalem Aufwand maximales validiertes Lernen ermöglicht. Minimal bezieht sich dabei auf den Umfang der Funktionen, nicht auf die Qualität der Umsetzung.
Ein MVP definieren heißt, die Lernfrage vor die Featureliste zu setzen. Der Umfang der ersten Version umfasst genau das, was nötig ist, um diese eine Frage an echten Nutzern zu beantworten. Minimal bezieht sich auf die Zahl der Funktionen, nicht auf Qualität, Sicherheit oder Compliance. Fehlt die Lernfrage, entsteht kein MVP, sondern ein verkleinertes Endprodukt.
Was ein MVP wirklich ist
Validiertes Lernen bezieht sich bei Ries auf die Reaktion echter Nutzer auf ein echtes Produkt. Eine Meinung aus dem eigenen Team zählt in diesem Sinn nicht als Validierung. Damit lässt sich das MVP von zwei Nachbarbegriffen abgrenzen, die in Projekten gern durcheinandergeraten. Ein Prototyp ist wegwerfbar und hat keine echten Nutzer, er dient der internen Validierung einer Idee oder einem Kundengespräch. Ein MVP ist bereits ein echtes Produkt mit echten Nutzern, auch wenn es noch klein ist. Eine Beta-Version wiederum ist nahezu fertig und dient vor allem dem letzten Schliff vor dem breiten Rollout.
| Form | Echte Nutzer | Zweck |
|---|---|---|
| Prototyp | nein | Eine Idee intern oder im Kundengespräch prüfen, danach wegwerfbar |
| MVP | ja | Eine Lernfrage mit dem kleinsten tragfähigen Umfang beantworten |
| Beta-Version | ja | Letzter Schliff vor dem breiten Rollout |
Ein Beispiel aus der Praxis zeigt den Unterschied. Ein Handelsunternehmen, das prüfen will, ob Außendienstmitarbeiter ein digitales Bestellformular überhaupt nutzen würden, braucht dafür keine vollständige Anbindung an das Warenwirtschaftssystem. Ein Formular, das Bestellungen zunächst per E-Mail an den Innendienst weiterleitet, reicht aus, um die eigentliche Frage zu beantworten. Nimmt die Zielgruppe das Werkzeug an, folgt die Anbindung an die Bestandssysteme erst danach.
MVP definieren: der Ein-Satz-Test fürs Scoping
Ein praktischer Test aus der Scoping-Praxis hilft bei der Einordnung. Lässt sich das Vorhaben als Satz formulieren, der mit „Wir bauen das, um herauszufinden, ob …“ beginnt, handelt es sich um ein MVP. Fehlt eine solche Lernfrage, handelt es sich meist nur um ein verkleinertes Endprodukt mit weniger Funktionen. Nach einer Einordnung von Refact aus dem Jahr 2026 bedeutet Minimum den kleinsten Umfang, der eine Frage beantwortet, nicht den billigsten Umfang. Sicherheits- und Compliance-Anforderungen bleiben laut Refact (2026) auch im MVP bestehen. Sie gehören nicht zu den Dingen, die sich beim Scoping herauskürzen lassen.
Die häufigsten Scoping-Fehler
Nach einer Analyse von Identify Digital aus dem Jahr 2026 wiederholen sich beim Scoping vor allem drei Fehler. Der erste ist eine fehlende Lernfrage, das Team startet mit einer Featureliste statt mit einer Hypothese, die sich widerlegen ließe. Der zweite ist eine Featureliste ohne echte Priorisierung, bei der am Ende doch fast alles als „must have“ markiert wird. Der dritte ist Planung für morgige statt für heutige Nutzer, etwa eine Architektur, die für 100.000 Nutzer ausgelegt wird, obwohl die ersten 50 Testnutzer noch fehlen.
Fehlende Lernfrage, Featureliste ohne echte Priorisierung und Planung für morgige statt heutige Nutzer wiederholen sich beim Zuschnitt der ersten Version.
Identify Digital, 2026
Kleine Teams neigen zum ersten Fehler, weil sich eine Lernfrage schwerer formulieren lässt als eine Featureliste. Größere Organisationen neigen eher zum dritten, weil dort meist schon eine Vorstellung vom Endprodukt existiert, bevor der erste Nutzer etwas gesehen hat. Alle drei Fehler wirken ähnlich. Das MVP wächst, bevor die erste Zeile Code geschrieben ist, und verliert dabei die Geschwindigkeit, die den Ansatz ursprünglich attraktiv gemacht hat.
Wo der MVP-Ansatz nicht passt
Der Ansatz setzt voraus, dass sich ein unfertiges Produkt echten Nutzern zumuten lässt und dass ein Scheitern im kleinen Rahmen erlaubt ist. Bei Software mit hohen Zulassungshürden, etwa in der Medizintechnik oder im sicherheitsrelevanten Anlagenbau, greift diese Voraussetzung nicht. Dort lässt sich ein unfertiges Produkt nicht einfach an echte Anwender geben, weil Zulassung, Dokumentation und Haftung von Anfang an feststehen müssen. In solchen Fällen verschiebt sich das, was validiert werden kann, von der Software selbst auf einzelne Komponenten, etwa eine Bedienoberfläche im Testlabor statt am fertigen Gerät. Ein Ausweg ist häufig ein zweistufiges Vorgehen. Die riskanten fachlichen Annahmen werden in einem geschützten Rahmen getestet, etwa mit einem eingeschränkten Nutzerkreis unter fachlicher Aufsicht, während die formalen Anforderungen von Anfang an vollständig mitlaufen.
Nach dem MVP: Vertrag und nächste Schritte
Wer ein MVP definieren konnte, steht kurz darauf vor der nächsten Frage. Wie wird die weitere Entwicklung vertraglich geregelt? Nach einem erfolgreichen MVP ändert sich oft der Charakter der Zusammenarbeit, von einer explorativen Phase hin zu einem Projekt mit klareren Anforderungen. Welches „Vertragsmodell für die jeweilige Phase passt“, hängt vom Grad der Unsicherheit ab, der nach einem erfolgreichen MVP meist schon deutlich kleiner ist als zu Beginn. Wie sich diese klareren Anforderungen strukturiert festhalten lassen, zeigt der Beitrag Pflichtenheft schreiben: Anleitung mit Vorlage.
Der Ansatz lebt davon, dass ein unfertiges Produkt echten Nutzern zumutbar ist. In der Medizintechnik oder im sicherheitsrelevanten Anlagenbau gilt das nicht, dort stehen Zulassung, Dokumentation und Haftung von Anfang an fest. Auch die Abgrenzung zwischen Prototyp, MVP und Beta ist keine feste Norm, sondern eine Verabredung im Projekt. Wer sie nicht schriftlich festhält, streitet später über Erwartungen statt über Ergebnisse.
Die eigene Lernfrage auf den Punkt bringen
Ob sich ein Vorhaben wirklich als Satz mit „Wir bauen das, um herauszufinden, ob …“ formulieren lässt, zeigt sich oft erst im Austausch mit jemandem außerhalb des eigenen Teams. Ein erstes Gespräch geht den geplanten Funktionsumfang anhand dieses Tests durch.
Häufige Fragen
Wie lange dauert ein MVP?
Eine pauschale Dauer gibt es nicht, weil sie von der Lernfrage abhängt und nicht von einem Kalenderziel. In der Praxis bewegen sich technisch einfache MVPs oft im Bereich von sechs bis zwölf Wochen, während Vorhaben mit Anbindung an Bestandssysteme wie ein ERP deutlich länger brauchen. Ein Warnzeichen ist, wenn ein MVP länger dauert als die geplante Lebensdauer der Frage, die es beantworten soll. Dann hat sich der Umfang meist unbemerkt vergrößert.
Was gehört auf keinen Fall hinein?
Alles, was die Lernfrage nicht direkt beantwortet, gehört zunächst nicht hinein, auch wenn es später gebraucht wird. Dazu zählen typischerweise Mehrsprachigkeit für Märkte, die noch nicht bedient werden, ein feingliedriges Rollen- und Rechtekonzept für Nutzerzahlen, die noch nicht erreicht sind, oder Reporting-Funktionen, die in der Testphase niemand anschaut. Ausgenommen sind, wie beschrieben, Sicherheits- und Compliance-Anforderungen, die von Anfang an gelten.
Wie geht es nach dem MVP weiter?
Nach dem MVP folgt normalerweise eine Auswertungsphase, in der sich die Lernfrage anhand echter Nutzungsdaten beantworten lässt, nicht anhand von Meinungen aus dem Vertrieb. Bestätigt sich die Annahme, wächst das Produkt in Richtung Beta und danach in Richtung eines vollständigen Systems. Bestätigt sie sich nicht, hat das MVP trotzdem seinen Zweck erfüllt. Genau für dieses Ergebnis wurde die erste Version gebaut.
Bei torck übernehmen die Entwicklungsteams in Maxhütte-Haidhof, Wien und Rabat regelmäßig die Aufgabe, ein MVP so zuzuschneiden, dass die Lernfrage im Mittelpunkt bleibt und nicht die Wunschliste aus dem Fachbereich. Verträge laufen über die deutsche torck GmbH, was gerade bei einem ersten gemeinsamen Projekt ohne lange Vorgeschichte Sicherheit gibt. Weil torck Individualsoftware für Industrie und Handel baut, kennen die Teams die Fallstricke, wenn ein MVP später an ERP- oder Maschinendaten andocken muss. Ein Erstgespräch klärt, welcher Umfang für die erste Version realistisch ist.
German 
English 
French