Was vor dem Bau eines MVP zu entscheiden ist

Ein MVP ist keine kleinere Fassung jeder Idee auf Ihrer Roadmap. Es ist das kleinste nützliche Produkt, mit dem eine definierte Gruppe von Menschen einen wichtigen Ablauf abschließen kann und das dem Team Belege für die nächste Entscheidung liefert.

Bei diesem einen Wort — Belege — lohnt sich das Innehalten.

Die Analyse von CB Insights, warum Start-ups scheitern (wird in einem neuen Tab geöffnet), im März 2026 veröffentlicht, untersuchte 431 risikokapitalfinanzierte Unternehmen, die seit 2023 öffentlich geschlossen haben. Sie fand in 70 % der Fälle ausgehendes Kapital und in 43 % einen schlechten Product-Market-Fit.

Nützlicher ist ihre Beobachtung dazu, wann Fit-Fehlschläge passieren: „Zwei Drittel der Product-Market-Fit-Fehlschläge waren Unternehmen in der Frühphase, die nie einen Markt gefunden haben.“

Geld ist, wie es endet. Zu langsames Lernen ist oft, warum. Dasselbe Prinzip gilt für ein internes Unternehmenswerkzeug: Seine erste Version sollte belegen, dass ein wichtiger Ablauf besser funktioniert.

Die erste Version ist also keine Demonstration Ihres Anspruchs. Sie ist ein Instrument, um etwas herauszufinden. Die folgenden Entscheidungen bestimmen, ob sie das kann.

Was ein MVP nicht ist

Drei Missverständnisse richten den meisten Schaden an, und es lohnt sich, sie vor der Planung zu benennen:

• Eine günstigere Fassung des vollen Produkts. Überall an der Qualität zu sparen hinterlässt etwas, das niemand beurteilen kann. Kürzen Sie stattdessen den Umfang und bauen Sie das Verbleibende richtig.
• Ein Prototyp. Ein Prototyp beantwortet eine Entwurfsfrage und wird danach verworfen. Ein MVP ist echte Software mit echten Nutzenden und muss wartbar sein.
• Eine endgültige Architektur. Die erste Version sollte sich ändern können. Entscheidungen, die teuer rückgängig zu machen sind, verdienen mehr Nachdenken als solche, die es nicht sind.

Die nützliche Frage lautet nicht „Was ist das Wenigste, das wir bauen können?“ Sondern: „Was ist das Wenigste, das wir bauen können und das uns trotzdem etwas beibringt, nach dem wir handeln würden?“

Sollten Sie überhaupt individuell bauen?

Bevor Sie einen Individualbau zuschneiden, lohnt die Frage, ob Sie ihn schon brauchen.

Individualsoftware ist die richtige Antwort, wenn Ihr Ablauf wirklich spezifisch ist, wenn Sie das Ergebnis besitzen müssen oder wenn Standardwerkzeuge sich nicht so verbinden lassen, wie Ihr Geschäft funktioniert.

Sie ist oft die falsche erste Antwort, wenn ein No-Code-Werkzeug, eine Tabelle oder ein bestehendes Produkt Sie dieselbe Annahme noch diese Woche testen ließe.

Eine sinnvolle Reihenfolge ist, die Nachfrage mit dem Günstigsten zu validieren, das funktioniert, und dann individuell zu bauen, sobald Sie wissen, welche Teile es wirklich brauchen.

Viele erfolgreiche Produkte beginnen als manueller Prozess oder als zusammengesetztes Werkzeugbündel. Sie werden erst dort zu Individualsoftware, wo dieses Bündel zu schmerzen beginnt.

Zu früh individuell zu bauen, verbraucht Ihr Budget dafür, etwas zu beweisen, das ein weit günstigerer Test hätte zeigen können. Zu spät zu bauen, lässt Sie mit Werkzeugen kämpfen, die nicht mehr passen.

Beantworten Sie das ehrlich, bevor Sie mit dem Zuschnitt beginnen — nicht danach.

Beginnen Sie mit dem Nutzerablauf

Bevor Sie über Technik sprechen, beschreiben Sie, wer das Produkt nutzen wird, in welcher Lage diese Person ist und welche Aufgabe sie erledigen muss. Bleibt das vage, zieht sich die Vagheit durch jeden Bildschirm und jede Funktion.

Schreiben Sie den Hauptablauf als kurze Abfolge. Zum Beispiel: Ein Kunde reicht eine Anfrage ein, ein Teammitglied prüft sie, das System hält die Entscheidung fest, und beide Seiten sehen den nächsten Schritt.

Der britische Government Digital Service formalisiert das als Discovery-Phase. Sein Service-Handbuch (wird in einem neuen Tab geöffnet) wird bei der Reihenfolge deutlich: „Bevor Sie sich darauf festlegen, einen Service zu bauen, müssen Sie das zu lösende Problem verstehen.“

Als typisch für diese Discovery nennt er etwa vier bis acht Wochen, die mit einer ausdrücklichen Entscheidung darüber enden, ob überhaupt ein tragfähiger Service existiert.

Eine kurze, begrenzte Untersuchung mit einem echten Go/No-Go ist günstiger als ein Bau, der dasselbe im fünften Monat herausfindet.

Legen Sie fest, was in den Umfang gehört

Trennen Sie dann das Unverzichtbare vom später Nützlichen. Anmeldung, Berechtigungen, Zahlungen, Benachrichtigungen, Auswertungen, Schnittstellen und Verwaltungswerkzeuge mögen alle wichtig sein, aber das erste Release braucht sie nicht alle im gleichen Ausbaugrad.

Ein guter Umfang hat für jedes Feature einen Grund. Behalten Sie ein Feature in der ersten Version, wenn es mindestens einen dieser Tests besteht:

1. die ersten Nutzenden können den Kernablauf ohne es nicht abschließen
2. es senkt ein Lieferrisiko, das Sie bereits identifiziert haben
3. es gibt dem Team die Kontrolle, die es vom ersten Tag an braucht
4. es wegzulassen würde eine Neuschreibung erzwingen statt einer Ergänzung

Besteht ein Feature keinen davon, ist es eine spätere Entscheidung und keine Streichung. Es so festzuhalten, entschärft meist den Streit über das Weglassen.

Entscheiden Sie, woran Sie den Erfolg erkennen

Einigen Sie sich vor Baubeginn darauf, welches Ergebnis ein Weitermachen, einen Kurswechsel oder ein Ende rechtfertigen würde. Ohne das liest sich jedes Ergebnis als ermutigend.

Wählen Sie Signale, die Sie in den ersten Wochen echter Nutzung beobachten können, nicht solche, die ein Jahr Daten brauchen:

• Menschen schließen den Kernablauf ab, ohne dass man sie hindurchführt
• sie kommen wieder, ohne dass man sie erinnert
• die manuelle Arbeit, die das Produkt ersetzt hat, geht sichtbar zurück
• jemand fragt nach dem nächsten Feature statt nach einer grundlegenden Fehlerbehebung

Schreiben Sie auf, was Sie erwarten und bis wann. Das mit dem Geschehenen zu vergleichen, ist der ganze Sinn eines frühen Release.

Schreiben Sie auf, was „fertig“ bedeutet

Definieren Sie vor Entwicklungsbeginn, was „funktioniert“ heißt. Nutzen Sie beobachtbare Abnahmekriterien, etwa: Die Nutzenden können eine Anfrage einreichen, die richtige Person kann sie prüfen, und das System hält das Ergebnis korrekt fest.

Der GDS-Leitfaden zum Schreiben von User Storys (wird in einem neuen Tab geöffnet) beschreibt Abnahmekriterien als „eine Liste von Ergebnissen, die Sie als Checkliste nutzen, um zu bestätigen, dass Ihr Service seine Aufgabe erfüllt hat“ — jedes in der Form Fertig ist es, wenn … formuliert.

Der Wert liegt darin, dass es jemand prüfen kann, der es nicht gebaut hat.

Auf Release-Ebene definiert The Scrum Guide (wird in einem neuen Tab geöffnet) die Definition of Done als „eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaße erfüllt“.

Ob Sie Scrum einsetzen oder nicht — die Idee trägt. Eine vereinbarte, schriftliche Qualitätsschwelle verhindert, dass „fertig“ für jede Person im Gespräch etwas anderes bedeutet.

Legen Sie Datenregeln vor dem Schema fest

Entscheiden Sie, welche Informationen das Produkt speichern muss und wer darauf zugreifen darf. Datenschutz, Berechtigungen, Aufbewahrung, Backups und Audit-Anforderungen lassen sich leichter planen, bevor die ersten Datenbanktabellen und Integrationen stehen.

Bei Produkten, die personenbezogene Daten von Menschen in der EU verarbeiten, ist diese Reihenfolge Gesetz und keine Vorliebe.

Der Leitfaden der Europäischen Kommission zu Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (wird in einem neuen Tab geöffnet) beschreibt Maßnahmen, die bereits in den frühesten Phasen der Gestaltung der Verarbeitung greifen, mit Voreinstellungen, die so gesetzt sind, dass „personenbezogene Daten mit dem höchsten Datenschutz verarbeitet werden“.

Der Europäische Datenschutzausschuss verabschiedete eigene Leitlinien zu Artikel 25 (wird in einem neuen Tab geöffnet) im Oktober 2020 in endgültiger Fassung, falls Sie die detaillierte Position der Aufsicht brauchen.

In der Praxis ist das eine kurze Liste zum Aufschreiben: was Sie erheben, warum, wer es sehen darf, wie lange Sie es behalten und wie jemand die Löschung erreicht.

Diese Fragen zu beantworten, bevor die Datenbank entworfen wird, kostet weit weniger, als sie später nachzurüsten.

Wählen Sie Technologie und KI sorgfältig

Wählen Sie Technologie rund um das Produkt und seine Randbedingungen. Ein modernes Framework kann gut passen, aber die bessere Wahl hängt von den Nutzenden, den Daten, den Integrationen, den Lieferanforderungen und den Menschen ab, die die Software pflegen werden.

KI verdient dieselbe Disziplin. Entscheiden Sie, ob sie den Kernablauf stützt, was passiert, wenn ihre Ausgabe falsch ist, und wie eine Person sie prüfen oder korrigieren kann, bevor Sie sie als Produktanforderung behandeln.

Es gibt inzwischen gemessene Gründe zur Vorsicht. Der 2025 DORA report (wird in einem neuen Tab geöffnet), der auf Antworten von fast 5.000 Technologiefachleuten beruht, berichtet, dass „die KI-Einführung weiterhin in einem negativen Zusammenhang mit der Stabilität der Softwareauslieferung steht“.

Schnellere Ausgabe ohne belastbare Tests und Reviews summiert sich nicht zu schnellerer Lieferung. Sie summiert sich zu Nacharbeit.

Planen Sie Reviews, Zugriff, Übergabe

Planen Sie die Prüfpunkte vor der ersten Zeile Code. Kurze Vorführungen, eine gemeinsame Aufgabenliste und Entscheidungen, die für alle sichtbar festgehalten sind, lassen Sie den Kurs ändern, solange ein Kurswechsel noch günstig ist.

Das US Government Accountability Office begründet das Risiko in seinem Agile Assessment Guide (wird in einem neuen Tab geöffnet): Inkrementelle Lieferung mit fortlaufender Evaluierung „kann die Risiken senken, ein Programm zu finanzieren, das scheitert oder veraltete Technik hervorbringt“.

Einigen Sie sich von Anfang an auf Eigentum und Zugriff. Das Projekt sollte ein klares Quellcode-Repository, dokumentierte Umgebungen, einen vereinbarten Deployment-Weg und einen Übergabeplan haben, der nicht vom privaten Konto einer einzelnen Person abhängt.

Die DORA-Fähigkeit Versionskontrolle (wird in einem neuen Tab geöffnet) benennt konkret, was dort hineingehört: Anwendungscode und Abhängigkeiten, Werkzeuge zur Umgebungserstellung, Container-Composition-Dateien, Cloud-Konfiguration und KI-Artefakte wie Prompts.

Die angeführte Grundlage: „Die Forschung zeigt durchgehend, dass eine umfassende Nutzung der Versionskontrolle Continuous Delivery vorhersagt.“

Der Leitfaden des GDS zur Versionskontrolle (wird in einem neuen Tab geöffnet) ergänzt die andere Hälfte der Regel, das Review: „Jede Codeänderung wird von jemandem geprüft, der sie nicht geschrieben hat.“

Zusammen machen diese Gewohnheiten eine Übergabe erst möglich. Wenn das Wiederherstellen des Systems vom Laptop einer bestimmten Person abhängt, haben Sie kein Liefergut — Sie haben eine Abhängigkeit.

Planen Sie Zeitrahmen und Budget

Ein fokussiertes MVP lässt sich oft um ein Lieferfenster von 6–8 Wochen planen, wenn der Umfang zu dieser Form passt. Das ist ein Planungsrichtwert, kein allgemeines Versprechen; Integrationen, Freigaben und unbekannte Altsysteme können den Zeitrahmen verändern.

Es hilft zu wissen, wie Softwarezeitpläne scheitern, denn sie scheitern nicht in beide Richtungen gleich.

Eine im Journal of Management Information Systems (wird in einem neuen Tab geöffnet) veröffentlichte Studie zu 5.392 IT-Projekten ergab, dass Kostenüberschreitungen einem Potenzgesetz statt einer Normalverteilung folgen.

Die meisten Überschreitungen sind moderat, aber es gibt „einen langen Ausläufer mit einer kleineren Zahl von Projekten mit extremen Überschreitungen“. Auf den Durchschnitt zu planen, unterschätzt genau das Risiko, auf das es ankommt.

Das ist nicht nur ein Start-up-Problem. Die Hochrisikobewertung der Bundes-IT des GAO (wird in einem neuen Tab geöffnet), veröffentlicht im Januar 2025, hält fest, dass IT-Investitionen des Bundes „zu häufig scheitern oder Kostenüberschreitungen und Terminverzüge verursachen, während sie wenig zu missionsbezogenen Ergebnissen beitragen“.

Und das bei jährlichen Ausgaben von über 100 Milliarden US-Dollar. Größe und Budget lösen das nicht; Umfangsdisziplin und kurze Feedbackschleifen schon.

Budgetieren Sie Entscheidungen, nicht nur Programmierstunden. Analyse, Design, Bau, Tests, Auslieferung, Inhalte, Fremdleistungen und die Korrekturen nach dem Launch erhöhen alle den Aufwand, den erste Release brauchbar zu machen.

Ein durchgerechnetes Beispiel

Denken Sie an eine Gründerin, die eine Buchungsplattform will: Kundschaft bucht Termine, Anbietende verwalten Kalender, beide Seiten zahlen und erhalten Erinnerungen, und eine Administration behält alles im Blick. Das ist ein reales Produkt mit einer langen Featureliste.

Der Kernablauf ist allerdings eng: Eine Kundin findet einen freien Termin und bucht ihn, und die anbietende Person sieht die Buchung. Alles andere stützt das oder kann warten.

Eine disziplinierte erste Version könnte so aussehen:

• Im Umfang: Verfügbarkeiten der Anbietenden, Kundenbuchung, eine Bestätigung und eine einfache Anbieteransicht der kommenden Buchungen.
• Zurückgestellt: In-App-Zahlungen (zunächst manuell eine Anzahlung nehmen), automatische Erinnerungen, Bewertungen, anbieterübergreifende Suche und das Admin-Dashboard.
• Vorab entschieden: welche Kundendaten gespeichert werden und wie lange, wem das Repository gehört und was „eine Buchung hat funktioniert“ als Abnahmekriterium bedeutet.

Die zurückgestellte Liste ist nicht aufgegeben — sie ist die Roadmap. Aber den Kern zuerst auszuliefern, beantwortet die einzige Frage, die früh zählt: Werden Anbietende ihre Kalender aktuell halten, und wird die Kundschaft buchen?

Wenn ja, lohnt sich der Rest. Wenn nicht, hätte keine Zahlungsintegration das gerettet.

Erste Schritte

Das Ziel ist nicht, alles vorherzusagen. Das Ziel ist, die wichtigen Annahmen sichtbar zu machen, den Kernablauf zu testen und eine Produktgrundlage zu schaffen, die sich verbessern lässt, ohne die Arbeit zu verwerfen.

Wenn Sie eine Idee, aber keine vollständige Spezifikation haben, beginnen Sie mit den Nutzenden, dem Ablauf und der Entscheidung, die die erste Version stützen soll. Diese drei Punkte genügen für ein nützliches Planungsgespräch.