PRD-mal for produktkravsdokument (+ et fullstendig eksempel du kan kopiere)

PRD-mal for produktkravsdokument (+ et fullstendig eksempel du kan kopiere)

Sist oppdatert: 28. juli 2026.

De fleste sidene med PRD-mal for produktkravsdokument gir deg et tomt skjema. Atlassians er fire seksjoner med instruksjoner rundt en tom tabell for suksessmålinger. Product School har «(med eksempel)» i tittelen og inneholder ikke noe eksempel. Markdown-blokken med 12 seksjoner nedenfor er hele malen, fri og kopierbar. Seksjon 4 fyller deretter ut alle disse 12 seksjonene for en komplett gjennomarbeidet bygging: en fakturaportal for kunder som leser PDF-er med en LLM og sender de tvilsomme videre til en menneskelig gjennomgang. Kopier den tomme. Les den utfylte. Skriv din egen.

Nøkkelpunkter

• En PRD svarer på hva som skal bygges og hvorfor; det tekniske designdokumentet svarer på hvordan.
• De 12 seksjonene passer til ethvert prosjekt uansett størrelse. En ettsider er samme mal med færre rader.
• Ikke-mål må skrives ned. En AI-kodingsagent kan ikke utlede omfang fra det som er utelatt.
• Akseptansekriterier må være maskinsjekkbare: «p95 under 400ms», aldri «rask».

Hvilken PRD-form bør du bruke?

Velg formen etter hvem som leser dokumentet, ikke etter hvor stort produktet føles. En enkelt funksjon som går til dine egne utviklere, trenger en ettsider. En bygging overlevert til et eksternt team trenger den fulle 12-delers PRD-en, fordi akseptansekriteriene også fungerer som godkjenningsporter. En spesifikasjon til en AI-kodingsagent trenger de samme tolv seksjonene delt opp i faser.

Ettsider-malen for produktkrav som alle spør etter, er ikke et eget dokument. Lenny Rachitskys mye kopierte 1-sider, publisert med reelle eksempler i nyhetsbrevet hans, er det samme skjelettet med seremonien fjernet. En ettsider er ikke et annet dokument. Det er de samme tolv seksjonene med de tomme radene slettet.

Smidige team stiller ofte det samme spørsmålet, som regel formulert som om en PRD tåler møtet med en backlog. Det gjør den, som en ettsider: PRD-en tar vare på hvorfor-et og grensene, sakene tar vare på arbeidet.

PRD-malen (kopier-lim markdown)

Her er hele greia som markdown, fri og uten e-postmur. Lim den inn i Notion, Confluence, Google Docs, Linear, Word, eller commit den til GitHub som PRD.md og la den versjoneres sammen med koden. Folk ber om denne malen i ni forskjellige formater; markdown er den som overlever en innliming i alle sammen, og det er den eneste en AI-kodingsagent leser rent.

# PRD: [Produkt- eller funksjonsnavn]

## 1. Header
- Eier (produkt):
- Teknisk lead:
- Design-lead:
- Status: Utkast | Til gjennomgang | Godkjent | Lansert
- Sist oppdatert:
- Endringshistorikk: dato / forfatter / hva som ble endret

## 2. Problemstilling
Ett avsnitt. Hvem det rammer, hvor ofte, hva det koster i dag. Ingen løsningsspråk.

## 3. Mål og suksessmålinger
| Mål | Måling | Utgangspunkt | Mål | Måles av | Dato |
|---|---|---|---|---|---|

## 4. Ikke-mål
Skrevet positivt: «Denne fasen inkluderer ikke X.»

## 5. Brukere og personas
Hvem bruker det, hva de allerede vet, hvilken enhet, hvor ofte.

## 6. Brukerhistorier og akseptansekriterier
Som [persona] vil jeg [handling], slik at [utfall].
- Given [kontekst], when [hendelse], then [observerbart resultat].

## 7. Funksjonelle krav
Nummerert. Ett krav per linje. Testbart. Ingen setning med «og».

## 8. Ikke-funksjonelle krav
Ytelse / sikkerhet og leietaker-isolasjon / datalokasjon og oppbevaring / tilgjengelighet / driftstid.

## 9. Avhengigheter og integrasjoner
Eksterne systemer, API-er, legitimasjon, hvem eier tilgangen, ledetid.

## 10. Milepæler og fasing
| Fase | Omfang | Avslutningskriterier | Måldato |
|---|---|---|---|

## 11. Åpne spørsmål og risikoer
| Spørsmål eller risiko | Eier | Trengs innen | Konsekvens hvis ubesvart |
|---|---|---|---|

## 12. Vedlegg og lenker
Design, research, konkurrentnotater, tidligere saker, kontrakter.

De tolv seksjonene, i rekkefølge: header, problemstilling, mål og suksessmålinger, ikke-mål, brukere og personas, brukerhistorier med akseptansekriterier, funksjonelle krav, ikke-funksjonelle krav, avhengigheter og integrasjoner, milepæler og fasing, åpne spørsmål og risikoer, vedlegg.

Hva bør en PRD inneholde? De 12 seksjonene, og den svake versjonen av hver

Et produktkravsdokument bør inneholde en problemstilling, målbare mål, eksplisitte ikke-mål, personas, brukerhistorier med akseptansekriterier, funksjonelle og ikke-funksjonelle krav, avhengigheter, milepæler, åpne spørsmål med eiere, og en endringshistorikk. Alt annet er vedlegg. Testen for hver linje er den samme som ISO/IEC/IEEE 29148:2018 bruker for krav generelt: verifiserbar, entydig, enkeltstående.

De fleste PRD-er stryker på testen på de samme tre stedene.

To seksjoner fortjener mer enn de vanligvis får.

Ikke-funksjonelle krav er der omfanget stille og rolig dobles. Ytelse, leietaker-isolasjon, datalokasjon, oppbevaring, tilgjengelighet, driftstid: hver av disse er en teknisk beslutning med en kostnad, og ingen av dem dukker opp i en brukerhistorie. Legg sikkerhetslinjen her i stedet for som en håndvifting, og skriv den slik du vil at den skal sjekkes, ved å bruke noe som vår sikkerhetssjekkliste før lansering som kildeliste. Hvis byggingen har en AI-komponent, hører produksjonsklarhetskravene også hjemme her, ikke i en senere «herding»-fase som aldri blir planlagt: vår sjekkliste fra PoC til produksjon er versjonen vi bruker.

Åpne spørsmål trenger tre kolonner, ikke én. Spørsmål, eier, trengs-innen-dato. Et spørsmål uten eier er en beslutning ingen tar, og det vil dukke opp som en endringsforespørsel i uke seks. Verdt å si: en PRD er det du skriver etter at du har bestemt deg for å bygge fremfor å kjøpe. Hvis problemstillingen fortsatt leser som en handleliste med funksjoner, har bygge-eller-kjøpe-avgjørelsen egentlig ikke skjedd ennå.

Det gjennomarbeidede eksempelet: En PRD for fakturaportal, utfylt

Her er et komplett gjennomarbeidet eksempel, alle 12 seksjonene fylt ut. Byggingen: en fakturaportal for kunder hos en mellomstor logistikkoperatør. Kunder laster opp PDF-fakturaer, en LLM trekker ut varelinjene, systemet flagger avvik mot ordredata, og alt den er usikker på, går til en menneskelig gjennomgangskø. Stack: Next.js, Supabase/Postgres, ett LLM-ekstraksjonstrinn. Kopier den, skriv den ut, eksporter til PDF, hva du enn trenger.

# PRD: Fakturaportal for kunder, fase 1

## 1. Header
- Eier (produkt): Driftsdirektør, kundeside
- Teknisk lead: Leveranseansvarlig, Techsy
- Design-lead: Produktdesigner, Techsy
- Status: Godkjent for bygging
- Sist oppdatert: 2026-07-28
- Endringshistorikk:
  - 2026-07-14 / produkt / første utkast
  - 2026-07-21 / utvikling / la til regel for konfidensterskel i 6.2
  - 2026-07-28 / produkt / flyttet ERP-tilbakeskriving til ikke-mål

## 2. Problemstilling
Driftspersonell mottar kundefakturaer som PDF-er på e-post og taster dem
manuelt inn i ordresystemet. Volumet passerer 300 fakturaer i uken,
gjennomsnittlig behandlingstid er rundt 6 minutter hver, og rundt 4%
inneholder en tastefeil som først oppdages ved avstemming ved månedsslutt.
Hver korrigering koster en ny runde og en telefonsamtale.

## 3. Mål og suksessmålinger
| Mål | Måling | Utgangspunkt | Mål | Måles av | Dato |
|---|---|---|---|---|---|
| Redusere manuell behandling | Gj.snitt. behandlingstid | 6 min | under 90 sek | Driftsdashbord, ukentlig median | 2026-11-01 |
| Redusere tastefeil | Fakturaer korrigert ved avstemming | 4% | under 1% | Finans, månedsrapport | 2026-12-01 |
| Begrense gjennomgangslast | Andel sendt til manuell gjennomgang | n/a | under 25% | Portalens kø-målinger | 2026-11-01 |

## 4. Ikke-mål
Denne fasen støtter ikke fakturaer i flere valutaer, ERP-tilbakeskriving,
kundens egen selvbetjente kreditnota, eller en mobilapp. Ekstraksjon dekker
kun PDF. Fotografier av papirfakturaer og skanninger under 200 DPI avvises
ved opplasting med en melding som forklarer hvorfor.

## 5. Brukere og personas
- Driftsmedarbeider (primær, 6 personer): jobber med unntakskøen hele dagen,
  dyp domenekunnskap, kun stasjonær.
- Kundens regnskapskontakt (ekstern, ~140 kontoer): laster opp fakturaer,
  lav toleranse for friksjon ved kontooppsett.
- Finanssjef (sekundær): henter ut månedsrapporten, trenger et revisjonsspor
  per faktura.

## 6. Brukerhistorier og akseptansekriterier
6.1 Som kundens regnskapskontakt vil jeg laste opp en faktura-PDF, slik at jeg
slipper å sende den på e-post og vente.
- Given en PDF under 20 MB på 200 DPI eller bedre, when jeg laster den opp,
  then returnerer portalen et referansenummer innen 5 sekunder og viser
  «Behandler».

6.2 Som driftsmedarbeider vil jeg at ekstraksjoner med lav konfidens holdes
tilbake, slik at ingenting feil blir godkjent automatisk.
- Given en tolket faktura, when konfidensen for en varelinje er under 0.85,
  then sendes fakturaen til gjennomgangskøen og blir aldri automatisk
  godkjent.

6.3 Som driftsmedarbeider vil jeg se avviket på ett sted, slik at jeg kan løse
det uten å åpne ordresystemet.
- Given en faktura matchet mot en ordre, when et linjeantall eller en
  enhetspris avviker fra ordredataene, then viser portalen begge verdiene
  side om side og flagger avviket.

6.4 Som finanssjef vil jeg filtrere fakturaer, slik at jeg kan avslutte
måneden.
- Given fakturalisten, when jeg filtrerer etter leverandør, datoperiode og
  status, then returneres resultater på under 400ms ved p95 og tom tilstand
  viser «Nullstill filtre».

## 7. Funksjonelle krav
1. Opplasting godtar kun PDF, maks 20 MB, én fil per innsending.
2. Ekstraksjon returnerer leverandør, fakturanummer, dato, valuta og
   varelinjer med antall, enhetspris og totalsum.
3. Hver varelinje har en konfidensscore mellom 0 og 1.
4. Matching sammenligner den ekstraherte fakturaen med den åpne ordren via
   PO-nummer.
5. Unntak går inn i en kø sortert eldst først, som kan tildeles én
   medarbeider.
6. Hver tilstandsendring skriver en revisjonsoppføring med aktør, tidsstempel
   og tidligere verdi.
7. Godkjente fakturaer eksporteres som en CSV-batch til regnskapssystemet.

## 8. Ikke-funksjonelle krav
- Ytelse: fakturalisten p95 under 400ms. Ekstraksjon fullføres innen 90
  sekunder etter opplasting ved p95.
- Sikkerhet og leietaker-isolasjon: isolasjon per leietaker håndheves på
  databaseradnivå. En kunde kan aldri lese en annen kundes faktura. Verifisert
  av en automatisk test ved hver utgivelse.
- Datalokasjon og oppbevaring: dokumenter lagres i EU. Originaler oppbevares i
  7 år, ekstraksjonsdata i 90 dager.
- Tilgjengelighet: køen er fullt betjenbar med tastatur, WCAG 2.2 AA-kontrast.
- Driftstid: 99.5% månedlig, support i arbeidstiden.

## 9. Avhengigheter og integrasjoner
- Ordredata: skrivebeskyttet Postgres-replika. Tilgang eies av kundens
  IT-avdeling, legitimasjon trengs innen 2026-08-15.
- LLM-ekstraksjonsleverandør: kontrakt og databehandleravtale signert før
  byggingen starter.
- E-postvarsler: eksisterende transaksjonsleverandør, avsenderdomene
  verifisert av kunden.

## 10. Milepæler og fasing
| Fase | Omfang | Avslutningskriterier | Måldato |
|---|---|---|---|
| P1 | Opplasting, ekstraksjon, ruting basert på konfidens | 50 reelle fakturaer fra ende til ende, under 25% i kø | 2026-09-19 |
| P2 | Ordrematching og avviksvisning | Avvik korrekt flagget på 20 seedede tilfeller | 2026-10-10 |
| P3 | Revisjonsspor, CSV-eksport, rapportering | Finans avslutter én måned i portalen | 2026-11-01 |

## 11. Åpne spørsmål og risikoer
| Spørsmål eller risiko | Eier | Trengs innen | Konsekvens hvis ubesvart |
|---|---|---|---|
| Hvilket PO-nummer er gjeldende når en faktura viser to? | Kundens driftsdirektør | 2026-08-08 | Matchelogikken blokkeres |
| Sender de 12 største kundene skannede eller native PDF-er? | Leveranseansvarlig | 2026-08-08 | Konfidensterskelen kan være feil |
| Er 7-års oppbevaring bekreftet med kundens juridiske avdeling? | Kundens finanssjef | 2026-08-22 | Lagringsdesign og kostnad endres |
| Ekstraksjonskostnad per faktura ved 300/uke | Leveranseansvarlig | 2026-09-05 | Enhetsøkonomi ukjent |

## 12. Vedlegg og lenker
Anonymisert eksempelsett med fakturaer (40 filer), skjema for ordretabell,
gjeldende studie av behandlingstid, Figma-flyter for opplasting og kø,
signert oppdragsavtale.

Fire valg der er verdt å trekke frem, fordi den late versjonen av hver koster ekte penger.

Seksjon 3, utgangspunktet. «6 minutter» er ikke pynt. Uten et utgangspunkt kan du ikke vite om tiltaket faktisk virket, og seks måneder senere krangler noen om det i et møte uten data. Den late versjonen, «forbedre effektiviteten», gjør prosjektet umulig å motbevise.

Seksjon 4, ikke-målet. ERP-tilbakeskriving ble flyttet til ikke-mål 2026-07-28, etter å ha blitt antatt inn i eksistens under en gjennomgang. Å skrive det ned som et ikke-mål kostet én linje og reddet en omfangskrangel.

Seksjon 6.2, konfidensterskelen. Dette er regelen våre egne førsteutkast oftest overser. Utelat den, og systemet godkjenner automatisk fakturaer et menneske burde ha sett, som er nøyaktig den feilen som visker ut tidsbesparelsen du lovet i seksjon 3.

Seksjon 11, eierne. Hvert åpent spørsmål har et navn og en dato. Den kolonnen er forskjellen mellom et dokument og en gjøreliste ingen eier.

PRD-en forteller deg hva. Den forteller deg ikke hvor lenge eller hvor mye, som er en egen øvelse: se omfangsbestemmelse for bygging for den halvparten. Og et ikke-mål du ikke skrev ned, er en funksjon noen kommer til å bygge.

Hvordan skriver du en PRD en AI-kodingsagent faktisk kan bygge fra?

En PRD skrevet for en AI-kodingsagent bytter kortfattethet mot eksplisitthet. Agenten har ingen uformell delt kontekst, ingen felles historie, og ingen instinkt for hva du åpenbart ikke mente. Fire regler dekker mesteparten av forskjellen, og de kommer fra å observere spesifikasjoner lykkes og mislykkes på tvers av våre egne agent-assisterte byggeprosjekter.

1. Angi ikke-mål positivt. Mennesker utleder omfang fra det som er utelatt. Agenter gjør ikke det. «Ikke legg til autentisering i denne fasen» må være en setning i dokumentet, ellers blir autentisering bygget, testet og levert tilbake til deg.

2. Del arbeidet i faser. Én monolitt på 40 sider produserer en selvsikker, sprikende, halvveis riktig pull request. Del PRD-en i deler en agent fullfører i én avgrenset kjøring, hver med sine egne avslutningskriterier.

3. Gjør akseptansekriteriene maskinsjekkbare. «Rask» er ikke et krav, det er en følelse. «p95 under 400ms på fakturalistens endepunkt» er en test agenten kan skrive før den skriver funksjonen.

4. Sett filstier og stack-begrensninger i dokumentet, ikke i chatten. Chat-kontekst fordamper mellom økter. Spesifikasjonen gjør ikke det. Dette er også grunnen til at Claude Codes plan-modus er viktig: den leser filene dine og foreslår en plan uten å redigere noe før du godkjenner, og det godkjenningssteget er langt mer nyttig når planen sjekkes mot en skriftlig spesifikasjon i stedet for hukommelsen din om hva du ba om.

Her er fakturaportalen, delt inn i én fase en agent kan utføre i én omgang.

# Byggeoppgave: Fakturaopplasting og ekstraksjon (Fase 1 av 3)

## Stack-begrensninger (ikke bytt ut)
Next.js 15 App Router, TypeScript, Supabase Postgres med row-level security,
Vercel-deploy. Ingen nye avhengigheter uten å spørre først.

## Filer du kan opprette eller redigere
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Ikke rør
- lib/auth/*  (autentisering leveres i fase 2; ikke legg til innloggingsflyter nå)
- Alt under app/(marketing)/
- Det eksisterende ordreskjemaet. Les det. Aldri migrer det.

## Akseptansekriterier (skriv disse som tester først)
1. POST /api/invoices avviser ikke-PDF med 415 og filer over 20 MB med 413.
2. En varelinje med confidence < 0.85 setter invoice.status = 'review',
   aldri 'approved'.
3. Hver innsetting skriver en revisjonsrad med actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returnerer under 400ms på en
   10,000-row seed.

## Utenfor omfanget for denne omgangen
Ordrematching, avviksvisning, CSV-eksport, e-postvarsler.

Tre ting endret seg sammenlignet med den menneskelige versjonen: filstier dukket opp, en ikke-rør-liste dukket opp, og akseptansekriteriene ble påstander i stedet for setninger. Hvilken agent du gir den til, betyr mindre enn folk tror, selv om sammenligningen av kodingsagenter er verdt å lese før du bestemmer deg. Hold krav og prosjektregler i separate filer: Cursor rules og CLAUDE.md inneholder konvensjoner og verktøy, PRD-en inneholder hva som skal bygges. Hvis du vil ha AI-hjelp til å utarbeide omfanget i utgangspunktet i stedet for å bruke det, er det en annen arbeidsflyt. Og for selve ekstraksjonstrinnet er modellvalg og evalueringsløkke sitt eget AI-integrasjonsarbeid.

Hva endrer seg når PRD-en går til et eksternt team

Når PRD-en går til et byrå eller en kontraktør, slutter den å være et samstemmingsdokument og blir kontraktsspråk. Tvetydighet et internt team løser med en to-minutters samtale, blir en endringsforespørsel med en pris. PMIs Pulse of the Profession fant at 47 % av mislykkede prosjekter ikke når målene sine på grunn av unøyaktig kravhåndtering. Det er hele grunnen til at dette dokumentet finnes.

Tre seksjoner bærer uforholdsmessig mye vekt i den settingen. Akseptansekriterier blir godkjenningsporter, så de må være observerbare for noen som ikke er utvikler. Åpne spørsmål trenger en navngitt eier på kundens side, fordi leverandøren ikke kan svare på dem og vil bygge rundt hullet. Og endringshistorikken slutter å være byråkrati: det er dokumentasjonen av hva som ble avtalt når, som er det første noen griper etter under en uenighet.

Linjen vi har sett gå galt mer enn én gang, er en eller annen versjon av «brukere kan eksportere dataene sine». Ingen skriver ned hvilket format. Den dyre versjonen av det, for oss, endte som en CSV-eksport når kunden hadde ment en formatert PDF-fakturapakke med sin egen merkevare på, og å gjøre det om igjen brukte omtrent en uke med utvikling ingen hadde budsjettert for. Den ærlige lesningen er at feilen lå i dokumentet, ikke i leveransen. Et akseptansekriterium ville fanget det på fem minutter: gitt en eksportforespørsel, når filen genereres, da er den en PDF som matcher det angitte oppsettet. En ikke-mål-linje ville også fanget det, fra den andre siden. Så det er nå en regel i vår kartlegging: ethvert krav som henger på et substantiv som «eksport», «rapport» eller «varsel», får et format, en utløser og et gjennomarbeidet eksempel festet før en oppdragsavtale signeres.

Det meste av det hvordan vi kjører webapplikasjonsbygging faktisk er: å gjøre om den vage halvparten av en kundes spesifikasjon til testbare linjer før noen skriver kode.

Hva sier r/ProductManagement egentlig om PRD-maler

Søk product requirements document template reddit, og du finner den samme klagen gjentatt i r/ProductManagement: malbesvær. PRD-er ingen leser. Seksjoner fylt ut fordi malen hadde en overskrift, ikke fordi noen trengte innholdet. Dokumenter som blir foreldet dagen etter oppstart og stille erstattes av en Slack-tråd. Det er en rettferdig kritikk av de fleste maler, inkludert flere blant de ti beste treffene på dette søket.

Vårt svar: slett seksjoner i stedet for å fylle dem med ingenting. Personas kommer først når brukerne er åpenbare. Vedlegg kommer nummer to. Milepæler kan bo i sporingsverktøyet i stedet. Den vi aldri sletter, er ikke-mål, fordi det er den eneste seksjonen som blir kortere jo mer arbeid du gjør, og den eneste som pålitelig forhindrer krangelen du ellers ville hatt i uke seks.

Ofte stilte spørsmål

Hva er et produktkravsdokument?

Et produktkravsdokument (PRD) angir hva et team bygger og hvorfor: problemet, målene og målingene deres, ikke-målene, hvem det er for, og kravene som definerer «ferdig». Det utelater bevisst implementasjonsdetaljer, som hører hjemme i et teknisk designdokument skrevet i etterkant av utviklingsteamet.

Hvordan skriver du et produktkravsdokument?

Start med problemstillingen og nekt å bruke løsningsspråk i den. Legg til målbare mål med et utgangspunkt og en måldato, skriv deretter ikke-mål. Fyll inn personas, brukerhistorier med Gitt/Når/Da-akseptansekriterier, funksjonelle og ikke-funksjonelle krav, avhengigheter, milepæler og åpne spørsmål med eiere.

Hva bør en PRD inneholde?

Tolv seksjoner: header med endringshistorikk, problemstilling, mål og suksessmålinger, ikke-mål, brukere og personas, brukerhistorier med akseptansekriterier, funksjonelle krav, ikke-funksjonelle krav, avhengigheter og integrasjoner, milepæler og fasing, åpne spørsmål og risikoer, og et vedlegg. Alt som ikke passer inn i en av disse, er trolig ikke et krav.

Hvor lang bør en PRD være?

Én til to sider for en enkelt funksjon, tre til fem for en produktfase, fem til åtte når et eksternt team bygger den og akseptansekriteriene fungerer som godkjenningsporter. Lengden følger antall beslutninger som dokumenteres, ikke produktets størrelse. Tomme seksjoner bør slettes, ikke fylles med utfylling.

Er en PRD det samme som en BRD?

Nei. Et forretningskravdokument (BRD) angir det kommersielle utfallet organisasjonen ønsker og begrensningene rundt det, vanligvis før en løsning er valgt. En PRD beskriver produktet som leverer det: brukere, atferd, akseptansekriterier, ikke-mål. I mindre selskaper er BRD-en ofte bare problemstillings-seksjonen.

Skriver smidige team fortsatt PRD-er?

Ja, som regel som en ettsider. Backloggen holder arbeidet, men saker er dårlige til å holde på hvorfor-et, ikke-målene og suksessmålingen. Team som hopper over PRD-en helt, har en tendens til å gjenoppdage den som en Confluence-side kalt «kontekst» tre sprinter inn i prosjektet.

Kan du skrive en PRD i markdown?

Markdown er det beste formatet for det. Det limes rent inn i Notion, Confluence, Google Docs og Linear, versjoneres i Git ved siden av koden som PRD.md, viser riktige diff-er i en pull request, og er det eneste formatet en AI-kodingsagent leser uten å miste strukturen. Malen ovenfor er markdown av nettopp disse grunnene.

Hvordan skriver du en PRD for en AI-kodingsagent?

Vær eksplisitt der du normalt ville vært kortfattet. Angi ikke-mål positivt, fordi en agent ikke kan utlede omfang fra det som er utelatt. Del dokumentet inn i faser som kan fullføres i én omgang. Skriv akseptansekriterier som påstander med tall. Navngi filene agenten kan redigere og de den ikke kan røre.

Hva er forskjellen mellom en PRD og et teknisk designdokument?

PRD-en svarer på hva og hvorfor: problem, brukere, atferd, akseptansekriterier, ikke-mål. Det tekniske designdokumentet svarer på hvordan: arkitektur, datamodell, API-kontrakter, avveininger som ble vurdert. Produkt eier vanligvis det første, utvikling det andre, og designdokumentet bør kunne leses som et svar på PRD-en.

Hvem eier PRD-en, produkt, utvikling eller kunden?

Produkt eier dokumentet og beslutningene i det. Utvikling eier gjennomførbarhetstilbakemeldingene og de ikke-funksjonelle kravene. På byråprosjekter eier kunden problemstillingen, målene og alle åpne spørsmål om sin egen virksomhet. Delt eierskap over hele dokumentet betyr som regel at ingen vedlikeholder det.

Avslutning

Tre ting å ta med seg. Malen er bare nyttig når den er fylt ut, så kopier formen til det gjennomarbeidede eksempelet fremfor den tomme. Ikke-mål er den seksjonen med høyest verdi per ord i dokumentet, og den første folk hopper over. Og akseptansekriterier skrevet som testbare påstander tjener to lesere like godt: en utvikler som godkjenner en leveranse, og en agent som skriver testen.

Hvis du skriver en PRD som skal overleveres til et eksternt team og vil ha et ekstra par øyne på den før den blir kontraktsspråk, leser vi den gjerne og markerer de tvetydige linjene. Det er den samme gjennomgangen vi kjører på våre egne webapplikasjonsbygginger.