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

Question

Accepted Answer

Et **Product Requirements Document (PRD)** forklarer *hva* du bygger, *hvorfor*, og *hvordan du vet at det fungerte* — slik at ingeniørteamet og designteamet kan bygge den riktige løsningen uten konstant avklaringer. Et godt PRD er et tenktekstil og et justeringsartefakt, ikke byråkratisk papirer.

## Et solid PRD-utkast

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

## Start med hvorfor

Den aller viktigste delen er **problemet og målene**. Hvis teamet forstår *hvorfor* og *hva suksess ser ut som*, vil de ofte finne bedre løsninger enn den du spesifiserte. Et PRD som bare er en funksjonsspec mangler dette.

## Ikke-mål er undervurdert

Å eksplisitt si hva som er utenfor omfanget, forhindrer omfangskryp og "mens vi holder på"-fellen. Det er like verdifullt som kravene selv.

## Vanlige fallgruver

```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 dette er viktig

Det meste av omarbeidingen kommer fra feilaktig justering: teamet bygde det som ble spurt om, ikke det som var nødvendig.

Et klart PRD bringer disse hullene til overflaten *før* noen skriver kode.

Det tvinger også *deg* til å tenke gjennom problemet.

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