MVP oder direkt komplett — wie du den Funktionsumfang planst

„Wir wollen erstmal nur ein MVP” ist der Satz, den wir am häufigsten hören — und meistens ist damit gemeint: kleines Produkt, halber Scope, Rest später. Der Begriff stammt aus Eric Ries’ „The Lean Startup” und meint dort etwas anderes: die kleinste Version, mit der du eine konkrete Hypothese am Markt testbar machst. Nicht „weniger Features”, sondern „genug, dass echte Nutzer:innen echtes Verhalten zeigen”. Daraus folgt die Heuristik, mit der wir Scope-Diskussionen in einer Session zu einem belastbaren V1-Schnitt führen.

Was MVP heißt — und was nicht

Drei Abgrenzungen, die in jeder zweiten Diskussion fehlen:

• MVP ≠ Prototyp. Ein Prototyp testet eine Idee in einem Mockup. Ein MVP testet eine Idee mit echten Nutzer:innen unter realen Bedingungen — inklusive Fehlerfällen, Last, Onboarding.
• MVP ≠ Beta. Eine Beta ist ein fast-fertiges Produkt mit kleinem Nutzerkreis zur Stabilisierung. Ein MVP liegt davor: es darf rough sein, aber es muss tragen, was es verspricht.
• MVP ≠ unfertig. Was drin ist, muss vollständig funktionieren. Was nicht drin ist, darf fehlen — aber das, was da ist, darf nicht halb-implementiert sein.

Der Unterschied klingt akademisch, ist aber teuer, wenn er wegfällt: ein „kleiner V1” wird oft zu einem „nicht ganz fertigen V1”, und damit zerstört er die Hypothese, statt sie zu testen.

Der Kern-Test: was V1 zwingend können muss

Vor jedem Feature-Streit hilft eine kleine Sequenz mit drei Fragen:

1. Welches Problem löst die App in einem Satz? Wenn du dafür zwei Sätze brauchst, ist der Scope schon zu breit.
2. Wer nutzt die App das erste Mal — und in welchem Moment spürt diese Person Wert? Das ist der Aha-Moment. Alles zwischen App-Start und diesem Moment gehört in V1, alles dahinter ist verhandelbar.
3. Was passiert, wenn dieser eine Use-Case nicht funktioniert? Wenn die Antwort „dann ist die App sinnlos” lautet, ist es Kern-Funktionalität. Wenn es nur Komfort ist, gehört es nicht in V1.

Praxis-Test: schreib auf einer Seite Papier den End-to-End-Flow für genau einen Nutzer, der genau eine Sache erledigt. Wenn das Team einig ist, dass dieser Flow das Wertversprechen abdeckt, hast du den Kern. Alles, was nicht an diesem Flow hängt, ist V1.5 oder später.

Die häufigsten Scope-Fehler

Drei Anti-Pattern, die wir regelmäßig sehen — meist in Kombination:

Über-Engineering auf Verdacht

Microservices, eigene Auth, Multi-Tenant-Datenmodelle für eine App, die in V1 hundert Nutzer:innen sieht. Jede dieser Entscheidungen kostet jetzt Zeit und macht das System komplexer, ohne dass der Nutzen heute messbar wäre. Default in den ersten zwölf Monaten: monolithischer Backend-Service, eine Datenbank, gemanagter Auth-Provider, ein Hosting-Setup. Skalierungs-Architektur kommt, wenn die Last sie verlangt — und nicht früher.

Feature-Bloat aus dem Lastenheft

Lastenhefte aus Stakeholder-Workshops haben einen unangenehmen Effekt: jede:r will, dass das eigene Anliegen drinsteht. Am Ende stehen 60 Features auf der Liste, von denen 50 nichts zum Aha-Moment beitragen. Faustregel: wenn du nicht in einem Satz erklären kannst, warum ein Feature in V1 drin sein muss (nicht „später wäre es schön”), gehört es nicht hinein.

Vorgegebener Vollausbau

„Wenn schon, denn schon” — wer in eine App investiert, will am Tag des Launches alle Features sehen, die die eigene Vision beschreibt. Das Argument „weniger ist heute schneller” überzeugt rational, das Bauchgefühl sagt „das wirkt unfertig”. Hilft nur eines: Stakeholder früh in die Priorisierung einbeziehen, ihre Wünsche dokumentieren, einen klaren Trigger nennen, ab wann das Feature kommt. Was sichtbar geparkt ist, wirkt anders als was vergessen wirkt.

MoSCoW als Priorisierungs-Werkzeug

MoSCoW ist die eine Methode, die wir in jedem Scope-Workshop einsetzen, weil sie Trade-offs explizit macht. Vier Kategorien:

• Must-have. Ohne dieses Feature ist V1 nicht funktionsfähig. Wenn du es streichst, wird die App nicht ausgeliefert. Das ist eine harte Aussage — nicht „wäre sehr unschön”.
• Should-have. Die App funktioniert technisch ohne, aber das Erlebnis hat sichtbare Schwächen. Should-haves landen in V1 nur, wenn nach den Must-haves Zeit übrig ist — und werden sonst V1.5.
• Could-have. Nettes Detail, sichtbarer Komfortgewinn, aber nicht entscheidend. Diese Liste bleibt für später dokumentiert. Sie wird nicht in V1 umgesetzt, auch wenn theoretisch Zeit wäre — die Zeit gehört in Stabilität, Performance und Polish der Must-haves.
• Won’t-have (this time). Aktiv ausgeschlossen. Wichtige Kategorie, weil sie erlaubt, ein Feature zu nennen und gleichzeitig zu sagen „nicht in dieser Runde”.

Die Disziplin liegt in den Verhältnissen: ein gesunder MVP-Scope hat etwa 60 % Must-have, 20 % Should-have, 20 % Won’t-have-this-time. Wenn deine Liste 80 % Must-have ist, ist „Must” nicht hart genug definiert.

Wie ein V1 in acht Wochen passt

Acht Wochen ist die Zeitspanne, in der ein erfahrenes Zwei-Personen-Team einen vollständigen V1 für die meisten App-Klassen baut — inklusive Auth, Datenmodell, Kern-Flow, Onboarding, einer Zahlungs- oder Berechtigungs-Logik und App-Store-Submission. Sechzehn Wochen sind oft auch noch MVP, vier Wochen sind zu wenig für etwas, das im Store stehen soll.

Praktische Reduktions-Schritte, in dieser Reihenfolge:

1. Nutzer-Rollen halbieren. Drei Rollen (Admin, Standard, Gast) werden meist zu zwei oder einer mit Backend-Bypass. Jede zusätzliche Rolle multipliziert die UI-Permutation und die Test-Last.
2. Datenmodell ausdünnen. Statt zehn Entitäten mit voller Relationen-Logik: vier Entitäten, einfache 1:n-Beziehungen, Aggregations-Reports erst in V1.5.
3. Onboarding minimieren. Login plus die kürzeste mögliche „erstes Wert-Erlebnis”-Strecke. Tutorials, Walkthroughs, Personalisierungs-Wizards kommen später, wenn die Daten zeigen, wo Nutzer:innen abspringen.
4. Edge-Cases priorisieren. Welche zehn Edge-Cases gibt es, welche fünf decken 90 % aller realen Vorkommen ab? Die fünf gehören in V1, die anderen werden dokumentiert und in V1.5 nachgezogen.
5. Plattformen reduzieren. Eine Plattform priorisieren, statt iOS und Android parallel zu submitten — siehe Native vs. Cross-Plattform vs. PWA. Spart in V1 erstaunlich viel Test- und Submission-Aufwand.

Wenn der Scope nach diesen fünf Schritten immer noch zwölf Wochen verlangt, ist die Vision wahrscheinlich nicht ein Produkt, sondern zwei. Dann ist die ehrliche Diskussion: welches der beiden testen wir zuerst?

Wann ein MVP kein MVP sein darf

Drei Klassen, in denen das MVP-Modell nicht trägt:

• Regulierte Branchen mit Zertifizierungspflicht. Medizinprodukte mit MDR-Klassifizierung, Banking-Apps mit BaFin-Anforderungen, Apps mit DSGVO-Auftragsverarbeitung in besonders sensiblen Datenkategorien — Audit-, Doku- und Test-Anforderungen sind binär. Was reduzierbar ist, sind Features in der Fachlogik, nicht das Compliance-Fundament. Mehr dazu im Guide DSGVO-Wartungspflichten für Apps.
• Hardware-gekoppelte Produkte mit Sicherheits-Relevanz. Eine Companion-App, die Industrie-Hardware steuert oder Maschinen-Sicherheit beeinflusst, kann nicht „erstmal nur das Wichtigste” liefern. Die Sicherheits-Schichten gehören vollständig hinein.
• Apps, die Vertrauen als Kern-Wertversprechen tragen. Banking, Versicherung, Gesundheits-Plattformen mit Patientendaten — wenn das wahrgenommene Sicherheits-Niveau Teil des Produkts ist, untergräbt ein „MVP-Look” das Wertversprechen. „Lean” passiert hier in der Roadmap nach Launch, nicht im V1-Scope.

In allen drei Fällen ist die richtige Frage nicht „MVP oder Vollausbau”, sondern: welche Kern-Domäne baue ich zuerst vollständig aus, welche kommt im nächsten Release. Das ist eine Roadmap-Frage, keine Scope-Reduktions-Frage.

Beispiel-Roadmap mit Triggern statt Daten

So sieht eine realistische MVP-Roadmap am Beispiel einer fiktiven B2C-Buchungs-App aus:

V1 — Wochen 1 bis 8. Auth (Email plus Apple/Google), Suche, Detail-Ansicht, Buchungs-Flow inkl. Stripe, Buchungs-Übersicht für Endkunden, Basis-Admin im Backend für Anbieter:innen. Eine Plattform (iOS), eine Sprache (Deutsch), keine Push, keine Personalisierung. Submission Woche 9.

V1.5 — Wochen 10 bis 14, ausgelöst durch: mindestens 100 wöchentlich aktive Nutzer:innen oder Top-3 Support-Anfragen, die wiederholt dasselbe Feature betreffen. Inhalt: Push-Notifications für Buchungs-Updates, Android-Build, Anbieter-Self-Service-Onboarding, Buchungs-Storno-Flow, Stripe-Connect für Auszahlungen.

V2 — Quartal 2 nach Launch, ausgelöst durch: stabiler Wachstumstrend (4 Wochen in Folge ≥ 10 % Wachstum) oder ein klarer Use-Case-Erweiterungs-Wunsch aus den Top-5 Kunden-Interviews. Inhalt: Empfehlungs-Logik, Mehrsprachigkeit, Loyalty-Programm, API für externe Integrationen, größere UX-Überarbeitung auf Basis der V1-Daten.

Was diese Roadmap leistet: jeder Schritt hat einen expliziten Trigger statt einer Datums-Annahme. Wenn V1 schlechter performt als erhofft, ist V1.5 nicht „verspätet”, sondern korrekt verzögert: erst Hypothese validieren, dann investieren. Wenn V1 besser performt, kann V1.5 vorgezogen werden, ohne dass irgendwer „außer der Reihe” arbeitet. Datums-Roadmaps werden gegen Daten verteidigt, Trigger-Roadmaps werden gegen Realität geprüft — letzteres ist gesünder für alle Beteiligten.

Wenn du mit einer konkreten Idee in dieser Logik landen willst: beschreib uns die App in drei Sätzen — wer nutzt sie, welches Problem löst sie, was ist der eine Aha-Moment? Wir gehen mit dir den MoSCoW-Schnitt durch und sagen ehrlich, ob acht Wochen für deinen V1 realistisch sind. Schick die Eckdaten über das Kontaktformular, Antwort in 24 Stunden. Mehr Kontext: Custom-Dev vs. No-Code/Low-Code für die Stack-Wahl, wenn ein No-Code-Pilot der schnellere Validierungspfad ist.