PRD-skabelon (produktkravsdokument) + et fuldt gennemarbejdet eksempel du kan kopiere

PRD-skabelon (produktkravsdokument) + et fuldt gennemarbejdet eksempel du kan kopiere

Sidst opdateret: 28. juli 2026.

De fleste sider med produktkravsdokument skabeloner giver dig et tomt skema. Atlassians version er fire afsnit med instruktioner viklet rundt om en tom succes-metrics-tabel. Product Schools har "(with Example)" i titlen og indeholder intet eksempel. Markdown-blokken med 12 sektioner nedenfor er hele skabelonen, ugated, klar til at kopiere. Afsnit 4 udfylder derefter alle de 12 sektioner i et komplet gennemarbejdet byggeri: en klientfaktura-portal, der læser PDF'er med en LLM og sender de tvivlsomme videre til et menneske. Kopiér den tomme. Læs den udfyldte. Skriv din egen.

Vigtigste pointer

• En PRD svarer på hvad der skal bygges, og hvorfor; det tekniske designdokument svarer på hvordan.
• De 12 sektioner passer til ethvert projektomfang. En one-pager er den samme skabelon med færre rækker.
• Ikke-mål skal skrives ned. En AI-kodeagent kan ikke udlede omfang ud fra det, der ikke er nævnt.
• Acceptkriterier skal kunne tjekkes maskinelt: "p95 under 400 ms", aldrig "hurtigt".

Hvilken PRD-form skal du bruge?

Vælg formen efter, hvem der læser dokumentet, ikke efter hvor stort produktet føles. En enkelt funktion, der går til jeres egne udviklere, kræver en one-pager. Et byggeri, der overdrages til et eksternt team, kræver den fulde 12-sektions PRD, fordi acceptkriterierne samtidig fungerer som godkendelsesporte. En spec til en AI-kodeagent kræver de samme tolv sektioner, skåret op i faser.

Den one-page produktkravsdokument-skabelon, alle beder om, er ikke et separat dokument. Lenny Rachitskys meget kopierede one-pager, udgivet med rigtige eksempler i hans nyhedsbrev, er det samme skelet med ceremonien skåret væk. En one-pager er ikke et andet dokument. Det er de samme tolv sektioner med de tomme rækker slettet.

Agile teams spørger også ofte om dette, som regel formuleret som, om en PRD holder, når der findes en backlog. Det gør den, som en one-pager: PRD'en rummer hvorfor'et og grænserne, ticketsene rummer arbejdet.

PRD-skabelonen (kopiér-indsæt markdown)

Her er det hele som markdown, gratis, uden krav om e-mail. Indsæt det i Notion, Confluence, Google Docs, Linear, Word, eller commit det til GitHub som PRD.md og lad det versionere sammen med koden. Folk beder om denne skabelon i ni forskellige formater; markdown er det, der overlever en indsætning i dem alle, og det er det eneste, en AI-kodeagent læser rent.

# PRD: [Produkt- eller funktionsnavn]

## 1. Header
- Ejer (produkt):
- Teknisk lead:
- Design-lead:
- Status: Kladde | Under gennemgang | Godkendt | Lanceret
- Sidst opdateret:
- Ændringshistorik: dato / forfatter / hvad der blev ændret

## 2. Problembeskrivelse
Ét afsnit. Hvem lider, hvor ofte, hvad koster det i dag. Ingen løsningssprog.

## 3. Mål & succesmålinger
| Mål | Måling | Baseline | Mål | Måles ved | Dato |
|---|---|---|---|---|---|

## 4. Ikke-mål
Formuleret positivt: "Denne fase omfatter ikke X."

## 5. Brugere & personaer
Hvem bruger det, hvad ved de allerede, hvilken enhed, hvor ofte.

## 6. Brugerhistorier & acceptkriterier
Som [persona] vil jeg [handling], så jeg [resultat].
- Givet [kontekst], når [hændelse], så [observerbart resultat].

## 7. Funktionelle krav
Nummereret. Ét krav per linje. Testbart. Ingen sætning med "og".

## 8. Ikke-funktionelle krav
Performance / sikkerhed & tenancy / dataresidens & opbevaring / tilgængelighed / driftsstabilitet.

## 9. Afhængigheder & integrationer
Eksterne systemer, API'er, credentials, hvem ejer adgangen, leveringstid.

## 10. Milepæle & faseinddeling
| Fase | Omfang | Exit-kriterier | Måldato |
|---|---|---|---|

## 11. Åbne spørgsmål & risici
| Spørgsmål eller risiko | Ejer | Nødvendigt inden | Konsekvens hvis ubesvaret |
|---|---|---|---|

## 12. Appendiks & links
Designs, research, konkurrentnoter, tidligere tickets, kontrakter.

De tolv sektioner, i rækkefølge: header, problembeskrivelse, mål og succesmålinger, ikke-mål, brugere og personaer, brugerhistorier med acceptkriterier, funktionelle krav, ikke-funktionelle krav, afhængigheder og integrationer, milepæle og faseinddeling, åbne spørgsmål og risici, appendiks.

Hvad skal en PRD indeholde? De 12 sektioner, og den svage version af hver

Et produktkravsdokument bør indeholde en problembeskrivelse, målbare mål, eksplicitte ikke-mål, personaer, brugerhistorier med acceptkriterier, funktionelle og ikke-funktionelle krav, afhængigheder, milepæle, åbne spørgsmål med ejere og en ændringshistorik. Alt andet er appendiks. Testen for hver linje er den samme, som ISO/IEC/IEEE 29148:2018 anvender på krav generelt: verificerbar, entydig, enkeltstående.

De fleste PRD'er fejler den test på de samme tre steder.

To sektioner fortjener mere, end de normalt får.

Ikke-funktionelle krav er der, hvor omfanget stille og roligt fordobles. Performance, tenancy, dataresidens, opbevaring, tilgængelighed, driftsstabilitet: hver af dem er en teknisk beslutning med en pris, og ingen af dem optræder i en brugerhistorie. Placér sikkerhedslinjen her i stedet for som en vag håndbevægelse, og skriv den, som du ville ønske den blev tjekket, ved brug af noget som vores pre-launch sikkerhedstjekliste som kildeliste. Hvis byggeriet har en AI-komponent, hører produktionsklarhedskravene også til her, ikke i en senere "hærdnings"-fase, der aldrig bliver skemalagt: vores PoC-til-produktion-tjekliste er den version, vi bruger.

Åbne spørgsmål kræver tre kolonner, ikke én. Spørgsmål, ejer, nødvendig-inden-dato. Et spørgsmål uden ejer er en beslutning, som ingen tager, og det vil dukke op som en ændringsanmodning i uge seks. Værd at nævne: en PRD er det, du skriver, efter du har besluttet at bygge frem for at købe. Hvis problembeskrivelsen stadig ligner en indkøbsliste af funktioner, er build-versus-buy-beslutningen faktisk ikke truffet endnu.

Det gennemarbejdede eksempel: en fakturaportal-PRD, udfyldt

Her er et komplet gennemarbejdet eksempel, alle 12 sektioner udfyldt. Byggeriet: en klientfaktura-portal til en mellemstor logistikoperatør. Kunder uploader PDF-fakturaer, en LLM udtrækker linjeposterne, systemet flager uoverensstemmelser mod ordredata, og alt, den er usikker på, går til en manuel review-kø. Stack: Next.js, Supabase/Postgres, ét LLM-udtræksskridt. Kopiér det, print det, eksportér det til PDF, hvad du nu har brug for.

# PRD: Klientfaktura-portal, fase 1

## 1. Header
- Ejer (produkt): Ops-direktør, klientside
- Teknisk lead: Delivery lead, Techsy
- Design-lead: Produktdesigner, Techsy
- Status: Godkendt til byggeri
- Sidst opdateret: 2026-07-28
- Ændringshistorik:
  - 2026-07-14 / produkt / første udkast
  - 2026-07-21 / teknik / tilføjede konfidensgrænse-regel til 6.2
  - 2026-07-28 / produkt / flyttede ERP-tilbageskrivning til ikke-mål

## 2. Problembeskrivelse
Ops-medarbejdere modtager kundefakturaer som e-mailede PDF'er og genindtaster
dem manuelt i ordresystemet. Volumen ligger over 300 fakturaer om ugen,
gennemsnitlig behandlingstid er omkring 6 minutter hver, og cirka 4% indeholder
en indtastningsfejl, der først opdages ved månedsafstemningen. Hver rettelse
koster en ekstra gennemgang og et opkald.

## 3. Mål & succesmålinger
| Mål | Måling | Baseline | Mål | Måles ved | Dato |
|---|---|---|---|---|---|
| Reducér manuel behandling | Gns. behandlingstid | 6 min | under 90 sek | Ops-dashboard, ugentlig median | 2026-11-01 |
| Reducér indtastningsfejl | Fakturaer rettet ved afstemning | 4% | under 1% | Finans' månedsafslutningsrapport | 2026-12-01 |
| Begræns review-belastning | Andel sendt til manuel review | n/a | under 25% | Portalkø-metrikker | 2026-11-01 |

## 4. Ikke-mål
Denne fase understøtter ikke multivaluta-fakturaer, ERP-tilbageskrivning,
kundens selvbetjente kreditnotaer eller en mobilapp. Udtræk dækker kun PDF.
Fotografier af papirfakturaer og scanninger under 200 DPI afvises ved upload
med en besked, der forklarer hvorfor.

## 5. Brugere & personaer
- Ops-medarbejder (primær, 6 personer): arbejder undtagelseskøen hele dagen,
  dyb domæneviden, kun desktop.
- Kundens AP-kontakt (ekstern, ~140 konti): uploader fakturaer, lav tolerance
  over for friktion ved kontoopsætning.
- Finanschef (sekundær): trækker månedsafslutningsrapporten, har brug for et
  revisionsspor per faktura.

## 6. Brugerhistorier & acceptkriterier
6.1 Som kundens AP-kontakt vil jeg uploade en faktura-PDF, så jeg ikke skal
sende den som e-mail og vente.
- Givet en PDF under 20 MB ved 200 DPI eller bedre, når jeg uploader den, så
  returnerer portalen et referencenummer inden for 5 sekunder og viser
  "Behandler".

6.2 Som ops-medarbejder vil jeg have udtræk med lav konfidens tilbageholdt, så
intet forkert bliver auto-godkendt.
- Givet en fortolket faktura, når udtrækskonfidensen for en linjepost er under
  0.85, så sendes fakturaen til review-køen og bliver aldrig auto-godkendt.

6.3 Som ops-medarbejder vil jeg se uoverensstemmelsen ét sted, så jeg kan løse
den uden at åbne ordresystemet.
- Givet en faktura matchet til en ordre, når en linjes mængde eller
  enhedspris afviger fra ordredata, så viser portalen begge værdier side om
  side og flager forskellen.

6.4 Som finanschef vil jeg filtrere fakturaer, så jeg kan lukke måneden.
- Givet fakturalisten, når jeg filtrerer efter leverandør, datointerval og
  status, så returneres resultater på under 400ms ved p95, og den tomme
  tilstand tilbyder "Ryd filtre".

## 7. Funktionelle krav
1. Upload accepterer kun PDF, maks. 20 MB, én fil per indsendelse.
2. Udtræk returnerer leverandør, fakturanummer, dato, valuta og linjeposter
   med mængde, enhedspris og total.
3. Hver linjepost bærer en konfidensscore mellem 0 og 1.
4. Matching sammenligner den udtrukne faktura med den åbne ordre via PO-nummer.
5. Undtagelser går i en kø sorteret ældste først, tildelt én medarbejder.
6. Hver statusændring skriver en revisionspost med aktør, tidsstempel, forrige
   værdi.
7. Godkendte fakturaer eksporteres som en CSV-batch til finanssystemet.

## 8. Ikke-funktionelle krav
- Performance: fakturaliste p95 under 400ms. Udtræk afsluttes inden for 90
  sekunder efter upload ved p95.
- Sikkerhed & tenancy: isolation per lejer håndhævet på databaserækkeniveau.
  En kunde kan aldrig læse en anden kundes faktura. Verificeret af en
  automatiseret test ved hver release.
- Dataresidens & opbevaring: dokumenter lagres i EU. Originaler opbevares i 7
  år, udtræksdata i 90 dage.
- Tilgængelighed: kø fuldt betjenbar med tastatur, WCAG 2.2 AA-kontrast.
- Driftsstabilitet: 99.5% månedligt, support i åbningstiden.

## 9. Afhængigheder & integrationer
- Ordredata: skrivebeskyttet Postgres-replika. Adgang ejes af klientens IT,
  credentials nødvendige inden 2026-08-15.
- LLM-udtræksudbyder: kontrakt og databehandleraftale underskrevet før
  byggeriet starter.
- E-mail-notifikationer: eksisterende transaktionel udbyder, afsenderdomæne
  verificeret af klienten.

## 10. Milepæle & faseinddeling
| Fase | Omfang | Exit-kriterier | Måldato |
|---|---|---|---|
| P1 | Upload, udtræk, konfidensrouting | 50 rigtige fakturaer ende til ende, under 25% i kø | 2026-09-19 |
| P2 | Ordrematching og visning af uoverensstemmelser | Uoverensstemmelse flaget korrekt på 20 seedede cases | 2026-10-10 |
| P3 | Revisionsspor, CSV-eksport, rapportering | Finans lukker én måned i portalen | 2026-11-01 |

## 11. Åbne spørgsmål & risici
| Spørgsmål eller risiko | Ejer | Nødvendigt inden | Konsekvens hvis ubesvaret |
|---|---|---|---|
| Hvilket PO-nummer er autoritativt, når en faktura viser to? | Klientens ops-direktør | 2026-08-08 | Matchinglogik blokeret |
| Sender de 12 største kunder scannede eller native PDF'er? | Delivery lead | 2026-08-08 | Konfidensgrænse kan være forkert |
| Er 7-årig opbevaring bekræftet med klientens jurister? | Klientens finanschef | 2026-08-22 | Lagerdesign og omkostning ændres |
| Udtræksomkostning per faktura ved 300/uge | Delivery lead | 2026-09-05 | Enhedsøkonomi ukendt |

## 12. Appendiks & links
Anonymiseret eksempelfaktura-sæt (40 filer), ordretabel-skema, aktuel
behandlingstidsstudie, Figma-flows for upload og kø, underskrevet
arbejdsbeskrivelse.

Fire valg deri er værd at fremhæve, fordi den dovne version af hver koster rigtige penge.

Sektion 3, baselinen. "6 minutter" er ikke pynt. Uden en baseline kan du ikke afgøre, om tingen virkede, og seks måneder senere diskuterer nogen det i et møde uden data. Den dovne version, "forbedre effektiviteten", gør projektet ufalsificerbart.

Sektion 4, ikke-målet. ERP-tilbageskrivning blev flyttet til ikke-mål den 2026-07-28, efter at være blevet antaget ind i eksistens under et review-kald. At skrive det ned som et ikke-mål kostede én linje og sparede en diskussion om omfang.

Sektion 6.2, konfidensgrænsen. Det er den regel, vores egne førsteudkast oftest overser. Udelad den, og systemet auto-godkender fakturaer, et menneske burde have set, hvilket er præcis den fejl, der sletter de tidsbesparelser, du lovede i sektion 3.

Sektion 11, ejerne. Hvert åbent spørgsmål har et navn og en dato. Den kolonne er forskellen mellem et dokument og en to-do-liste, ingen ejer.

PRD'en fortæller dig hvad. Den fortæller dig ikke hvor lang tid eller hvor meget, hvilket er en separat øvelse: se afgrænsning af byggeriet for den halvdel. Og et ikke-mål, du ikke skrev ned, er en funktion, nogen vil bygge.

Hvordan skriver du en PRD, en AI-kodeagent faktisk kan bygge ud fra?

En PRD skrevet til en AI-kodeagent bytter kortfattethed for eksplicithed. Agenten har ingen uformel delt kontekst, ingen fælles historik og ingen instinkt for, hvad du åbenlyst ikke mente. Fire regler dækker det meste af forskellen, og de kommer fra at have set specs lykkes og fejle på tværs af vores egne agent-assisterede byggerier.

1. Formulér ikke-mål positivt. Mennesker udleder omfang ud fra det, der ikke er nævnt. Agenter gør ikke. "Tilføj ikke autentificering i denne fase" skal være en sætning i dokumentet, ellers bliver auth bygget, testet og afleveret tilbage til dig.

2. Faseinddel arbejdet. Én 40-siders monolit producerer en selvsikker, vidtfavnende, halvt korrekt pull request. Skær PRD'en op i passager, en agent kan afslutte i én afgrænset kørsel, hver med sine egne exit-kriterier.

3. Gør acceptkriterier maskinelt tjekbare. "Hurtigt" er ikke et krav, det er en stemning. "p95 under 400 ms på fakturaliste-endpointet" er en test, agenten kan skrive, før den skriver funktionen.

4. Sæt filstier og stack-begrænsninger i dokumentet, ikke i chatten. Chat-kontekst fordamper mellem sessioner. Specen gør ikke. Det er også derfor, Claude Codes plan mode betyder noget: den læser dine filer og foreslår en plan uden at redigere noget, før du godkender, og det godkendelsestrin er langt mere nyttigt, når planen tjekkes mod en skreven spec i stedet for din hukommelse om, hvad du bad om.

Her er fakturaportalen, skåret op i én fase, en agent kan udføre i ét hug.

# Byggeopgave: Faktura-upload og -udtræk (fase 1 af 3)

## Stack-begrænsninger (må ikke erstattes)
Next.js 15 App Router, TypeScript, Supabase Postgres med row-level security,
Vercel deploy. Ingen nye dependencies uden at spørge først.

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

## Rør ikke
- lib/auth/*  (auth lanceres i fase 2; tilføj ikke sign-in-flows nu)
- Alt under app/(marketing)/
- Det eksisterende orders-skema. Læs det. Migrér det aldrig.

## Acceptkriterier (skriv disse som tests først)
1. POST /api/invoices afviser ikke-PDF med 415 og filer over 20 MB med 413.
2. En linjepost med confidence < 0.85 sætter invoice.status = 'review',
   aldrig 'approved'.
3. Hver insert skriver en revisionsrække med actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returnerer under 400ms på en
   10,000-row seed.

## Ude af scope for denne omgang
Ordrematching, mismatch-UI, CSV-eksport, e-mail-notifikationer.

Tre ting ændrede sig i forhold til menneske-versionen: filstier dukkede op, en rør-ikke-liste dukkede op, og acceptkriterierne blev til assertions i stedet for sætninger. Hvilken agent, du giver den til, betyder mindre, end folk tror, selvom sammenligningen af kodeagenter er værd at læse, før du forpligter dig. Hold krav og projektregler i separate filer: Cursor Rules og CLAUDE.md rummer konventioner og værktøjer, PRD'en rummer hvad der skal bygges. Hvis du vil have AI-hjælp til at producere omfanget i første omgang i stedet for at forbruge det, er det en anden arbejdsgang. Og for selve udtræksskridtet er modelvalget og evalueringsloopet deres eget AI-integrationsarbejde.

Hvad ændrer sig, når PRD'en går til et eksternt team

Når PRD'en går til et bureau eller en kontraktør, holder den op med at være et alignment-dokument og bliver kontraktsprog. Tvetydighed, som et internt team løser med en to-minutters samtale, bliver en ændringsanmodning med en pris. PMI's Pulse of the Profession fandt, at 47 % af mislykkede projekter går galt på grund af unøjagtig kravstyring. Det er hele grunden til, at dette dokument findes.

Tre sektioner vejer uforholdsmæssigt tungt i den sammenhæng. Acceptkriterier bliver til godkendelsesporte, så de skal kunne observeres af en, der ikke er ingeniør. Åbne spørgsmål skal have en navngiven ejer på klientsiden, fordi leverandøren ikke kan besvare dem og vil bygge udenom hullet. Og ændringshistorik holder op med at være bureaukrati: det er registreringen af, hvad der blev aftalt hvornår, hvilket er det første, nogen griber fat i under en uenighed.

Den linje, vi har set gå galt mere end én gang, er en eller anden version af "brugere kan eksportere deres data". Ingen skriver ned, hvilket format. Den dyre version af det, for os, endte som en CSV-eksport, da klienten havde ment en formateret PDF-fakturapakke med deres branding på, og at lave det om igen brændte cirka en uges udviklingsarbejde, som ingen havde afgrænset. Den ærlige læsning er, at fejlen lå i dokumentet, ikke i leverancen. Et acceptkriterium ville have fanget det på fem minutter: givet en eksportanmodning, når filen genereres, så er det en PDF, der matcher det leverede layout. En ikke-måls-linje ville også have fanget det, fra den anden retning. Så det er nu en regel i vores discovery: ethvert krav, der hænger på et navneord som "eksport", "rapport" eller "notifikation", får et format, en trigger og et gennemarbejdet eksempel knyttet til sig, før en arbejdsbeskrivelse underskrives.

Det er det meste af, hvad sådan kører vi webapplikations-byggerier faktisk handler om: at omdanne den vage halvdel af en klients spec til testbare linjer, før nogen skriver kode.

Hvad r/ProductManagement faktisk siger om PRD-skabeloner

Søg product requirements document template reddit, og du finder den samme klage igen og igen i r/ProductManagement: skabelon-bloat. PRD'er, ingen læser. Sektioner udfyldt, fordi skabelonen havde en overskrift, ikke fordi nogen havde brug for indholdet. Dokumenter, der bliver forældede dagen efter kickoff og stille og roligt erstattes af en Slack-tråd. Det er en fair kritik af de fleste skabeloner, inklusive flere af de ti bedste resultater for denne søgning.

Vores svar: slet sektioner i stedet for at fylde dem med ingenting. Personaer kommer først, når brugerne er indlysende. Appendiks kommer i anden række. Milepæle kan leve i trackeren i stedet. Den, vi aldrig sletter, er ikke-mål, fordi det er den eneste sektion, der bliver kortere, jo mere arbejde du lægger i den, og den eneste, der pålideligt forhindrer den diskussion, du ellers ville have haft i uge seks.

Ofte stillede spørgsmål

Hvad er et produktkravsdokument?

Et produktkravsdokument (PRD) angiver, hvad et team bygger og hvorfor: problemet, målene og deres målinger, ikke-målene, hvem det er til, og de krav, der definerer "færdig". Det udelader bevidst implementeringsdetaljer, som hører hjemme i et teknisk designdokument skrevet bagefter af udviklingsteamet.

Hvordan skriver du et produktkravsdokument?

Start med problembeskrivelsen, og undlad at bruge løsningssprog i den. Tilføj målbare mål med en baseline og en måldato, skriv derefter ikke-mål. Udfyld personaer, brugerhistorier med Given/When/Then-acceptkriterier, funktionelle og ikke-funktionelle krav, afhængigheder, milepæle og åbne spørgsmål med ejere.

Hvad skal en PRD indeholde?

Tolv sektioner: header med ændringshistorik, problembeskrivelse, mål og succesmålinger, ikke-mål, brugere og personaer, brugerhistorier med acceptkriterier, funktionelle krav, ikke-funktionelle krav, afhængigheder og integrationer, milepæle og faseinddeling, åbne spørgsmål og risici, samt et appendiks. Alt, der ikke passer ind i en af dem, er formentlig ikke et krav.

Hvor lang skal en PRD være?

Én til to sider for en enkelt funktion, tre til fem for en produktfase, fem til otte når et eksternt team bygger den, og acceptkriterierne fungerer som godkendelsesporte. Længden følger antallet af beslutninger, der registreres, ikke produktets størrelse. Tomme sektioner bør slettes, ikke fyldes ud.

Er en PRD det samme som en BRD?

Nej. Et forretningskravsdokument (BRD) angiver det kommercielle resultat, organisationen ønsker, og de begrænsninger, der er omkring det, normalt før en løsning vælges. En PRD beskriver det produkt, der leverer det: brugere, adfærd, acceptkriterier, ikke-mål. I mindre virksomheder er BRD'en ofte bare problembeskrivelses-sektionen.

Skriver agile teams stadig PRD'er?

Ja, som regel som en one-pager. Backloggen rummer arbejdet, men tickets er elendige til at rumme hvorfor'et, ikke-målene og succesmålingen. Teams, der helt springer PRD'en over, har en tendens til at genopdage den som en Confluence-side kaldet "kontekst" tre sprints inde i projektet.

Kan du skrive en PRD i markdown?

Markdown er det bedste format til en. Det indsættes rent i Notion, Confluence, Google Docs og Linear, versionerer i Git ved siden af koden som PRD.md, differ korrekt i en pull request, og er det eneste format, en AI-kodeagent læser uden at miste struktur. Skabelonen ovenfor er markdown af præcis de grunde.

Hvordan skriver du en PRD til en AI-kodeagent?

Vær eksplicit, hvor du normalt ville være kortfattet. Formulér ikke-mål positivt, fordi en agent ikke kan udlede omfang ud fra det, der ikke er nævnt. Skær dokumentet op i faser, der kan afsluttes i én omgang. Skriv acceptkriterier som assertions med tal. Navngiv de filer, agenten må redigere, og dem den ikke må røre.

Hvad er forskellen på en PRD og et teknisk designdokument?

PRD'en svarer på hvad og hvorfor: problem, brugere, adfærd, acceptkriterier, ikke-mål. Det tekniske designdokument svarer på hvordan: arkitektur, datamodel, API-kontrakter, overvejede afvejninger. Produkt ejer normalt det første, udvikling det andet, og designdokumentet bør kunne læses som et svar på PRD'en.

Hvem ejer PRD'en – produkt, udvikling eller klienten?

Produkt ejer dokumentet og beslutningerne i det. Udvikling ejer feasibility-feedbacken og de ikke-funktionelle krav. På bureau-byggerier ejer klienten problembeskrivelsen, målene og ethvert åbent spørgsmål om deres egen forretning. Delt ejerskab af hele dokumentet betyder som regel, at ingen vedligeholder det.

Afrunding

Tre ting at tage med. Skabelonen er kun nyttig, når den er udfyldt, så kopiér formen fra det gennemarbejdede eksempel i stedet for den tomme. Ikke-mål er den sektion med den højeste værdi per ord i dokumentet og den første, folk springer over. Og acceptkriterier skrevet som testbare assertions tjener to læsere lige godt: en ingeniør, der godkender en leverance, og en agent, der skriver testen.

Hvis du skriver en PRD, der skal overdrages til et eksternt team, og gerne vil have et ekstra sæt øjne på den, før den bliver kontraktsprog, læser vi den gerne og markerer de tvetydige linjer. Det er den samme gennemgang, vi kører på vores egne webapplikations-byggerier.