Product Requirements Document Sjabloon (+ een Volledig Uitgewerkt Voorbeeld Om Te Kopiëren)

Product Requirements Document Sjabloon (+ een Volledig Uitgewerkt Voorbeeld Om Te Kopiëren)

Laatst bijgewerkt: 28 juli 2026.

De meeste pagina's met een product requirements document sjabloon geven je een leeg formulier. Dat van Atlassian bestaat uit vier secties instructies rond een lege succes-metrics-tabel. Product School zet "(with Example)" in de titel en bevat geen voorbeeld. Het markdown-blok met 12 secties hieronder is het complete sjabloon, gratis toegankelijk, direct te kopiëren. Sectie 4 vult vervolgens elk van die 12 secties in voor een complete uitgewerkte build: een facturenportaal voor een klant, dat PDF's leest met een LLM en de twijfelgevallen doorstuurt naar een mens. Kopieer de lege versie. Lees de ingevulde versie. Schrijf de jouwe.

Belangrijkste Punten

• Een PRD beantwoordt wat je bouwt en waarom; het technisch ontwerpdocument beantwoordt hoe.
• De 12 secties passen bij elk projectformaat. Een one-pager is hetzelfde sjabloon met minder rijen.
• Niet-doelen moeten worden opgeschreven. Een AI coding agent kan scope niet afleiden uit wat je weglaat.
• Acceptatiecriteria moeten machinaal controleerbaar zijn: "p95 onder 400ms", nooit "snel".

Welke PRD-vorm Moet Je Gebruiken?

Kies de vorm op basis van wie het document leest, niet op basis van hoe groot het product aanvoelt. Eén feature voor je eigen engineers heeft genoeg aan een one-pager. Een build die naar een extern team gaat, heeft de volledige 12-delige PRD nodig, omdat de acceptatiecriteria ook dienen als goedkeuringsmomenten. Een spec voor een AI coding agent heeft dezelfde twaalf secties nodig, maar dan opgedeeld in fasen.

Het product requirements document sjabloon van één pagina waar iedereen om vraagt, is geen apart document. Lenny Rachitsky's veelgekopieerde one-pager, gepubliceerd met echte voorbeelden in zijn nieuwsbrief, is dezelfde structuur zonder alle formaliteiten. Een one-pager is geen ander document. Het zijn dezelfde twaalf secties met de lege rijen verwijderd.

Agile teams stellen deze vraag ook vaak, meestal geformuleerd als: houdt een PRD stand zodra er een backlog is? Dat doet hij, als one-pager: de PRD bevat het waarom en de grenzen, de tickets bevatten het werk.

Het PRD-sjabloon (Kopieer-Plak Markdown)

Hier is het geheel als markdown, gratis toegankelijk, geen e-mail vereist. Plak het in Notion, Confluence, Google Docs, Linear, Word, of commit het naar GitHub als PRD.md en laat het meeversioneren met de code. Mensen vragen om dit sjabloon in negen verschillende formaten; markdown is degene die een plak-actie in al die tools overleeft, en het is de enige die een AI coding agent netjes leest.

# PRD: [Product- of featurenaam]

## 1. Header
- Eigenaar (product):
- Engineering lead:
- Design lead:
- Status: Concept | In review | Goedgekeurd | Live
- Laatst bijgewerkt:
- Wijzigingsgeschiedenis: datum / auteur / wat er veranderde

## 2. Probleemstelling
Eén alinea. Wie heeft er last van, hoe vaak, wat kost het nu. Geen oplossingstaal.

## 3. Doelen & succesmetrics
| Doel | Metric | Basiswaarde | Doelwaarde | Gemeten door | Datum |
|---|---|---|---|---|---|

## 4. Niet-doelen
Positief geformuleerd: "Deze fase omvat geen X."

## 5. Gebruikers & persona's
Wie gebruikt het, wat weten ze al, welk apparaat, hoe vaak.

## 6. User stories & acceptatiecriteria
Als [persona] wil ik [actie], zodat [uitkomst].
- Given [context], when [event], then [waarneembaar resultaat].

## 7. Functionele eisen
Genummerd. Eén eis per regel. Testbaar. Geen zin met "en".

## 8. Niet-functionele eisen
Performance / beveiliging & tenancy / dataresidentie & retentie / toegankelijkheid / beschikbaarheid.

## 9. Afhankelijkheden & integraties
Externe systemen, API's, credentials, wie het toegangsbeheer heeft, doorlooptijd.

## 10. Mijlpalen & fasering
| Fase | Scope | Exitcriteria | Streefdatum |
|---|---|---|---|

## 11. Open vragen & risico's
| Vraag of risico | Eigenaar | Nodig vóór | Impact indien onbeantwoord |
|---|---|---|---|

## 12. Bijlage & links
Ontwerpen, onderzoek, concurrentienotities, eerdere tickets, contracten.

De twaalf secties, in volgorde: header, probleemstelling, doelen en succesmetrics, niet-doelen, gebruikers en persona's, user stories met acceptatiecriteria, functionele eisen, niet-functionele eisen, afhankelijkheden en integraties, mijlpalen en fasering, open vragen en risico's, bijlage.

Wat Moet Een PRD Bevatten? De 12 Secties, En De Zwakke Versie Van Elk

Een product requirements document moet een probleemstelling bevatten, meetbare doelen, expliciete niet-doelen, persona's, user stories met acceptatiecriteria, functionele en niet-functionele eisen, afhankelijkheden, mijlpalen, open vragen met eigenaren, en een wijzigingsgeschiedenis. Al het overige is bijlage. De toets voor elke regel is dezelfde die ISO/IEC/IEEE 29148:2018 in het algemeen toepast op eisen: verifieerbaar, ondubbelzinnig, enkelvoudig.

De meeste PRD's falen op die toets steeds op dezelfde drie plekken.

Twee secties verdienen meer aandacht dan ze meestal krijgen.

Niet-functionele eisen is waar scope stilletjes verdubbelt. Performance, tenancy, dataresidentie, retentie, toegankelijkheid, beschikbaarheid: elk daarvan is een engineering-beslissing met een prijskaartje, en geen enkele verschijnt in een user story. Zet de beveiligingsregel hier neer in plaats van in een vaag gebaar, en schrijf hem op zoals je hem gecontroleerd wilt zien, met bijvoorbeeld onze pre-launch security checklist als bronlijst. Heeft de build een AI-component, dan horen de production-readiness-eisen hier ook thuis, niet in een latere "hardening"-fase die nooit wordt ingepland: onze PoC-naar-productie-checklist is de versie die wij gebruiken.

Open vragen hebben drie kolommen nodig, niet één. Vraag, eigenaar, nodig-vóór-datum. Een vraag zonder eigenaar is een beslissing die niemand neemt, en die duikt in week zes weer op als change request. Het is de moeite waard te zeggen: een PRD schrijf je nadat je hebt besloten te bouwen in plaats van te kopen. Leest de probleemstelling nog als een boodschappenlijstje met features, dan heeft de buy-versus-build-beslissing eigenlijk nog niet plaatsgevonden.

Het Uitgewerkte Voorbeeld: Een Facturenportaal-PRD, Ingevuld

Hier is een compleet uitgewerkt voorbeeld, alle 12 secties ingevuld. De build: een facturenportaal voor een klant, een middelgrote logistieke onderneming. Klanten uploaden PDF-facturen, een LLM extraheert de regelitems, het systeem markeert afwijkingen ten opzichte van de orderregistratie, en alles waar het niet zeker van is gaat naar een menselijke reviewwachtrij. Stack: Next.js, Supabase/Postgres, één LLM-extractiestap. Kopieer het, print het, exporteer het naar PDF, wat je maar nodig hebt.

# PRD: Facturenportaal voor Klant, Fase 1

## 1. Header
- Eigenaar (product): Ops director, klantzijde
- Engineering lead: Delivery lead, Techsy
- Design lead: Product designer, Techsy
- Status: Goedgekeurd voor bouw
- Laatst bijgewerkt: 2026-07-28
- Wijzigingsgeschiedenis:
  - 2026-07-14 / product / eerste concept
  - 2026-07-21 / engineering / confidence-threshold regel toegevoegd aan 6.2
  - 2026-07-28 / product / ERP write-back verplaatst naar niet-doelen

## 2. Probleemstelling
Ops-medewerkers ontvangen klantfacturen als PDF's per e-mail en typen ze
handmatig over in het ordersysteem. Het volume ligt boven de 300 facturen per
week, de gemiddelde verwerkingstijd is ongeveer 6 min per factuur, en ongeveer
4% bevat een typefout die pas bij de maandafsluiting aan het licht komt. Elke
correctie kost een extra ronde en een telefoontje.

## 3. Doelen & succesmetrics
| Doel | Metric | Basiswaarde | Doelwaarde | Gemeten door | Datum |
|---|---|---|---|---|---|
| Verminder handmatige verwerking | Gem. verwerkingstijd | 6 min | onder 90 sec | Ops dashboard, wekelijkse mediaan | 2026-11-01 |
| Verminder typefouten | Facturen gecorrigeerd bij afstemming | 4% | onder 1% | Financieel maandrapport | 2026-12-01 |
| Beperk reviewlast | Aandeel doorgestuurd naar menselijke review | n.v.t. | onder 25% | Portaal wachtrij-metrics | 2026-11-01 |

## 4. Niet-doelen
Deze fase ondersteunt geen facturen in meerdere valuta's, ERP write-back,
self-service creditnota's voor klanten, of een mobiele app. Extractie werkt
alleen met PDF. Foto's van papieren facturen en scans onder 200 DPI worden bij
upload geweigerd met een melding die uitlegt waarom.

## 5. Gebruikers & persona's
- Ops-medewerker (primair, 6 personen): werkt de hele dag aan de
  uitzonderingenwachtrij, diepe domeinkennis, alleen desktop.
- AP-contactpersoon van de klant (extern, ~140 accounts): upload facturen,
  weinig tolerantie voor wrijving bij het instellen van een account.
- Finance manager (secundair): haalt het maandrapport op, heeft een audittrail
  per factuur nodig.

## 6. User stories & acceptatiecriteria
6.1 Als AP-contactpersoon van de klant wil ik een factuur-PDF uploaden, zodat
ik hem niet hoef te mailen en te wachten.
- Given een PDF onder 20 MB op 200 DPI of beter, when ik hem upload, then
  geeft het portaal binnen 5 seconden een referentienummer terug en toont
  "Verwerken".

6.2 Als ops-medewerker wil ik dat extracties met lage confidence worden
tegengehouden, zodat er nooit iets verkeerds automatisch wordt goedgekeurd.
- Given een geparste factuur, when de extractie-confidence voor een regelitem
  onder 0.85 ligt, then gaat de factuur naar de reviewwachtrij en wordt hij
  nooit automatisch goedgekeurd.

6.3 Als ops-medewerker wil ik de mismatch op één plek zien, zodat ik hem kan
oplossen zonder het ordersysteem te openen.
- Given een factuur gekoppeld aan een order, when een regelhoeveelheid of
  eenheidsprijs afwijkt van de orderregistratie, then toont het portaal beide
  waarden naast elkaar en markeert het verschil.

6.4 Als finance manager wil ik facturen filteren, zodat ik de maand kan
afsluiten.
- Given de factuurlijst, when ik filter op leverancier, periode en status,
  then komen resultaten terug in onder 400ms bij p95 en biedt de lege staat
  "Filters wissen" aan.

## 7. Functionele eisen
1. Upload accepteert alleen PDF, maximaal 20 MB, één bestand per indiening.
2. Extractie levert leverancier, factuurnummer, datum, valuta en regelitems
   met hoeveelheid, eenheidsprijs en totaal.
3. Elk regelitem heeft een confidence score tussen 0 en 1.
4. Matching vergelijkt de geëxtraheerde factuur met de openstaande order op
   basis van PO-nummer.
5. Uitzonderingen komen in een wachtrij, oudste eerst, toewijsbaar aan één
   medewerker.
6. Elke statuswijziging schrijft een auditregel met actor, tijdstempel en
   vorige waarde.
7. Goedgekeurde facturen worden geëxporteerd als CSV-batch voor het
   financiële systeem.

## 8. Niet-functionele eisen
- Performance: factuurlijst p95 onder 400ms. Extractie is binnen 90 seconden
  na upload voltooid bij p95.
- Beveiliging & tenancy: per-tenant-isolatie afgedwongen op databaserij-niveau.
  Een klant kan nooit de factuur van een andere klant lezen. Geverifieerd
  door een geautomatiseerde test bij elke release.
- Dataresidentie & retentie: documenten opgeslagen in de EU. Originelen 7 jaar
  bewaard, extractiegegevens 90 dagen.
- Toegankelijkheid: wachtrij volledig met toetsenbord te bedienen, WCAG 2.2 AA
  contrast.
- Beschikbaarheid: 99.5% per maand, ondersteuning tijdens kantooruren.

## 9. Afhankelijkheden & integraties
- Orderregistraties: read-only Postgres-replica. Toegang in beheer bij de IT-
  afdeling van de klant, credentials nodig vóór 2026-08-15.
- LLM-extractieleverancier: contract en verwerkersovereenkomst getekend vóór
  start van de build.
- E-mailmeldingen: bestaande transactionele provider, afzenderdomein
  geverifieerd door de klant.

## 10. Mijlpalen & fasering
| Fase | Scope | Exitcriteria | Streefdatum |
|---|---|---|---|
| P1 | Upload, extractie, confidence-routering | 50 echte facturen end-to-end, onder 25% in wachtrij | 2026-09-19 |
| P2 | Order matching en mismatchweergave | Mismatch correct gemarkeerd bij 20 testcases | 2026-10-10 |
| P3 | Audittrail, CSV-export, rapportage | Finance sluit één maand af in het portaal | 2026-11-01 |

## 11. Open vragen & risico's
| Vraag of risico | Eigenaar | Nodig vóór | Impact indien onbeantwoord |
|---|---|---|---|
| Welk PO-nummer is leidend als een factuur er twee toont? | Ops director van de klant | 2026-08-08 | Matchinglogica geblokkeerd |
| Sturen de 12 grootste klanten gescande of native PDF's? | Delivery lead | 2026-08-08 | Confidence-drempel mogelijk onjuist |
| Is de bewaartermijn van 7 jaar bevestigd met de juridisch adviseur van de klant? | Finance manager van de klant | 2026-08-22 | Opslagontwerp en kosten veranderen |
| Extractiekosten per factuur bij 300/week | Delivery lead | 2026-09-05 | Unit economics onbekend |

## 12. Bijlage & links
Geanonimiseerde voorbeeldfactuurset (40 bestanden), schema van de ordertabel,
huidige studie naar verwerkingstijd, Figma-flows voor upload en wachtrij,
getekende statement of work.

Vier keuzes daarin zijn het vermelden waard, omdat de luie versie van elk ervan echt geld kost.

Sectie 3, de basiswaarde. "6 minuten" is geen versiering. Zonder basiswaarde kun je niet vaststellen of het heeft gewerkt, en zes maanden later ligt iemand hierover in een vergadering te discussiëren zonder data. De luie versie, "verbeter de efficiëntie", maakt het project onweerlegbaar.

Sectie 4, het niet-doel. ERP write-back werd op 2026-07-28 verplaatst naar de niet-doelen, nadat het tijdens een reviewgesprek stilzwijgend als vanzelfsprekend was aangenomen. Het als niet-doel opschrijven kostte één regel en voorkwam een scope-discussie.

Sectie 6.2, de confidence-drempel. Dit is de regel die onze eigen eerste conceptversies het vaakst missen. Laat je hem weg, dan keurt het systeem automatisch facturen goed die een mens had moeten zien, precies de fout die de tijdwinst uit sectie 3 tenietdoet.

Sectie 11, de eigenaren. Elke open vraag heeft een naam en een datum. Die kolom is het verschil tussen een document en een to-do-lijst die niemand beheert.

De PRD vertelt je wat. Hij vertelt je niet hoe lang of hoeveel dat kost, dat is een aparte oefening: zie de build scopen voor dat deel. En een niet-doel dat je niet hebt opgeschreven, is een feature die iemand alsnog gaat bouwen.

Hoe Schrijf Je Een PRD Waar Een AI Coding Agent Daadwerkelijk Mee Kan Bouwen?

Een PRD geschreven voor een AI coding agent ruilt bondigheid in voor expliciete duidelijkheid. De agent heeft geen informele achtergrondkennis, geen gedeelde geschiedenis, en geen instinct voor wat je duidelijk niet bedoelde. Vier regels dekken het grootste deel van het verschil, en ze komen voort uit het zien slagen en falen van specs bij onze eigen agent-ondersteunde builds.

1. Formuleer niet-doelen positief. Mensen leiden scope af uit wat er ontbreekt. Agents doen dat niet. "Voeg in deze fase geen authenticatie toe" moet letterlijk als zin in het document staan, anders wordt auth gebouwd, getest en aan je teruggeleverd.

2. Deel het werk op in fasen. Eén monoliet van 40 pagina's levert een zelfverzekerde, wijdlopige, half-correcte pull request op. Deel de PRD op in stappen die een agent in één afgebakende run kan afronden, elk met eigen exitcriteria.

3. Maak acceptatiecriteria machinaal controleerbaar. "Snel" is geen eis, het is een gevoel. "p95 onder 400ms op het invoice-list endpoint" is een test die de agent kan schrijven voordat hij de feature schrijft.

4. Zet bestandspaden en stack-beperkingen in het document, niet in de chat. Chatcontext verdampt tussen sessies. De spec niet. Dit is ook waarom Claude Code's plan mode belangrijk is: het leest je bestanden en stelt een plan voor zonder iets te bewerken totdat je akkoord geeft, en die goedkeuringsstap is veel nuttiger wanneer het plan wordt getoetst aan een geschreven spec in plaats van aan je herinnering van wat je hebt gevraagd.

Hier is het facturenportaal, opgedeeld in één fase die een agent in één keer kan uitvoeren.

# Bouwtaak: Facturen uploaden en extractie (Fase 1 van 3)

## Stack constraints (do not substitute)
Next.js 15 App Router, TypeScript, Supabase Postgres met row-level security,
Vercel deploy. Geen nieuwe dependencies zonder eerst te vragen.

## Files you may create or edit
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Do not touch
- lib/auth/*  (auth komt in Fase 2; voeg nu geen inlogflows toe)
- Alles onder app/(marketing)/
- Het bestaande orders-schema. Lezen mag. Nooit migreren.

## Acceptance criteria (write these as tests first)
1. POST /api/invoices weigert niet-PDF met 415 en bestanden boven 20 MB met 413.
2. Een regelitem met confidence < 0.85 zet invoice.status = 'review',
   nooit 'approved'.
3. Elke insert schrijft een auditregel met actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= geeft antwoord binnen 400ms op
   een 10,000-row seed.

## Out of scope for this pass
Order matching, mismatch UI, CSV-export, e-mailmeldingen.

Drie dingen veranderden ten opzichte van de menselijke versie: er verschenen bestandspaden, er verscheen een niet-aanraken-lijst, en de acceptatiecriteria werden assertions in plaats van zinnen. Welke agent je het geeft, maakt minder uit dan mensen denken, al is de vergelijking van coding agents het lezen waard voordat je kiest. Houd requirements en projectregels in aparte bestanden: Cursor rules en CLAUDE.md bevatten conventies en tooling, de PRD bevat wat je bouwt. Wil je AI-hulp bij het opstellen van de scope zelf in plaats van het consumeren ervan, dan is dat een andere workflow. En voor de extractiestap zelf zijn modelkeuze en de evaluatielus hun eigen AI-integratiewerk.

Wat Verandert Er Als De PRD Naar Een Extern Team Gaat

Zodra de PRD naar een bureau of contractor gaat, is het niet langer een afstemmingsdocument, maar contracttaal. Ambiguïteit die een intern team met een gesprek van twee minuten oplost, wordt een change request met een prijskaartje. PMI's Pulse of the Profession vond dat 47% van de mislukte projecten hun doelen mist door onnauwkeurig requirements management. Dat is precies de reden waarom dit document bestaat.

Drie secties wegen in die situatie zwaarder dan de rest. Acceptatiecriteria worden goedkeuringsmomenten, dus ze moeten waarneembaar zijn voor iemand die geen engineer is. Open vragen hebben een met naam genoemde eigenaar aan klantzijde nodig, want de leverancier kan ze niet beantwoorden en bouwt gewoon om het gat heen. En wijzigingsgeschiedenis wordt allesbehalve bureaucratisch: het is de vastlegging van wat wanneer is afgesproken, en dat is het eerste waar iedereen naar grijpt bij een meningsverschil.

De regel die we vaker dan eens fout hebben zien gaan, is een variant van "gebruikers kunnen hun data exporteren". Niemand schrijft op in welk formaat. Bij ons kwam de dure versie daarvan neer op een CSV-export terwijl de klant een opgemaakt PDF-factuurpakket met eigen huisstijl had bedoeld, en het overdoen kostte ongeveer een week engineering die niemand had ingepland. De eerlijke lezing is dat de fout in het document zat, niet in de oplevering. Een acceptatiecriterium had het in vijf minuten opgevangen: given een exportverzoek, when het bestand wordt gegenereerd, then is het een PDF die overeenkomt met de aangeleverde lay-out. Een regel bij niet-doelen had het vanuit de andere hoek ook opgevangen. Dat is nu dan ook een vaste regel bij onze intake: elke eis die aan een zelfstandig naamwoord hangt zoals "export", "rapport" of "notificatie" krijgt een formaat, een trigger en een uitgewerkt voorbeeld voordat er een statement of work wordt getekend.

Dat is grotendeels waar hoe wij webapplicatiebuilds uitvoeren om draait: het vage deel van de spec van een klant omzetten in testbare regels voordat er ook maar één regel code wordt geschreven.

Wat r/ProductManagement Daadwerkelijk Zegt Over PRD-sjablonen

Zoek op product requirements document template reddit en je vindt op r/ProductManagement steeds dezelfde klacht terug: sjabloon-opblazing. PRD's die niemand leest. Secties ingevuld omdat het sjabloon nu eenmaal een kop had, niet omdat iemand de inhoud nodig had. Documenten die de dag na de kickoff al verouderd zijn en stilletjes worden vervangen door een Slack-thread. Het is een terechte kritiek op de meeste sjablonen, inclusief meerdere resultaten in de top tien voor deze zoekopdracht.

Ons antwoord: verwijder secties in plaats van ze met niets te vullen. Persona's zijn de eerste die sneuvelen als de gebruikers voor de hand liggen. Bijlage volgt als tweede. Mijlpalen kunnen ook prima in de tracker leven. De sectie die we nooit verwijderen is niet-doelen, want het is de enige sectie die korter wordt naarmate je meer werk verzet, en de enige die betrouwbaar de discussie voorkomt die je anders in week zes had gehad.

Veelgestelde Vragen

Wat is een product requirements document?

Een product requirements document (PRD) beschrijft wat een team bouwt en waarom: het probleem, de doelen en hun metrics, de niet-doelen, voor wie het is, en de eisen die bepalen wanneer iets af is. Het sluit implementatiedetails bewust uit, die horen thuis in een technisch ontwerpdocument dat engineering er later bij schrijft.

Hoe schrijf je een product requirements document?

Begin met de probleemstelling en gebruik daarin bewust geen oplossingstaal. Voeg meetbare doelen toe met een basiswaarde en een streefdatum, en schrijf daarna de niet-doelen. Vul persona's in, user stories met Given/When/Then-acceptatiecriteria, functionele en niet-functionele eisen, afhankelijkheden, mijlpalen en open vragen met eigenaren.

Wat moet een PRD bevatten?

Twaalf secties: header met wijzigingsgeschiedenis, probleemstelling, doelen en succesmetrics, niet-doelen, gebruikers en persona's, user stories met acceptatiecriteria, functionele eisen, niet-functionele eisen, afhankelijkheden en integraties, mijlpalen en fasering, open vragen en risico's, en een bijlage. Alles wat daar niet in past, is waarschijnlijk geen eis.

Hoe lang moet een PRD zijn?

Eén tot twee pagina's voor een enkele feature, drie tot vijf voor een productfase, vijf tot acht wanneer een extern team hem bouwt en de acceptatiecriteria als goedkeuringsmomenten fungeren. De lengte volgt uit het aantal vastgelegde beslissingen, niet uit de grootte van het product. Lege secties moet je verwijderen, niet opvullen.

Is een PRD hetzelfde als een BRD?

Nee. Een business requirements document beschrijft het commerciële resultaat dat de organisatie wil en de bijbehorende randvoorwaarden, meestal vóórdat een oplossing is gekozen. Een PRD beschrijft het product dat dat resultaat levert: gebruikers, gedrag, acceptatiecriteria, niet-doelen. Bij kleinere bedrijven is de BRD vaak niet meer dan de probleemstelling-sectie.

Schrijven agile teams nog steeds PRD's?

Ja, meestal als one-pager. De backlog bevat het werk, maar tickets zijn slecht in het vasthouden van het waarom, de niet-doelen en de succesmetric. Teams die de PRD helemaal overslaan, vinden hem vaak drie sprints later opnieuw uit als een Confluence-pagina genaamd "context".

Kun je een PRD in markdown schrijven?

Markdown is daar het beste formaat voor. Het plakt netjes in Notion, Confluence, Google Docs en Linear, versioneert in Git naast de code als PRD.md, toont nette diffs in een pull request, en is het enige formaat dat een AI coding agent leest zonder structuur te verliezen. Het sjabloon hierboven is precies om die redenen markdown.

Hoe schrijf je een PRD voor een AI coding agent?

Wees expliciet waar je normaal beknopt zou zijn. Formuleer niet-doelen positief, want een agent kan scope niet afleiden uit wat er ontbreekt. Deel het document op in fasen die in één keer af te ronden zijn. Schrijf acceptatiecriteria als assertions met getallen. Benoem de bestanden die de agent mag bewerken en de bestanden die hij niet mag aanraken.

Wat is het verschil tussen een PRD en een technisch ontwerpdocument?

De PRD beantwoordt wat en waarom: probleem, gebruikers, gedrag, acceptatiecriteria, niet-doelen. Het technisch ontwerpdocument beantwoordt hoe: architectuur, datamodel, API-contracten, overwogen trade-offs. Product is meestal eigenaar van het eerste, engineering van het tweede, en het ontwerpdocument zou leesbaar moeten zijn als antwoord op de PRD.

Wie is eigenaar van de PRD: product, engineering, of de klant?

Product is eigenaar van het document en de beslissingen erin. Engineering is eigenaar van de haalbaarheidsfeedback en de niet-functionele eisen. Bij builds via een bureau is de klant eigenaar van de probleemstelling, de doelen en elke open vraag over hun eigen bedrijf. Gedeeld eigenaarschap van het hele document betekent meestal dat niemand het onderhoudt.

Tot Slot

Drie dingen om mee te nemen. Het sjabloon is pas nuttig zodra het is ingevuld, dus kopieer de vorm van het uitgewerkte voorbeeld in plaats van de lege versie. Niet-doelen zijn de sectie met de hoogste waarde per woord in het document, en de eerste die mensen overslaan. En acceptatiecriteria geschreven als testbare assertions dienen twee lezers even goed: een engineer die een oplevering afvinkt, en een agent die de test schrijft.

Schrijf je een PRD om over te dragen aan een extern team en wil je er graag nog een extra paar ogen naar laten kijken voordat het contracttaal wordt? Wij lezen hem graag door en markeren de ambigue regels. Dat is dezelfde controle die we uitvoeren op onze eigen webapplicatiebuilds. </content>