Von der Idee zum MVP in 12 Wochen: Ein realistischer Zeitplan

12 Wochen vom Briefing zum produktiven MVP – das ist ambitioniert, aber möglich. Mit der Betonung auf "möglich": Es gelingt nur mit klarem Scope, schneller Entscheidungsfindung und einem eingespielten Entwicklungsteam.

Wer mit unklaren Anforderungen startet, Entscheidungen verzögert oder jede Woche neue Features einbringt, landet nicht in Woche 12 im Markt, sondern in Woche 24 mit einem halbfertigen Produkt. Dieser Beitrag zeigt realistisch, was wann passiert – und welche Voraussetzungen auf Auftraggeberseite erfüllt sein müssen.

Voraussetzungen für einen 12-Wochen-MVP

Kurz: Bevor der erste Sprint startet, müssen diese Rahmenbedingungen stimmen:

Bevor der erste Sprint startet, müssen diese Rahmenbedingungen stimmen:

Klare Vision, engagierter Product Owner. Eine Person mit Entscheidungsgewalt, die Anfragen innerhalb von 24–48 Stunden beantwortet. Entscheidungsstau ist der häufigste Grund für Verzögerungen.

Bereits gedachter Scope. Das Team braucht nicht "von null" starten. Erste User Stories, grobe Wireframes oder eine Productbrief erleichtern den Discovery-Sprint enorm.

Budget freigegeben. Keine 12-Wochen-Entwicklung funktioniert mit wöchentlichen Budgetdiskussionen. Das Budget steht, der Scope steht – dann kann das Team arbeiten.

Technische Entscheidungsbereitschaft. Manche Entscheidungen (Hosting, Datenbanktyp, Framework) müssen schnell getroffen werden. Wer technische Präferenzen hat, sollte diese im ersten Meeting kommunizieren.

Woche 1–2: Discovery und Scope-Definition

Was passiert:

• Kick-off mit allen Stakeholdern
• User Personas und User Stories für Primärnutzer erstellen
• Features nach MoSCoW (Must/Should/Could/Won't) priorisieren
• Technologiearchitektur festlegen (Backend, Frontend, Hosting, Datenbanktyp)
• Integrationsanforderungen klären (welche externen Systeme, APIs)
• MVP-Scope schriftlich vereinbaren (Scope-Dokument)
• Zeitplan und Meilensteine finalisieren

Ergebnis: Verbindlicher Scope, technische Architekturskizze, Sprint-Plan für Wochen 3–12.

Häufiger Fehler: In dieser Phase Features "noch schnell" hinzufügen. Jedes Feature in Discovery kostet in Entwicklung das 5-fache.

Woche 3–4: UX-Design und Prototyp

Was passiert:

• Wireframes für alle Kernscreens
• Klickbarer Prototyp (Figma, InVision o.ä.)
• Erster Nutzer-Test mit dem Prototyp (3–5 Personen aus der Zielgruppe reichen)
• UX-Anpassungen auf Basis Feedback
• Finaler Design-Handoff ans Entwicklungsteam

Ergebnis: Klickbarer, validierter Prototyp. Entwickler haben ein klares Zielbild.

Häufiger Fehler: Design-Phase überspringen oder abkürzen. Dann findet das UX-Feedback während der Entwicklung statt – 5x teurer als vorher.

Woche 5–8: Kern-Entwicklung (Sprint 1 + 2)

Sprint 1 (Woche 5–6):

• Basis-Infrastruktur aufsetzen (Datenbank, Backend, Hosting)
• Authentifizierung und Nutzerrollen implementieren
• Erste Kernfunktionen des kritischen Nutzerpfads entwickeln
• Demo am Ende von Sprint 1

Sprint 2 (Woche 7–8):

• Verbleibende Must-Have-Features
• Integrationen mit externen Systemen (wenn geplant)
• Erste interne Tests und Bugfixing
• Demo am Ende von Sprint 2 mit Stakeholdern

Ergebnis: Vollständig implementierter MVP-Scope, intern getestet.

Häufiger Fehler: Sprint-Demos überspringen. Dann kommt das Feedback gesammelt am Ende – zu spät für Korrekturen.

Woche 9–10: Beta-Testing

Was passiert:

• 5–20 ausgewählte Erstnutzer aus der Zielgruppe erhalten Zugang
• Strukturierte Aufgaben und Beobachtung (oder Remote-Testing)
• Qualitative Interviews mit Testnutzern
• Kritische Bugs priorisieren und fixen
• Must-Have-Verbesserungen aus Nutzerfeedback einarbeiten

Ergebnis: Validierter MVP, bekannte Prioritäten für die erste Iteration nach Launch.

Wichtig: Beta-Test nicht mit internen Mitarbeitern durchführen, die den Kontext kennen. Echte Zielgruppen-Mitglieder müssen testen.

Woche 11–12: Hardening und Launch

Was passiert:

• Verbleibende Bugs fixen
• Performance-Tests unter Last
• Sicherheits-Grundchecks (Eingabevalidierung, Authentifizierungssicherheit)
• Produktions-Deployment einrichten
• Monitoring und Error-Tracking aufsetzen (Sentry, Datadog o.ä.)
• Onboarding erster Produktionsnutzer
• Go-live

Ergebnis: Produktiver MVP, erste echte Nutzer im System.

Was nach Woche 12 passiert

Kurz: Der Launch ist nicht das Ende, sondern der Anfang des echten Lernens.

Der Launch ist nicht das Ende, sondern der Anfang des echten Lernens. Jetzt zählen Nutzungsmetriken, qualitatives Feedback und Retention-Rates. Die Ergebnisse fließen in Sprint 3, 4, 5 – die Iteration, mit der aus dem MVP ein reifes Produkt wird.

Typischer Iterationsrhythmus nach dem MVP-Launch: alle 3–4 Wochen ein neues Release mit verbesserter Funktionalität – getrieben von Nutzer-Feedback statt von ursprünglichen Annahmen.

Fazit

Kurz: 12 Wochen zum MVP sind realistisch – mit den richtigen Voraussetzungen.

12 Wochen zum MVP sind realistisch – mit den richtigen Voraussetzungen. Schnelle Entscheidungen, klarer Scope, engagiertes Team. Wer die Voraussetzungen nicht erfüllt, sollte 16–20 Wochen planen – das ist ehrlicher als falsche Versprechen.

Unser Team begleitet MVP-Entwicklungsprojekte strukturiert von der ersten Scope-Definition bis zum produktiven Launch und darüber hinaus.

Häufig gestellte Fragen (FAQ)

Kurz: Was passiert, wenn der Scope in Woche 6 noch nicht klar ist?

Was passiert, wenn der Scope in Woche 6 noch nicht klar ist? Das Projekt verschiebt sich entsprechend. 12 Wochen Entwicklung setzt voraus, dass der Scope zu Beginn von Woche 3 feststeht. Scope-Klärung nach Entwicklungsstart verdoppelt typisch die Projektlaufzeit.

Können wir parallel testen und entwickeln? Ja. Interne Tests laufen parallel zur Entwicklung (QA). Beta-Testing mit echten Nutzern beginnt erst, wenn der MVP-Scope vollständig implementiert ist.

Was wenn das Feedback aus dem Beta-Test grundlegende Änderungen fordert? Dann hat der MVP seinen Zweck erfüllt – er hat Fehlentscheidungen aufgedeckt, bevor das volle Budget investiert wurde. Grundlegende Änderungen fließen in Iteration 1 nach dem Launch, nicht in den MVP zurück.

Können Feature-Wünsche nach Sprint 1 noch in den MVP? Nur wenn ein anderes Feature rausgenommen wird (Scope-Trade). Ein MVP-Budget ist kein offenes Konto – Ergänzungen kommen erst in die Iteration nach dem Launch.