MVP entwickeln: Umfang, Zeitplan und was Sie streichen sollten

Um ein MVP (Minimum Viable Product) zu entwickeln und zu launchen, wählen Sie einen Nutzer, ein Problem und einen Weg durch Ihr Produkt, bauen nur das, was dieser Weg braucht, und bringen es innerhalb von Wochen statt Monaten zu echten Menschen. Alles andere wartet, bis die Daten zeigen, dass es sich lohnt. Das ist schon der ganze Trick. Schwierig ist nur, daran festzuhalten, wenn die Feature-Liste spannend wird.

Dieser Leitfaden führt Sie durch Umfang, Zeitplan, Technologiewahl und eine Streichliste, die Sie direkt im nächsten Planungsmeeting verwenden können.

#Was ein MVP ist (und was nicht)

Ein MVP ist die kleinste Version Ihres Produkts, mit der Sie herausfinden, ob Menschen es tatsächlich wollen. Es ist weder eine Billigversion des fertigen Produkts noch eine Demo mit Attrappen-Buttons. Es muss für echte Nutzer funktionieren – nur eben für eine eng umrissene Aufgabe.

Eine hilfreiche Denkweise:

• Minimum – nur das, was nötig ist, um den Kernnutzen einmal von Anfang bis Ende zu liefern.
• Viable (tragfähig) – gut genug, dass ein echter Mensch es nutzen kann, ohne dass Sie danebenstehen.
• Product – Menschen können es finden, sich registrieren, es nutzen und (idealerweise) dafür bezahlen.

Was ein MVP nicht ist: ein Pitch Deck, ein Figma-Prototyp (ein guter Schritt vor dem MVP) oder „Version 1.0 mit allem, was uns eingefallen ist, nur ohne Feinschliff“.

#Schritt 1: Den Kernablauf Ihres MVP definieren

Bevor Sie einen einzigen Screen entwerfen, schreiben Sie einen Satz auf:

[Nutzer] möchte [X tun], damit [Ergebnis]. Heute löst er das mit [Behelfslösung].

Beschreiben Sie dann den Kernablauf (Core Loop) – die Schritte vom Ankommen bis zum erlebten Nutzen. Bei einer Buchungs-App in Chișinău könnte das sein: Website öffnen → Leistung wählen → Uhrzeit wählen → bestätigen → Erinnerung erhalten. Fünf Schritte. Alles, was nicht zu diesen Schritten gehört, ist ein Kandidat für die Streichliste.

Wenn Sie den Ablauf nicht in fünf bis sieben Schritten beschreiben können, ist der Umfang vermutlich noch zu breit. Grenzen Sie die Zielgruppe ein („Salons in einer Stadt“ statt „alle Dienstleister“), bis es passt.

#Schritt 2: Umfang mit MoSCoW festlegen

Ordnen Sie jede Feature-Idee einer von vier Kategorien zu:

Bauen Sie für den Launch nur die Spalte Must. Seien Sie dabei ehrlich – Gründer schmuggeln gern „Should“-Punkte in „Must“. Ein guter Test: Würde ein Nutzer das Produkt ohne diese Funktion ablehnen? Wenn nicht, rutscht sie nach unten.

#Schritt 3: Klug streichen – was meist zuerst gehen kann

Diese Funktionen kosten viel Zeit und entscheiden selten über den Erfolg eines MVP:

• Admin-Bereiche. Anfangs reichen oft eine Tabelle, Airtable oder die Oberfläche der Datenbank. Einen richtigen Admin-Bereich können Sie später bauen.
• Komplexe Rollen und Berechtigungen. Starten Sie mit „Nutzer“ und „Admin“.
• Mehrere Sprachen. Launchen Sie in der Sprache Ihrer ersten Zielgruppe. In Moldau ist das oft zuerst Rumänisch oder Russisch – die andere Sprache kann folgen, sobald Sie Zugkraft sehen (die Struktur sollten Sie aber dafür vorbereiten).
• Social Logins überall. E-Mail oder ein einziger Anbieter reicht völlig.
• Eigene Analytics-Dashboards. Nutzen Sie ein Standard-Analytics-Tool.
• Automatisierte Zahlungen. Bei geringen Volumina funktionieren anfangs auch Rechnungen oder ein einfacher Zahlungslink.
• Beide App Stores ab Tag eins. Eine PWA oder responsive Web-App validiert die Idee oft schneller – siehe PWA vs. React Native.

Was Sie nicht streichen sollten: grundlegende Sicherheit, Datensicherungen, eine funktionierende Registrierung, verständliche Fehlermeldungen und die Möglichkeit, Sie zu kontaktieren. Fehlende Funktionen verzeihen Nutzer; verlorene Daten nicht.

#Schritt 4: Den passenden technischen Ansatz wählen

Die Technologiewahl sollte sich nach dem Umfang richten, nicht umgekehrt.

Ein „Concierge-MVP“ – bei dem Sie die Arbeit hinter einer einfachen Landingpage manuell erledigen – wird unterschätzt. Wenn sich niemand für die manuelle Version anmeldet, rettet sie auch die automatisierte nicht.

#Schritt 5: Ein realistischer MVP-Zeitplan

Der Zeitrahmen hängt vom Umfang ab, die Phasen sind aber immer ähnlich:

1. Discovery (etwa 1 Woche). Kernablauf, MoSCoW-Liste, User Flow, ein kurzes Projekt-Briefing.
2. Design (1–2 Wochen). Wireframes der Kern-Screens, danach UI nur für diese Screens.
3. Entwicklung (einige Wochen). Meist die längste Phase. Wöchentliche Demos sorgen dafür, dass alle ehrlich bleiben.
4. Test (etwa 1 Woche). Echte Geräte, echte Daten, eine Handvoll echter Nutzer.
5. Launch und Lernen (fortlaufend). Veröffentlichen, beobachten, was Menschen wirklich tun, mit ihnen sprechen.

Ein eng gefasstes MVP liegt typischerweise irgendwo zwischen einigen Wochen und einigen Monaten. Wächst eine Schätzung darüber hinaus, ist das meist ein Umfangs- und kein Tempoproblem.

#Schritt 6: Vor dem Launch festlegen, was „Erfolg“ bedeutet

Wählen Sie zwei oder drei Signale, die Sie nach dem Launch prüfen – sonst wirkt jedes Ergebnis irgendwie „vielversprechend“. Beispiele:

• Wie viele Besucher den Kernablauf mindestens einmal abschließen.
• Wie viele innerhalb von ein, zwei Wochen wiederkommen und es erneut tun.
• Wie viele Ja sagen, wenn Sie sie bitten zu bezahlen (oder vorzubestellen).

Legen Sie die Schwellenwerte fest, bevor Sie die Zahlen sehen. Und sprechen Sie dann mit den Nutzern – fünf ehrliche Gespräche lehren oft mehr als ein Dashboard.

#Checkliste für den MVP-Launch

• Problemstellung in einem Satz aufgeschrieben
• Kernablauf mit 5–7 Schritten
• Nur „Must“-Funktionen im Launch-Umfang
• Technischer Ansatz gewählt (No-Code, Web/PWA oder App)
• Analytics und Fehler-Tracking eingerichtet
• Datenschutzerklärung und grundlegende Nutzungsbedingungen veröffentlicht
• Backups und grundlegende Sicherheit vorhanden
• Feedback-Kanal (Formular, Chat oder E-Mail) sichtbar
• Erfolgssignale und Schwellenwerte vereinbart
• Liste der „nächsten“ Funktionen geparkt – nicht gelöscht

#FAQ

#Wie lange dauert es, ein MVP zu entwickeln?

Bei fokussiertem Umfang meist zwischen einigen Wochen und einigen Monaten. No-Code- und PWA-MVPs sind tendenziell schneller; Apps für beide Stores dauern wegen Tests und Store-Prüfung länger.

#Sollte mein MVP eine Website oder eine Mobile App sein?

Gehen Sie davon aus, wo Ihre Nutzer schon sind und was der Kernablauf braucht. Wenn er keine Push-Benachrichtigungen, Hintergrundprozesse oder Gerätehardware erfordert, ist eine Web-App oder PWA oft der schnellere und günstigere Weg zur Validierung.

#Was ist der Unterschied zwischen einem Prototyp und einem MVP?

Ein Prototyp zeigt, wie das Produkt funktionieren könnte – er dient zum Testen von Ideen und Usability. Ein MVP funktioniert tatsächlich für echte Nutzer mit echten Daten, sodass Sie Nachfrage und Verhalten testen können.

#Lässt sich der MVP-Code später weiterverwenden?

Oft ja – besonders, wenn er mit einer sauberen API und einem verbreiteten Stack gebaut ist. Manche Teile werden beim Wachstum neu geschrieben, und das ist normal. Ziel eines MVP ist Lernen, nicht perfekter Code.

#Bereit, Ihren Umfang festzulegen?

Der schnellste Weg zu einem ehrlichen Umfang ist, ihn aufzuschreiben. Öffnen Sie den Projekt-Konfigurator, wählen Sie den Typ (Website, PWA oder Mobile App) und die unverzichtbaren Funktionen – Sie erhalten eine Schätzung und einen klaren Ausgangspunkt. Lieber erst darüber sprechen? Sehen Sie sich an, wie ich Apps und Websites entwickle.