Bei der MVP Entwicklung für Startups entscheidet nicht der Funktionsumfang über den Erfolg, sondern die Frage, die Sie beantworten wollen. Viele Gründer behandeln das MVP als verkleinerte Version des fertigen Produkts. Das verführt dazu, Budget in Funktionen zu stecken, die noch kein Kunde bestätigt hat. Ein MVP ist zuerst ein Experiment und erst danach ein Produkt.
Die gebräuchlichste Definition geht laut Computerwoche und ihrem Beitrag zum Minimum Viable Product auf Eric Ries zurück. Er beschreibt das MVP in „Lean Startup“ (2011) als Version eines neuen Produkts, mit der ein Team die maximale Menge validierter Informationen über Kunden bei minimalem Aufwand gewinnt. Der Maßstab ist also Erkenntnis, nicht Umfang. Das verändert, wie Sie Budget, Zeitplan und Partner auswählen.
Beginnen Sie mit einer Aussage, die sich widerlegen lässt. Die Computerwoche spielt das an einem Taschenmesser durch: Mit einem Korkenzieher steigt der Umsatz in vier Wochen um zehn Prozent. Für Ihr Startup könnte die Aussage lauten, dass Betriebe einer bestimmten Branche monatlich für die Lösung eines konkreten Problems zahlen. Legen Sie vorab fest, welches Ergebnis die Annahme bestätigt und welches sie widerlegt.
Aus der Hypothese folgt der Umfang, nicht umgekehrt. Jede Funktion, die keine Antwort auf Ihre Frage liefert, gehört nicht ins erste Release. Das spart Geld, denn eine voll ausgebaute Beta ist bei einem SaaS-Produkt laut einem Beitrag auf deutsche-startups.de über MVP-Konzepte gerade in der Pre-Seed-Phase mit einem erheblichen wirtschaftlichen Risiko verbunden. Es spart auch Zeit, weil weniger Funktionen weniger Abstimmung erfordern.
Bevor Sie Entwicklungsbudget freigeben, prüfen Sie, ob sich Ihre Hypothese manuell testen lässt. Der Beitrag von deutsche-startups.de beschreibt vier Formate, die sich in Aufwand und Aussagekraft unterscheiden.
| Format | Was der Kunde erlebt | Was Sie lernen |
|---|---|---|
| Concierge-MVP | Er erkennt, dass Menschen die Leistung manuell erbringen | Ob die Leistung gebraucht wird und ob Kunden dafür zahlen würden |
| Wizard-of-Oz-MVP | Er glaubt an ein automatisiertes Produkt, dahinter arbeiten Menschen | Wie Kunden ein vollständig wirkendes Produkt nutzen |
| Landing-Page-MVP | Eine Seite, die das Produkt als verfügbar darstellt | Wie groß das Kaufinteresse ist, gemessen an Anmeldungen |
| E-Mail-MVP | Eine regelmäßige E-Mail mit dem Kerninhalt des Produkts | Öffnungs- und Klickraten sowie direktes Feedback |
Die Beispiele aus dem Beitrag zeigen die Spannweite. Zappos-Gründer Nick Swinmurn fotografierte Schuhe in Läden, bot sie online an und kaufte sie erst nach einer Bestellung. Joel Gascoigne sprach nach 120 Registrierungen für Buffer mit 50 der Interessenten. Ryan Hoover verschickte Produktempfehlungen per E-Mail, bevor Product Hunt als Plattform entstand, und AngelList übernahm sie 2016 für 20 Millionen Dollar. Das sind Erfolgsfälle und keine Prognose für Ihr Vorhaben, aber sie zeigen, dass die erste Antwort des Marktes oft ohne eigene Software kommt.
Beim Wizard-of-Oz-Format wissen Kunden nicht, dass Menschen im Hintergrund arbeiten. Das ist kein Freibrief. Sobald Sie personenbezogene Daten von Hand verarbeiten, greifen Datenschutz und Informationspflichten, und was für Ihre Branche gilt, klärt eine Fachperson für Datenschutzrecht. Das Concierge-Format ist hier transparenter, weil die Kunden Bescheid wissen.
Programmieren wird nötig, wenn Ihre Hypothese von etwas abhängt, das nur Software leistet: Automatisierung bei höherem Volumen, Anbindung an andere Systeme oder ein Nutzungserlebnis, das sich von Hand nicht nachstellen lässt. Dann beginnt die eigentliche MVP Entwicklung für Startups mit einem schmalen Kernprozess, den Nutzer von Anfang bis Ende durchlaufen. Eine MVP-Entwicklung zum Festpreis von Xerx bindet Umfang und Budget vorab. Das funktioniert aber nur, wenn der Umfang aus der Hypothese abgeleitet und schriftlich fixiert ist.
Was ein MVP kostet, hängt von Umfang, Integrationen und Bedienkomfort ab, und einen seriösen Richtwert gibt es erst mit Ihrem Scope. Wie sich die Posten bei einer Web-App verteilen, zeigt unser Vergleich Web App Kosten im Vergleich zur Native App. Lassen Sie Angebote nach Meilensteinen gliedern und achten Sie auf klare Abnahmekriterien, wie die Vertragsfragen bei Individualsoftware sie beschreiben. Welche Konditionen für Sie passen, bestätigt Ihre Rechtsberatung.
Ein MVP darf klein sein, aber nicht unbrauchbar. UX-Direktor Uwe Todoroff kritisiert in seinem t3n-Beitrag zu UX und MVP das beliebte Bild vom Skateboard, das Schritt für Schritt zum Auto wird. Wer ein Auto will, gibt sich mit einem Skateboard nicht zufrieden. Außerdem übersieht ein rein funktionales MVP ein Bedürfnis: Menschen wollen ein Produkt leicht bedienen können.
Praktisch heißt das: Wählen Sie einen engen Anwendungsfall und machen Sie ihn gut, statt viele Funktionen halb fertig anzubieten. Der Beitrag nennt außerdem einen von Yona Gidalevitz vorgeschlagenen Zyklus aus UX, Messen, Lernen und Wiederholen, der den klassischen Zyklus aus Bauen, Messen und Lernen ergänzt. Ein grobes Zielbild des späteren Produkts hilft, weil Sie das MVP daraus ableiten und so lose Enden vermeiden.
Ein MVP scheitert selten an der Technik allein, öfter an unklaren Zuständigkeiten. Rolf Scheuch fragt in einer heise-Kolumne über ein babylonisches Softwareprojekt, wie man Teams, die sehr unterschiedlich denken, dazu bringt, an einem Strang zu ziehen. Klären Sie das für Ihr Vorhaben vorab: Benennen Sie eine Person, die über den Umfang entscheidet, und legen Sie feste Termine für Feedback fest.
Legen Sie Entscheidungsregeln fest, bevor die ersten Daten eintreffen. Laut t3n durchläuft ein Produkt nach dem Markteintritt entweder schnelle Iterationen, oder die Entwicklung endet, wenn der Markt es für unbrauchbar hält. Dafür brauchen Sie vier Dinge:
Ein MVP beantwortet eine Frage. Wenn Sie sie nicht benennen können, fehlt noch das Experiment.
Die Computerwoche weist darauf hin, dass Sie den Erfolg nicht nur am Umsatz messen, sondern auch an Kosteneinsparungen. Bei einem Werkzeug für interne Abläufe kann das die wichtigere Zahl sein. Die MVP Entwicklung für Startups endet deshalb nicht mit dem Launch, sondern mit einer Entscheidung. Ein erstes Release, das noch ruckelt, aber Ihre Frage beantwortet, hat seine Aufgabe erfüllt.
Ein Prototyp zeigt, wie etwas aussehen oder funktionieren könnte. Ein MVP trifft bereits auf echte Nutzer und prüft Annahmen, etwa ob Kunden das Angebot nutzen oder dafür zahlen.
Nein. Concierge-, Landingpage- und E-Mail-MVPs testen eine Idee ohne eigene Software. Entwicklung lohnt sich erst, wenn Ihre Hypothese von technischen Leistungen abhängt.
So wenige, dass sie Ihre Hypothese beantworten. Wählen Sie einen engen Anwendungsfall und sorgen Sie dafür, dass er leicht bedienbar ist.
Das hängt von Umfang, Plattform, Integrationen und Bedienkomfort ab. Eine belastbare Zahl liefert nur ein Angebot auf Basis Ihres abgegrenzten Umfangs.
