MVP Anforderungsdokument Vorlage: Der Scope, der wirklich live geht
Ein gutes MVP Anforderungsdokument ist kein Feature-Backlog. Nutzen Sie diese Vorlage, um Lernziel, Scope und Briefing für einen lieferbaren Build zu klären.
Eine MVP Anforderungsdokument Vorlage sollte definieren, was die erste Version beweisen muss, nicht alles, was das Produkt später werden könnte. Bei webvise behandeln wir sie als Lernvertrag: ein Nutzer, ein Workflow, eine Erfolgsmetrik und eine harte Out-of-scope-Liste.
Wenn Ihr Dokument wie ein Feature-Backlog liest, ist Ihr MVP bereits zu groß.
Gründer kennen das Produkt meist besser als der Builder, briefen aber oft das falsche Artefakt. Dieser Leitfaden gibt Ihnen die Vorlage, die wir vor einem Festpreis-MVP Build sehen wollen, mit Beispielen und Kürzungen, die verhindern, dass ein 3 bis 5 Wochen Build zur Quartals-Revision wird.
Das Dokument soll Lernen kaufen, nicht Vollständigkeit. Wenn ein Feld nicht hilft, die kommerzielle Annahme zu beweisen, streichen Sie es.
Ein Workflow reicht für Version eins. Mehr Workflows bedeuten mehr Zustände, mehr Tests und einen späteren Launch.
Die Out-of-scope-Liste schützt das Budget. Ein Feature ist erst gestrichen, wenn alle sehen können, wohin es verschoben wurde.
Der Builder braucht Entscheidungen, keine Essays. Nennen Sie Nutzer, Ereignis, Daten, Owner und Launch-Metrik.
Ein guter MVP Brief passt auf 2 Seiten. Die harte Arbeit besteht darin, zu entscheiden, was Sie nicht schreiben.
Die Vorlage ist ein Lernvertrag
Ein normales PRD erklärt ein Produkt. Ein MVP Anforderungsdokument erklärt einen Test. Die erste Zeile sollte die riskante Annahme nennen, die das Produkt überhaupt bauenswert macht.
Diese Unterscheidung verändert den Scope. Ein Produktdokument sammelt Möglichkeiten, während ein MVP Dokument zu einer Ja-oder-nein-Entscheidung zwingt, was echte Nutzer tun müssen, bevor die nächste Investition sinnvoll ist.
webvise MVP Builds starten bei €5,000, weil wir den ersten Release um das Lernziel herum schneiden, nicht um einen Wunsch-Backlog. Wenn Ihre erste Version Auth, einen Kernworkflow, eine Datenbank, Deployment und Analytics braucht, gehört sie in einen 3 bis 5 Wochen Build. Wenn sie fünf Nutzerrollen und drei Dashboards braucht, ist sie nicht mehr der erste Test.
Kopieren Sie diese MVP Anforderungsdokument Vorlage
Nutzen Sie sie als zweiseitigen Brief, bevor Sie ein Angebot anfragen. Je knapper die Antwort, desto leichter kann ein seriöser Builder die Arbeit bepreisen, ohne Unsicherheit in den Kostenvoranschlag einzubauen.
| Abschnitt | Was Sie schreiben | Besteht, wenn |
|---|---|---|
| Riskante Annahme | Der kommerzielle Glaube, den diese Version beweisen muss | Wenn er falsch ist, würden Sie Produkt ändern oder stoppen |
| Primärer Nutzer | Ein benannter Nutzertyp, kein Marktsegment | Ein Builder kann sich die Person vorstellen, die das Produkt nutzt |
| Kernworkflow | Die Schritte von erster Aktion bis Wert | Der Workflow kann von einer fremden Person getestet werden |
| Erfolgsmetrik | Eine Zahl, die entscheidet, ob Version eins funktioniert hat | Die Metrik ist innerhalb von 30 Tagen nach Launch sichtbar |
| Out of scope | Verlockende Features, die ausgeschlossen sind | Alle Stakeholder zeigen auf dieselben Kürzungen |
| Daten und Integrationen | Systeme, Dateien, APIs, Payments, E-Mail, Auth | Keine versteckte Abhängigkeit taucht in Build-Woche zwei auf |
| Launch-Grenze | Budget, Timing, Recht, Gerät, Browser, Sprache | Die Grenze kann Scope blockieren, bevor Code startet |
| Entscheider | Die Person, die Kürzungen akzeptieren darf | Der Builder vermittelt nicht jeden internen Streit |
Verstecken Sie Unsicherheit nicht. Wenn Sie die Metrik noch nicht kennen, schreiben Sie den nächsten Proxy und markieren ihn als vorläufig. Eine fehlende Entscheidung im Dokument wird während des Builds zu einem Meeting.
Arbeitstitel: ein Satz, der sagt, was das Produkt tut.
Primärer Nutzer: der erste Nutzer, den Sie rekrutieren, nicht jeder denkbare Käufer.
Kernworkflow: 5 bis 10 Schritte vom Einstieg bis zum Wert.
Launch-Metrik: die Zahl, die Sie in den ersten 30 Tagen messen können.
Erforderliche Systeme: Stripe, Resend, CRM, Tabelle, CMS oder interne API.
Out-of-scope-Liste: jedes Feature, das Sie jetzt bewusst nicht bauen.
Abnahmeregel: wer unterschreibt, wenn der Build dem Brief entspricht.
Wenn Sie einen Build-Partner brauchen, der dieses Dokument vor dem ersten Code herausfordert, umfasst webvise MVP Development Product Scoping, Feature-Priorisierung, UI Design, Full-Stack-Entwicklung, Deployment und Basis-Analytics.
Kürzen Sie Features mit dem Fünf-Fragen-Gate
Die meisten Scope-Streits entstehen, weil jedes Feature einzeln vernünftig klingt. Das Gate behebt das. Ein Feature bleibt nur im MVP, wenn es alle fünf Fragen übersteht.
| Frage | Behalten, wenn | Kürzen, wenn |
|---|---|---|
| Beweist es die riskante Annahme? | Die Antwort verändert die nächste Finanzierungs-, Vertriebs- oder Build-Entscheidung | Es lässt das Produkt nur vollständiger wirken |
| Braucht der erste Nutzer es? | Der primäre Nutzer erreicht ohne das Feature keinen Wert | Ein späterer Nutzertyp hätte es gern |
| Kann es in 30 Tagen gemessen werden? | Nutzungs-, Zahlungs-, Abschluss- oder Antwortdaten erscheinen schnell | Das Signal braucht eine große Zielgruppe, die Sie noch nicht haben |
| Reduziert es operatives Risiko? | Es verhindert Betrug, Datenverlust, Support-Versagen oder rechtliches Risiko | Es existiert, weil ein Wettbewerber es hat |
| Kann ein Mensch es in Version eins manuell tun? | Manuelle Arbeit würde das Versprechen brechen oder unsicheren Datenumgang erzeugen | Manuelle Arbeit nervt, ist aber für die ersten zehn Nutzer akzeptabel |
Die Frage nach manueller Arbeit spart echtes Geld. Viele Gründer bauen Admin Screens, Billing-Randfälle und Notification Center, bevor sie wissen, ob jemand das Produkt zweimal nutzt.
Mini-Story: OHYP hatte einen Output, der zählte
Am 2026-02-20 veröffentlichten wir die OHYP GmbH Case Study, einen Berliner Immobiliendienst, der Finanzierungszertifikate für Immobilienkäufer brauchte. Das Produkt startete nicht als generische Fintech-Plattform. Es startete mit einem Output: Ein Käufer sollte innerhalb von 24 Stunden ein verbindliches Zertifikat erhalten, ohne SCHUFA-Abfrage, während das System mehr als 550 Partnerbanken verglich.
Dieser Output machte den MVP Scope klar. Wir bauten ein 10-stufiges Finanzierungsformular, automatisierte PDF-Zertifikatserstellung und ein Admin Dashboard für den Anfrage-Lebenszyklus. Der Build ging in 6 Wochen live, mit Next.js, React, tRPC, TypeScript, PostgreSQL, Drizzle ORM, Tailwind CSS und Vercel.
| Scope-Entscheidung | OHYP Beispiel | Warum es blieb |
|---|---|---|
| Primärer Nutzer | Immobilienkäufer in Deutschland | Der Zertifikatsworkflow beginnt mit diesem Nutzer |
| Kernworkflow | 10-stufiges Finanzierungsformular | Es erfasst die Daten für ein gültiges Zertifikat |
| Erfolgsoutput | Zertifikat in unter 24 Stunden | Das Geschäftsversprechen hängt von der Bearbeitungszeit ab |
| Datenabhängigkeit | Mehr als 550 Partnerbanken | Das Produkt kann das Versprechen ohne Vergleich nicht erfüllen |
| Admin-Bedarf | Dashboard für den Anfrage-Lebenszyklus | Das Team brauchte nach der Einreichung Kontrolle |
| Performance-Bar | 96 Lighthouse, unter 1.2s Ladezeit | Der Funnel musste vor sensibler Dateneingabe vertrauenswürdig wirken |
Die Lektion ist nicht, dass jedes MVP ein 10-stufiges Formular braucht. Die Lektion ist, dass ein scharfer Output zehn Schritte kleiner wirken lässt als fünf vage Features.
Mini-Story: Vibe-coded MVPs scheitern beim Handoff
Lovable, Bolt und v0 sind nützlich für Prototypen, weil sie die Zeit zwischen Idee und öffentlicher URL verkürzen. Das Scheitern beginnt, wenn dieser Prototyp in MVP umbenannt wird und einen zahlenden Kunden annimmt, bevor jemand Auth, Datenzugriff, Admin Workflows oder Observability besitzt.
In unserem Vibe-coded MVP Teardown haben wir die Regel dokumentiert, die wir nutzen, wenn Gründer uns solche Codebases bringen: Wir bauen neu. Ein sauberer Build auf unserem Stack dauert 3 bis 6 Wochen. Salvage dauert 8 bis 12 Wochen, weil jeder Fix ein Schema, eine Routenstruktur und ein Live-Datenmodell respektieren muss, die niemand entworfen hat.
Darum muss das Anforderungsdokument die Handoff-Fläche enthalten. Wenn ein Kunde zahlt, braucht das MVP ab Tag eins ein echtes Datenmodell, Session-Regeln, Admin-Aktionen und Monitoring. Wenn das Dokument nur Login, Dashboard und AI Feature sagt, füllt der Builder die riskantesten Teile ohne Ihren Input aus.
So geben Sie das Dokument an eine Agentur
Senden Sie das Dokument vor dem ersten Angebot, und bewerten Sie die Agentur an ihren Fragen. Ein guter Builder kürzt, fordert heraus und ordnet den Scope. Ein schwacher Builder akzeptiert jedes Feature und versteckt die Kosten in einem größeren Angebot.
Budgetband: sagen Sie, ob dies eine €5,000, €15,000 oder €50,000 Entscheidung ist, bevor der Scope wächst.
Timeline: nennen Sie das Launch-Datum und warum es wichtig ist.
Vorhandener Beweis: fügen Sie Waitlist-Zahlen, Interviews, Prototyp-Links, bezahlte Letters of Intent oder manuelle Workflow-Daten hinzu.
Erforderliche Accounts: listen Sie Stripe, Vercel, Supabase, PostHog, CRM, E-Mail und Domain-Zugänge vor Kickoff.
Harte Nein-Liste: sagen Sie, was nicht passieren darf, etwa medizinische Daten speichern, ein No-Code Backend nutzen oder ohne Audit Logs launchen.
Cut Owner: nennen Sie die Person, die ein Feature innerhalb von 24 Stunden entfernen kann.
Zum Kontext: webvise baut MVPs mit Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel, CI/CD, Analytics und Deployment im Initialscope. Dieser Stack ist nicht der Punkt. Der Punkt ist, dass das MVP sauber genug sein sollte, um zu wachsen, wenn der Test funktioniert.
Der finale Test vor dem Versand
Lesen Sie jede Zeile und fragen Sie, ob sie dem Builder bei einer Scope-Entscheidung hilft. Wenn sie nicht verändert, was gebaut, gemessen, gekürzt oder verschoben wird, entfernen Sie sie.
| Schwache Zeile | Besser schreiben | Warum es funktioniert |
|---|---|---|
| Nutzer können ihr Profil verwalten | Käufer können Name, E-Mail, Telefon und Finanzierungssumme vor Zertifikatserstellung bearbeiten | Es nennt Nutzer, Felder und Workflow |
| Admin Dashboard | Mitarbeiter können neue Zertifikatsanfragen sehen, Status ändern und das generierte PDF herunterladen | Es beschreibt den echten Admin-Job |
| AI Empfehlungen | Das System markiert fehlende Finanzierungsdaten vor Einreichung zuerst mit festen Validierungsregeln | Es vermeidet vagen AI Scope, bis die Regel bekannt ist |
| Payments später | Stripe ist out of scope für Version eins, außer ein bezahlter Pilot wird vor Kickoff unterschrieben | Es macht aus einer Zukunftsidee einen Trigger |
| Mobile friendly | Das 10-stufige Formular muss auf einem 390px breiten Telefon nutzbar sein, bevor Desktop-Polish startet | Es macht die Geräte-Grenze testbar |
Ein kurzes MVP Anforderungsdokument fühlt sich unbequem an, weil es die echte Entscheidung freilegt. Genau das ist der Punkt. Das Dokument sollte offensichtlich machen, worauf Sie wetten, was Sie nicht bauen und welches Ergebnis die nächste Version rechtfertigt.
webvise hilft Gründern, diese Entscheidung in eine gelieferte erste Version zu verwandeln, nicht in eine aufgeblähte Feature-Liste. Wenn Ihr MVP Brief nah dran, aber noch zu breit ist, senden Sie ihn an webvise und wir sagen Ihnen, was wir vor Build-Woche eins kürzen würden.