Wie schreibt man ein gutes Product Requirements Document (PRD)?

Question

Accepted Answer

Ein **Product Requirements Document (PRD)** erklärt *was* du baust, *warum* und *wie du wissen wirst, dass es funktioniert* — damit Engineering und Design das Richtige bauen können, ohne ständige Klärungen zu brauchen. Ein gutes PRD ist ein Denk-Werkzeug und ein Alignment-Artefakt, keine bürokratische Dokumentation.

## Eine solide PRD-Gliederung

```text
1. PROBLEM / CONTEXT → what problem, for whom, why now
2. GOALS & SUCCESS METRICS → what outcome, how measured
3. NON-GOALS → what this explicitly does NOT cover
4. USER STORIES / REQUIREMENTS → what it must do
5. UX → flows, wireframes, key states
6. EDGE CASES → errors, empty states, limits
7. DEPENDENCIES & RISKS → what could block or break this
8. OPEN QUESTIONS → known unknowns to resolve
```

## Mit dem Warum beginnen

Der wichtigste Abschnitt ist das **Problem und die Ziele**. Wenn das Team versteht, *warum* und *wie Erfolg aussieht*, werden sie oft bessere Lösungen finden als die, die du spezifiziert hast. Ein PRD, das nur ein Feature-Spec ist, verpasst das.

## Non-Goals sind unterschätzt

Explizit festzuhalten, was nicht in den Umfang gehört, verhindert Scope Creep und die "Während wir gerade dabei sind..."-Falle. Es ist genauso wertvoll wie die Anforderungen selbst.

## Häufige Fallstricke

```text
✗ Over-specifying the HOW → boxes in engineering's better ideas
✗ No success metric → you can't tell if it worked
✗ Writing it alone → involve eng/design early to catch issues
✗ Treating it as fixed → a PRD is a living doc
```

## Warum es wichtig ist

Die meiste Überarbeit kommt von fehlender Ausrichtung: Das Team hat gebaut, was gefragt wurde, nicht was gebraucht wurde.

Ein klares PRD zeigt diese Lücken *bevor* jemand Code schreibt.

Es zwingt *dich* auch, das Problem durchzudenken.

Wenn du das Ziel und die Erfolgsmessgröße nicht klar schreiben kannst, verstehst du das Problem nicht gut genug, um es noch zu bauen.