MVP (Minimum Viable Product)

Ein MVP (Minimum Viable Product) ist ein Produkt mit dem minimal notwendigen Feature-Set, um das Wertversprechen zu validieren und echtes Nutzer-Feedback zu sammeln. Die Philosophie: Statt Monate in die Entwicklung eines "perfekten" Produkts zu investieren, wird eine funktionsfähige Basisversion in Wochen launched. Nutzer-Feedback bestimmt dann die weitere Entwicklung.

Der MVP-Ansatz ist besonders im Startup-Kontext wertvoll, findet aber auch bei etablierten Unternehmen Anwendung. Bekannte Beispiele: Dropbox startete mit einem simplen Demo-Video als MVP, Airbnb begann mit einer einfachen Website für Airmatratzen-Vermietung. Der Fokus liegt auf Lernen und Validieren, nicht auf Perfektion. Ein MVP sollte das Kernproblem lösen, aber nicht jedes "nice-to-have" Feature enthalten.

Die Entwicklung eines MVPs dauert typischerweise 4-8 Wochen und kostet 10-30% eines vollständigen Produkts. Der ROI ist messbar: 60% der Features in Software werden nie oder kaum genutzt (Standish Group). Ein MVP verhindert Ressourcenverschwendung auf unwichtige Features. Nach Launch wird basierend auf realen Nutzungsdaten iteriert und erweitert.

Entscheidend ist die Betonung beider Wörter: minimum UND viable. Ein MVP muss trotz reduziertem Umfang echten Nutzen stiften und ein reales Problem lösen - eine bloße Ansammlung halbfertiger Funktionen ist kein tragfähiges MVP. Am Anfang steht deshalb eine klare Hypothese samt messbarer Erfolgskriterien (etwa Anmelde-, Kauf- oder Wiederkehrrate), die der Build-Measure-Learn-Zyklus aus dem Lean-Startup-Ansatz überprüft.

Nicht jedes MVP muss voll programmiert sein: Beim Concierge- oder Wizard-of-Oz-MVP wird die Leistung zunächst manuell im Hintergrund erbracht, eine Landing Page mit Warteliste testet die Nachfrage sogar vor dem Bau. Wichtig ist die Abgrenzung zu verwandten Begriffen - ein Prototyp prüft Design und Bedienbarkeit, ein Proof of Concept die technische Machbarkeit, das MVP dagegen die tatsächliche Marktnachfrage mit echten, zahlenden oder aktiven Nutzern. Ein typischer Fehler ist, den Umfang schleichend zu erweitern (Scope Creep), bis aus dem MVP doch das teure Vollprodukt wird; ein zweiter, die für Tempo bewusst eingegangenen technischen Schulden nach der Validierung nicht wieder abzubauen.