METHODE

MVP

Minimum Viable Product

Die kleinste Produktversion, die feststellen lässt, ob die Idee falsch ist. Nicht die kleinste shippbare Version, die kleinste lehrreiche Version.

Zuletzt geprüft: 2026-05-24 vonKevin Riedl wiki ↗

Das Wort „Viable" trägt die Last in MVP, und fast jeder versteht es falsch. Viable heißt nicht „abgespeckte Variante des späteren Produkts". Viable heißt „ausreichend, um die Hypothese zu testen, ob dieses Produkt gebaut werden sollte". Eine Landing Page mit Warteliste kann ein MVP sein. Ein lauffähiges Produkt mit drei Features kann ein schlechteres MVP sein als die Landing Page.

Häufigster Fehler: das MVP bauen, das man sich vor sechs Monaten vorgestellt hat, statt jenes MVP, das die diese-Woche-unsicherste Annahme testet. Jede Woche ändert sich, welche Annahme zu testen wäre. Die meisten MVPs sind veraltet, bevor sie shippen.

Wavects Discovery-Phase existiert auch, um das zu beheben. Vor dem MVP-Scope benennen wir die Hypothese, die das MVP testen soll. Lautet die Hypothese „Nutzer wollen Feature X", ist das MVP nicht ein poliertes Feature X, sondern der billigste Weg, das herauszufinden."

// FAQ

Häufige Fragen

Häufige Fragen

4 bis 8 Wochen, wenn die Hypothese scharf ist. Über 12 Wochen ist es kein MVP mehr, sondern ein V1 mit MVP-Marketing. Wenn ein Anbieter sechs Monate für ein MVP veranschlagt, ist die Hypothese unscharf oder der Scope ist es.
Genau dafür ist es da. Ein MVP, das die Hypothese widerlegt, hat seinen Job gemacht und 80 Prozent des Build-Budgets eingespart. „Erfolg" des MVP ist Lernen, nicht Umsatz.
So wenig wie möglich, ohne dass Nutzer das MVP wegen UX vorzeitig verlassen. Wer hochpoliertes Design vor PMF baut, validiert Design statt Produkt. Wenn die Hypothese „der Nutzer kauft" ist, muss der Checkout funktionieren, der Onboarding-Flow nicht perfekt sein.