PRD-mall: Komplett produktkravsdokument (+ ett exempel du kan kopiera)

PRD-mall: Komplett produktkravsdokument (+ ett exempel du kan kopiera)

Senast uppdaterad: 28 juli 2026.

De flesta sidor med produktkravsdokument-mallar ger dig ett tomt formulär. Atlassians är fyra avsnitt med instruktioner runt en tom framgångsmått-tabell. Product Schools mall har "(med exempel)" i titeln men innehåller inget exempel. 12-avsnittsblocket i markdown nedan är hela mallen, olåst, redo att kopieras. Avsnitt 4 fyller sedan i alla dessa 12 avsnitt för ett komplett exempel-bygge: en kundfakturaportal som läser PDF:er med en LLM och skickar de osäkra fallen till en mänsklig granskare. Kopiera den tomma. Läs den ifyllda. Skriv din egen.

Viktiga slutsatser

• En PRD svarar på vad som ska byggas och varför; det tekniska designdokumentet svarar på hur.
• De 12 avsnitten passar alla projektstorlekar. En en-sidig version är samma mall med färre rader.
• Icke-mål måste skrivas ner. En AI-kodningsagent kan inte gissa sig till omfattning utifrån vad som utelämnats.
• Acceptanskriterier måste vara maskinkontrollerbara: "p95 under 400ms", aldrig "snabbt".

Vilken PRD-form ska du använda?

Välj formen efter vem som läser dokumentet, inte efter hur stor produkten känns. En enskild funktion som går till era egna utvecklare behöver en en-sidig version. Ett bygge som lämnas till ett externt team behöver den fullständiga 12-avsnitts-PRD:n, eftersom acceptanskriterierna även fungerar som godkännandegrindar. En spec som går till en AI-kodningsagent behöver samma tolv avsnitt uppdelade i faser.

Den en-sidiga produktkravsdokument-mallen alla efterfrågar är inte ett separat dokument. Lenny Rachitskys mycket kopierade en-sidiga mall, publicerad med riktiga exempel i hans nyhetsbrev, är samma skelett med ceremonin bortplockad. En en-sidig version är inte ett annat dokument. Det är samma tolv avsnitt med de tomma raderna borttagna.

Agila team ställer också den här frågan ofta, oftast formulerad som om en PRD håller när den möter en backlogg. Det gör den, som en en-sidig version: PRD:n håller varför och gränserna, ticketsen håller arbetet.

PRD-mallen (kopiera-och-klistra markdown)

Här är hela grejen som markdown, olåst, ingen mejlvägg. Klistra in den i Notion, Confluence, Google Docs, Linear, Word, eller committa den till GitHub som PRD.md och låt den versionshanteras tillsammans med koden. Folk frågar efter den här mallen i nio olika format; markdown är den som överlever en klistring in i alla, och det är det enda formatet en AI-kodningsagent läser rent.

# PRD: [Produkt- eller funktionsnamn]

## 1. Sidhuvud
- Ägare (produkt):
- Teknisk lead:
- Design-lead:
- Status: Utkast | Under granskning | Godkänd | Levererad
- Senast uppdaterad:
- Ändringshistorik: datum / författare / vad som ändrades

## 2. Problemformulering
Ett stycke. Vem drabbas, hur ofta, vad det kostar idag. Inget lösningsspråk.

## 3. Mål & framgångsmått
| Mål | Mått | Baslinje | Målvärde | Mäts av | Datum |
|---|---|---|---|---|---|

## 4. Icke-mål
Formulerat positivt: "Den här fasen inkluderar inte X."

## 5. Användare & personas
Vem använder den, vad de redan kan, vilken enhet, hur ofta.

## 6. Användarberättelser & acceptanskriterier
Som en [persona] vill jag [handling], så att [resultat].
- Given [kontext], when [händelse], then [observerbart resultat].

## 7. Funktionella krav
Numrerade. Ett krav per rad. Testbart. Ingen mening med "och".

## 8. Icke-funktionella krav
Prestanda / säkerhet & multitenans / datalokalisering & lagring / tillgänglighet / drifttid.

## 9. Beroenden & integrationer
Externa system, API:er, autentiseringsuppgifter, vem äger åtkomsten, ledtid.

## 10. Milstolpar & fasindelning
| Fas | Omfattning | Avslutskriterier | Måldatum |
|---|---|---|---|

## 11. Öppna frågor & risker
| Fråga eller risk | Ägare | Behövs senast | Konsekvens om obesvarad |
|---|---|---|---|

## 12. Bilaga & länkar
Designs, research, konkurrentanteckningar, tidigare tickets, kontrakt.

De tolv avsnitten, i ordning: sidhuvud, problemformulering, mål och framgångsmått, icke-mål, användare och personas, användarberättelser med acceptanskriterier, funktionella krav, icke-funktionella krav, beroenden och integrationer, milstolpar och fasindelning, öppna frågor och risker, bilaga.

Vad bör en PRD innehålla? De 12 avsnitten, och den svaga versionen av varje

Ett produktkravsdokument bör innehålla en problemformulering, mätbara mål, tydliga icke-mål, personas, användarberättelser med acceptanskriterier, funktionella och icke-funktionella krav, beroenden, milstolpar, öppna frågor med ägare, och en ändringshistorik. Allt annat är bilaga. Testet för varje rad är detsamma som ISO/IEC/IEEE 29148:2018 tillämpar på krav generellt: verifierbart, entydigt, singulärt.

De flesta PRD:er misslyckas med det testet på samma tre ställen.

Två avsnitt förtjänar mer uppmärksamhet än de vanligtvis får.

Icke-funktionella krav är där omfattningen tyst fördubblas. Prestanda, multitenans, datalokalisering, lagring, tillgänglighet, drifttid: var och en av dessa är ett tekniskt beslut med en kostnad, och ingen av dem dyker upp i en användarberättelse. Sätt säkerhetsraden här istället för i en handviftning, och skriv den på det sätt du vill se den kontrollerad, med hjälp av något i stil med vår checklista för säkerhet före lansering som källista. Om bygget har en AI-komponent hör produktionsberedskapskraven hemma här också, inte i en senare "härdningsfas" som aldrig blir schemalagd: vår checklista från PoC till produktion är den version vi använder.

Öppna frågor behöver tre kolumner, inte en. Fråga, ägare, behövs-senast-datum. En fråga utan ägare är ett beslut som ingen fattar, och det dyker upp som en ändringsbegäran i vecka sex. Värt att säga: en PRD är vad du skriver efter att ni bestämt er för att bygga snarare än att köpa. Om problemformuleringen fortfarande läses som en inköpslista med funktioner, har bygg-eller-köp-beslutet faktiskt inte tagits än.

Det ifyllda exemplet: en fakturaportal-PRD

Här är ett komplett ifyllt exempel, alla 12 avsnitt ifyllda. Bygget: en kundfakturaportal för en medelstor logistikoperatör. Kunder laddar upp PDF-fakturor, en LLM extraherar radposterna, systemet flaggar avvikelser mot orderregistret, och allt den är osäker på går till en mänsklig granskningskö. Stack: Next.js, Supabase/Postgres, ett LLM-extraktionssteg. Kopiera det, skriv ut det, exportera det till PDF, vad du än behöver.

# PRD: Kundfakturaportal, fas 1

## 1. Sidhuvud
- Ägare (produkt): Ops-direktör, kundsidan
- Teknisk lead: Leveransansvarig, Techsy
- Design-lead: Produktdesigner, Techsy
- Status: Godkänd för byggstart
- Senast uppdaterad: 2026-07-28
- Ändringshistorik:
  - 2026-07-14 / produkt / första utkast
  - 2026-07-21 / teknik / lade till konfidensgränsregel i 6.2
  - 2026-07-28 / produkt / flyttade ERP-återskrivning till icke-mål

## 2. Problemformulering
Ops-personal tar emot kundfakturor som PDF:er via mejl och knappar in dem
manuellt i ordersystemet. Volymen passerar 300 fakturor i veckan, genomsnittlig
handläggningstid är cirka 6 minuter per faktura, och ungefär 4% har ett
inmatningsfel som bara upptäcks vid månadsavstämningen. Varje rättelse kostar
en extra genomgång och ett samtal.

## 3. Mål & framgångsmått
| Mål | Mått | Baslinje | Målvärde | Mäts av | Datum |
|---|---|---|---|---|---|
| Minska manuell hantering | Genomsnittlig handläggningstid | 6 min | under 90 sec | Ops-instrumentpanel, veckomedian | 2026-11-01 |
| Minska inmatningsfel | Fakturor som rättas vid avstämning | 4% | under 1% | Ekonomirapport månadsslut | 2026-12-01 |
| Begränsa granskningsvolym | Andel som går till mänsklig granskning | N/A | under 25% | Portalens kömått | 2026-11-01 |

## 4. Icke-mål
Den här fasen stödjer inte multivaluta-fakturor, ERP-återskrivning,
självbetjänings-kreditnotor för kunder, eller en mobilapp. Extraktion täcker
endast PDF. Fotografier av pappersfakturor och skanningar under 200 DPI
avvisas vid uppladdning med ett meddelande som förklarar varför.

## 5. Användare & personas
- Ops-handläggare (primär, 6 personer): arbetar med undantagskön hela dagen,
  djup domänkunskap, endast desktop.
- Kundens ekonomikontakt (extern, ~140 konton): laddar upp fakturor, låg
  tolerans för friktion vid kontoinställning.
- Ekonomichef (sekundär): hämtar månadsrapporten, behöver ett spårbart
  granskningsspår per faktura.

## 6. Användarberättelser & acceptanskriterier
6.1 Som en kundekonomikontakt vill jag ladda upp en fakturaPDF, så att jag
slipper mejla den och vänta.
- Given en PDF under 20 MB i 200 DPI eller bättre, when jag laddar upp den,
  then returnerar portalen ett referensnummer inom 5 sekunder och visar
  "Bearbetar".

6.2 Som en ops-handläggare vill jag att lågkonfidens-extraktioner hålls
tillbaka, så att inget felaktigt blir automatiskt godkänt.
- Given en tolkad faktura, when extraktionskonfidensen för någon radpost är
  under 0.85, then går fakturan till granskningskön och blir aldrig
  automatiskt godkänd.

6.3 Som en ops-handläggare vill jag se avvikelsen på ett ställe, så att jag
kan lösa den utan att öppna ordersystemet.
- Given en faktura matchad mot en order, when något radantal eller
  enhetspris skiljer sig från orderregistret, then visar portalen båda
  värdena sida vid sida och flaggar skillnaden.

6.4 Som en ekonomichef vill jag filtrera fakturor, så att jag kan avsluta
månaden.
- Given fakturalistan, when jag filtrerar efter leverantör, datumintervall
  och status, then returneras resultat på under 400ms vid p95 och det tomma
  tillståndet erbjuder "Rensa filter".

## 7. Funktionella krav
1. Uppladdning accepterar endast PDF, max 20 MB, en fil per inlämning.
2. Extraktion returnerar leverantör, fakturanummer, datum, valuta, och
   radposter med antal, enhetspris och totalbelopp.
3. Varje radpost bär ett konfidensvärde mellan 0 och 1.
4. Matchning jämför den extraherade fakturan mot den öppna ordern via
   PO number.
5. Undantag går till en kö ordnad äldst först, tilldelningsbar till en
   handläggare.
6. Varje statusändring skriver en granskningspost med aktör, tidsstämpel,
   tidigare värde.
7. Godkända fakturor exporteras som en CSV-batch till ekonomisystemet.

## 8. Icke-funktionella krav
- Prestanda: fakturalistans p95 under 400ms. Extraktion slutförs inom 90
  sekunder från uppladdning vid p95.
- Säkerhet & multitenans: isolering per kund verkställs på databasradsnivå.
  En kund kan aldrig läsa en annan kunds faktura. Verifieras av ett
  automatiserat test vid varje release.
- Datalokalisering & lagring: dokument lagras inom EU. Original sparas i
  7 years, extraktionsdata i 90 days.
- Tillgänglighet: kön är helt tangentbordsstyrd, WCAG 2.2 AA-kontrast.
- Drifttid: 99.5% månadsvis, support under kontorstid.

## 9. Beroenden & integrationer
- Orderregister: skrivskyddad Postgres-replika. Åtkomst ägs av kundens IT,
  autentiseringsuppgifter behövs senast 2026-08-15.
- LLM-extraktionsleverantör: avtal och personuppgiftsbiträdesavtal signerat
  innan bygget påbörjas.
- E-postnotiser: befintlig transaktionsleverantör, avsändardomän verifierad
  av kunden.

## 10. Milstolpar & fasindelning
| Fas | Omfattning | Avslutskriterier | Måldatum |
|---|---|---|---|
| P1 | Uppladdning, extraktion, konfidensrouting | 50 riktiga fakturor från start till mål, under 25% köade | 2026-09-19 |
| P2 | Ordermatchning och avvikelsevy | Avvikelse flaggad korrekt på 20 testfall | 2026-10-10 |
| P3 | Granskningsspår, CSV-export, rapportering | Ekonomi stänger en månad i portalen | 2026-11-01 |

## 11. Öppna frågor & risker
| Fråga eller risk | Ägare | Behövs senast | Konsekvens om obesvarad |
|---|---|---|---|
| Vilket PO number är auktoritativt när en faktura visar två? | Kundens ops-direktör | 2026-08-08 | Matchningslogiken blockerad |
| Skickar de 12 största kunderna skannade eller native PDF:er? | Leveransansvarig | 2026-08-08 | Konfidensgränsen kan vara fel |
| Är 7-årig lagring bekräftad med kundens juridik? | Kundens ekonomichef | 2026-08-22 | Lagringsdesign och kostnad förändras |
| Extraktionskostnad per faktura vid 300/vecka | Leveransansvarig | 2026-09-05 | Enhetsekonomin okänd |

## 12. Bilaga & länkar
Anonymiserad exempelfaktura-uppsättning (40 filer), ordertabell-schema,
aktuell handläggningstidsstudie, Figma-flöden för uppladdning och kö,
signerat avtalsdokument.

Fyra val däri är värda att lyfta fram, för den lata versionen av var och en kostar riktiga pengar.

Avsnitt 3, baslinjen. "6 minuter" är inte dekoration. Utan en baslinje kan du inte avgöra om det fungerade, och sex månader senare argumenterar någon om det på ett möte utan data. Den lata versionen, "förbättra effektiviteten", gör projektet ofalsifierbart.

Avsnitt 4, icke-målet. ERP-återskrivning flyttades till icke-mål den 2026-07-28, efter att ha antagits existera under ett granskningsmöte. Att skriva ner det som ett icke-mål kostade en rad och räddade en omfattningsdiskussion.

Avsnitt 6.2, konfidensgränsen. Det här är regeln våra egna första utkast oftast missar. Utelämna den och systemet godkänner automatiskt fakturor en människa borde ha sett, vilket är exakt det fel som suddar ut tidsbesparingen du lovade i avsnitt 3.

Avsnitt 11, ägarna. Varje öppen fråga har ett namn och ett datum. Den kolumnen är skillnaden mellan ett dokument och en att-göra-lista som ingen äger.

PRD:n talar om vad. Den talar inte om hur länge eller hur mycket, vilket är en separat övning: se att scopa bygget för den halvan. Och ett icke-mål du inte skrev ner är en funktion någon kommer att bygga.

Hur skriver du en PRD som en AI-kodningsagent faktiskt kan bygga utifrån?

En PRD skriven för en AI-kodningsagent byter kortfattadhet mot explicithet. Agenten saknar informell delad kontext och delad historia, och har ingen instinkt för vad du uppenbarligen inte menade. Fyra regler täcker det mesta av skillnaden, och de kommer från att ha sett spec:ar lyckas och misslyckas i våra egna agentassisterade byggen.

1. Formulera icke-mål positivt. Människor gissar omfattning utifrån vad som utelämnats. Agenter gör inte det. "Lägg inte till autentisering i den här fasen" måste vara en mening i dokumentet, annars byggs autentiseringen, testas, och lämnas tillbaka till dig.

2. Fasindela arbetet. En 40-sidig monolit ger en självsäker, spretig, halvkorrekt pull request. Dela upp PRD:n i pass en agent klarar inom en avgränsad körning, var och en med sina egna avslutskriterier.

3. Gör acceptanskriterier maskinkontrollerbara. "Snabbt" är inget krav – det är en känsla. "p95 under 400ms på fakturalistans endpoint" är ett test agenten kan skriva innan den skriver funktionen.

4. Sätt filvägar och teknikbegränsningar i dokumentet, inte i chatten. Chattkontext försvinner mellan sessioner. Specen gör det inte. Det är också därför Claude Codes planläge spelar roll: det läser dina filer och föreslår en plan utan att redigera något förrän du godkänner, och det godkännandesteget är mycket mer användbart när planen kontrolleras mot en skriven spec istället för ditt minne av vad du bad om.

Här är fakturaportalen, uppdelad i en fas en agent kan utföra i en enda körning.

# Byggnadsuppgift: Fakturauppladdning och extraktion (Fas 1 av 3)

## Teknikbegränsningar (byt inte ut)
Next.js 15 App Router, TypeScript, Supabase Postgres med row-level security,
Vercel-driftsättning. Inga nya beroenden utan att fråga först.

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

## Rör inte
- lib/auth/*  (autentisering levereras i fas 2; lägg inte till inloggningsflöden nu)
- Allt under app/(marketing)/
- Det befintliga order-schemat. Läs det. Migrera det aldrig.

## Acceptanskriterier (skriv dessa som tester först)
1. POST /api/invoices avvisar icke-PDF med 415 och filer över 20 MB med 413.
2. En radpost med konfidens < 0.85 sätter invoice.status = 'review',
   aldrig 'approved'.
3. Varje insert skriver en granskningsrad med actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returnerar under 400ms på ett
   10,000-row seed.

## Utanför omfattningen för det här passet
Ordermatchning, avvikelse-UI, CSV-export, e-postnotiser.

Tre saker ändrades jämfört med den mänskliga versionen: filvägar dök upp, en rör-inte-lista dök upp, och acceptanskriterierna blev assertions istället för meningar. Vilken agent du lämnar den till spelar mindre roll än folk tror, även om jämförelsen av kodningsagenter är värd att läsa innan du bestämmer dig. Håll krav och projektregler i separata filer: Cursor rules och CLAUDE.md håller konventioner och verktyg, PRD:n håller vad som ska byggas. Om du vill ha AI-hjälp att ta fram omfattningen från grunden istället för att bara konsumera den, det är ett annat arbetsflöde. Och för själva extraktionssteget är modellvalet och utvärderingsloopen ett eget AI-integrationsarbete.

Vad förändras när PRD:n går till ett externt team

När PRD:n går till en byrå eller underleverantör slutar den vara ett samstämmighetsdokument och blir kontraktsspråk. Tvetydighet som ett internt team löser med ett tvåminuterssamtal blir en ändringsbegäran med ett pris. PMI:s Pulse of the Profession fann att 47% av misslyckade projekt missar sina mål på grund av bristfällig kravhantering. Det är hela anledningen till att det här dokumentet existerar.

Tre avsnitt väger oproportionerligt tungt i det sammanhanget. Acceptanskriterier blir godkännandegrindar, så de måste vara observerbara för någon som inte är utvecklare. Öppna frågor behöver en namngiven ägare på kundens sida, eftersom leverantören inte kan besvara dem och kommer att bygga runt luckan. Och ändringshistoriken slutar vara byråkratisk: det är protokollet över vad som avtalades när, vilket är det första man tar fram vid en oenighet.

Raden vi har sett gå fel mer än en gång är någon version av "användare kan exportera sin data". Ingen skriver ner vilket format. Den dyra versionen av det, för oss, levererades som en CSV-export när kunden hade menat ett formaterat PDF-fakturapaket med sin egen branding på, och att göra om det tog ungefär en veckas ingenjörsarbete som ingen hade budgeterat för. Den ärliga läsningen är att felet satt i dokumentet, inte i leveransen. Ett acceptanskriterium hade fångat det på fem minuter: givet en exportbegäran, när filen genereras, då är den en PDF som matchar den angivna layouten. En icke-målsrad hade fångat det också, från andra hållet. Så det är nu en regel i vår upptäcktsfas: varje krav som hänger på ett substantiv som "export", "rapport" eller "notis" får ett format, en trigger och ett ifyllt exempel bifogat innan ett avtalsdokument skrivs under.

Det är det mesta av vad hur vi driver webbapplikationsbyggen faktiskt är: att omvandla den vaga halvan av en kunds spec till testbara rader innan någon skriver kod.

Vad r/ProductManagement faktiskt säger om PRD-mallar

Sök product requirements document template reddit så hittar du samma klagomål upprepat i r/ProductManagement: mallsvullnad. PRD:er som ingen läser. Avsnitt ifyllda för att mallen hade en rubrik, inte för att någon behövde innehållet. Dokument som blir inaktuella dagen efter kickoff och tyst ersätts av en Slack-tråd. Det är en rättvis kritik av de flesta mallar, inklusive flera bland de tio bästa träffarna för den här sökningen.

Vårt svar: ta bort avsnitt istället för att fylla dem med ingenting. Personas kommer först när användarna är uppenbara. Bilaga kommer näst. Milstolpar kan bo i spårningsverktyget istället. Den vi aldrig tar bort är icke-mål, eftersom det är det enda avsnittet som blir kortare ju mer arbete du gör och det enda som pålitligt förhindrar den diskussion du annars skulle ha i vecka sex.

Vanliga frågor

Vad är ett produktkravsdokument?

Ett produktkravsdokument (PRD) anger vad ett team bygger och varför: problemet, målen och deras mått, icke-målen, vem det är för, och kraven som definierar klart. Det utesluter medvetet implementationsdetaljer, som hör hemma i ett tekniskt designdokument skrivet efteråt av utvecklingsteamet.

Hur skriver du ett produktkravsdokument?

Börja med problemformuleringen och undvik lösningsspråk i den. Lägg till mätbara mål med en baslinje och ett måldatum, skriv sedan icke-mål. Fyll i personas, användarberättelser med Given/When/Then-acceptanskriterier, funktionella och icke-funktionella krav, beroenden, milstolpar, och öppna frågor med ägare.

Vad bör en PRD innehålla?

Tolv avsnitt: sidhuvud med ändringshistorik, problemformulering, mål och framgångsmått, icke-mål, användare och personas, användarberättelser med acceptanskriterier, funktionella krav, icke-funktionella krav, beroenden och integrationer, milstolpar och fasindelning, öppna frågor och risker, samt en bilaga. Allt som inte passar in i något av dessa är förmodligen inte ett krav.

Hur lång ska en PRD vara?

En till två sidor för en enskild funktion, tre till fem för en produktfas, fem till åtta när ett externt team bygger den och acceptanskriterierna fungerar som godkännandegrindar. Längden följer antalet beslut som dokumenteras, inte produktens storlek. Tomma avsnitt ska tas bort, inte fyllas ut.

Är en PRD samma sak som en BRD?

Nej. Ett affärskravsdokument (BRD) anger det kommersiella resultatet organisationen vill ha och begränsningarna runt det, vanligtvis innan en lösning valts. En PRD beskriver produkten som levererar det: användare, beteende, acceptanskriterier, icke-mål. I mindre företag är BRD:n ofta bara problemformuleringsavsnittet.

Skriver agila team fortfarande PRD:er?

Ja, oftast som en en-sidig version. Backloggen håller arbetet, men tickets är dåliga på att hålla varför, icke-målen och framgångsmåttet. Team som hoppar över PRD:n helt tenderar att återupptäcka den som en Confluence-sida kallad "kontext" tre sprintar in i projektet.

Kan du skriva en PRD i markdown?

Markdown är det bästa formatet för en PRD. Den klistras in rent i Notion, Confluence, Google Docs och Linear, versionshanteras i Git bredvid koden som PRD.md, diffar korrekt i en pull request, och är det enda formatet en AI-kodningsagent läser utan att förlora struktur. Mallen ovan är markdown av exakt de skälen.

Hur skriver du en PRD för en AI-kodningsagent?

Var explicit där du normalt skulle vara kortfattad. Formulera icke-mål positivt, eftersom en agent inte kan gissa omfattning utifrån vad som utelämnats. Dela upp dokumentet i faser som går att slutföra i en körning. Skriv acceptanskriterier som assertions med siffror. Namnge filerna agenten får redigera och de den inte får röra.

Vad är skillnaden mellan en PRD och ett tekniskt designdokument?

PRD:n svarar på vad och varför: problem, användare, beteende, acceptanskriterier, icke-mål. Det tekniska designdokumentet svarar på hur: arkitektur, datamodell, API-kontrakt, avvägningar som övervägts. Produkt äger vanligtvis det första, utveckling det andra, och designdokumentet bör kunna läsas som ett svar på PRD:n.

Vem äger PRD:n – produkt, utveckling, eller kunden?

Produkt äger dokumentet och besluten i det. Utveckling äger genomförbarhetsfeedbacken och de icke-funktionella kraven. På byråbyggen äger kunden problemformuleringen, målen, och varje öppen fråga om sin egen verksamhet. Delat ägande av hela dokumentet betyder oftast att ingen underhåller det.

Sammanfattning

Tre saker att ta med sig. Mallen är bara användbar när den är ifylld, så kopiera det ifyllda exemplets form snarare än den tomma. Icke-mål är avsnittet med högst värde per ord i dokumentet och det första folk hoppar över. Och acceptanskriterier skrivna som testbara assertions tjänar två läsare lika väl: en utvecklare som godkänner en leverans, och en agent som skriver testet.

Om du skriver en PRD för att lämna till ett externt team och vill ha ett andra par ögon på den innan den blir kontraktsspråk, läser vi gärna igenom den och markerar de tvetydiga raderna. Det är samma genomgång vi kör på våra egna webbapplikationsbyggen.