Was steht in deinem PRD, und was lässt du bewusst weg?

Drin: das Problem, der Beleg, dass es echt ist, der Nutzer und sein aktueller Workaround, Erfolgsmetriken mit einer Scheiterschwelle, explizite Non-Goals und offene Fragen. Draußen: das Lösungsdesign und die Implementierung. Wenn dein Dokument die UI oder das Schema festlegt, hast du die interessanten Entscheidungen den Leuten weggenommen, die sie am besten treffen können, und du bekommst Gehorsam statt Ideen.

Mein PRD ist kurz und besteht überwiegend aus Belegen. Problem, wer es hat und wie oft, was sie heute stattdessen tun, warum jetzt, die Metrik mit einer expliziten Scheiterschwelle, und eine Non-Goals-Liste. Der Non-Goals-Abschnitt verdient seinen Platz jedes Mal, denn dort fängst du den Scope Creep ab, der sonst in Woche drei ankommt. Bewusst weg lasse ich die Lösung. Ich packe keine Wireframes und kein Schema hinein, denn in dem Moment hören Engineers und Designer auf zu lösen und fangen an, meine halbgare Idee umzusetzen. Das habe ich auf die harte Tour gelernt, nachdem ich einmal eine sehr detaillierte Spezifikation geschrieben und exakt das bekommen habe, worum ich gebeten hatte, was schlechter war als das, was das Team von sich aus gebaut hätte. Ich halte außerdem oben einen Abschnitt mit offenen Fragen und aktualisiere ihn laufend, damit das Dokument zeigt, was wir noch nicht wissen, statt so zu tun, als wäre es fertig.