Wie Sie ein MVP so definieren, dass es Ihr Budget nicht sprengt

Wenn ein MVP-Budget gesprengt wird, liegt es fast nie am Code, sondern am Umfang. Der Plan war anfangs schlank, dann kam ein Dutzend Mal „Wir sollten auch noch …“, und aus der kleinen ersten Version wurde still und leise eine große. Bis irgendetwas launcht, ist die Runway knapp, und das Produkt wurde noch immer nicht mit echten Nutzern getestet.

Ein gut definierter Umfang ist das Wirkungsvollste, was Sie vor der Entwicklung tun können. Hier stecke ich bei einem neuen Projekt auch die meiste Energie hinein, denn die Entscheidungen an dieser Stelle bestimmen, ob das Budget hält. So gehe ich vor.

Das geschäftliche Problem: Schleichender Mehrumfang ist ein getarntes Budgetproblem

Jedes Feature, das Sie hinzufügen, kostet mehr, als es aussieht. Es ist nicht nur die Zeit, es zu bauen. Es sind das Design, die Randfälle, die Tests und die Art, wie es mit allem anderen zusammenspielt. Zehn „kleine“ Ergänzungen addieren sich nicht linear, sie multiplizieren sich, weil jede die anderen berührt.

Das Ergebnis ist die klassische Falle: Ein Gründer bezahlt sechs Monate Entwicklung, bevor er auch nur das Geringste darüber lernt, ob die Kernidee funktioniert. Das ist das Gegenteil dessen, wofür ein MVP da ist. (Über das große Ganze habe ich in warum die meisten MVPs scheitern geschrieben. Das meiste davon lässt sich auf den Umfang zurückführen.)

Warum der Umfang wichtiger ist als fast alles andere

Ein MVP hat eine einzige Aufgabe: Ihnen so günstig wie möglich zu zeigen, ob die Kernidee funktioniert. Ein enger Umfang macht das möglich. Je weniger Sie vor dem Launch bauen, desto früher bekommen Sie echtes Feedback und desto mehr Runway bleibt Ihnen, um darauf zu reagieren.

Gründer befürchten manchmal, dass ein kleines MVP wenig beeindruckend wirkt. Aber ein fokussiertes Produkt, das eine Sache gut macht, schlägt ein aufgeblähtes, das zehn Dinge schlecht macht, und kostet nur einen Bruchteil in der Entwicklung. Zurückhaltung ist ein Feature.

Wie ich den Umfang eines MVP definiere

Mit dem einen Kernablauf beginnen

Jedes Produkt hat einen einzigen Kernablauf, also das Wichtigste, wofür ein Nutzer kommt. Bei einem Marktplatz könnte das „etwas finden und buchen“ sein. Bei einem SaaS-Tool „Daten eingeben, ein nützliches Ergebnis erhalten“. Ich bestehe darauf, diesen Ablauf in einem Satz zu benennen, denn alles im MVP unterstützt ihn entweder oder muss warten.

Jedes Feature in drei Kategorien sortieren

Ich nehme die Wunschliste und sortiere sie schonungslos:

• Kern: Ohne das ist das Produkt sinnlos. Das ist das MVP.
• Später: wirklich wertvoll, aber das Produkt kann ohne es launchen und sich beweisen.
• Nie (wahrscheinlich): Ideen, die gut klangen, dem Kern aber nicht wirklich dienen.

Die meisten Features, die sich wie „Must-haves“ anfühlen, sind in Wahrheit „Später“-Features, sobald man fragt, ob das Produkt seinen Wert auch ohne sie beweisen kann.

Das Fundament schützen, nicht die Features

Den Umfang zu kürzen heißt nicht, an Qualität zu sparen. Manches lässt sich später günstig ergänzen (ein neuer Screen, ein zusätzlicher Bericht), anderes ist später brutal schwer zu ändern (das Datenmodell, wie Konten und Berechtigungen funktionieren). Ich halte das MVP bei den Features schlank und lege gleichzeitig das Fundament richtig, damit ein erfolgreiches MVP wachsen kann, statt einen Rewrite zu brauchen.

Ein realistisches Beispiel

Ein gutes Beispiel für einen engen Umfang in meinen Projekten ist der Greenwashing Identifier, ein MVP, das eine fokussierte Sache tat: Umweltaussagen mit einem LLM analysieren und Berichte zur Prüfung erstellen. Es versuchte nicht, eine ausufernde Plattform zu sein. Es bewies ein konkretes Konzept, sauber, und genau das soll ein MVP tun.

Das Muster, das funktioniert, ist immer dasselbe: den Kernablauf wählen, ihn sauber bauen, gelöste Probleme integrieren statt neu zu bauen und alles andere aufheben, bis man etwas gelernt hat. Die Produkte, die gut wachsen, sind die, die schmal angefangen haben.

Typische Fehler bei der Umfangsplanung

• „Wertvoll“ mit „jetzt nötig“ verwechseln: Die meisten Must-haves sind in Wahrheit „Später“.
• Für eine Größe planen, die Sie noch nicht haben, statt fürs Lernen.
• Features hinzufügen, um Eindruck zu machen, statt die Kernidee zu testen.
• Die grundlegenden Entscheidungen überspringen, die heute günstig und später schmerzhaft zu ändern sind.
• Den Umfang still wachsen lassen während der Entwicklung, eine kleine Anfrage nach der anderen.
• Das MVP als Version eins von allem behandeln, statt als schärfsten Test des Kerns.

Wie ich mit Gründern am Umfang arbeite

1. Den Kernablauf gemeinsam benennen, in einem einzigen, klaren Satz.
2. Die gesamte Wunschliste ehrlich sortieren in Kern, Später und Nie.
3. Den MVP-Umfang festschreiben und aufschreiben, was ausdrücklich aufgeschoben wird, damit es eine Entscheidung ist und keine Erinnerung.
4. Das teuer zu ändernde Fundament richtig legen und die Features schlank halten.
5. Den Umfang bewusst überprüfen, wenn sich etwas ändert, als Entscheidung und nicht als schleichende Abweichung.

Diese schriftliche „Aufgeschoben“-Liste ist wichtiger, als viele erwarten. Sie verwandelt jedes künftige „Können wir auch noch …“ in eine schnelle, ruhige Entscheidung statt in eine Diskussion, und sie hält das Budget zusammen. Wie sich das in den gesamten Weg einfügt, lesen Sie in wie ich ein MVP von der Idee bis zum Launch bringe.

Sie planen ein MVP und sorgen sich ums Budget?

Wenn Sie eine Idee und ein Budget haben, das nicht ewig reicht, ist das Gespräch über den Umfang der Punkt, an dem ich Ihnen am meisten Geld sparen kann, noch bevor eine Zeile Code geschrieben ist. Ich helfe Ihnen, den echten Kern zu finden, den Rest aufzuschieben und etwas zu bauen, das schlank genug zum Ausliefern und solide genug zum Wachsen ist.

Sehen Sie sich an, was ich gebaut habe, lesen Sie mehr über meine Arbeitsweise und nehmen Sie Kontakt auf, um Ihre Idee durchzugehen. Definieren wir den Umfang gleich beim ersten Mal richtig.