PRD-Vorlage: Produktanforderungsdokument (+ komplettes Beispiel zum Kopieren)

PRD-Vorlage: Produktanforderungsdokument (+ komplettes Beispiel zum Kopieren)

Zuletzt aktualisiert: 28. Juli 2026.

Die meisten Seiten zur Produktanforderungsdokument-Vorlage liefern nur ein leeres Formular. Atlassians Version besteht aus vier Abschnitten mit Anweisungen um eine leere Erfolgsmetrik-Tabelle herum. Product School trägt "(mit Beispiel)" im Titel und enthält kein Beispiel. Der 12-Punkte-Markdown-Block weiter unten ist die gesamte Vorlage, kostenlos und ohne Anmeldung, direkt zum Kopieren. Abschnitt 4 füllt anschließend jeden dieser 12 Abschnitte für einen kompletten Beispiel-Build aus: ein Kundenportal für Rechnungen, das PDFs mit einem LLM ausliest und zweifelhafte Fälle an einen Menschen weiterleitet. Kopieren Sie die leere Version. Lesen Sie die ausgefüllte. Schreiben Sie Ihre eigene.

Wichtigste Erkenntnisse

• Ein PRD beantwortet, was gebaut wird und warum; das technische Design-Dokument beantwortet das Wie.
• Die 12 Abschnitte passen zu jeder Projektgröße. Ein One-Pager ist dieselbe Vorlage mit weniger Zeilen.
• Nicht-Ziele müssen schriftlich festgehalten werden. Ein KI-Coding-Agent kann den Umfang nicht aus dem Weglassen ableiten.
• Akzeptanzkriterien müssen maschinell prüfbar sein: "p95 unter 400ms", niemals "schnell".

Welche PRD-Form sollten Sie verwenden?

Wählen Sie die Form danach, wer das Dokument liest, nicht danach, wie groß sich das Produkt anfühlt. Ein einzelnes Feature für die eigenen Entwickler braucht einen One-Pager. Ein Build, der an ein externes Team übergeben wird, braucht das vollständige 12-Punkte-PRD, weil die Akzeptanzkriterien gleichzeitig als Freigabe-Gates dienen. Eine Spezifikation für einen KI-Coding-Agenten braucht dieselben zwölf Abschnitte, aufgeteilt in Phasen.

Die One-Page-Produktanforderungsdokument-Vorlage, nach der alle fragen, ist kein eigenständiges Artefakt. Lenny Rachitskys vielkopierter One-Pager, mit echten Beispielen in seinem Newsletter veröffentlicht, ist dasselbe Grundgerüst, nur ohne den prozeduralen Ballast. Ein One-Pager ist kein anderes Dokument. Es sind dieselben zwölf Abschnitte mit gestrichenen leeren Zeilen.

Agile Teams stellen diese Frage ebenfalls häufig, meist formuliert als: Hält ein PRD überhaupt stand, sobald ein Backlog existiert? Ja, als One-Pager: Das PRD hält das Warum und die Grenzen fest, die Tickets halten die eigentliche Arbeit.

Die PRD-Vorlage (Markdown zum Kopieren)

Hier ist das Ganze als Markdown, kostenlos, ohne E-Mail-Sperre. Fügen Sie es in Notion, Confluence, Google Docs, Linear oder Word ein, oder committen Sie es als PRD.md in GitHub und lassen Sie es mit dem Code versionieren. Nach dieser Vorlage wird in neun verschiedenen Formaten gefragt; Markdown ist das einzige, das den Einfügevorgang in alle diese Tools übersteht, und das einzige, das ein KI-Coding-Agent sauber liest.

# PRD: [Produkt- oder Feature-Name]

## 1. Kopfzeile
- Verantwortlich (Produkt):
- Technische Leitung:
- Design-Leitung:
- Status: Entwurf | In Prüfung | Freigegeben | Live
- Zuletzt aktualisiert:
- Änderungshistorie: Datum / Autor / was geändert wurde

## 2. Problemstellung
Ein Absatz. Wer leidet, wie oft, was es heute kostet. Keine Lösungssprache.

## 3. Ziele & Erfolgsmetriken
| Ziel | Metrik | Ausgangswert | Zielwert | Gemessen durch | Datum |
|---|---|---|---|---|---|

## 4. Nicht-Ziele
Positiv formuliert: "Diese Phase umfasst X nicht."

## 5. Nutzer & Personas
Wer nutzt es, was wissen sie bereits, welches Gerät, wie oft.

## 6. User Stories & Akzeptanzkriterien
Als [Persona] möchte ich [Aktion], damit [Ergebnis].
- Gegeben [Kontext], wenn [Ereignis], dann [beobachtbares Ergebnis].

## 7. Funktionale Anforderungen
Nummeriert. Eine Anforderung pro Zeile. Testbar. Kein Satz mit "und".

## 8. Nicht-funktionale Anforderungen
Performance / Sicherheit & Mandantenfähigkeit / Datenresidenz & Aufbewahrung / Barrierefreiheit / Verfügbarkeit.

## 9. Abhängigkeiten & Integrationen
Externe Systeme, APIs, Zugangsdaten, wer den Zugriff verantwortet, Vorlaufzeit.

## 10. Meilensteine & Phasenplanung
| Phase | Umfang | Exit-Kriterien | Zieldatum |
|---|---|---|---|

## 11. Offene Fragen & Risiken
| Frage oder Risiko | Verantwortlich | Benötigt bis | Auswirkung, falls unbeantwortet |
|---|---|---|---|

## 12. Anhang & Links
Designs, Recherche, Wettbewerbsnotizen, frühere Tickets, Verträge.

Die zwölf Abschnitte in der Reihenfolge: Kopfzeile, Problemstellung, Ziele und Erfolgsmetriken, Nicht-Ziele, Nutzer und Personas, User Stories mit Akzeptanzkriterien, funktionale Anforderungen, nicht-funktionale Anforderungen, Abhängigkeiten und Integrationen, Meilensteine und Phasenplanung, offene Fragen und Risiken, Anhang.

Was sollte ein PRD enthalten? Die 12 Abschnitte und ihre schwache Version

Ein Produktanforderungsdokument sollte eine Problemstellung, messbare Ziele, explizite Nicht-Ziele, Personas, User Stories mit Akzeptanzkriterien, funktionale und nicht-funktionale Anforderungen, Abhängigkeiten, Meilensteine, offene Fragen mit Verantwortlichen und eine Änderungshistorie enthalten. Alles andere gehört in den Anhang. Der Test für jede Zeile ist derselbe, den ISO/IEC/IEEE 29148:2018 generell an Anforderungen anlegt: nachprüfbar, eindeutig, einzeln.

Die meisten PRDs scheitern an diesem Test immer wieder an denselben drei Stellen.

Zwei Abschnitte verdienen mehr Aufmerksamkeit, als sie normalerweise bekommen.

Nicht-funktionale Anforderungen sind die Stelle, an der sich der Umfang still und leise verdoppelt. Performance, Mandantenfähigkeit, Datenresidenz, Aufbewahrung, Barrierefreiheit, Verfügbarkeit: Jede davon ist eine technische Entscheidung mit Kosten, und keine taucht in einer User Story auf. Schreiben Sie die Sicherheitszeile hier hin, statt sie vage zu umschreiben, und formulieren Sie sie so, wie Sie sie geprüft haben wollen, zum Beispiel mit unserer Sicherheitscheckliste vor dem Launch als Quellliste. Hat der Build eine KI-Komponente, gehören die Produktionsreife-Anforderungen ebenfalls hierher, nicht in eine spätere "Hardening"-Phase, die nie eingeplant wird: Unsere PoC-zu-Produktion-Checkliste ist die Version, die wir selbst verwenden.

Offene Fragen brauchen drei Spalten, nicht nur eine. Frage, Verantwortlicher, Datum, bis wann. Eine Frage ohne Verantwortlichen ist eine Entscheidung, die niemand trifft, und sie taucht in Woche sechs als Change Request wieder auf. Wichtig zu sagen: Ein PRD schreibt man, nachdem man sich für Eigenentwicklung statt Kauf entschieden hat. Liest sich die Problemstellung noch wie eine Einkaufsliste von Features, ist die Build-versus-Buy-Entscheidung noch gar nicht gefallen.

Das Beispiel: Ein ausgefülltes PRD für ein Rechnungsportal

Hier ist ein vollständiges Beispiel, alle 12 Abschnitte ausgefüllt. Der Build: ein Kundenportal für Rechnungen für einen mittelgroßen Logistikbetrieb. Kunden laden PDF-Rechnungen hoch, ein LLM extrahiert die Positionen, das System markiert Abweichungen gegenüber dem Bestelldatensatz, und alles Unsichere landet in einer Warteschlange zur manuellen Prüfung. Stack: Next.js, Supabase/Postgres, ein LLM-Extraktionsschritt. Kopieren Sie es, drucken Sie es aus, exportieren Sie es als PDF, was auch immer Sie brauchen.

# PRD: Kundenportal für Rechnungen, Phase 1

## 1. Kopfzeile
- Verantwortlich (Produkt): Ops-Director, Kundenseite
- Technische Leitung: Delivery Lead, Techsy
- Design-Leitung: Product Designer, Techsy
- Status: Freigegeben für Build
- Zuletzt aktualisiert: 2026-07-28
- Änderungshistorie:
  - 2026-07-14 / Produkt / erster Entwurf
  - 2026-07-21 / Engineering / Confidence-Threshold-Regel zu 6.2 hinzugefügt
  - 2026-07-28 / Produkt / ERP-Write-back zu Nicht-Zielen verschoben

## 2. Problemstellung
Das Ops-Team erhält Kundenrechnungen als per E-Mail versandte PDFs und tippt
sie manuell ins Bestellsystem ein. Das Volumen liegt bei über 300 Rechnungen
pro Woche, die durchschnittliche Bearbeitungszeit beträgt etwa 6 Minuten pro
Rechnung, und bei rund 4% wird ein Tippfehler erst beim Monatsabschluss
entdeckt. Jede Korrektur kostet einen zweiten Durchgang und einen Anruf.

## 3. Ziele & Erfolgsmetriken
| Ziel | Metrik | Ausgangswert | Zielwert | Gemessen durch | Datum |
|---|---|---|---|---|---|
| Manuelle Bearbeitung senken | Ø Bearbeitungszeit | 6 Min | unter 90 Sek | Ops-Dashboard, wöchentlicher Median | 2026-11-01 |
| Tippfehler senken | Beim Abgleich korrigierte Rechnungen | 4% | unter 1% | Finanz-Monatsabschlussbericht | 2026-12-01 |
| Prüfaufwand begrenzen | Anteil in manueller Prüfung | n/v | unter 25% | Portal-Warteschlangen-Metriken | 2026-11-01 |

## 4. Nicht-Ziele
Diese Phase unterstützt keine Mehrwährungsrechnungen, kein ERP-Write-back,
keine Self-Service-Gutschriften für Kunden und keine mobile App. Die
Extraktion deckt ausschließlich PDF ab. Fotos von Papierrechnungen und Scans
unter 200 DPI werden beim Upload mit einer Fehlermeldung abgelehnt.

## 5. Nutzer & Personas
- Ops-Sachbearbeiter (primär, 6 Personen): arbeitet den ganzen Tag die
  Ausnahme-Warteschlange ab, tiefes Fachwissen, nur Desktop.
- Kunden-AP-Kontakt (extern, ~140 Konten): lädt Rechnungen hoch, geringe
  Toleranz für Reibung bei der Kontoeinrichtung.
- Finanzmanager (sekundär): zieht den Monatsabschlussbericht, benötigt einen
  Audit-Trail pro Rechnung.

## 6. User Stories & Akzeptanzkriterien
6.1 Als Kunden-AP-Kontakt möchte ich eine Rechnungs-PDF hochladen, damit ich
sie nicht per E-Mail senden und warten muss.
- Gegeben eine PDF unter 20 MB mit mindestens 200 DPI, wenn ich sie hochlade,
  dann gibt das Portal innerhalb von 5 Sekunden eine Referenznummer zurück
  und zeigt "Wird verarbeitet".

6.2 Als Ops-Sachbearbeiter möchte ich, dass Extraktionen mit geringer
Konfidenz zurückgehalten werden, damit nichts Falsches automatisch
freigegeben wird.
- Gegeben eine geparste Rechnung, wenn die Extraktionskonfidenz für eine
  Position unter 0.85 liegt, dann geht die Rechnung in die Prüf-Warteschlange
  und wird niemals automatisch freigegeben.

6.3 Als Ops-Sachbearbeiter möchte ich die Abweichung an einer Stelle sehen,
damit ich sie lösen kann, ohne das Bestellsystem zu öffnen.
- Gegeben eine Rechnung, die einer Bestellung zugeordnet ist, wenn Menge oder
  Einzelpreis einer Position vom Bestelldatensatz abweichen, dann zeigt das
  Portal beide Werte nebeneinander und markiert die Differenz.

6.4 Als Finanzmanager möchte ich Rechnungen filtern, damit ich den Monat
abschließen kann.
- Gegeben die Rechnungsliste, wenn ich nach Lieferant, Zeitraum und Status
  filtere, dann kommen die Ergebnisse in unter 400ms bei p95 zurück, und der
  leere Zustand bietet "Filter zurücksetzen" an.

## 7. Funktionale Anforderungen
1. Der Upload akzeptiert ausschließlich PDF, maximal 20 MB, eine Datei pro
   Einreichung.
2. Die Extraktion liefert Lieferant, Rechnungsnummer, Datum, Währung sowie
   Positionen mit Menge, Einzelpreis und Gesamtbetrag.
3. Jede Position trägt einen Konfidenzwert zwischen 0 und 1.
4. Der Abgleich vergleicht die extrahierte Rechnung anhand der Bestellnummer
   mit der offenen Bestellung.
5. Ausnahmen laufen in einer nach Alter sortierten Warteschlange auf, einem
   Sachbearbeiter zuweisbar.
6. Jede Statusänderung schreibt einen Audit-Eintrag mit Akteur, Zeitstempel
   und vorherigem Wert.
7. Freigegebene Rechnungen werden als CSV-Batch für das Finanzsystem
   exportiert.

## 8. Nicht-funktionale Anforderungen
- Performance: Rechnungsliste p95 unter 400ms. Die Extraktion ist innerhalb
  von 90 Sekunden nach Upload bei p95 abgeschlossen.
- Sicherheit & Mandantenfähigkeit: mandantenspezifische Isolation auf
  Datenbank-Zeilenebene erzwungen. Ein Kunde kann niemals die Rechnung eines
  anderen Kunden lesen. Bei jedem Release durch einen automatisierten Test
  verifiziert.
- Datenresidenz & Aufbewahrung: Dokumente werden in der EU gespeichert.
  Originale werden 7 Jahre aufbewahrt, Extraktions-Payloads 90 Tage.
- Barrierefreiheit: Warteschlange vollständig per Tastatur bedienbar,
  WCAG 2.2 AA Kontrast.
- Verfügbarkeit: 99.5% monatlich, Support während der Geschäftszeiten.

## 9. Abhängigkeiten & Integrationen
- Bestelldatensätze: schreibgeschützte Postgres-Replik. Zugriff liegt bei der
  Kunden-IT, Zugangsdaten benötigt bis 2026-08-15.
- LLM-Extraktionsanbieter: Vertrag und Auftragsverarbeitungsvereinbarung
  vor Build-Start unterzeichnet.
- E-Mail-Benachrichtigungen: bestehender Transaktions-Provider,
  Absenderdomain vom Kunden verifiziert.

## 10. Meilensteine & Phasenplanung
| Phase | Umfang | Exit-Kriterien | Zieldatum |
|---|---|---|---|
| P1 | Upload, Extraktion, Konfidenz-Routing | 50 echte Rechnungen von Anfang bis Ende, unter 25% in Warteschlange | 2026-09-19 |
| P2 | Bestellabgleich und Abweichungsansicht | Abweichung bei 20 Testfällen korrekt markiert | 2026-10-10 |
| P3 | Audit-Trail, CSV-Export, Reporting | Finanzabteilung schließt einen Monat im Portal ab | 2026-11-01 |

## 11. Offene Fragen & Risiken
| Frage oder Risiko | Verantwortlich | Benötigt bis | Auswirkung, falls unbeantwortet |
|---|---|---|---|
| Welche Bestellnummer ist maßgeblich, wenn eine Rechnung zwei zeigt? | Ops-Director des Kunden | 2026-08-08 | Abgleichlogik blockiert |
| Senden die 12 größten Kunden gescannte oder native PDFs? | Delivery Lead | 2026-08-08 | Konfidenzschwelle könnte falsch sein |
| Ist die 7-jährige Aufbewahrung mit der Rechtsabteilung des Kunden bestätigt? | Finanzmanager des Kunden | 2026-08-22 | Speicherdesign und Kosten ändern sich |
| Extraktionskosten pro Rechnung bei 300/Woche | Delivery Lead | 2026-09-05 | Unit Economics unbekannt |

## 12. Anhang & Links
Anonymisierter Beispiel-Rechnungssatz (40 Dateien), Bestelltabellen-Schema,
aktuelle Bearbeitungszeit-Studie, Figma-Flows für Upload und Warteschlange,
unterzeichnetes Statement of Work.

Vier Entscheidungen darin verdienen besondere Aufmerksamkeit, denn die faule Version jeder einzelnen kostet echtes Geld.

Abschnitt 3, der Ausgangswert. "6 Minuten" ist keine Dekoration. Ohne Ausgangswert lässt sich nicht feststellen, ob etwas funktioniert hat, und sechs Monate später streitet jemand ohne Daten darüber in einem Meeting. Die faule Version, "Effizienz verbessern", macht das Projekt unwiderlegbar.

Abschnitt 4, das Nicht-Ziel. ERP-Write-back wurde am 2026-07-28 in die Nicht-Ziele verschoben, nachdem es in einem Review-Call einfach als gegeben vorausgesetzt worden war. Es als Nicht-Ziel festzuhalten kostete eine Zeile und ersparte einen Scope-Streit.

Abschnitt 6.2, die Konfidenzschwelle. Das ist die Regel, die in unseren eigenen ersten Entwürfen am häufigsten fehlt. Lässt man sie weg, gibt das System Rechnungen automatisch frei, die ein Mensch hätte sehen sollen, und genau dieser Fehler zunichte macht die in Abschnitt 3 versprochene Zeitersparnis.

Abschnitt 11, die Verantwortlichen. Jede offene Frage hat einen Namen und ein Datum. Diese Spalte macht den Unterschied zwischen einem Dokument und einer To-do-Liste, für die niemand zuständig ist.

Das PRD sagt Ihnen, was. Es sagt Ihnen nicht, wie lange oder wie viel das kostet. Das ist eine eigene Übung: siehe Scoping des Builds für diese Hälfte. Und ein Nicht-Ziel, das nicht aufgeschrieben wurde, ist ein Feature, das irgendwann jemand baut.

Wie schreibt man ein PRD, aus dem ein KI-Coding-Agent tatsächlich bauen kann?

Ein PRD für einen KI-Coding-Agenten tauscht Kürze gegen Explizitheit. Der Agent hat keinen informellen gemeinsamen Kontext, keine gemeinsame Vorgeschichte und kein Gespür dafür, was Sie offensichtlich nicht gemeint haben. Vier Regeln decken den größten Teil des Unterschieds ab, und sie stammen daher, dass wir beobachtet haben, welche Spezifikationen in unseren eigenen agentengestützten Builds funktioniert haben und welche nicht.

1. Nicht-Ziele positiv formulieren. Menschen leiten den Umfang aus dem Weglassen ab. Agenten nicht. "In dieser Phase keine Authentifizierung hinzufügen" muss ein Satz im Dokument sein, sonst wird Auth gebaut, getestet und Ihnen zurückgegeben.

2. Die Arbeit in Phasen zuschneiden. Ein 40-seitiger Monolith erzeugt einen selbstsicheren, ausufernden, halb richtigen Pull Request. Zerlegen Sie das PRD in Durchgänge, die ein Agent in einem begrenzten Lauf abschließen kann, jeweils mit eigenen Exit-Kriterien.

3. Akzeptanzkriterien maschinell prüfbar machen. "Schnell" ist keine Anforderung, das ist ein Gefühl. "p95 unter 400ms für den Rechnungslisten-Endpoint" ist ein Test, den der Agent schreiben kann, bevor er das Feature baut.

4. Dateipfade und Stack-Vorgaben ins Dokument schreiben, nicht in den Chat. Chat-Kontext verflüchtigt sich zwischen Sessions. Die Spezifikation nicht. Das ist auch, warum der Plan-Modus von Claude Code wichtig ist: Er liest Ihre Dateien und schlägt einen Plan vor, ohne etwas zu bearbeiten, bis Sie zustimmen, und dieser Freigabeschritt ist deutlich nützlicher, wenn der Plan gegen eine schriftliche Spezifikation geprüft wird statt gegen Ihre Erinnerung daran, was Sie eigentlich wollten.

Hier ist das Rechnungsportal, aufgeteilt in eine Phase, die ein Agent in einem einzigen Durchgang ausführen kann.

# Build-Aufgabe: Rechnungs-Upload und -Extraktion (Phase 1 von 3)

## Stack-Vorgaben (nicht ersetzen)
Next.js 15 App Router, TypeScript, Supabase Postgres mit row-level security,
Vercel-Deployment. Keine neuen Abhängigkeiten ohne vorherige Rückfrage.

## Dateien, die Sie anlegen oder bearbeiten dürfen
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Nicht anfassen
- lib/auth/*  (Auth kommt in Phase 2; jetzt keine Sign-in-Flows hinzufügen)
- Alles unter app/(marketing)/
- Das bestehende orders-Schema. Lesen. Niemals migrieren.

## Akzeptanzkriterien (zuerst als Tests schreiben)
1. POST /api/invoices lehnt Nicht-PDF-Dateien mit 415 und Dateien über 20 MB
   mit 413 ab.
2. Eine Position mit einer Konfidenz < 0.85 setzt invoice.status = 'review',
   niemals 'approved'.
3. Jeder Insert schreibt eine Audit-Zeile mit actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= liefert unter 400ms bei einem
   10,000-row seed.

## Nicht Teil dieses Durchgangs
Bestellabgleich, Abweichungs-UI, CSV-Export, E-Mail-Benachrichtigungen.

Drei Dinge haben sich gegenüber der menschlichen Version geändert: Dateipfade sind aufgetaucht, eine Nicht-anfassen-Liste ist aufgetaucht, und die Akzeptanzkriterien wurden zu Assertions statt zu Sätzen. Welchem Agenten Sie es geben, spielt eine kleinere Rolle, als man denkt, auch wenn sich der Vergleich von Coding-Agenten vor der Entscheidung lohnt. Halten Sie Anforderungen und Projektregeln in getrennten Dateien: Cursor-Regeln und CLAUDE.md enthalten Konventionen und Tooling, das PRD enthält, was gebaut werden soll. Wenn Sie KI-Unterstützung wollen, um den Scope überhaupt erst zu erzeugen, statt ihn nur zu verarbeiten, ist das ein anderer Workflow. Und für den Extraktionsschritt selbst sind Modellwahl und Evaluationsschleife ihr eigenes Thema: KI-Integrationsarbeit.

Was sich ändert, wenn das PRD an ein externes Team geht

Geht das PRD an eine Agentur oder einen Auftragnehmer, hört es auf, ein Abstimmungsdokument zu sein, und wird zu Vertragssprache. Mehrdeutigkeit, die ein internes Team in einem zweiminütigen Gespräch klärt, wird zu einem Change Request mit einem Preisschild. PMIs Pulse of the Profession fand heraus, dass 47% der erfolglosen Projekte ihre Ziele aufgrund von ungenauem Anforderungsmanagement verfehlen. Genau dafür existiert dieses Dokument.

Drei Abschnitte tragen in diesem Kontext überproportionales Gewicht. Akzeptanzkriterien werden zu Freigabe-Gates und müssen deshalb für jemanden nachvollziehbar sein, der kein Entwickler ist. Offene Fragen brauchen einen namentlich benannten Verantwortlichen auf Kundenseite, weil der Dienstleister sie nicht beantworten kann und stattdessen um die Lücke herumbaut. Und die Änderungshistorie hört auf, bürokratisch zu sein: Sie ist die Aufzeichnung, was wann vereinbart wurde, und das ist das Erste, wonach jeder bei einer Meinungsverschiedenheit greift.

Die Zeile, bei der wir mehr als einmal beobachtet haben, dass es schiefgeht, ist irgendeine Version von "Nutzer können ihre Daten exportieren". Niemand schreibt auf, in welchem Format. Die teure Version davon lieferten wir als CSV-Export aus, als der Kunde eigentlich ein formatiertes PDF-Rechnungspaket mit seinem eigenen Branding gemeint hatte, und die Nachbesserung verbrannte rund eine Woche Engineering-Zeit, die niemand eingeplant hatte. Ehrlich betrachtet lag der Fehler im Dokument, nicht in der Lieferung. Ein Akzeptanzkriterium hätte es in fünf Minuten aufgedeckt: gegeben eine Export-Anfrage, wenn die Datei erzeugt wird, dann ist es ein PDF, das dem gelieferten Layout entspricht. Eine Nicht-Ziele-Zeile hätte es aus der anderen Richtung ebenfalls gefangen. Deshalb ist das jetzt eine Regel in unserer Discovery-Phase: Jede Anforderung, die an einem Substantiv wie "Export", "Report" oder "Benachrichtigung" hängt, bekommt ein Format, einen Auslöser und ein durchgerechnetes Beispiel angehängt, bevor ein Statement of Work unterschrieben wird.

Genau das ist der Großteil dessen, was unsere Arbeitsweise bei Webanwendungs-Builds tatsächlich ausmacht: die vage Hälfte der Spezifikation eines Kunden in testbare Zeilen zu verwandeln, bevor jemand Code schreibt.

Was r/ProductManagement tatsächlich über PRD-Vorlagen sagt

Suchen Sie product requirements document template reddit und Sie finden in r/ProductManagement immer wieder dieselbe Beschwerde: Vorlagen-Aufblähung. PRDs, die niemand liest. Abschnitte, die ausgefüllt wurden, weil die Vorlage eine Überschrift hatte, nicht weil jemand den Inhalt brauchte. Dokumente, die schon am Tag nach dem Kickoff veraltet sind und stillschweigend durch einen Slack-Thread ersetzt werden. Das ist eine berechtigte Kritik an den meisten Vorlagen, einschließlich mehrerer unter den Top-Ten-Ergebnissen zu dieser Suche.

Unsere Antwort: Abschnitte streichen statt sie mit nichts zu füllen. Personas fallen zuerst weg, wenn die Nutzer offensichtlich sind. Anhang fällt als Zweites weg. Meilensteine können stattdessen im Tracker leben. Der einzige Abschnitt, den wir nie streichen, sind die Nicht-Ziele, weil er der einzige ist, der kürzer wird, je mehr Arbeit man erledigt, und der einzige, der zuverlässig den Streit verhindert, den man sonst in Woche sechs hätte.

Häufig gestellte Fragen

Was ist ein Produktanforderungsdokument?

Ein Produktanforderungsdokument (PRD) legt fest, was ein Team baut und warum: das Problem, die Ziele und ihre Metriken, die Nicht-Ziele, für wen es ist, und die Anforderungen, die "fertig" definieren. Implementierungsdetails lässt es bewusst aus, die gehören in ein technisches Design-Dokument, das die Engineering-Abteilung anschließend schreibt.

Wie schreibt man ein Produktanforderungsdokument?

Beginnen Sie mit der Problemstellung und verzichten Sie darin konsequent auf Lösungssprache. Fügen Sie messbare Ziele mit Ausgangswert und Zieldatum hinzu, dann schreiben Sie die Nicht-Ziele. Füllen Sie Personas, User Stories mit Given/When/Then-Akzeptanzkriterien, funktionale und nicht-funktionale Anforderungen, Abhängigkeiten, Meilensteine und offene Fragen mit Verantwortlichen aus.

Was sollte ein PRD enthalten?

Zwölf Abschnitte: Kopfzeile mit Änderungshistorie, Problemstellung, Ziele und Erfolgsmetriken, Nicht-Ziele, Nutzer und Personas, User Stories mit Akzeptanzkriterien, funktionale Anforderungen, nicht-funktionale Anforderungen, Abhängigkeiten und Integrationen, Meilensteine und Phasenplanung, offene Fragen und Risiken sowie ein Anhang. Alles, was in keinen dieser Punkte passt, ist wahrscheinlich keine Anforderung.

Wie lang sollte ein PRD sein?

Ein bis zwei Seiten für ein einzelnes Feature, drei bis fünf für eine Produktphase, fünf bis acht, wenn ein externes Team baut und die Akzeptanzkriterien als Freigabe-Gates dienen. Die Länge richtet sich nach der Anzahl der festgehaltenen Entscheidungen, nicht nach der Größe des Produkts. Leere Abschnitte sollten gestrichen, nicht aufgefüllt werden.

Ist ein PRD dasselbe wie ein BRD?

Nein. Ein Business Requirements Document legt das wirtschaftliche Ergebnis fest, das die Organisation will, sowie die Rahmenbedingungen dazu, meist bevor eine Lösung gewählt wird. Ein PRD beschreibt das Produkt, das dieses Ergebnis liefert: Nutzer, Verhalten, Akzeptanzkriterien, Nicht-Ziele. In kleineren Unternehmen ist das BRD oft nur der Abschnitt Problemstellung.

Schreiben agile Teams noch PRDs?

Ja, meist als One-Pager. Das Backlog hält die Arbeit fest, aber Tickets sind denkbar schlecht darin, das Warum, die Nicht-Ziele und die Erfolgsmetrik zu halten. Teams, die das PRD ganz weglassen, entdecken es tendenziell nach drei Sprints als Confluence-Seite mit dem Namen "context" wieder.

Kann man ein PRD in Markdown schreiben?

Markdown ist das beste Format dafür. Es lässt sich sauber in Notion, Confluence, Google Docs und Linear einfügen, versioniert sich in Git neben dem Code als PRD.md, diff't sauber in einem Pull Request und ist das einzige Format, das ein KI-Coding-Agent liest, ohne die Struktur zu verlieren. Genau aus diesen Gründen ist die Vorlage oben in Markdown.

Wie schreibt man ein PRD für einen KI-Coding-Agenten?

Seien Sie explizit, wo Sie sonst knapp wären. Formulieren Sie Nicht-Ziele positiv, weil ein Agent den Umfang nicht aus dem Weglassen ableiten kann. Zerlegen Sie das Dokument in Phasen, die in einem Durchgang abschließbar sind. Schreiben Sie Akzeptanzkriterien als Assertions mit Zahlen. Benennen Sie die Dateien, die der Agent bearbeiten darf, und die, die er nicht anfassen darf.

Was ist der Unterschied zwischen einem PRD und einem technischen Design-Dokument?

Das PRD beantwortet das Was und Warum: Problem, Nutzer, Verhalten, Akzeptanzkriterien, Nicht-Ziele. Das technische Design-Dokument beantwortet das Wie: Architektur, Datenmodell, API-Verträge, abgewogene Trade-offs. In der Regel verantwortet Produkt das Erste und Engineering das Zweite, und das Design-Dokument sollte sich wie eine Antwort auf das PRD lesen lassen.

Wem gehört das PRD, Produkt, Engineering oder dem Kunden?

Produkt verantwortet das Dokument und die Entscheidungen darin. Engineering verantwortet das Machbarkeits-Feedback und die nicht-funktionalen Anforderungen. Bei Agentur-Builds verantwortet der Kunde die Problemstellung, die Ziele und jede offene Frage zu seinem eigenen Geschäft. Geteilte Verantwortung für das gesamte Dokument bedeutet meist, dass niemand es pflegt.

Zusammenfassung

Drei Dinge zum Mitnehmen. Die Vorlage ist erst nützlich, sobald sie ausgefüllt ist. Kopieren Sie also die Form des Beispiels und nicht die leere Version. Nicht-Ziele sind der wertvollste Abschnitt pro Wort im gesamten Dokument und der erste, den Leute überspringen. Und als testbare Assertions formulierte Akzeptanzkriterien dienen zwei Lesern gleichermaßen: einem Entwickler, der eine Lieferung abzeichnet, und einem Agenten, der den Test schreibt.

Wenn Sie ein PRD schreiben, das an ein externes Team geht, und vor der Vertragsunterschrift noch einen zweiten Blick darauf wollen, lesen wir es gerne durch und markieren die mehrdeutigen Zeilen. Das ist derselbe Durchgang, den wir auch bei unseren eigenen Webanwendungs-Builds anwenden.