Ein MVP bauen, ohne zu viel zu bauen

Jeder Gründer kennt den Rat: Bau ein MVP, ein Minimum Viable Product. Nur was „minimal“ konkret heißt, darüber ist sich kaum jemand einig – und diese Unklarheit kostet richtig Geld. Die einen stellen eine Landingpage online und nennen das ihr MVP. Die anderen feilen neun Monate an einer ausgereiften Plattform, nach der nie jemand gefragt hat, und nennen es genauso.

Das Wort, an dem alle hängenbleiben, ist „viable“, also tragfähig. Ein MVP ist keine geschrumpfte Version deines fertigen Produkts. Es ist das kleinstmögliche Experiment, das die eine Frage beantwortet, von der deine ganze Idee abhängt. Verstehst du das, sparst du dir Monate. Verstehst du es nicht, baust du eine wunderschöne Antwort auf eine Frage, die nie jemand gestellt hat.

Dieser Leitfaden zeigt dir, wie du ein MVP um eine einzige riskante Annahme herum zuschneidest, wie du die einfachste denkbare Umsetzung wählst und wie du der Falle des Überbauens entgehst – jenem stillen Killer, der mehr erste Produkte erledigt, als schlechter Code es je könnte.

Fang bei der Annahme an, nicht bei den Features

Bevor du eine einzige Zeile Code oder eine einzige User Story schreibst, beantworte eine Frage: Was muss wahr sein, damit dieses Geschäft funktioniert – und wovon bist du gerade am wenigsten überzeugt? Das ist deine riskanteste Annahme. Genau dafür ist dein MVP da, für nichts sonst.

Bei den meisten frühen Ideen liegt das Risiko in der Nachfrage: Wird das überhaupt jemand nutzen oder dafür zahlen? Bei manchen ist es die Machbarkeit – lässt sich das überhaupt bauen? Bei wenigen ein bestimmtes Verhalten: Tun die Nutzer das Ungewöhnliche, das das Produkt von ihnen verlangt? Was auch immer es ist: Formulier es als widerlegbare Aussage mit einer konkreten Schwelle, so wie du es auch im 30-Tage-Sprint zur Validierung deiner Startup-Idee tun würdest. „Mindestens 30 % der Leute, die auf der Seite landen, tragen sich in die Warteliste ein“ lässt sich prüfen. „Die Leute werden das lieben“ nicht.

Wähl die einfachste Umsetzung, die echte Belege bringt

Sobald die Frage steht, wähl den günstigsten Weg, sie ehrlich zu beantworten. Code ist meist die teuerste Option – also dein letztes Mittel, nicht dein Ausgangspunkt. Das Spektrum der MVPs, vom leichtesten zum schwersten:

Die Kunst ist, die Umsetzung zur Frage passen zu lassen. Geht es ums Nachfrage-Risiko, beantwortet eine Landingpage mit einem echten Call-to-Action das an einem Tag – ganz ohne Produkt. Geht es darum, ob Leute einen komplexen Workflow zu Ende bringen, brauchst du vielleicht eine funktionierende Version. Oft aber reicht es, das Backend nur vorzutäuschen (der „Wizard of Oz“) und es von Hand zu betreiben, während die Nutzer glauben, alles laufe automatisch. Berühmte Frühphasen-Firmen haben Concierge-MVPs gefahren, bei denen die Gründer Bestellungen lange von Hand erledigt haben, bevor irgendetwas automatisiert war.

35%

Die Falle des Überbauens

Überbauen ist der Standardfehler, und während es passiert, fühlt es sich selten wie ein Fehler an. Jedes einzelne Feature wirkt für sich genommen vernünftig. Zusammen schieben sie den Launch um Monate nach hinten und begraben genau das Signal, das du eigentlich lesen wolltest.

Es gibt drei Gründe, warum Gründer überbauen – und alle drei sind emotional, nicht strategisch:

• Angst vor dem Urteil. Ein nacktes MVP ist dir peinlich, also polierst du es, bis es sich „fertig“ anfühlt. Doch über die Reife entscheiden die Nutzer, nicht dein Unbehagen.
• Aufwand mit Fortschritt verwechseln. Features auszuliefern fühlt sich produktiv an. Aber der einzige Fortschritt, der zählt, ist herauszufinden, ob sie überhaupt jemand will.
• Der unangenehmen Frage ausweichen. Solange du baust, musst du nie einen echten Nutzer Nein sagen hören. Bauen wird zur Methode, die Wahrheit aufzuschieben.

Jedes Feature, das du vor dem Launch hinzufügst, ist eine Wette darauf, dass du längst weißt, was die Nutzer wollen. Der ganze Sinn eines MVP ist, dass du es eben nicht weißt.

Die Disziplin lautet: streichen, bis es wehtut, und dann ausliefern. Wenn dir nicht ein bisschen unwohl ist, wie wenig dein MVP kann, hast du zu viel gebaut.

Liefere nichts aus, das nichts testet

Es gibt den umgekehrten Fehler, und er ist genauso häufig: ein MVP, das so minimal ist, dass es die Kernaktion gar nicht erst zulässt. Eine Landingpage ist ein hervorragender Nachfrage-Test. Aber wenn deine eigentliche Frage lautet „Nutzen die Leute den Workflow?“, beantwortet eine Landingpage rein gar nichts. Das „Minimum“ hat seine Grenze im „Viable“: Das Produkt muss einen echten Nutzer die Kernsache erledigen lassen und ein klares Signal erzeugen.

Der Test auf Tragfähigkeit ist simpel: Schafft es ein Fremder, ganz ohne deine Erklärung, die eine Aktion auszuführen, von der dein Geschäft abhängt – und liefert er dir dabei Daten darüber, ob er es wieder tun würde? Wenn ja, ist es tragfähig. Musst du ihm dabei über die Schulter schauen, hast du eine Demo, kein MVP.

Hier zahlt sich auch ein starker technischer Partner aus. Zu entscheiden, was du nur vortäuschen und was du wirklich bauen musst – und den echten Teil dann schnell zu bauen –, ist Ermessenssache. Genau deshalb lohnt sich jemand, der schon einmal etwas ausgeliefert hat: sei es ein technischer Mitgründer aus dem Netzwerk oder ein früher Entwickler, der dieses Spiel kennt.

Dein MVP in vier Schritten

1. Benenne die riskanteste Annahme

   Schreib die eine Sache auf, die wahr sein muss – als Aussage, die du widerlegen könntest, mit einer Zahl daran. Dieser Satz ist die komplette Stellenbeschreibung deines MVP.

2. Wähl die einfachste Umsetzung, die sie testet

   Fang oben im MVP-Spektrum an – Landingpage, Concierge, No-Code – und arbeite dich nur dann zu echtem Code vor, wenn ein leichterer Test die Frage nicht beantworten kann.

3. Setz eine Deadline in Wochen

   Begrenz den Build auf ein paar Wochen. Die Deadline zwingt dich, den Umfang ehrlich zu halten: Alles, was nicht der Kernfrage dient, fliegt raus, damit du sie einhältst.

4. Leg vorab fest, was „funktioniert“ heißt

   Bestimm die Schwelle, bevor du live gehst – so liest du das Ergebnis ehrlich, statt es dir schönzureden. Dann gib es echten Nutzern und beobachte, was sie tun, nicht was sie sagen.

Sobald dein MVP ein klares Signal liefert, lautet die nächste Frage, ob diese frühe Zugkraft echt und wiederholbar ist – der Beginn der Suche nach dem Product-Market-Fit. Diese Suche startet aber erst, wenn du etwas Echtes ausgeliefert hast, das klein genug ist, um daraus zu lernen. Bau das Experiment, nicht das Produkt. Das Produkt kommt nach den Belegen.