MVP - was streichen und was behalten?

Ein MVP ist die kleinste Produktversion, mit der sich eine wichtige Hypothese mit echten Nutzenden überprüfen und ein verlässliches Signal für die nächste Entscheidung gewinnen lässt. Es kann eine funktionierende Anwendung mit engem Umfang sein; man sollte es jedoch nicht mit einer zufällig unvollständigen Version eines größeren Systems verwechseln.

Die ganze Schwierigkeit liegt darin, dass die Entscheidung „Was streichen wir?“ eine Geschäftsentscheidung ist, aber oft technisch getroffen wird. Im Folgenden der Test, mit dem wir sie treffen.

Der Test mit drei Fragen

Stellen Sie für jede Funktion auf der Liste nacheinander folgende Fragen:

1. Lässt sich der Hauptablauf ohne diese Funktion überhaupt von Anfang bis Ende ausführen? Falls nein, bleibt sie. Falls ja, ist sie ein Kandidat zum Streichen.
2. Würde ihr Fehlen die Einführung beim ersten echten Nutzer blockieren? Nicht beim idealen Zielkunden, sondern beim ersten. Das sind zwei unterschiedliche Personen.
3. Erzeugt das Verschieben dieser Entscheidung unverhältnismäßige Kosten oder Risiken? Betrifft sie Datengrenzen, Berechtigungen oder Compliance, muss das notwendige Minimum jetzt entworfen werden; die Tatsache, dass eine spätere Änderung etwas teurer wird, rechtfertigt nicht die gesamte künftige Funktion.

Die dritte Frage schützt vor scheinbarer Ersparnis. Nicht alles lässt sich später ohne Kosten ergänzen, aber das bedeutet nicht, die gesamte zukünftige Architektur bereits in der ersten Version zu entwerfen.

Was sich oft verschieben lässt

• Ein Admin-Panel für alles. Entwerfen Sie zu Beginn nur die sicheren Vorgänge, die für den Betrieb der ersten Version nötig sind. Direkter Datenbankzugriff darf keine Berechtigungskontrolle, Änderungsprotokollierung und Backups ersetzen.
• Mehrsprachigkeit ohne aktuelle Zielgruppe dafür. Sie vergrößert den Aufwand bei Bildschirmen, Meldungen, Inhalten und Tests. Verschieben Sie sie aber nicht, wenn die erste Version tatsächlich mehrere Sprachen bedient oder Recht beziehungsweise Vertrag sie verlangen.
• Umfangreiche Berichte. Zu Beginn genügt der kleinste Satz an Kennzahlen, der für die getestete Entscheidung erforderlich ist. Diagnosesichten ergänzen Sie anhand von Nutzerfragen und in Daten sichtbar gewordenen Problemen.
• Benachrichtigungen in allen Kanälen. Beginnen Sie mit den Kanälen, die für den zentralen Ablauf und das Risiko nötig sind; zusätzliche Varianten können nach der Nutzungsprüfung folgen.
• Konfigurierbarkeit ohne bestätigten Bedarf. Ein Einstellungsbereich ist gerechtfertigt, wenn Nutzende einen Parameter tatsächlich häufig ändern müssen oder die Lösung unterschiedliche Varianten bedienen soll. Andernfalls reicht eine explizite, vom Team betriebene Konfiguration.
• Eine KI-Schicht, wenn sie nicht das Herzstück des Produkts ist. Einen Assistenten zu einer Anwendung hinzuzufügen, die noch keine Nutzenden hat, verursacht Kosten ohne Messung.
• Integrationen „für später“. Wir binden nur jene an, ohne die der Prozess nicht abgeschlossen wird.

Was nicht ohne Risikobewertung gestrichen werden darf

Folgende Elemente gelten bisweilen als Funktionen für später, obwohl ihr Fehlen die Kosten eines Ausfalls, Umbaus oder der Betreuung der ersten Nutzenden erhöhen kann:

• Ein Datenmodell mit richtigen Grenzen. Es geht nicht darum, alle künftigen Funktionen vorherzusagen, sondern die grundlegenden Begriffe, Datenhoheit und Beziehungen zu erkennen, die im aktuellen Umfang erforderlich sind. Ein übermäßig ausgebautes Modell erhöht ebenfalls die MVP-Kosten.
• Authentifizierung und Berechtigungen, die dem aktuellen Umfang entsprechen. Spätes Hinzufügen einer Zugriffskontrolle verlangt die Prüfung von Bildschirmen, Vorgängen und Daten. Das Berechtigungsmodell entwickelt sich weiter, doch die sicheren Grenzen der ersten Version müssen vor Zulassung von Nutzenden feststehen.
• Backups mit getesteter Wiederherstellung. Das bloße Erstellen eines Backups beweist nicht, dass es innerhalb der nötigen Zeit wiederhergestellt werden kann. Passen Sie Umfang und Testfrequenz an Datenwert und akzeptable Unterbrechung an.
• Grundlegendes Monitoring und Logs. Ihr Fehlen begrenzt die Möglichkeit, einen Fehler zu rekonstruieren, und lässt dem Team oft nur eine allgemeine Nutzermeldung.
• Für Nutzende sichtbare Fehlerbehandlung. Eine Anwendung, die bei einem Problem ein leeres Fenster zeigt, wirkt defekt, selbst wenn ihre Logik fehlerfrei ist.
• Test mit echten Daten. Eine Anwendung, die mit drei Beispieldatensätzen funktioniert, kann bei zehntausend auseinanderfallen.

Regel: Wir streichen Funktionen, nicht die Anforderungen, die für den sicheren Betrieb des aktuellen Umfangs nötig sind. Jedes „Fundament“ muss sich aus Risiko und Nutzungsweise des MVP ableiten, nicht aus einer hypothetischen Version in einigen Jahren.

Woran man erkennt, dass ein MVP zu groß ist

Vier Warnsignale:

Signal	Was es bedeutet
Es gibt keinen Termin und kein Budgetlimit	Der Umfang hat keine reale Grenze
Sie können ihn nicht in einem Satz beschreiben	Der Umfang ist noch nicht entschieden
Jede neue Rolle braucht einen eigenen Ablauf und Berechtigungen	Prüfen Sie, ob sie für die getestete Hypothese nötig ist
Die Antwort auf „Was, wenn wir das nicht machen?“ lautet „Es wäre dann eben schöner“	fällt weg

Woran man erkennt, dass ein MVP zu klein ist

Auch ein zu enger Umfang kann keinen verlässlichen Test liefern:

• Das versprochene Ergebnis lässt sich nicht prüfen. Ein manueller Schritt oder eine Tabelle kann ein bewusster Teil des MVP sein, sofern der Nutzer weiterhin Wert erhält und das Team die richtige Hypothese misst.
• Es gibt keine Möglichkeit zu messen, ob es geholfen hat. Ohne Ausgangspunkt und zur Hypothese passende Kennzahlen erfahren Sie nicht, ob sich der nächste Schritt lohnt.
• Die Version ist so eng, dass der Nutzer keinen Wert erkennt. Dann erhalten Sie kein Feedback, sondern Gleichgültigkeit.

Was kostet das?

Unser Preisrahmen vom August 2026 für ein Einstiegsprodukt: 15.000–35.000 PLN netto, ungefähr 4–6 Wochen und ein Festpreis für den definierten Umfang. Der Termin gilt für einen zentralen Ablauf, verfügbare Daten und eine begrenzte Zahl von Integrationen; einen größeren Umfang kalkulieren wir als separates Projekt. Ein Festpreis verlangt Abnahmekriterien, Annahmen auf Kundenseite und Regeln für Änderungen.

Wenn der Umfang noch nicht klar ist, kann die erste Phase ein Discovery für 3.000–8.000 PLN netto sein, das die für die Kalkulation nötigen Annahmen ordnet. Mehr zu den Preisrahmen: Was kostet eine Webanwendung?.

Was nach der Einführung des MVP zu tun ist

Ein MVP ist kein Ziel, sondern ein Werkzeug für die nächste Entscheidung. Legen Sie das Messfenster nach Nutzungshäufigkeit und untersuchtendem Verhalten fest:

1. Vergleichen Sie die Nutzung mit der erwarteten Aufgabe. Fehlende Nutzung kann eine überflüssige Funktion bedeuten, aber auch ein Problem bei Auffindbarkeit, Zugang oder Auswahl der Zielgruppe.
2. Sammeln Sie Fragen, nicht Wünsche. „Wo finde ich X?“ weist auf ein Interface-Problem hin, „Ich möchte Y“ auf die Idee einer einzelnen Person.
3. Entscheiden Sie über die nächste Phase anhand von Daten. Dafür war die ganze Disziplin beim Umfang da.

Häufige Fragen

Lässt sich ein MVP später erweitern, oder muss man neu schreiben?

Meist lässt es sich erweitern, wenn der Umfang klare Grenzen hat und Datenmodell sowie Berechtigungen zum aktuellen Prozess passen. Ein Umbau kann jedoch nicht ausgeschlossen werden: Eine Änderung von Geschäftsmodell, Größe oder regulatorischen Anforderungen kann eine andere Architektur erzwingen.

Muss ein MVP schön aussehen?

Es muss verständlich, zugänglich und ausreichend konsistent sein, damit die visuelle Ebene das Testergebnis nicht verfälscht. Eine ausgearbeitete Markensprache ist bei einem kundenorientierten Produkt wichtiger, aber auch ein internes Werkzeug braucht klare Hierarchie, Fehlerzustände und Rückmeldung.

Wer sollte über das Streichen von Funktionen entscheiden?

Die für das Geschäftsergebnis verantwortliche Person sollte die Entscheidung gemeinsam mit technischem Team, Sicherheit und – falls nötig – Rechtsberatung treffen. Kosten sind ein Kriterium, dürfen aber den Einfluss der Funktion auf die getestete Hypothese und den sicheren Betrieb nicht verdecken.

---

Wir bieten ein MVP in 4–6 Wochen zu einem Festpreis für den vereinbarten Umfang an, weil Etappierung das Risiko auf beiden Seiten senkt. Wenn Sie eine Idee haben und nicht wissen, was in die erste Version gehört, schreiben Sie uns.