Offizieller Skill · Produkt

PRD aus chaotischen Notizen

v1.0.1 · Aktualisiert am 4. November 2026

Macht aus Notizen, Slack-Threads und Gesprächsnotizen ein PRD: Problem mit Belegen, Ziele und Nicht-Ziele, Kennzahlen, Must/Should/Could-Anforderungen und markierte Lücken.

Zum Pod meines Teams hinzufügen

Funktioniert in Claude, ChatGPT und Coding-Agents. In Team und Business aktualisiert sich der offizielle Skill in deinem Pod von selbst, wenn wir ihn verbessern.

Wann du ihn nutzt

Du hast verstreute Notizen oder einen Thread zu einem Feature und brauchst ein PRD, nach dem das Team bauen kann
Jemand aus der Gründung bittet dich nach einem Call oder einer Whiteboard-Session, „das aufzuschreiben“

Was du ihm gibst

Notizen, Threads, Transkripte oder Zitate
Zielnutzer (optional)
Deadlines oder Zielwerte (optional)

Was du bekommst

Ein PRD in Markdown mit Problem, Belegen, Nutzern, Zielen, Nicht-Zielen, Kennzahlentabelle, priorisierten Anforderungen, offenen Fragen, Risiken und Lücken.

So funktioniert er

Arbeite das Problem und seine Belege heraus Beantworte die erste Frage aus Marty Cagans Opportunity Assessment: Welches Problem löst das, und für wen? Formuliere das Problem als das, was Nutzer heute nicht können oder was es sie kostet. Liste darunter die Belege auf: Zitate, Ticketzahlen, verlorene Deals, Zahlen. Enthalten die Notizen keine Belege, schreib „Keine Belege in den Notizen“, statt eine Begründung zu erfinden.
Benenne die Nutzer Ein primärer Nutzer und höchstens 2 sekundäre, jeweils mit der Situation, in der das Problem zuschlägt. „Kleinunternehmer“ ist zu breit; „eine Inhaberin, die ihre erste Rechnung vom Smartphone verschickt“ passt.
Trenn Ziele von Nicht-Zielen Ziele sind Ergebnisse, keine Features. Schreib mindestens 2 Nicht-Ziele; alles, was in den Notizen besprochen und verworfen wurde, gehört hierher, damit es niemand wieder aufmacht.
Leg Erfolgskennzahlen fest Eine primäre Kennzahl, die sich bewegt, wenn das Problem gelöst ist, dazu 1 oder 2 Leitplanken, die sich nicht verschlechtern dürfen. Jede braucht einen Ausgangswert und ein Ziel; geben die Notizen sie nicht her, schreib „[offen: Ausgangswert]“ und „[offen: Ziel]“.
Schreib die Anforderungen als Must/Should/Could (MoSCoW) Must = ohne das ist die Lösung nicht tragfähig. Should = wichtig, schmerzhaft wegzulassen, aber es gibt einen Workaround. Could = wünschenswert, fliegt als Erstes raus, wenn der Termin wackelt. Won't (diesmal nicht) kommt zu den Nicht-Zielen, damit es nicht still wieder auftaucht. Jede Zeile ist testbar („Nutzer können als CSV exportieren“), nicht vage („einfacher Export“). Der Leitfaden des Agile Business Consortium hält die Musts typischerweise bei höchstens 60 % des Aufwands; wirken die Musts größer, sag, dass der Umfang für ein Release zu groß ist.
Liste offene Fragen und Risiken auf Jeder Widerspruch zwischen zwei Notizen wird zu einer offenen Frage, die beide Positionen nennt. Risiken decken ab, woran das Feature scheitern könnte: Akzeptanz, Technik, Recht, Abhängigkeit von einem anderen Team. Gib jedem eine verantwortliche Person, wenn die Notizen eine nennen.
Kennzeichne die Quelle jeder Aussage Fakten aus den Notizen stehen ohne Zusatz. Alles, was du abgeleitet hast, bekommt „[Annahme]“. Trag nie eine Zahl, ein Datum oder einen Kundennamen ein, der nicht im Input steht.

Teile ihn mit deinem Team

Füge ihn einem AI Skill Pod hinzu, und alle im Team, auch Freelancer, nutzen dieselbe Version aus ihrer eigenen KI. Lies, wie Teams KI-Skills am besten teilen