Hvordan skriver du et godt Product Requirements Document (PRD)?

Question

Accepted Answer

Et **Product Requirements Document (PRD)** forklarer *hvad* du bygger, *hvorfor*, og *hvordan du ved, at det virkede* — så engineering og design kan bygge det rigtige uden konstant præcisering. Et godt PRD er et tænkeredskab og et justeringsartefakt, ikke byrokrati.

## En solid PRD-disposition

```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
```

## Begynd med hvorfor

Den vigtigste sektion er **problemet og målene**. Hvis teamet forstår *hvorfor* og *hvad succes ligner*, finder de ofte bedre løsninger end den, du specificerede. Et PRD, der kun er en feature spec, går glip af dette.

## Non-goals er undervurderede

At eksplicit angive, hvad der er uden for rammerne, forhindrer scope creep og "mens vi alligevel er i gang..."-fælden. Det er lige så værdifuldt som kravene selv.

## Almindelige fejl

```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
```

## Hvorfor det betyder noget

Det meste omarbejde kommer fra dårlig justering: teamet byggede det, der blev spurgt efter, ikke det, der var brug for.

Et klart PRD afslører disse huller *før* nogen skriver kode.

Det tvinger også *dig* til at tænke problemet igennem.

Hvis du ikke kan skrive målet og successmetrikken klart, forstår du problemet ikke godt nok til at bygge det endnu.