MVP bauen als Gründer: kleiner denken, mehr lernen
Fast jeder Gründer, mit dem ich spreche, will ein MVP bauen. Und fast jeder meint damit etwas anderes als das, wofür der Begriff eigentlich steht. In den meisten Köpfen ist ein MVP eine abgespeckte, billigere Version des fertigen Produkts. Etwas, das man schnell rausschiebt, um dann "richtig" loszulegen. Das ist ein teurer Denkfehler, und er kostet österreichische Startups regelmäßig Monate und fünfstellige Beträge.
Was ein MVP wirklich ist (und was nicht)
Ein Minimum Viable Product ist das Kleinste, mit dem du eine konkrete Annahme über dein Geschäft testen kannst. Nicht das kleinste Produkt. Das kleinste Experiment. Der Zweck ist Lernen, nicht Ausliefern.
Der Unterschied klingt akademisch, hat aber massive Folgen. Wenn das Ziel Lernen ist, dann fragst du bei jedem Feature: Was bringt mir das an Erkenntnis? Wenn das Ziel eine kleine Version 1.0 ist, dann fragst du: Was gehört halt dazu? Und "was halt dazugehört" ist eine Liste ohne Ende.
Ein MVP ist also keine billige Vollversion. Es ist ein gezielter Test der einen Annahme, an der dein ganzes Geschäft hängt. Meistens ist das: Zahlt jemand freiwillig für die Lösung dieses Problems? Alle anderen Fragen sind zweitrangig, solange diese nicht beantwortet ist.
Den Kern finden: die eine Annahme
Setz dich hin und schreib auf, woran dein Startup scheitert, wenn du dich irrst. Nicht zehn Risiken. Das größte. Das ist deine Kernannahme, und dein MVP existiert nur, um genau die zu prüfen.
Ein Beispiel. Du willst eine Plattform bauen, über die Handwerksbetriebe ihre Materialbestellungen bündeln. Die riskanteste Annahme ist selten die Technik. Sie ist: Wollen Handwerker ihre Bestellungen überhaupt über eine Plattform laufen lassen, statt beim gewohnten Großhändler anzurufen? Wenn die Antwort Nein ist, hilft dir die schönste Software nichts.
Für diesen Test brauchst du keine Plattform. Du brauchst zehn Betriebe, die bereit sind, dir ihre Bestellung zu schicken, und du gibst die zunächst per Hand weiter. Wenn niemand mitmacht, hast du in zwei Wochen gelernt, was du sonst nach neun Monaten Entwicklung schmerzhaft erfahren hättest.
Feature-Creep und die Scope-Falle
Feature-Creep passiert nicht durch böse Absicht, sondern durch lauter vernünftig klingende Einzelentscheidungen. "Login brauchen wir sowieso." "Ohne Zahlungsabwicklung wirkt es unfertig." "Ein Dashboard erwartet doch jeder." Jedes für sich plausibel, in Summe ein halbes Jahr Arbeit, bevor du irgendetwas gelernt hast.
Die ehrliche Frage bei jedem geplanten Feature lautet: Fällt mein Test in sich zusammen, wenn das fehlt? Meistens nicht. Ein echtes Beispiel aus einem Sparring: Ein Team wollte vor dem Launch ein Nutzerrollen- und Rechtesystem bauen, weil "das später eh gebraucht wird". Später hatten sie noch keinen einzigen zahlenden Kunden. Rechtesysteme baut man, wenn man Nutzer hat, deren Rechte man verwalten muss.
Was du bewusst weglässt, ist genauso eine Produktentscheidung wie das, was du baust. Führ eine sichtbare "Bewusst nicht dabei"-Liste. Das nimmt dem Weglassen das schlechte Gewissen und macht aus einer Lücke eine Entscheidung.
Wann No-Code oder manuell reicht
Der schnellste MVP hat oft gar keinen Code. Was deine Software später automatisch tun soll, machst du am Anfang von Hand. Das nennt man manchmal Concierge- oder Wizard-of-Oz-Ansatz: Der Kunde erlebt ein funktionierendes Produkt, hinter der Kulisse sitzt aber du mit einer Tabelle und tippst.
Das fühlt sich unskalierbar an, und genau das ist der Punkt. Du willst in dieser Phase nicht skalieren, du willst verstehen. Zehn Kunden von Hand zu bedienen bringt dir mehr echte Einsicht in deren Verhalten als jede fertig programmierte Automatisierung, die du ins Blaue hinein baust.
No-Code-Werkzeuge, ein simples Formular, eine WhatsApp-Gruppe, ein geteiltes Dokument: All das kann ein vollwertiger MVP sein, wenn es deine Kernannahme testet. Frag dich vor jeder Zeile Code, ob es ohne auch geht. Überraschend oft geht es.
Lernen messen statt Features zählen
Ein MVP ohne definierte Lernfrage ist kein MVP, sondern nur ein kleines Projekt. Leg vor dem Start fest, welches Ergebnis die Annahme bestätigt und welches sie widerlegt. Zum Beispiel: "Wenn von zwanzig angesprochenen Betrieben mindestens fünf innerhalb von zwei Wochen tatsächlich eine Bestellung schicken, ist die Annahme tragfähig."
Das klingt banal, wird aber ständig übersprungen. Ohne vorher definierte Schwelle interpretierst du hinterher jedes Ergebnis so, dass es dir recht gibt. Zwei Interessenten werden dann zu "grundsätzlich positivem Feedback". Miss Verhalten, nicht Höflichkeit. Ob jemand etwas gut findet, sagt wenig. Ob jemand zahlt, bestellt oder wiederkommt, sagt alles.
Zähl also nicht, wie viele Features du geschafft hast, sondern welche Annahmen du widerlegt oder bestätigt hast. Ein MVP, das deine Idee sauber widerlegt, war erfolgreich. Es hat dich vor einem viel teureren Irrtum bewahrt.
Ehrlich zu technischen Schulden
Und jetzt der Teil, den Berater gern verschweigen: Ein MVP ist voller technischer Schulden, und das ist völlig in Ordnung. Du baust bewusst schnell und unsauber, weil du noch nicht weißt, ob das Ding überhaupt gebraucht wird. Sauber zu bauen, was sich als überflüssig herausstellt, ist keine Ingenieurstugend, sondern Verschwendung.
Wegwerf-Code ist dann legitim, wenn du ihn wirklich wegwirfst. Der Fehler beginnt in dem Moment, in dem das MVP funktioniert, die ersten Kunden zahlen, und aus dem Prototyp klammheimlich das Produktivsystem wird, weil "läuft doch". Genau hier entsteht der Ärger, mit dem Startups zwei Jahre später zu mir kommen: ein System, das niemand mehr anfassen will, weil es nie für Dauerbetrieb gedacht war.
Deshalb die klare Grenze. Wegwerf-Code ist erlaubt, solange die Annahme noch offen ist. Sobald der Test bestanden ist und du ernsthaft weiterbaust, gehört ein bewusster Schnitt dazu: Was trägt jetzt echtes Geschäft, und muss das neu und solide gebaut werden? Diese Entscheidung darf nicht aus Bequemlichkeit unterbleiben. Sie muss aktiv getroffen werden, mit Budget und Zeitplan.
Die eine Sache, bei der ich auch im MVP nicht mit mir reden lasse, ist der verantwortungsvolle Umgang mit echten Personendaten. Schnell und schlampig beim Feature-Code ja, aber nicht beim Schutz von Kundendaten. Alles andere ist verhandelbar.
Kurz gesagt
Ein MVP bauen heißt kleiner denken, als es sich anfühlt, und mehr lernen, als es scheint. Finde die eine Annahme, teste sie mit dem geringstmöglichen Aufwand, miss echtes Verhalten und sei ehrlich zu dem Provisorium, das du dabei baust. Der teuerste MVP ist der, der aussieht wie ein fertiges Produkt, aber nie eine einzige Frage beantwortet hat.
Wenn du gerade davorstehst und unsicher bist, was dein echter Kern ist und was getrost warten kann, ist genau das ein Thema fürs Founder & CTO Sparring. Ich schaue mir deinen Plan mit dir an und wir schneiden gemeinsam auf das zusammen, was wirklich zählt. Ein erstes Kennenlerngespräch ist kostenlos und unverbindlich.