Was in ein Minimum Viable Product gehört (und was nicht)
Wie du definierst, was in dein MVP kommt und was nicht. Ein Framework, um das Wesentliche vom Nice-to-have zu trennen – mit echten Beispielen und der Liste an Features, die fast nie in einen ersten Launch gehören.
Das Wort „minimal" in MVP ist am schwersten einzuhalten. Denn es gibt immer einen scheinbar berechtigten Grund, noch ein Feature aufzunehmen: „Die Nutzer werden danach fragen", „die Konkurrenz hat es", „ohne das sieht es nicht nach einem fertigen Produkt aus".
Das Ergebnis ist ein MVP, das 4 Monate statt 6 Wochen dauert, doppelt so viel kostet wie geschätzt und noch immer die Frage nicht beantwortet hat, die seinen Bau rechtfertigte: Will das überhaupt jemand?
Dieser Leitfaden gibt dir ein Framework für die Entscheidung, was hinein- und was herausgehört – mit konkreten Beispielen und der Liste an Features, die – von sehr spezifischen Ausnahmen abgesehen – in keinen ersten Launch gehören.
Baust du dein Startup ohne technischen Mitgründer?
Der Definitionsfehler: was ein MVP wirklich ist
Ein MVP ist nicht die kleinste Version deines fertigen Produkts. Es ist das günstigste Experiment, das du durchführen kannst, um die wichtigste Frage über dein Geschäft zu beantworten.
Diese Frage ist meist eine davon:
- Ist jemand bereit, dafür zu zahlen, dieses Problem zu lösen?
- Kann unser Produkt das Problem besser lösen als die aktuellen Alternativen?
- Gibt es genug Nachfrage, um den Bau des vollständigen Produkts zu rechtfertigen?
Wenn das MVP als „Experiment zur Beantwortung von X" definiert wird, wird die Entscheidung, was aufzunehmen ist, objektiv: Ist dieses Feature nötig, um X zu beantworten? Wenn nicht, kommt es nicht ins MVP.
Das 3-Stufen-Framework
Ordne jedes vorgeschlagene Feature einer dieser drei Stufen zu:
Stufe 1 — Kritisch zur Beantwortung der zentralen Hypothese Ohne dieses Feature kann das MVP die Frage nicht beantworten, die seinen Bau rechtfertigt. Wenn deine Hypothese lautet „Nutzer sind bereit, für X zu zahlen", brauchst du X und den Bezahlfluss. Ohne den Bezahlfluss kannst du die Hypothese nicht beantworten.
Stufe 2 — Nötig, damit das Produkt funktioniert, aber kein Differenzierungsmerkmal Registrierung, Login, grundlegende Kontoverwaltung, transaktionale Bestätigungs-E-Mails. Diese Features müssen existieren, damit das Produkt nutzbar ist, aber sie sind nicht die, die dir verraten, ob der Markt das Produkt will.
Stufe 3 — Wünschenswert, aber nicht essenziell für die Validierung Alles andere. Push-Benachrichtigungen, Integrationen mit externen Tools, fortgeschrittene Personalisierung, ein vollständiges Admin-Panel, Mehrsprachigkeit, Dark Mode. Features, die das Produkt verbessern, aber die Fähigkeit des MVP, die zentrale Hypothese zu beantworten, nicht beeinflussen.
Die Regel: Ins MVP kommen nur Stufe 1 und Stufe 2. Stufe 3 kommt in die v1.1.
Was fast nie in ein MVP gehört
Ein vollständiges Admin-Panel
Beim ersten Launch kann das Team die Daten direkt aus der Datenbank oder mit einfachen Tools verwalten (Retool, Metabase, sogar einer exportierten Tabelle). Ein vollständiges Admin-Panel – mit Nutzerverwaltung, Rollen, Datenexport, erweiterten Filtern – ist ein 3–4-Wochen-Projekt, das dem Endnutzer keinen Mehrwert bietet.
Ausnahme: Wenn das Produkt eine operative Komponente hat, bei der das Startup-Team Echtzeit-Abläufe manuell steuern muss (Content-Moderation, Support, der schnelle Aktionen auf der Datenbank erfordert), kann ein minimales Admin-Panel von Anfang an nötig sein.
Push-Benachrichtigungen und Marketing-E-Mails
App-Push-Benachrichtigungen und E-Mail-Marketing-Kampagnen sind Retention-Tools. Retention ist ein Problem der Wochen 4–8 eines Produkts in Produktion, nicht des Launch-Tags.
Im MVP reichen eine Bestätigungs-E-Mail zur Registrierung und eine transaktionale E-Mail für kritische Aktionen (Buchung bestätigt, Zahlung verarbeitet).
Integration mit jedem möglichen Anbieter
„Wir brauchen Login mit Google, Facebook, Apple und E-Mail." Im MVP reicht der E-Mail-Login für 80 % der Produkte. Google-Login kostet 1–2 Tage Entwicklung; Apple-Login kostet 3–5 Tage (Apples Einrichtungsprozess ist notorisch komplex). Diese Tage sind besser in den Core-Flow investiert.
Mehrsprachigkeit
Sofern das MVP nicht ausdrücklich für einen zweisprachigen Markt gebaut wird, ist Mehrsprachigkeit v1.1. Eine App nachträglich zu internationalisieren ist teurer, als es von Anfang an einzubauen, aber günstiger, als den Launch dafür zu verschieben.
Ein Test- / Sandbox-Modus für Nutzer
Testumgebungen sind Werkzeuge für Enterprise-Kunden. Im MVP mit deinen ersten 50–100 Nutzern kannst du Testfälle manuell handhaben.
„Wenn das Unternehmen wächst"-Features
„Wenn wir 10.000 Nutzer haben, müssen Administratoren rollenbasierte Berechtigungen verwalten können." Das stimmt. Es ist auch irrelevant für ein Produkt, das heute 0 Nutzer hat. Skalierungs-Features werden gebaut, wenn sie gebraucht werden, nicht vorher.
Komplexe interne Metriken und Dashboards
Im MVP reicht ein einfaches Google Analytics + Sentry für Fehler. Ein internes Analytics-System mit individuellen Dashboards ist ein Produktmanagement-Tool, keine Launch-Anforderung.
Was sehr wohl in jedes MVP gehört
Der vollständige Core-Flow, reibungslos
Der Flow, der den zentralen Produktwert demonstriert, muss makellos sein. Nicht perfekt im Design, nicht vollständig in den Features, aber frei von Reibung, die den Nutzer davon abhält, den Moment zu erreichen, in dem er versteht, warum das Produkt wertvoll ist.
Wenn der zentrale Wert deines Produkts „X in Y Schritten erledigen" ist, muss dieser Flow perfekt funktionieren. Alles andere kann grob sein; dieser Flow nicht.
Registrierung und grundlegende Authentifizierung
Sie muss nicht ausgefeilt sein. Registrierung mit E-Mail + Passwort (oder Magic Link) reicht für die meisten Fälle. Was nicht versagen darf: die Bestätigungs-E-Mail, das Zurücksetzen des Passworts, die persistente Sitzung.
Ein Mechanismus, um Feedback zu sammeln
Das wird am häufigsten vergessen. Das MVP ist ein Experiment, und du brauchst Instrumente, um das Ergebnis zu messen. Mindestens: ein Feedback-Formular im Produkt, grundlegende Verhaltensanalyse (Mixpanel oder PostHog mit den Core-Events) und eine Möglichkeit, aktive Nutzer zu kontaktieren.
Grundlegende Fehlerbehandlung
Fehlermeldungen müssen nicht perfekt sein. Nötig ist, dass Fehler nicht stillschweigend passieren: Wenn etwas schiefgeht, weiß es der Nutzer und hat einen Weg, es zu lösen oder den Support zu kontaktieren.
Nicht verhandelbare Grundsicherheit
HTTPS, gehashte Passwörter, Zugangsdaten außerhalb des Codes, Authentifizierung auf allen Routen, die auf private Daten zugreifen. Diese sind nicht optional, auch wenn das MVP „nur zur Validierung" dient: Sie schützen echte Daten echter Nutzer.
Die Übung, die das Gespräch verändert
Wenn das Team debattiert, was ins MVP gehört, hilft diese Übung, die Debatte abzukürzen:
Schreibe auf eine Karte: „Das MVP validiert, dass [zentrale Hypothese]. Um sie zu validieren, muss der Nutzer [minimale Aktion] tun können."
Jedes Feature, das für diese minimale Aktion nicht nötig ist, kommt in die v1.1.
Die Hypothese zwingt dich, konkret zu sein. Und wenn du konkret bist, wird die Entscheidung, was aufzunehmen ist, viel einfacher.
Bei Collybrix definieren wir den MVP-Umfang, bevor eine einzige Zeile Code geschrieben wird, um sicherzustellen, dass das Gebaute die richtige Frage beantwortet. Erzähl uns, woran du arbeitest →
Mehr zum vollständigen MVP-Entwicklungsprozess: MVP-Entwicklung
Baust du dein Startup ohne technischen Mitgründer?