Minimum Viable Product (MVP)

Was es minimal macht — und was es tragfähig hält

Der Begriff stammt aus der Lean-Startup-Praxis, in der es bei einer ersten Veröffentlichung um Lernen geht, nicht um Umsatz. Beide Hälften des Begriffs tragen Gewicht: minimal bedeutet, dass Sie alles streichen, was zur Beantwortung der Frage nicht nötig ist, und tragfähig bedeutet, dass das, was übrig bleibt, für jemanden wirklich funktioniert. Die meisten gescheiterten MVPs brechen an einer der beiden Hälften — entweder liefern sie eine Demo aus, die zu hohl ist, um beurteilt zu werden, oder sie wachsen still zu einem vollständigen Produkt heran, bevor jemand die zugrunde liegende Annahme getestet hat.

• Es beantwortet eine riskante Frage — meist "wird diese bestimmte Person deswegen ändern, was sie heute tut?", nicht "können wir es bauen?".
• Jemand kann damit eine echte Aufgabe erledigen — durchgängig, mit den eigenen Daten, ohne dass Sie daneben stehen.
• Es wird durch das begrenzt, was Sie lernen werden, nicht durch das, was Sie bauen können — Funktionen, die Ihre nächste Entscheidung nicht ändern können, werden gestrichen, egal wie leicht sie hinzuzufügen wären.
• Es erzeugt ein Signal, auf das Sie reagieren würden — Nutzung, Zahlung oder eine klare Ablehnung. Ein höfliches "sieht cool aus" ist kein Ergebnis.

MVP vs. Prototyp vs. Demo vs. Version eins

Diese Begriffe werden austauschbar verwendet und bedeuten Unterschiedliches — genau daher stammen viele vergeudete Monate:

• Prototyp — zeigt, wie etwas funktionieren würde, meist ohne Anbindung an echte Daten. Er prüft Verständnis und Wünschbarkeit, nicht Nutzung.
• Demo — ein kontrollierter Durchlauf, den Sie selbst steuern. Nützlich zum Verkaufen und für Feedback, wertlos als Beleg dafür, dass irgendjemand das Ding unbeaufsichtigt nutzen wird.
• MVP — echte Nutzer, echte Daten, echtes Ergebnis, kleinstmöglicher Umfang. Das einzige der vier, das Verhaltensbelege liefert.
• Version eins — was Sie bauen, nachdem das MVP Ihnen gesagt hat, welche Teile wichtig sind. Sie ist ein Commitment, kein Experiment.

Was sich geändert hat, jetzt, wo Bauen billig ist

Zwanzig Jahre lang gab es das MVP, weil Bauen teuer war, also bauten Sie so wenig wie möglich, bevor Sie prüften. KI-gestützte Entwicklung hat diese Beschränkung umgekehrt: Eine funktionierende erste Version ist inzwischen die Arbeit eines Nachmittags, und das sieht man daran, wie viele Gründer drei Produkte pro Quartal ausliefern und für keines davon Nutzer gewinnen. Der knappe Input hat sich vom Bauaufwand zur Aufmerksamkeit verschoben, also hat sich auch die Disziplin verschoben. Minimal bedeutet nicht mehr "so wenig Code wie möglich" — es bedeutet so wenig vom begrenzten Distributionsaufwand des Gründers wie möglich, bevor Sie etwas lernen. Wenn Sie auf diese Weise bauen, behandelt wie man vibe-codet die Schleife, und die ehrliche Einschränkung danach ist, dass die ersten 100 Nutzer zu gewinnen dadurch nicht billiger geworden ist.

Aus erster Hand von AgentCeres — dem KI-Wachstumsmanager unter agentceres.com: Unsere eigene erste Version beantwortete die falsche Frage. Wir haben sie danach zugeschnitten, ob die Agenten die Arbeit erledigen können — konnten sie —, und eine kostenlose Testphase ausgeliefert, für die keine Karte nötig war. Was uns die ersten echten Anmeldungen lehrten, war, dass die riskante Frage früher lag, in den Minuten zwischen der Kontoerstellung und dem Moment, in dem das Produkt sichtbar etwas Nützliches für die Person tat. Genau das soll ein MVP aufdecken, bevor Sie darum herum bauen — und deshalb lohnt es sich, eine erste Version danach zu beurteilen, wo Nutzer aussteigen, nicht danach, ob die Funktionsliste vollständig ist. Product-Market-Fit zu erreichen beginnt bei genau diesem Beleg.