10. PRD — was gebaut werden muss, bevor eine einzige Zeile Code geschrieben wird
Die einzige Wahrheitsquelle, in der die Betreiberabsicht außerhalb der Sitzung lebt. Was in eine PRD gehört, was nicht, das kumulative Gate-Muster und wie man sie lebendig hält.
Die ersten neun Beiträge dieser Serie handelten davon, was Alice ist — Persona, Gedächtnis, Skills, Hooks, Multi-Agent, Verifikation, Token-Ökonomie, Sitzungsprotokolle. Dinge, die innerhalb des Systems leben.
Die nächsten drei Beiträge handeln von der Arbeit, die durch Alice läuft. Die Form der Absicht, bevor der Code beginnt, das Gate, das sagt, wann Code fertig ist, und der Loop, der beides laufen lässt, ohne dass der Betreiber an der Tastatur sitzt.
Dies ist der erste dieser drei. PRD.
0. Die Prämisse — Code ist das Letzte, was man schreibt
Die meisten Betreiber beginnen mit Code. Editor öffnen, Funktion schreiben, schauen ob es funktioniert.
Dieses Muster kollabiert in dem Moment, in dem die Arbeit größer wird als ein einzelner Nachmittag. Der Code von gestern erinnert sich nicht daran, warum er existiert. Die Sitzung von morgen weiß nicht, was als fertig zählt. Der Team-Lead genehmigt einen Slice, und Wochen später passt der Slice nicht mehr.
Das Problem ist nicht der Code. Das Problem ist, dass die Absicht nirgendwo dauerhaft niedergeschrieben wurde. Der Betreiber trug sie im Kopf, die KI trug Fragmente im context window — und beide Oberflächen verdampfen.
PRD — Product Requirement Document — ist die Antwort. Kein Planungs-Artefakt. Eine Oberfläche, auf der die Absicht des Betreibers außerhalb der Sitzung lebt, wo die nächste Sitzung und der nächste Kollaborateur sie lesen können, ohne erneut zu fragen.
1. Was bricht, wenn es keine PRD gibt
Ein paar Muster, deren Kollaps ich beobachtet habe — in meiner eigenen Arbeit und in Übergaben an mich.
- Entscheidungsfäulnis. Eine Wahl wird in einer Chat-Sitzung getroffen. Drei Wochen später erinnert sich niemand — auch der Betreiber selbst nicht — warum. Der Code wird zurückgedreht, driftet ab oder wird in jeder Sitzung neu verhandelt.
- Scope-Drift. „Wenn wir schon dabei sind" schleicht sich ein. Bis der Slice ausgeliefert wird, hat er vier Dinge statt einem getan, und keines der vier wurde geprüft.
- Kollaps der Fertig-Definition. Jemand meldet „Feature ist drin." Der Team-Lead fragt „in welchem Sinne?" Gebaut? Getestet? Live? Geprüft? Jede Antwort ist halb ja, und das Gespräch dreht sich im Kreis.
- Onboarding-Kollaps. Ein neuer Kollaborateur — ein anderer Agent, ein anderes Teammitglied, eine zukünftige Alice in frischem Kontext — hat keinen Einstiegspunkt. Sie rekonstruieren die Absicht aus dem Code — genau der Loop, den der Betreiber teuer bezahlt hatte, um ihn zu vermeiden.
Der gemeinsame Faden ist derselbe, mit dem Teil 1 — Why Alice eröffnete. Die Absicht des Betreibers — der Zweck hinter dem Code — überlebt die Sitzungsgrenze nicht.
2. PRD ist Absicht, dauerhaft gemacht
Die Aufgabe einer PRD ist eng und spezifisch. Sie plant keine Aufgaben, weist keine Verantwortlichen zu, verfolgt keinen Fortschritt. Das gehört anderswohin.
Eine PRD beantwortet eine Frage: was bauen wir, und was lässt es als gebaut zählen?
| Schicht | Was sie enthält | Warum sie hier hingehört |
|---|---|---|
| Produktübersicht | Ein Absatz, den der Betreiber laut vorlesen könnte | Zwingt den Betreiber, das Ziel in einem Atemzug aussprechen zu können |
| Zielnutzer | Für wen das ist und was sie mitnehmen | Filtert jede spätere Entscheidung — wenn ein Feature diesem Nutzer nicht dient, streichen |
| Funktionale Anforderungen | Was das System tun muss | Nummeriert. Jede testbar. |
| Nicht-funktionale Anforderungen | Performance, Sicherheit, Barrierefreiheits-Untergrenzen | Gleiche Nummern-Disziplin. „Lighthouse Perf ≥ 90" schlägt „sollte schnell sein." |
| Meilensteine | M0 → M1 → M2 mit dem, was jeder freischaltet | Die Form des Weges, nicht die Arbeitsaufschlüsselung |
| Release gates | Die kumulativen Kriterien, damit jeder Meilenstein als live zählt | Siehe §4 unten |
| Offene Fragen | Dinge, die explizit noch nicht entschieden sind | Der am wenigsten genutzte Abschnitt. Sichtbar unentschieden > unsichtbar unentschieden. |
Beachte, was nicht auf dieser Liste steht. Keine Aufgabenliste, kein Tageslog, kein Wer-hat-was-getan. Diese Dinge ändern sich jede Sitzung. Eine PRD ändert sich, wenn die Absicht sich ändert — und das ist viel langsamer.
Eine PRD beschreibt das Ziel. Alles andere beschreibt die Route.
3. Was hineingehört und was draußen bleibt
Die Regel, auf die ich nach PRDs konvergierte, die auf vierzig Seiten anwuchsen, und nach PRDs, die auf eine Postkarte passten:
In die PRD, wenn: das Ändern der Zeile ändert, was das System ist. Beispiele — „i18n ist Pflicht, sechs Locales", „Downloads müssen SHA-256 anzeigen", „kein Klarname des Betreibers erscheint irgendwo."
Nicht in die PRD, wenn: das Ändern der Zeile ändert nur, wie das System gebaut wird. Beispiele — „pnpm für Builds verwenden", „shadcn für UI-Primitiven verwenden", „Commits mit [devAlice]-Präfix taggen."
Die zweite Liste lebt in CLAUDE.md oder einer README oder einem Tooling-Dokument. Nicht in der PRD.
Der Grund für diese Trennung ist keine Ästhetik. Es ist Lebensdauer. PRD-Zeilen sollten ein Jahr überleben. Build-System-Zeilen überleben vielleicht keine zwei Quartale. Sie in unterschiedlichen Dokumenten zu halten, lässt jede in ihrem eigenen Tempo verrotten, ohne die andere mitzuziehen.
4. Das Muster der kumulativen Gates
Das nützlichste Muster, das ich in PRDs verwendet habe, ist ein kumulativer Release-Gate-Abschnitt.
Die Form:
Gate 0: M0 launch (temporary domain)
- Build passes
- Four category routes render
- One seed guide per category
- ESLint clean
Gate 1: Compliance (required before publication)
- Privacy policy (ko + en)
- Content license (CC BY)
- Code license (MIT)
- About page exists
- ...
Gate 2: Infrastructure
- Custom domain bound
- SSL active (auto)
- Production env vars set
- ...
Gate 3: Security
- No hardcoded secrets
- .env.example has every key
- RLS enabled on user tables
- ...
... Gate 10
Jedes Gate ist eine Tabelle. Jede Zeile ist [item | status | note]. Status ist eines von ✅ pass / ⏳ in progress / 🔒 waiting on operator / ❌ not started / — N/A.
Drei Dinge machen dieses Muster wirksam.
Kumulativ. Gate 2 setzt voraus, dass Gate 1 bestanden ist. Gate 9 setzt Gates 0–8 voraus. Die Form des Weges ist eingebaut. Niemand muss je fragen „in welcher Reihenfolge?" — das Dokument antwortet.
Atomare Zeilen. Eine Zeile besteht entweder oder nicht. „Funktioniert größtenteils" ist kein Status. Das zwingt den Betreiber, vage Punkte („Performance ist okay") in Zeilen aufzubrechen, die abgehakt werden können („Lighthouse Performance ≥ 90 auf fünf Referenzseiten").
Status sichtbar auf Zeilen-Ebene. Der Betreiber muss keine Prosa lesen, um zu wissen, wo das Projekt steht. Spalte überfliegen — die ✅ gegen die 🔒 zählen — und das Bild ist sofort da.
Dies ist der Abschnitt, den der Team-Lead in jeder Sitzung zuerst liest. Es ist auch der Abschnitt, der Teil 11 — Release gates und Teil 12 — Ralph loop antreibt.
5. PRD vs. der einmalige Plan
Betreiber verwechseln eine PRD oft mit dem Sitzungs-Plan. Sie sind nicht dasselbe. Sie leben auf unterschiedlichen Zeitskalen.
| Dokument | Zeitskala | Was es ändert |
|---|---|---|
| PRD | Monate | Der Betreiber entscheidet, was das Produkt ist |
| PLAN.md | Tage bis Wochen | Der Betreiber entscheidet, wie ein Slice gebaut wird |
| HANDOFF.md | Eine Sitzung | Die vorherige Sitzung hinterlässt Notizen für die nächste |
| TASK_BOARD | Stunden bis Tage | Arbeits-Aufschlüsselung für den aktiven Sprint |
| Lessons-learned | Monate, nur-anfügen | Fehler, die das System nicht wiederholen soll |
Eine Absichtszeile, die zwischen diesen herumspringt — heute in HANDOFF, morgen in PLAN, übermorgen in einer Chat-Sitzung — akkumuliert sich nie. Dieselbe Absicht muss an einer konsistenten Stelle ausdrückbar sein. Die PRD ist diese Stelle.
Wenn eine Sitzung startet, liest Alice zuerst PRD.md, dann HANDOFF.md, dann PLAN.md. Die Lesungen bauen aufeinander auf. Die PRD legt fest, was zählt; HANDOFF sagt, wo der Betreiber aufgehört hat; PLAN sagt, was in diesem Slice passiert.
6. Die PRD am Leben halten
Eine PRD, die verrottet, ist schlimmer als keine PRD, denn alle lesen sie weiterhin und handeln nach veralteter Absicht. Drei Gewohnheiten, die ich in Rotation halte.
Versionierung an Ort und Stelle. Oben in der Datei: v1.0 → v1.1 → v1.2. Jede Version hat eine einzeilige Notiz, was sich geändert hat. Die aktuelle Version ist das, was die jüngste Zeile sagt. Es gibt keine separate Changelog-Datei.
Offene-Fragen-Abschnitt ist Pflicht. Jede PRD, die ich schreibe, hat einen „offene Fragen"-Abschnitt, der während aktiver Entwicklung niemals leer ist. An dem Tag, an dem er leer wird, ist entweder das Projekt fertig oder jemand versteckt Entscheidungen im Kopf.
Status-Review bei jedem Meilenstein. Wenn ein Meilenstein abschließt, die gesamte Gate-Tabelle durchgehen. Punkte, die während des Meilensteins auf ✅ gedriftet sind, werden befördert; Punkte, die nicht angerührt wurden, wandern in den Offene-Fragen-Abschnitt. Die PRD ist die Momentaufnahme der aktuellen Absicht, nicht der historischen.
7. Die Fallen
Muster, deren Bruch ich in der Praxis an PRDs beobachtet habe.
7.1 PRD-als-Marketing
Zeilen wie „begeisternde UX" und „erstklassige Performance". Nichts in diesen Zeilen ist testbar. Streichen. Wenn „Performance" zählt, schreibe „Lighthouse Performance ≥ 90 auf Mobil, fünf Referenzseiten."
7.2 PRD-als-Aufgabenliste
Jede Zeile beginnt mit einem Verb. „Implementiere X. Baue Y. Verdrahte Z." Das ist ein Task-Board, keine PRD. PRD-Zeilen beschreiben das System — was es ist, was es tun muss — nicht die Arbeit, es so zu machen.
7.3 PRD, die nie aktualisiert wird
Die PRD hat v1.0 oben und der Meilenstein ist M3. Entweder passieren Entscheidungen in Chat-Sitzungen und landen nicht hier zurück, oder das Projekt segelt auf veralteter Absicht. Beides sind Warnsignale.
7.4 Entscheidungen im Chat, nicht in der PRD
Der Team-Lead genehmigt etwas in einer Slack-Nachricht oder einer Sitzungsantwort. Zwei Wochen später erinnert sich niemand, warum. Wenn eine Entscheidung die PRD ändert, geht sie in die PRD, bevor die Sitzung endet. Das ist der Preis des Genehmigens.
7.5 Zwei PRDs
Jemand schreibt eine „echte PRD" und eine „Zusammenfassungs-PRD" oder eine „koreanische PRD" und eine „englische PRD", die auseinanderdriften. Eine wählen. Mehrsprachige Oberflächen sind für die Nutzer; PRDs sind für das Team und leben in einer Sprache und einer Datei.
Download — PRD-Vorlage
Eine einsatzbereite PRD-Vorlage: Arbeitsumfang, globale Einschränkungen, der Verifikationsbefehl, eine Entscheidungszuständigkeitsmatrix und Abnahmekriterien pro Element. Die Form, die dieser Beitrag beschreibt, als eine Datei.
PRD-code.mdshasum -a 256 PRD-code.md
# expected: 1c41c0e61b3dd027fa261e10a8b1f06381e40ee3ce476c24a8df673acb310e7c8. Ein Prinzip
Die ganze Form, wie ich PRDs verwende, kollabiert auf eine Zeile.
„Alles, was die Absicht des Betreibers zwischen Sitzungen verlieren würde, in die PRD schreiben. Alles, was kein Quartal überlebt, draußen lassen."
Das ist auch die Brücke zu den nächsten beiden Beiträgen. Eine PRD beantwortet was ist das Ziel. Teil 11 — Release gates beantwortet woher wissen wir, dass wir angekommen sind. Teil 12 — Ralph loop beantwortet wie lassen wir das System den Großteil des Weges gehen, ohne dass der Betreiber es an der Hand führt.
Zusammen verwandeln diese drei die Absicht des Betreibers — die Absicht aus Teil 1 — in etwas, das das System über Sitzungen, Tage und Kollaborateure hinweg tragen kann, ohne sie zu verlieren.