Wie Sie mit KI ein Product Requirements Doc schreiben (kostenlose Vorlage)

Ein Product Requirements Document (PRD) ist eine kurze, verständlich formulierte Beschreibung dessen, was Sie bauen, für wen es gedacht ist, was es leisten muss und woran Sie erkennen, dass es funktioniert. KI beschleunigt das Schreiben erheblich: Sie geben grobe Notizen ein, und die KI macht daraus strukturierte Abschnitte, Nutzerstories und Randfälle. Ihre Aufgabe ist es, die Entscheidungen zu liefern, die die KI nicht treffen kann – das Ziel, den Umfang und das, was wegfällt – und zu prüfen, was sie ergänzt.

Dieser Leitfaden erklärt, was in ein PRD gehört, wie Sie mit einem beliebigen KI-Assistenten Schritt für Schritt einen Entwurf erstellen, welche Prompts sich für jeden Abschnitt eignen, und stellt eine Ausfüllvorlage zum Kopieren bereit.

Wofür ein PRD da ist (und wofür nicht)

Ein PRD beantwortet vier Fragen:

1. Warum bauen wir das? Welches Problem, für wen?
2. Was muss es in der ersten Version leisten?
3. Was wird es noch nicht können?
4. Wie erkennen wir, dass es funktioniert hat?

Es ist kein technisches Design. Es legt nicht fest, welche Datenbank oder welches Framework verwendet wird – das gehört gegebenenfalls in eine separate technische Spezifikation. Es ist auch kein Marketing-Briefing und kein Businessplan. Wenn das PRD sich auf das Verhalten des Produkts beschränkt, ist es für alle Beteiligten nützlich: für Designer, Entwickler, Entscheider, die es freigeben, oder einen KI-App-Builder, der es in Code umsetzt.

Wer ein PRD braucht

• Solo-Gründer, die Scope Creep von Anfang an verhindern wollen.
• Kleine Teams, die einen gemeinsamen Ort für „das, was wir vereinbart haben“ brauchen.
• Alle, die einen Freelancer oder eine Agentur beauftragen, denn ein klares PRD führt zu klareren Angeboten. Siehe Entwickler beauftragen oder mit KI bauen.
• Alle, die mit KI bauen, denn die Nutzerstories und die Datenliste eines PRDs ergeben bessere Prompts als eine unstrukturierte Wunschliste.

Was KI gut kann – und was nicht

Der häufigste Fehler ist die Umkehrung der vorletzten Zeile: Die KI füllt Lücken selbstbewusst mit plausiblen Vermutungen über Ihre Nutzer. Behandeln Sie alles, was sie über Nutzer, Marktgröße oder Verhalten schreibt, als Frage, die Sie prüfen müssen, nicht als Fakt.

Schritt 1: Alles sammeln, was Sie wissen

Bevor Sie etwas prompten, schreiben Sie grobe Notizen auf. Stichpunkte reichen. Halten Sie fest:

• Das Problem in ein bis zwei Sätzen, aus Sicht des Nutzers.
• Wer es hat. Seien Sie konkret: „freiberufliche Buchhalter mit 10 bis 40 Kunden“, nicht „kleine Unternehmen“.
• Was diese Menschen heute stattdessen tun (eine Tabelle, E-Mails, ein Tool, das sie nicht mögen).
• Das eine Ergebnis, das Version eins zum Erfolg macht.
• Was Sie schon jetzt sicher nicht umsetzen werden.
• Harte Rahmenbedingungen: Termin, Budget, muss auf dem Smartphone funktionieren, muss sich mit einem bereits genutzten Tool verbinden.

Wenn Sie noch mit niemandem gesprochen haben, der dieses Problem hat, tun Sie das zuerst. Eine App-Idee validieren beschreibt einen praktischen Weg dorthin. Ein PRD, das auf Vermutungen beruht, ist eine gut formatierte Vermutung.

Schritt 2: Die KI um einen ersten Entwurf bitten

Fügen Sie Ihre Notizen ein und bitten Sie um einen Entwurf in einer festen Struktur. Ein Prompt, der gut funktioniert:

Hier sind meine Notizen zu einem Produkt. Wandle sie in ein Product Requirements Document mit genau diesen Abschnitten um: Zusammenfassung, Problem, Nutzer, Ziele und Erfolgsmetriken, Umfang (enthalten / nicht enthalten), Nutzerstories mit Akzeptanzkriterien, Daten, Berechtigungen, Randfälle, offene Fragen. Halte es unter zwei Seiten. Erfinde keine Fakten über Nutzer oder den Markt – wo meine Notizen nichts sagen, formuliere die Frage unter „Offene Fragen“.

Die letzte Anweisung ist wichtig. Wenn Sie die KI anweisen, Unbekanntes in „Offene Fragen“ zu schreiben, statt es zu ergänzen, entsteht ein deutlich ehrlicherer Entwurf.

Schritt 3: Jeden Abschnitt schärfen

Gehen Sie den Entwurf Abschnitt für Abschnitt durch. Diese Folgeprompts helfen:

Problem und Nutzer

Formuliere die Problembeschreibung in ein oder zwei Sätzen aus Sicht des Nutzers neu. Keine Lösungsbegriffe.

Nennt die Problembeschreibung Ihr Produkt, beschreibt sie eine Lösung, kein Problem.

Ziele und Erfolgsmetriken

Schlage drei Erfolgsmetriken für Version eins vor, die ich im ersten Monat mit einer kleinen Nutzerzahl messen kann. Sage zu jeder, wie ich sie messen würde.

Wählen Sie eine oder zwei aus. „Zwanzig Buchhalter nutzen es einen Monat lang wöchentlich“ ist messbar. „Produktivität verbessern“ nicht.

Umfang

Liste alles in diesem PRD auf, was in eine spätere Version verschoben werden könnte, ohne den Kernablauf zu brechen.

KI-Tools neigen dazu, Funktionen hinzuzufügen. Dieser Prompt bewirkt das Gegenteil. Seien Sie konsequent: Die meisten PRDs für Version eins sind zu groß. Was ist ein MVP erklärt, warum kleine erste Versionen mehr beibringen.

Nutzerstories und Akzeptanzkriterien

Schreibe jede Anforderung als Nutzerstory („Als [Nutzer] möchte ich [Handlung], damit [Ergebnis]“) mit zwei bis vier Akzeptanzkriterien in der Form Given / When / Then.

Akzeptanzkriterien sind die Checkliste, gegen die Sie später testen. „Gegeben ein gebuchter Termin, wenn ein anderer Kunde den Kalender ansieht, dann wird der Termin nicht angezeigt“ ist testbar. „Buchung funktioniert gut“ nicht.

Randfälle und Berechtigungen

Liste für jede Nutzerstory auf, was bei leeren Daten, ungültiger Eingabe, einer langsamen oder fehlgeschlagenen Netzwerkanfrage und bei einem Nutzer passiert, der keinen Zugriff haben sollte.

Hier zahlt sich KI aus. Sie erkennt schnell die leeren Zustände und Berechtigungslücken, die Menschen gerne übersehen.

Schritt 4: Mit kritischem Blick prüfen

Lesen Sie das Ganze noch einmal und prüfen Sie:

• Jede Aussage über Nutzer stammt von Ihnen oder aus Recherche, nicht von der KI.
• „Nicht enthalten“ ist mindestens so lang wie „enthalten“.
• Jede Nutzerstory hat Akzeptanzkriterien, die jemand ohne Rückfrage bei Ihnen testen kann.
• Der Datenabschnitt listet jede Art von Datensatz auf, die die App speichert, und wer ihn sehen darf.
• Offene Fragen haben einen Verantwortlichen und ein Datum.
• Nichts Technisches hat sich eingeschlichen, es sei denn, es ist eine echte Rahmenbedingung („muss offline funktionieren“ ist eine Anforderung; „Redis verwenden“ nicht).

Zeigen Sie es danach einer Person, die das Produkt nutzen oder bauen wird, und fragen Sie, was unklar ist. Ihre Fragen zeigen die Lücken.

Ausfüllvorlage für das PRD

Kopieren Sie dies in ein Dokument und ersetzen Sie die Platzhalter in eckigen Klammern. Löschen Sie Abschnitte, die wirklich nicht zutreffen.

Produktname: [Name] Verantwortlich: [Person, die Entscheidungen trifft] Status: [Entwurf / in Prüfung / vereinbart] — Zuletzt aktualisiert: [Datum]

1. Zusammenfassung

[Zwei oder drei Sätze: worum es geht, für wen und das wichtigste Ergebnis.]

2. Problem

[Das Problem aus Sicht des Nutzers. Was er heute tut und warum das belastend ist.]

3. Nutzer

4. Ziele und Erfolgsmetriken

• Ziel: [das Ergebnis, das Version eins erreichen muss]
• Metrik: [wie Sie es messen, und der Zielwert]
• Nicht-Ziel: [etwas, das man annehmen könnte, das diese Version aber nicht anstrebt]

5. Umfang

In Version eins:

• [Funktion]
• [Funktion]

Nicht in Version eins:

• [Funktion und warum sie warten kann]
• [Funktion und warum sie warten kann]

6. Nutzerstories

Story 1: Als [Nutzer] möchte ich [Handlung], damit [Ergebnis].

• Gegeben [Kontext], wenn [Handlung], dann [Ergebnis].
• Gegeben [Kontext], wenn [Handlung], dann [Ergebnis].

Story 2: Als [Nutzer] möchte ich [Handlung], damit [Ergebnis].

• Gegeben [Kontext], wenn [Handlung], dann [Ergebnis].

7. Daten

8. Berechtigungen

[Wer sich anmelden kann, welche Rollen es gibt und was jede Rolle sehen und ändern darf.]

9. Randfälle

• [Leerer Zustand: was angezeigt wird, wenn noch keine Daten vorhanden sind]
• [Ungültige Eingabe: was bei einer falschen E-Mail-Adresse oder einem fehlenden Feld passiert]
• [Zugriff: was passiert, wenn jemand eine Seite öffnet, die er nicht sehen darf]

10. Integrationen und Rahmenbedingungen

[Zahlungen, E-Mail, bestehende Tools, Termine, Budget, Geräte, auf denen es funktionieren muss.]

11. Offene Fragen

Vom PRD zu Prompts

Ein gutes PRD lässt sich fast direkt in Prompts für einen KI-App-Builder umwandeln:

• Die Zusammenfassung, die Nutzer und die Datentabelle werden Ihr erster Prompt.
• Jede Nutzerstory wird zu einem Folgeprompt.
• Jedes Akzeptanzkriterium wird etwas, das Sie in der Vorschau testen.
• Die Liste „Nicht in Version eins“ ist das, was Sie vorerst nicht anfordern.

Eine Story nach der anderen zu bauen und die Akzeptanzkriterien zu prüfen, bevor Sie weitergehen, ist deutlich verlässlicher, als das ganze PRD einzufügen und alles auf einmal zu verlangen. Prompts für KI-App-Builder schreiben behandelt die Prompt-Seite ausführlicher.

Häufige Fehler

• Die Lösung als Problem formulieren. „Nutzer brauchen ein Dashboard“ ist eine Lösung. „Inhaber können nicht sehen, welche Rechnungen überfällig sind, ohne jede einzeln zu öffnen“ ist ein Problem.
• Kein Abschnitt „nicht enthalten“. Ohne ihn wird bei jedem Gespräch der Umfang neu verhandelt.
• Die KI Nutzer erfinden lassen. Von der KI erfundene Personas wirken echt und sind es nicht.
• Metriken, die Sie nicht messen können. Wenn Sie es nicht zählen können, ist es keine Metrik.
• Nie aktualisieren. Ein PRD, das nicht mehr zu dem passt, was Sie bauen, ist schlechter als keins. Pflegen Sie ein Datum „zuletzt aktualisiert“ und ändern Sie es, wenn sich Entscheidungen ändern.

PRD mit Mythex verwenden

Wenn Sie in Mythex bauen, können Sie Ihr PRD direkt in den Chat einfügen. Der Modus Plan eignet sich gut für ein PRD: Der Agent liest es, schlägt einen Ansatz und eine Schrittliste vor, die Sie in einem Plan-Tab prüfen können, und beginnt erst mit Änderungen an Dateien, wenn Sie auf Build drücken. Sie können außerdem die Teile, die immer gelten sollen – Zielgruppe, Marke, Regeln – als Projektwissen speichern, damit Sie sie nicht in jedem Chat wiederholen müssen. Die Chat-Dokumentation erklärt die Modi Build, Plan und Ask, und die Vorlagen zeigen schnell, wie eine erste Version aussehen könnte, bevor Sie das vollständige Dokument schreiben.

Fragen