Eine PRD-Vorlage in Markdown:kopieren und ausfüllen.

Die Vorlage

Kopiere sie in eine neue Datei und ersetze alles in spitzen Klammern. Streiche einen Abschnitt nur, wenn du sicher bist, dass er nicht zutrifft, und schreibe „none“, statt ihn leer zu lassen, damit ein Leser erkennt, dass er bedacht wurde.

# PRD: <Feature name>

Status: Draft | In review | Approved
Owner: <name>
Last updated: <date>

## 1. Problem
Who has the problem, what it is, and what it costs them today.
One short paragraph. No solution here.

## 2. Goals
- <Outcome 1, measurable>
- <Outcome 2, measurable>

## 3. Non-goals
Things this work will NOT do, so nobody builds them by accident.
- <Not in scope 1>
- <Not in scope 2>

## 4. Users and scenarios
- As a <role>, I want <action>, so that <benefit>.
- As a <role>, I want <action>, so that <benefit>.

## 5. Requirements
Number each one so it can be referenced in plans and tests.
- R1. The system must <behavior>.
- R2. The system must <behavior>.
- R3. The system should <optional behavior>.

## 6. Acceptance criteria
- [ ] R1: Given <state>, when <action>, then <result>.
- [ ] R2: Given <state>, when <action>, then <result>.

## 7. Edge cases and errors
- <Empty state>
- <Invalid input>
- <Network or permission failure>

## 8. Data and interfaces
- Data stored or changed: <fields, formats, migrations>
- APIs or screens affected: <names>

## 9. Success metrics
- <Metric>: from <baseline> to <target> by <date>.

## 10. Rollout and rollback
- Release plan: <flag, staged, all at once>
- How to turn it off if it goes wrong: <step>

## 11. Open questions
- [ ] <Question> (owner: <name>)

## 12. Context for the agent
Files to read first: <paths>. Constraints: <stack, style, limits>.

Warum es so geschrieben ist

Ein PRD für einen KI-Agenten hat dieselbe Aufgabe wie eines für einen Menschen, nur mit weniger Spielraum zum Raten. Ein Mensch fragt dich auf dem Flur, was du gemeint hast. Ein Agent füllt die Lücke mit seiner besten Vermutung und macht weiter.

• Nicht-Ziele sind der günstigste Schutz gegen schleichende Erweiterung. Agenten ergänzen „hilfreiche“ Extras, wenn man es ihnen nicht verbietet.
• Nummerierte Anforderungen (R1, R2) lassen einen Plan, einen Test und einen Review-Kommentar auf dasselbe zeigen.
• Abnahmekriterien als Aufgabenlisten-Kästchen werden zu einer To-do-Liste, die sich abhaken lässt. Die Syntax steht unter Markdown-Aufgabenlisten.
• Randfälle sind die Stelle, an der generierter Code zuerst scheitert: leere Daten, falsche Eingaben, eine unterbrochene Verbindung.
• Rollback zwingt dich, darüber nachzudenken, wie du die Änderung rückgängig machst, bevor du sie auslieferst.

So füllst du es aus

1. Schreibe das Problem ohne die Lösung

   Kannst du das Problem nicht beschreiben, ohne ein Feature zu nennen, ist das Feature eine Vermutung. Sag, wen es betrifft und was heute passiert.

2. Mach jedes Ziel messbar

   „Schnellerer Checkout“ ist ein Wunsch. „Median-Checkout unter 30 Sekunden“ ist ein Ziel.

3. Schreibe Anforderungen als Verhalten

   „Das System muss einen Fehler anzeigen, wenn die Datei größer als 10 MB ist“ lässt sich testen. „Gute Fehlerbehandlung“ nicht.

4. Ordne jeder Anforderung ein Kriterium zu

   Nimm Given, when, then. Kannst du die Prüfung nicht schreiben, ist die Anforderung vage.

5. Schließe mit offenen Fragen

   Nenne zu jeder den Verantwortlichen. Ein Agent soll danach fragen, nicht darüber entscheiden.

Diagramme helfen bei Abläufen und Zuständen; ein Mermaid-Block in der Datei ist leicht zu ändern. Siehe Mermaid-Flussdiagramm.

Das PRD an einen KI-Agenten übergeben

Verweise den Agenten auf die Datei, statt sie einzufügen: „Lies docs/prd/export.md und schlage einen Plan vor; schreibe noch keinen Code.“ Bitte zuerst um einen Plan, prüfe ihn anhand der nummerierten Anforderungen und lass dann bauen. Ein PRD, ein Plan und eine Aufgabenliste sind meist drei getrennte Dateien. Das PRD sagt, was und warum, der Plan sagt, wie, und die Aufgaben sind die Schritte.

Halte projektweite Regeln (Befehle, Stil, Ordner) aus dem PRD heraus und in CLAUDE.md oder AGENTS.md, damit das PRD nur enthält, was für dieses Feature gilt.

Häufige Fehler

• Eine Lösung im Gewand eines Problems. „Wir brauchen ein Dropdown“ ist kein Problem.
• Keine Nicht-Ziele. Alles in der Nähe wird Teil des Umfangs.
• Anforderungen, die nicht scheitern können. Kann sie kein Test je verfehlen, sagt sie nichts.
• Ein PRD, das niemand mehr liest. Aktualisiere Status und offene Fragen laufend.
• Zehn Seiten für eine kleine Änderung. Ein Feature von einem Tag braucht eine halbe Seite.

Produktmanager können PRDs in DotMD als gerenderte Dokumente lesen und prüfen, mit Kommentaren an der genauen Stelle. Lesen ist kostenlos; für Bearbeiten und Reviews siehe Preise.

Fragen zu PRD-Vorlagen in Markdown

Weitere Fragen