So schreibst du ein MVP-PRD (Product Requirements Document)

Die meisten Gründer überspringen das PRD komplett und erklären das Produkt in einer Reihe verstreuter Calls, oder sie versuchen, eines so zu schreiben, wie es ein großes Enterprise-Produktteam tun würde — Dutzende Seiten über Randfälle, technische Architektur und Features, die niemand im kommenden Jahr bauen wird. Beide Ansätze erzeugen dasselbe Problem: Das Entwicklungsteam rät am Ende, und der Umfang läuft aus dem Ruder.

Ein PRD (Product Requirements Document) muss nicht lang sein, um nützlich zu sein. Es muss eine kleine Anzahl von Fragen klar genug beantworten, damit ein Designer oder Entwickler mit der Arbeit beginnen kann, ohne dich alle paar Stunden anzupingen. Dieser Leitfaden behandelt, was dieses Dokument im MVP-Stadium tatsächlich braucht, eine Vorlage, die du direkt kopieren kannst, und die Fehler, die PRDs entweder nutzlos oder aktiv schädlich machen.

Was ein PRD Ist — und Warum PRDs im MVP-Stadium Schlanker Sein Sollten

Ein PRD ist das Dokument, das ein Geschäftsproblem mit einem Bauplan verbindet. Es erklärt, für wen das Produkt ist, welches Problem es löst, was die erste Version tun muss und woran du erkennst, dass es funktioniert hat.

Traditionelle Enterprise-PRDs sind für eine andere Situation geschrieben: ein ausgereiftes Produkt, mehrere Stakeholder-Teams, bestehende Infrastruktur und die Notwendigkeit, Abteilungen zu koordinieren, die nicht täglich miteinander sprechen. Sie dokumentieren Randfälle erschöpfend, weil ein übersehener Fall Tausende bestehender Nutzer betreffen oder eine Compliance-Vorgabe verletzen kann.

Nichts davon trifft auf ein MVP zu. Du hast ein kleines Team, kein Altsystem zu schützen und ein einziges Ziel — zu testen, ob die zentrale Annahme hinter deinem Produkt zutrifft. Ein schweres PRD in diesem Stadium reduziert das Risiko nicht; es fügt ein anderes hinzu: Wochen, die damit verbracht werden, Features zu dokumentieren, die gestrichen werden, sobald echte Nutzer auf die erste Version reagieren. Je schlanker dein PRD, desto schneller kommst du zu der Version, die tatsächlich Erkenntnisse liefert.

Die Wesentlichen Abschnitte Eines MVP-PRD

Ein MVP-PRD braucht fünf Dinge. Alles andere ist optionales Detail, das bei Bedarf in einem ergänzenden Dokument stehen kann.

1. Problemstellung

Ein oder zwei Sätze, die das Problem beschreiben, wer es hat und warum aktuelle Alternativen nicht ausreichen. Kannst du das nicht schreiben, ohne Features aufzuzählen, ist das Problem noch nicht klar genug definiert.

2. Zielgruppe

Sei konkret. „Freiberufliche Buchhalter, die 10+ KMU-Kunden betreuen” ist nutzbar; „kleine Unternehmen” nicht. Eine eng gefasste Zielgruppe erleichtert jede spätere Umfangsentscheidung, weil du fragen kannst: „Hilft das dieser konkreten Person, ihre Aufgabe zu erledigen?”

3. Zentrale User Journey

Beschreibe den einen Pfad, den ein Nutzer vom Erreichen des Produkts bis zum Erhalt von Wert durchläuft — nicht jeden möglichen Pfad, nur den, der funktionieren muss. Schreibe ihn als nummerierte Schrittfolge, so wie du sie einem neuen Teammitglied an seinem ersten Tag erklären würdest.

4. Muss-Features vs. Features Außerhalb des Umfangs

Teile jede Feature-Idee in zwei Listen auf. Muss-Features sind jene, ohne die die Kern-Journey nicht funktionieren kann. Alles andere — einschließlich Features, von denen du sicher bist, dass du sie irgendwann willst — kommt auf eine explizite Liste außerhalb des Umfangs. Diese zweite Liste aufzuschreiben ist genauso wichtig wie die erste; sie verhindert „nur noch eine Sache”-Gespräche drei Wochen nach Entwicklungsbeginn.

5. Erfolgskennzahlen

Definiere vor Entwicklungsbeginn, welches Ergebnis dir sagen würde, dass das MVP funktioniert hat. Das sollte ein Verhalten sein — abgeschlossene Journey, wiederholte Nutzung, eine bezahlte Conversion, eine bestimmte Aktion — kein vages Ziel wie „positives Feedback”. Kannst du keine Kennzahl benennen, hast du die zu testende Annahme wahrscheinlich noch nicht fertig definiert.

Eine Einfache MVP-PRD-Vorlage

Hier ist eine Struktur, die du direkt in ein Dokument kopieren und ausfüllen kannst. Sie ist bewusst kurz genug, um auf zwei bis drei Seiten zu passen.

1. Problemstellung
   - Wer hat dieses Problem?
   - Was kostet es sie (Zeit, Geld, Aufwand)?
   - Wie lösen sie es heute, und warum ist das unzureichend?

2. Zielgruppe
   - Konkretes Nutzersegment (nicht „alle")
   - Kontext: wann/wo würden sie dieses Produkt nutzen

3. Zentrale User Journey
   - Schritt 1: ...
   - Schritt 2: ...
   - Schritt 3: ... (endet damit, dass der Nutzer echten Wert erhält)

4. Muss-Features
   - Feature A — erforderlich, weil es Schritt X der Journey unterstützt
   - Feature B — erforderlich, weil es Schritt Y unterstützt

5. Außerhalb des Umfangs (für dieses Release)
   - Feature C — für später geplant, nicht erforderlich für die Kern-Journey
   - Feature D — nice-to-have, nach dem Launch erneut prüfen

6. Erfolgskennzahlen
   - Primäre Kennzahl: ...
   - Unterstützende Signale: ...

7. Offene Fragen / Annahmen
   - Alles Ungeklärte, das das Team markieren, nicht erraten sollte

Abschnitt 7 lohnt sich, auch wenn er nicht zu den „wesentlichen fünf” oben gehört — eine ehrliche Liste ungeklärter Fragen ist für ein Entwicklungsteam nützlicher als ein Dokument, das so tut, als sei bereits alles entschieden.

Enterprise-PRD vs. Schlankes PRD im MVP-Stadium

Aspekt	Enterprise-PRD	Schlankes PRD im MVP-Stadium
Typischer Umfang	15–40+ Seiten	2–4 Seiten
Enthaltene Abschnitte	Vollständige Anforderungen, Randfälle, Compliance, teamübergreifende Abhängigkeiten, detaillierte Abnahmekriterien	Problem, Nutzer, Kern-Journey, Muss-Features/außerhalb des Umfangs, Erfolgskennzahlen
Für wen	Mehrere Stakeholder-Teams, bestehendes Produkt, etablierte Nutzerbasis	Gründer, Designer und ein kleines Entwicklungsteam
Zweck	Große Teams koordinieren und ein bestehendes System vor Regressionen schützen	Ein kleines Team schnell genug ausrichten, um mit dem Bau zu beginnen und eine Annahme zu testen
Update-Häufigkeit	Formell über einen Change-Control-Prozess überarbeitet	Frei aktualisiert, sobald echtes Nutzerfeedback eintrifft

Holst du Angebote von mehreren Entwicklungspartnern ein, statt dies nur für ein internes Team zu schreiben, bilden dieselbe Problemstellung, Zielgruppe und die Umfangsabschnitte den Kern einer MVP-RFP-Vorlage — du fügst nur noch Budgetrahmen, Zeitplanerwartungen und die Fragen hinzu, die jedes Angebot beantworten soll. Für einen genaueren Blick auf diesen speziellen Schritt siehe wie viele MVP-Entwicklungsunternehmen du ansprechen solltest, bevor du Anforderungen verschickst.

Häufige PRD-Fehler im MVP-Stadium

Überspezifizieren. Detaillierte Anforderungen für Features zu schreiben, die drei Releases entfernt liegen, verschwendet zweifach Zeit — einmal beim Schreiben und erneut, wenn sie umgeschrieben werden, nachdem echte Nutzer gezeigt haben, was sie wirklich brauchen. Ist ein Feature für die Kern-Journey nicht erforderlich, gehört es nicht in dieses PRD.

Das „Warum” unterspezifizieren. Eine Feature-Liste ohne klar formuliertes Problem und Zielgruppe zwingt Entwickler dazu, bei jedem Randfall die Absicht zu erraten. Das „Warum” ist das, was einem Entwicklungsteam erlaubt, gute Entscheidungen zu treffen, ohne jede kleine Entscheidung an dich zu eskalieren.

Es als Vertrag statt als lebendiges Dokument behandeln. Ein MVP-PRD spiegelt dein bestes Verständnis wider, bevor du echte Nutzerdaten hast. Sobald die Entwicklung beginnt und erstes Feedback eintrifft, sollte sich das Dokument ändern. Gründer, die das ursprüngliche PRD als fixiert behandeln — die sich weigern, ein „Muss-Feature” zu streichen, selbst wenn Belege das Gegenteil zeigen — enden damit, einen Plan zu verteidigen, statt ein funktionierendes Produkt zu bauen. Für einen tieferen Blick darauf, was passiert, wenn ein Dokument nicht aktuell gehalten wird, siehe wie du ein MVP-Lastenheft aktuell hältst.

Die Liste außerhalb des Umfangs überspringen. Es ist verlockend, nur aufzuschreiben, was gebaut werden soll. Aber eine explizite „nicht in diesem Release”-Liste verhindert Scope Creep — sie gibt dir etwas Konkretes, worauf du zurückverweisen kannst, wenn mitten im Sprint eine gute Idee auftaucht.

Wer das PRD Schreiben und Verantworten Sollte

Der Gründer sollte den ersten Entwurf schreiben, weil niemand sonst das Kundenproblem und die Geschäftsprioritäten so gut versteht. Nach dem Entwurf mit Designer und Entwicklern besprechen — sie markieren technisches Risiko, unrealistische Zeitpläne und Features, die einfach klingen, es aber nicht sind. Das ist auch ein guter Moment, um zu bestätigen, dass Zielgruppe und Problemstellung auf echten Belegen beruhen statt nur auf Annahmen, denn ein PRD, das auf einem unvalidierten Problem aufbaut, dokumentiert nur klarer das falsche Problem.

Behalte die Verantwortung während der gesamten Entwicklung beim Gründer. Das PRD ist ein Koordinationswerkzeug, keine Spezifikation, die übergeben und vergessen wird — jemand muss es aktuell halten, während sich Prioritäten verschieben, und das ist meist die Person, die dem Kunden am nächsten steht, nicht das Entwicklungsteam.

Das PRD Nützlich Machen, Nicht Nur Vollständig

Ein gutes MVP-PRD versucht nicht, jedes Szenario vorherzusehen. Es gibt einem kleinen Team genug gemeinsames Verständnis von Problem, Nutzer und der Grenze der ersten Version, um mit dem Bau zu beginnen — ohne ständige Rückfragen — und bleibt dabei kurz genug, dass es tatsächlich jeder liest.

Bist du dir nicht sicher, wie detailliert dein eigenes PRD für dein spezifisches Produkt sein muss, ist das meist ein Scoping-Gespräch, das sich lohnt, bevor die Entwicklung beginnt — nicht danach.

Häufig gestellte Fragen

Was ist ein MVP-PRD?

Ein MVP-PRD (Product Requirements Document) ist ein kurzes Dokument, das das Problem definiert, das du löst, für wen, die zentrale User Journey und was im und außerhalb des Umfangs der ersten Version liegt. Es dient dazu, Gründer, Designer und Entwickler vor Entwicklungsbeginn aufeinander abzustimmen — nicht als erschöpfende Spezifikation.

Wie lang sollte ein MVP-PRD sein?

Die nützlichsten MVP-PRDs passen auf zwei bis vier Seiten. Ist es länger, spezifizierst du wahrscheinlich Features, die bis nach dem Launch warten sollten, oder dokumentierst Implementierungsdetails, die in eine technische Spezifikation gehören.

Was ist der Unterschied zwischen einem PRD und einem RFP für ein MVP?

Ein PRD definiert, was du baust und warum — das Problem, den Nutzer, den Umfang und die Erfolgskriterien. Ein RFP (Request for Proposal) nutzt dieselben Informationen, um Entwicklungsagenturen oder Freelancer nach Kosten- und Zeitschätzungen zu fragen. Ein gutes MVP-PRD ist meist der Kerninhalt, den du in ein RFP einfügst, ergänzt um Budget- und Zeitrahmenvorgaben.

Sollte ein nicht-technischer Gründer das PRD selbst schreiben?

Ja, der erste Entwurf sollte vom Gründer kommen, weil niemand sonst das Kundenproblem und die Prioritäten so gut versteht. Entwickler und Designer können es danach prüfen, technische Risiken markieren und Anpassungen am Umfang vorschlagen — aber der Gründer sollte Eigentümer von Problemstellung und Prioritäten bleiben.

Braucht ein MVP-PRD Wireframes oder technische Spezifikationen?

Nein. Grobe Skizzen oder ein einfaches Flussdiagramm können helfen, die User Journey zu vermitteln, aber detaillierte Wireframes und technische Architektur gehören in separate Design- und Engineering-Dokumente, die entstehen, nachdem das PRD abgestimmt wurde.