Zurück zum Playbook
Define & DesignDD-06
Ein PRD schreiben
Beschreibt, was Nutzer können müssen, grenzt den Umfang explizit ab und ersetzt Anforderungen nicht durch Design oder Architektur.
ProduktstatusVerfügbar
Input3 benötigte InputsResearch und vereinbarte Feature-Richtung · Erfolgsmessgrössen und Einschränkungen · Fokus der Initiative und freigegebene Product-Brain-Leitlinien
SkillsDraft product requirements · Prepare task context · Review an artifact against agreed criteriaProduct Manager + Product Manager Agent
ErgebnisKnappes PRD: Problem und Bedeutung, Nutzer und Vorgehen, P0/P1/P2-Anforderungen, Grenzen, Erfolg und Evidenz.Artefakt: PRD
Owner
Product Manager
Mensch + Agent
Beteiligte · Agents
DesignerEngineerProduct Manager Agent
Auslöser
Ein bekanntes Nutzerproblem braucht gemeinsame Anforderungen.
Benötigter Kontext
KundenbelegeResearch und vereinbarte Feature-RichtungProduct BrainErfolgsmessgrössen und EinschränkungenProduct BrainFokus der Initiative und freigegebene Product-Brain-Leitlinien
Optionaler Kontext
ConfluenceFreigegebener Feature BriefJiraBestehende Anforderungen und EpicsCodeAktuelles Produktverhalten
Skills
Draft product requirementsPrepare task contextReview an artifact against agreed criteria
Vorgeschlagener Gesprächsbogen
- 1Bestätigen, dass das Problem verstanden istPrüfen, ob die Research das Nutzerbedürfnis belegt; ist das Problem noch spekulativ, die Discovery-Lücke festhalten, statt ein vollständiges PRD zu fabrizieren.Skills: Prepare task context
- 2Beobachtbare Anforderungen entwerfenEin knappes PRD mit Problem, Geschäftsbegründung, Use Cases, Lösungsrichtung, P0/P1/P2-Verhalten, Ausschlüssen, Erfolgsmessgrössen und offenen Fragen erstellen.Skills: Draft product requirements
- 3Umfang und Konsistenz prüfenAnforderungen gegen Problem und Erfolgsmessgrössen prüfen; durchgesickerte Lösungsdetails entfernen und Widersprüche oder unbelegten Umfang sichtbar machen.Skills: Review an artifact against agreed criteria
- 4Die Anforderungs-Baseline bestätigenVerbleibende Trade-offs mit dem PM und den betroffenen Funktionen besprechen und eine Version als Arbeits-Baseline bestätigen, ohne eine abgeschlossene Umsetzung zu behaupten.
Ergebnis
Knappes PRD: Problem und Bedeutung, Nutzer und Vorgehen, P0/P1/P2-Anforderungen, Grenzen, Erfolg und Evidenz.
Artefakte
Erstellt: PRD
So sieht gut aus
- Anforderungen sind beobachtbar und unterscheiden Priorität von Freigabe.
- Umfang und Erfolgsmessgrössen sind explizit, ohne die Umsetzung vorzuschreiben.
- Ungelöste Konflikte bleiben Entscheide, keine stillschweigend gewählten Anforderungen.
Freigabe
Der Product Manager bestätigt mit den betroffenen Funktionen eine Version als Arbeits-Baseline.
Ziel
ConfluenceJira
Meist als Nächstes
Menschen und Agents arbeiten mit demselben Product Brain. Der Owner bleibt verantwortlich. Zugewiesene Agents bereiten vor und prüfen. Ein benannter Mensch gibt an der Freigabe frei.
Vertiefung im AI PM Lab
Beiträge, die das Denken hinter dieser Activity erklären.
Wähl den Einstieg, der zu deiner Rolle passt.
Leg mit uns die Product-AI-Richtung fest oder teste das gemeinsame Product Brain mit Jira und Code an echter Arbeit.