Was ist ein Minimum Viable Product (MVP)?
Ein MVP ist die einfachste Version eines Produkts, mit der Sie Ihre zentrale Hypothese bei echten Kunden testen können. Erfahren Sie, was ein MVP ist und was nicht.
Key Takeaways
- Ein MVP ist kein halbfertiges Produkt — es ist das Minimum, das nötig ist, um eine bestimmte Hypothese zu testen
- Das Ziel eines MVP ist Lernen, nicht Launchen
- MVPs können nicht-technisch sein — eine Landingpage, ein Concierge-Service oder ein Wizard-of-Oz-Test
- Legen Sie fest, was Sie lernen müssen, bevor Sie das MVP bauen — nicht danach
Was ein MVP wirklich ist
Ein Minimum Viable Product ist keine abgespeckte, fehleranfällige Version Ihrer vollständigen Produktvision. Es ist die minimale Menge an Funktionen, die nötig ist, um eine bestimmte Geschäftshypothese bei echten Kunden zu testen und verwertbare Erkenntnisse zu gewinnen. Das Wort minimal bedeutet, dass Sie nichts bauen, was über das für den Hypothesentest Erforderliche hinausgeht. Das Wort tragfähig (viable) bedeutet, dass es gut genug sein muss, damit Kunden es tatsächlich nutzen und Ihnen aussagekräftiges Feedback geben können. Das Ziel ist Lernen, nicht Ausliefern.
Der hypothesenorientierte Ansatz
Der richtige Weg, ein MVP zu gestalten, ist, mit der Hypothese zu beginnen, die Sie testen müssen. Was ist die einzige kritischste Annahme, die, wenn sie falsch ist, Ihr gesamtes Geschäftsmodell zunichtemachen würde? Bauen Sie die minimale Version, die genau diese Annahme testet — nicht mehr. Wenn Ihre Hypothese lautet, dass kleine Unternehmer für automatisierte Buchhaltung zahlen würden, muss Ihr MVP diese Automatisierung demonstrieren und zeigen, dass diese Kunden bereit sind zu zahlen. Es muss nicht jeden Randfall abdecken, jeden Browser unterstützen oder eine polierte Benutzeroberfläche haben.
Nicht-technische MVPs
MVPs müssen keine Software sein. Eine Landingpage, die ein noch nicht existierendes Produkt beschreibt und einen Anmeldebutton enthält, testet die Nachfrage, ohne eine Zeile Code zu schreiben. Ein Concierge-MVP liefert das versprochene Ergebnis manuell — wenn Sie eine App für Restaurantempfehlungen bauen, können Sie zunächst selbst personalisierte Empfehlungen per SMS verschicken. Ein Wizard-of-Oz-MVP präsentiert ein Produkt, das automatisiert wirkt, aber hinter den Kulissen manuell betrieben wird. Diese Ansätze erzeugen echtes Lernen zu einem Bruchteil der Kosten eines fertig gebauten Produkts.
Häufige MVP-Fehler
Zu viel bauen: Funktionen hinzufügen, die über das für den Hypothesentest Nötige hinausgehen, getrieben vom Wunsch zu beeindrucken statt zu lernen. Im Verborgenen entwickeln: das MVP monatelang entwickeln, ohne es potenziellen Kunden zu zeigen. Die falsche Kennzahl optimieren: Downloads oder Anmeldungen messen statt zu prüfen, ob Kunden echten Nutzen ziehen. Das MVP als fertiges Produkt behandeln: Das MVP ist ein Lernvehikel, keine Grundlage. Sobald die zentrale Hypothese validiert ist, sollten Sie es sauber neu aufbauen, statt weiter zu flicken.
Wann das MVP fertig ist
Die MVP-Phase ist abgeschlossen, wenn Sie die kritische Hypothese mit genügend Belegen beantwortet haben, um eine fundierte Entscheidung zu treffen. Die Entscheidung könnte lauten: validieren und skalieren, zu einer verwandten Hypothese pivotieren oder aufhören. Die entscheidende Disziplin besteht darin, Ihre Erfolgskriterien vor Beginn des MVP festzulegen — welches Ergebnis würde Sie überzeugen, dass die Hypothese validiert ist? Welches Ergebnis würde sie widerlegen? Ohne vorab definierte Kriterien wird der Bestätigungsfehler dazu führen, dass Sie mehrdeutige Ergebnisse als Validierung interpretieren.