MVP. Drei Buchstaben, die heute fast jeder kennt – und fast niemand gleich versteht.
In Projekten höre ich den Begriff täglich. Das erste Release: MVP. Ein neues Feature: MVP. Ein technischer Durchstich, der zeigt, dass zwei Systeme miteinander reden können: auch MVP. Und im Enterprise-Umfeld manchmal noch dies: ein System, das Daten an ein bestehendes Tool liefert, das seit Jahren auf dem Markt ist. MVP.
Irgendwo auf dem Weg hat das «V» seine Bedeutung verloren.
Minimum Viable Product. Das «Minimum» ist verständlich. Das «Product» auch. Aber «Viable»?
Viable bedeutet lebensfähig. Ein Produkt ist lebensfähig, wenn es ein echtes Problem löst – für echte Nutzer, unter echten Bedingungen. Nicht wenn es technisch funktioniert. Nicht wenn es die Anforderungen des Backlogs erfüllt.
Und auch «Minimum» wird oft falsch verstanden. Es bedeutet nicht «möglichst wenig bauen», sondern «das Kleinste, das noch lebensfähig ist». Das ist ein grosser Unterschied.
Ein MVP entsteht deshalb nicht dadurch, dass man aus einer geplanten Vollversion ein paar Features streicht. So entstehen halbe Produkte: Sie sehen reduziert aus, funktionieren aber nicht wirklich als eigenständige Lösung. Nutzer stossen auf Lücken, umgehen das System oder bewerten eine Version, die nie bewusst als funktionierendes Produkt konzipiert wurde. Wer nur Features weglässt, testet nicht die Produktidee. Er testet die Lücken einer unvollständigen Version.
In der Praxis wird ein MVP oft zur ersten lieferbaren Version. Schlank, funktional, pünktlich. Gelernt wird vor allem, ob die Technik hält: Architektur, Schnittstellen, Deployment.
Das kann ein legitimes Lernziel sein. Technische Machbarkeit kann Teil eines MVP sein – aber nur, wenn sie eine zentrale Bedingung für die Lebensfähigkeit des Produkts ist. Wenn ein Produkt nur dann wirkt, wenn es sich sauber in ein Legacy-System integriert, dann ist dieser Nachweis wichtig. Aber die technische Integration allein macht ein Artefakt nicht zum MVP. Entscheidend bleibt die Frage: Welche kritische Annahme zur Lebensfähigkeit wird geprüft?
Diese Frage wird selten gestellt. In klassischen Projektorganisationen liegt der Grund auf der Hand: Der MVP wird nicht danach geschnitten, welche Annahme geprüft werden muss. Er wird danach geschnitten, was mit Budget, Zeit und vorhandenen Ressourcen noch lieferbar ist. Das ist verständlich – aber es ist kein MVP. Es ist ein Projektpaket mit gutem Gewissen.
Im Enterprise-Umfeld trifft ein Produkt nie auf einen leeren Raum. Es trifft auf bestehende Prozesse, Datenflüsse, Rollen, Fachsysteme und eingespielte Umgehungslösungen.
Nehmen wir ein Tool zur Auftragserfassung. Für die Person, die den Auftrag erfasst, kann eine reduzierte Version gut funktionieren: weniger Felder, weniger Komplexität, schnellerer Einstieg. Aber die erfassten Daten werden später woanders gebraucht – im Service, in der Planung, in der Abrechnung. Werden im MVP nur vereinfachte oder unvollständige Daten erfasst, kommen sie auch nur reduziert am Zielort an. Das Problem entsteht dann nicht im Eingabetool, sondern dort, wo mit den Daten weitergearbeitet werden muss.
Das hat wenig mit Nutzerakzeptanz zu tun. Es zeigt, dass die Lebensfähigkeit eines Enterprise-Produkts nicht an der ersten Interaktion hängt, sondern am ganzen Arbeitsfluss.
Ein Enterprise-MVP muss deshalb mehr leisten als eine reduzierte Oberfläche. Er muss als eigene, funktionierende Produktversion konzipiert werden – eine bewusst geschnittene Lösung, die mit weniger Funktionen trotzdem einen vollständigen Ablauf ermöglicht. Das kann über eine engere Zielgruppe gehen, über einen kleineren Prozess oder über bewusst gesetzte manuelle Zwischenschritte. Aber nicht dadurch, dass man einfach etwas nicht baut.
Ein MVP ist ein Lernwerkzeug. Er soll zeigen, ob eine Annahme stimmt. Ob ein Problem wirklich so existiert, wie man dachte. Ob die Lösung in der Praxis wirkt.
Bevor etwas MVP genannt wird, müssten drei Dinge klar sein:
Welche kritische Annahme testen wir? Nicht was bauen wir, sondern was wollen wir herausfinden – und warum ist das für die Lebensfähigkeit des Produkts entscheidend?
Woran erkennen wir, dass das Produkt unter realen Bedingungen wirkt? Nicht ob es läuft, sondern ob es im echten Arbeitsfluss einen Unterschied macht – messbar, nachweisbar.
Was entscheiden wir nach dem Test? Weiterbauen, anpassen oder stoppen. Ein MVP ohne diese Frage ist kein Lernwerkzeug, sondern ein Release mit gutem Gewissen. Und ohne echte Entscheidungsoption am Ende ist jedes Lernen folgenlos.
Dazu gehört auch eine Entwicklungsperspektive: keine starre Roadmap, die nur abgearbeitet wird, sondern eine Vorstellung davon, wie aus dem MVP ein tragfähiges Produkt werden kann. Welche Funktionen, Prozesse oder Integrationen relevant werden, wenn sich die Annahmen bestätigen. Welche Lücken bewusst akzeptiert sind – und welche das Ergebnis verfälschen würden. Fehlt diese Perspektive, wird der MVP zur abgespeckten Lieferetappe: zuerst weniger Features, später mehr, mit etwas Glück ein Pilot dazwischen.
Das alles setzt voraus, dass jemand diese Fragen vor der ersten Umsetzung stellt – und dass die Antworten den Scope beeinflussen dürfen. Beides ist im Enterprise-Kontext alles andere als selbstverständlich.
Wenn alles MVP heisst, lernt niemand mehr etwas.
Wenn der MVP einfach der erste Release ist, ist das Lernen dem Zufall überlassen. Man bekommt Feedback – irgendwann, irgendwie, von irgendwem. Oder das Produkt läuft still vor sich hin, wird genutzt, weil der Prozess es verlangt, und niemand stellt die Frage, ob es das Problem löst, das es lösen sollte.
Solange MVP «erster Release» bedeutet, bauen wir. Wir liefern. Wir nennen es MVP.
Und lernen fast nichts – ausser dass wir geliefert haben.