Ein PRD aus einer Ein-Satz-Feature-Anfrage schreiben
5 Min. Lesezeit
Die meisten PRDs beginnen gleich: ein leeres Dokument und eine Ein-Satz-Idee wie „Nutzer sollen ihre Daten exportieren können“. Von dort ist es leicht, einfach loszuschreiben, was einem zuerst einfällt, meist die Anforderungen, und drei Absätze später zu merken, dass nirgends im Dokument eine Problembeschreibung oder eine Erfolgskennzahl steht. Ein PM, der von einer Feature-Idee begeistert ist, beginnt oft damit, die Mechanik zu schreiben, wie es genau funktionieren soll, die genauen Felder, die genaue Button-Platzierung, lange bevor er aufschreibt, welches Problem es eigentlich löst.
Achtung
Ein leeres Dokument erinnert dich nicht daran, welche Abschnitte ein PRD braucht. Es gibt nur zurück, in welcher Reihenfolge dir die Dinge einfielen, was selten die Reihenfolge ist, die ein Prüfer erwartet.
Eine Feature-Idee ist ein Satz. Ein PRD ist eine Struktur. Loses Schreiben bringt dir den Satz, nur ausführlicher.
Warum loses Schreiben unbemerkt Abschnitte auslässt
Von einer leeren Seite zu schreiben bedeutet, die Struktur im Gehen zu erfinden, und es ist leicht, die Teile zu schreiben, die naheliegend wirken, meist die Anforderungen, und die Teile auszulassen, die mehr Denkarbeit brauchen, wie das eigentliche Problem zu benennen oder eine Kennzahl zu wählen, die beweist, dass das Feature funktioniert hat. Der Anforderungsabschnitt ist konkret und befriedigend zu schreiben, da er eine Liste spezifischer, prüfbarer Dinge ist. Die Problembeschreibung verlangt, einen Schritt zurückzutreten und zu formulieren, warum irgendetwas davon wichtig ist, eine andere, schwerere Art des Denkens, und das ist der Teil, der unter Zeitdruck zuerst wegfällt.
Nimm eine Ein-Satz-Idee wie „Nutzer sollen ihre Daten als CSV exportieren können“. Ein von der Idee begeisterter PM könnte zwanzig Minuten damit verbringen, genau festzulegen, welche Felder im Export enthalten sein sollen und was auf dem Button stehen soll, und erst beim Versenden zur Prüfung merken, dass nirgends ein Satz erklärt, warum das wichtig ist, dass der Support seit Monaten manuelle Exportanfragen bearbeitet. Ein Prüfer, der dieses Dokument öffnet, kann nicht beurteilen, ob die vorgeschlagenen Anforderungen das echte Problem tatsächlich lösen, weil das echte Problem nie aufgeschrieben wurde.
Vorher: ein leeres Dokument öffnen, anfangen, Anforderungen für die Feature-Idee zu schreiben, später merken, dass Problembeschreibung und Erfolgskennzahlen fehlen.
Nachher: Claude die Ein-Satz-Idee und das Problem geben, das sie löst, und einen strukturierten ersten Entwurf zurückbekommen, Problem, Ziele, Anforderungen und Kennzahlen, mit jedem Abschnitt schon vorhanden, um ihn zu verfeinern.
Ein Prozess für einen strukturierten ersten Entwurf
- 1
Die Feature-Idee und das Problem nennen, das sie löst
Ein Satz für jedes reicht zum Start. „Nutzer sollen ihre Daten als CSV exportieren können, weil der Support ständig manuell danach gefragt wird“ gibt Claude sowohl das Was als auch das Warum.
- 2
Um eine feste Struktur bitten, nicht einen offenen Entwurf
Bitte konkret um eine Problembeschreibung, eine kleine Anzahl Ziele, funktionale Anforderungen und Erfolgskennzahlen, in dieser Reihenfolge. Eine feste Struktur ist es, die den Entwurf prüfbar macht statt zu einem Aufsatz.
- 3
Eine echte Zahl für Ziele und Kennzahlen geben
Bitte um eine konkrete Anzahl, drei Ziele, zwei Kennzahlen, statt „einige Ziele“. Eine Zahl erzwingt Priorisierung statt einer offenen Liste, die immer weiter wächst.
- 4
Den Entwurf als Startstruktur behandeln, nicht als finales Dokument
Lies alles noch einmal durch und schreibe jeden Abschnitt in deiner eigenen Stimme um. Der Wert des ersten Entwurfs ist, dass nichts fehlt, nicht dass die Formulierung final ist.
Wir wollen Nutzern erlauben, ihre Daten als CSV zu exportieren. Entwirf ein einseitiges PRD mit einer Problembeschreibung, drei Zielen, funktionalen Anforderungen und zwei Erfolgskennzahlen, die wir in den ersten 30 Tagen verfolgen könnten.
”Stammt die Feature-Idee aus einer konkreten, bekannten Quelle, einem Cluster von Support-Tickets, einer Kundenanfrage, einer Wettbewerbslücke, lohnt es sich, Claude das explizit zu sagen, da eine Problembeschreibung, die sich auf eine echte, benannte Quelle stützt, einem Prüfer weit glaubwürdiger erscheint als eine plausibel klingende, aber generische.
Diese Idee kam direkt aus 15 Support-Tickets im letzten Monat, die alle nach einem Weg fragten, ihre Daten herauszubekommen, ohne den Support zu kontaktieren. Schreibe die Problembeschreibung um, um diese echte Quelle konkret zu referenzieren, nicht eine generische Beschreibung des Bedürfnisses.
”
In Claude Tutorial
Von einer festen Struktur statt einer leeren Seite zu starten ist übertragbar.
Mit einer bekannten Reihenfolge von Abschnitten zu arbeiten, statt die Struktur beim Schreiben zu erfinden, gilt weit über PRDs hinaus. Die App hat eine vollständige Lektion dazu, mit Übungen, die sich auf jedes Dokument mit einer von Prüfern erwarteten Form übertragen lassen.
Wenn die Ziele nicht zu den Kennzahlen passen
Eine häufige Lücke in einem ersten Entwurf ist ein Ziel ohne zugehörige Kennzahl, oder eine Kennzahl, die das genannte Ziel gar nicht wirklich beweist. Diese Diskrepanz lohnt es sich zu erkennen, bevor das Dokument hinausgeht, nicht nachdem jemand fragt, woran man erkennen wird, dass das Feature funktioniert hat. Ein Ziel wie „Supportaufwand senken“, gepaart mit einer Kennzahl wie „Anzahl durchgeführter Exporte“, klingt verwandt, beweist das Ziel aber nicht wirklich, da Nutzer ständig exportieren könnten, ohne dass ein einziges Support-Ticket vermieden wird.
Tipp
Bitte Claude, jedes Ziel direkt gegen seine Kennzahl zu prüfen: beweist das Erreichen dieser Zahl wirklich das Ziel, oder nur etwas damit Korreliertes? Eine leicht zu messende Kennzahl ist nicht automatisch die richtige.
Hier sind die drei Ziele und zwei Kennzahlen aus diesem PRD-Entwurf. Sag mir für jedes Ziel ehrlich, ob die Kennzahlen tatsächlich beweisen, dass es eingetreten ist, oder nur etwas Benachbartes messen.
”Stellt sich heraus, dass eine Kennzahl mit der bestehenden Tooling-Landschaft wirklich schwer zu verfolgen ist, lohnt es sich, diese Einschränkung früh offenzulegen, statt ein PRD mit einer Erfolgskennzahl zu versenden, die niemand tatsächlich messen kann, sobald das Feature live ist.
Eine dieser Kennzahlen würde ein Tracking erfordern, das wir derzeit nicht eingerichtet haben. Schlage eine Kennzahl vor, die dasselbe Ziel beweist, aber mit unserem bestehenden Analytics-Setup realistisch zu messen ist.
”Weiterlesen
- Ein PRD schärfen, bevor du es zur Prüfung schickst: den strukturierten Entwurf aus diesem Artikel testen, bevor er einen Prüfer erreicht.
- Ein Roadmap-Dokument schreiben, das die Kompromisse erklärt: was passiert, sobald diese Feature-Idee mit anderen um einen Platz auf der Roadmap konkurrieren muss.
- Support-Tickets in priorisierte Themen verwandeln: eine Quelle echter Feature-Ideen, aus denen überhaupt PRDs geschrieben werden.