MVP in 4 Wochen? Umfang, Voraussetzungen und Testplan
Mit einem MVP bringen Sie eine erste Version Ihres Produkts zu Nutzern, bevor Sie das volle Budget investieren. Sie begrenzen den Umfang auf die Funktion, die Sie testen möchten, und beobachten, ob Menschen sie nutzen.
Vier Wochen können als begrenzter Arbeitsrahmen für einen klar umrissenen Versuch dienen. Ob darin ein nutzbares MVP entsteht, hängt unter anderem von Vorarbeit, Umfang, Team, Zugängen und verfügbaren Testpersonen ab. Ein fertiger Test beweist noch keine Marktnachfrage. Der folgende Plan ist ein Beispiel zur Vorbereitung, keine Liefer- oder Erfolgszusage.
1. Erst die offene Frage bestimmen
Bevor Sie Funktionen sammeln, beschreiben Sie das Problem: Wer erledigt welche Aufgabe heute, wo entsteht Aufwand und was soll sich ändern? Der GOV.UK Service Manual zur Discovery-Phase empfiehlt, Nutzerbedürfnisse und Einschränkungen vor einer Umsetzung zu untersuchen. Er legt dafür keine feste Dauer fest. Die Hinweise stammen aus der Entwicklung öffentlicher Dienste; sie belegen keine Vier-Wochen-Frist für ein Startup.
Formulieren Sie eine Annahme, die sich durch Beobachtung prüfen lässt. Ein fiktives Beispiel: „Serviceteams können eine Anfrage mit Ort, Problem und Foto ohne Rückfrage erfassen.“ Das ist enger als „Wir bauen eine erfolgreiche Serviceplattform“. Für die erste Frage lässt sich ein Ablauf testen; für die zweite fehlen noch Aussagen über Nachfrage, Zahlungsbereitschaft und Betrieb.
2. Prototyp, MVP und Pilot auseinanderhalten
MVP steht für Minimum Viable Product. Für die gemeinsame Planung verwenden wir die folgenden Arbeitsbegriffe. Entscheidend ist, welchen Nachweis die vereinbarte Fassung tatsächlich liefern kann.
| Form | Was Sie damit untersuchen | Was daraus nicht folgt |
|---|---|---|
| Prototyp | Verständnis, Bedienung oder technische Machbarkeit eines Ausschnitts | Dass ein produktionsreifer Dienst oder Nachfrage besteht |
| MVP | Ob eine kleine nutzbare Lösung eine konkrete Aufgabe für die Zielgruppe erfüllt | Dass alle späteren Funktionen oder dauerhafte Wirtschaftlichkeit belegt sind |
| Pilot | Nutzung unter begrenzten, vereinbarten Bedingungen mit Betreuung | Dass ein Betrieb für beliebig viele Nutzer bereits abgesichert ist |
Der GOV.UK-Leitfaden zur Alpha-Phase beschreibt Prototypen als Mittel, riskante Annahmen zu testen. Solcher Code muss noch keine Produktionsqualität haben. Für Ihr Projekt heißt das: Vereinbaren Sie ausdrücklich, ob am Ende ein Demonstrator, ein betreuter Test oder ein produktiv nutzbarer Kernablauf erwartet wird. Die Begriffe sollten keine unterschiedlichen Erwartungen verdecken.
3. Wann ein kurzer Zeitrahmen überhaupt planbar wird
Für einen vierwöchigen Versuch sollten Testfrage und Kernablauf bereits eingegrenzt sein. Die verantwortliche Person muss Entscheidungen zeitnah treffen können. Testpersonen, Inhalte, notwendige Zugänge und technische Ansprechpartner sollten verfügbar sein. Offene Schnittstellen, umfangreiche Datenübernahmen oder ungeklärte Freigaben gehören als Abhängigkeiten in den Plan.
Den Umfang zu verkleinern bedeutet nicht, notwendige Zugriffsrechte, Fehlerbehandlung oder den Schutz verwendeter Daten zu streichen. Ein Test mit mehreren Organisationen kann zum Beispiel schon im Kern eine Trennung ihrer Daten benötigen. Lassen sich diese Voraussetzungen nicht verantwortbar umsetzen, wird der Test enger gefasst oder der Zeitrahmen angepasst.
Prüfen Sie vor der Umsetzung auch die Plattform: Web-App oder native App beantworten unterschiedliche Anforderungen. Benötigte Gerätefunktionen, Verteilung und Freigaben gehören in die Planung. Eine Store-Veröffentlichung wird durch diesen Beispielplan nicht zugesagt.
4. Beispiel: vier Wochen bis zu einer dokumentierten Entscheidung
Der folgende Ablauf ist eine eigene Planungsvorlage für einen vorbereiteten, kleinen Versuch. Er setzt verfügbare Beteiligte und geklärte Abhängigkeiten voraus. Die Wochen sind Arbeitsblöcke, keine empirischen Durchschnittswerte. Wenn eine entscheidende Frage offenbleibt, ist eine Verlängerung oder ein Stopp sinnvoller als ein erzwungener Start.
| Arbeitsblock | Schwerpunkt | Greifbares Ergebnis |
|---|---|---|
| Woche 1 | Annahme, Zielgruppe und Testaufgabe schärfen; einen einfachen Ablauf zeigen | Abgegrenzter Umfang, offene Risiken und vorab festgelegte Entscheidungskriterien |
| Woche 2 | Kernablauf umsetzen oder technische Unsicherheit durch einen Prototyp prüfen | Vorführbarer Stand mit dokumentierten Grenzen |
| Woche 3 | Aufgaben mit passenden Testpersonen beobachten und Hindernisse bearbeiten | Beobachtungen je Aufgabe, Fehler und notwendige Anpassungen |
| Woche 4 | Ergebnisse gemeinsam bewerten; nächste Schritte und Betrieb klären | Entscheidung: fortführen, enger testen, ändern oder stoppen |
Im fiktiven Service-Beispiel könnte der Kern aus Anfrage erfassen, zuständige Person informieren und Status ansehen bestehen. Zusätzliche Auswertungen werden nur aufgenommen, wenn sie für die Testfrage nötig sind. Ob dieser Ablauf tatsächlich in den Zeitrahmen passt, wird erst nach Prüfung der Daten, Rollen und Anbindungen eingeschätzt.
5. Beobachtungen statt Zustimmung sammeln
In Gesprächen helfen konkrete Erlebnisse mehr als die Frage, ob jemand Ihre Idee gut findet. Der GOV.UK-Leitfaden zu Nutzerinterviews empfiehlt offene, neutrale Fragen und reale Beispiele. Bitten Sie Teilnehmende etwa, ihre letzte vergleichbare Aufgabe zu schildern. Beobachten Sie anschließend die vereinbarte Testaufgabe, ohne den benötigten Weg vorzusagen.
| Prüffrage | Festhalten | Grenze der Aussage |
|---|---|---|
| Kann eine Anfrage vollständig erfasst werden? | Aufgabe, getestete Version, notwendige Hilfe und fehlende Angaben | Ein erfolgreicher Durchlauf belegt nicht die Nutzung im Alltag |
| Kommt sie bei der zuständigen Person an? | Tatsächlich beobachteter Eingang, Verzögerung oder Fehlermeldung | Eine sichtbare Bestätigung allein beweist keinen Empfang |
| Wird der Status verstanden? | Wiedergabe durch die Testperson und beobachtete Missverständnisse | Zustimmung im Gespräch ersetzt keine beobachtete Aufgabe |
| Besteht Bedarf an einem weiteren Test? | Konkreter nächster Schritt, zuständige Person und offene Bedingungen | Interesse ist noch keine Bestellung oder nachgewiesene Zahlungsbereitschaft |
Legen Sie vor Beginn fest, welche Beobachtungen für den nächsten Schritt ausreichen und welche einen Stopp auslösen. Trennen Sie Aussagen der Teilnehmenden, beobachtetes Verhalten und Ihre Interpretation. Notieren Sie auch, wer nicht teilgenommen hat und welche Situationen ungeprüft bleiben. Dieser Artikel nennt bewusst keine universelle Erfolgsquote; ein kleiner Test bildet nicht automatisch den gesamten Markt ab.
6. Nach dem Test: weiterbauen, ändern oder stoppen
Der GOV.UK-Leitfaden zur Beta-Phase beschreibt einen begrenzten Einstieg mit echten Nutzern, Rückmeldungen und anschließenden Verbesserungen. Er betont auch die Kapazität für Betreuung. Für ein MVP sollten deshalb nach dem ersten Test Verantwortliche für Rückfragen, Fehler und die nächste Entscheidung feststehen.
Halten Sie am Ende fest, welche Annahme gestützt wird, welche widerlegt wurde und welche offenbleibt. Eine funktionierende Oberfläche kann eine technische Frage beantworten, während Nachfrage und Vertrieb weiterhin ungeklärt sind. Auch die Entscheidung, nicht weiterzubauen, kann ein brauchbares Ergebnis sein.
Wenn daraus ein Entwicklungsprojekt wird, hilft unser Überblick zur individuellen Softwareentwicklung bei der Einordnung. Läuft der Test als Anwendung im Browser, beschreibt unsere Seite zur Webentwicklung für Web-Apps Ablauf und Abstimmung. Für eine App sollten Umfang und laufender Betrieb gemeinsam geplant werden; dazu dient der Leitfaden zu App-Kosten. Dieser MVP-Artikel nennt keinen pauschalen Entwicklungspreis und sagt kein Finanzierungs- oder Beteiligungsmodell zu.
Häufige Fragen
Ist ein MVP in vier Wochen garantiert fertig?
Nein. Vier Wochen sind hier ein beispielhafter Arbeitsrahmen für einen vorbereiteten, kleinen Versuch. Umfang, Team, Zugänge, Testpersonen und externe Abhängigkeiten bestimmen, was darin möglich ist. Ein verbindlicher Termin setzt eine konkrete Vereinbarung voraus.
Reicht ein Prototyp zur Validierung meiner Geschäftsidee?
Ein Prototyp kann Verständnis, Bedienung oder technische Machbarkeit prüfen. Daraus folgen noch keine nachgewiesene Marktnachfrage, Zahlungsbereitschaft oder dauerhafte Wirtschaftlichkeit. Benennen Sie genau, welche Annahme Ihr Test untersuchen soll.
Welche Funktionen gehören in ein MVP?
Die Funktionen, die für die vereinbarte Kernaufgabe und einen verantwortbaren Test nötig sind. Erforderliche Zugriffsrechte, Datenbehandlung und Fehlerfälle gehören dazu. Zusätzliche Funktionen werden anhand der Testfrage priorisiert, nicht pauschal aufgenommen oder ausgeschlossen.
Was sollte am Ende des ersten Tests vorliegen?
Ein dokumentierter Stand, beobachtete Ergebnisse, bekannte Grenzen und eine Entscheidung über den nächsten Schritt. Feststehen sollten außerdem Zuständigkeiten für Betreuung und Fehler sowie die noch offenen Annahmen. Eine Veröffentlichung allein bestätigt keinen Markterfolg.
Wir entwickeln Websites, Apps und Software bei Ragdom Venture in Nürnberg.
Über das Team