Schrijf een PRD dat engineering, design en stakeholders op één lijn brengt via een 8-sectie structuur met aannames en hypotheses.

PRD Schrijven

Metadata

Doel: Schrijf een PRD dat engineering, design en stakeholders op één lijn brengt. Een PRD is geen specificatie maar een communicatiemiddel: het maakt expliciet wat je wilt bereiken, welke aannames je maakt, en wat je nog niet weet.

Dit is geen snelle exercise. Een goede PRD vraagt grondige voorbereiding. Veel doorvragen, validatie van aannames, en structurering van onzekerheid.

Aanpak: 8-sectie structuur. Diepgang past zich aan: een kleine feature PRD (UI-tweak) is compacter dan een initiative PRD (nieuw product, marktexpansie).

Output: Volledig PRD in markdown met probleemstelling, doelgroep, hypotheses, requirements, aannames en risico's.

Instructies

Fase 0: Context ophalen

Stap 1 — Check wat er al is Scan uploads, gedeelde mappen en workspace op relevante bestanden (eerdere outputs, research, data). Lees ze door.

Stap 2 — Slimme vragen stellen

Wel context gevonden → Bevestig kort wat je ziet ("Ik zie [X], klopt dat?"). Stel alleen vragen over wat je nog mist.
Geen context → Stel onderstaande vragen.

1. START MET DOORVRAGEN

Voordat ik ook maar één woord van de PRD schrijf, stel ik vragen over:

Product & Context

Welk product/feature spreken we over? (Naam, huidige staat)
Is dit brand new, een uitbreiding op bestaand, of replacement?
Wie heeft dit bedacht? (PM, stakeholder, customer feedback, data?)

Scope & Doelen

Wat willen we bereiken met deze feature? (Business outcome, niet "we maken een knop")
Wie zijn de primaire gebruikers? (Rol, segment, use case)
Zijn er secundaire doelgroepen?
Wat meten we om succes te bepalen?

Team & Constraints

Wie zit in het team? (Engineering, design, data, etc.)
Zijn er technische beperkingen?
Timeline druk? (Go-to-market deadline, afhankelijkheden)
Budget/resource constraints?

Risico's & Aannames

Wat zijn je grootste onzekerheden? (Technisch, marktgerelateerd, user behavior)
Wat veronderstel je dat waar is?
Zijn er concurrenten die dit al doen?

Ik stuur doorvragen als gerichte vragen per categorie, geen lange checklist. Ik wacht op antwoorden voordat ik structuur bouw.

2. PRODUCTHYPOTHESE EERST

Zodra ik context heb, formuleren we samen de producthypothese. Dit is de kern: wat geloven we en waarom?

Template (verplicht):

Wij geloven dat door [ACTIE/FEATURE]
voor [DOELGROEP/SITUATIE],
we [BEHAVIOR/OUTCOME] veroorzaken,
wat leidt tot [BUSINESS RESULTAAT].

Voorbeeld:

Wij geloven dat door workspaces per departement aan te bieden
voor enterprise-admins,
we de adoption van Slack in grote organisaties versnellen,
wat leidt tot meer seats en contract retention.

Doorvraag per onderdeel:

Actie: Is dit concreet genoeg? Kan engineering dit bouwen?
Doelgroep: Wie is dit echt voor? (Niet "users", maar rollen/segmenten)
Behavior: Welk gedrag verwachten we? (User action, interactie, frequentie)
Resultaat: Meetbaar? Link naar OKRs?

3. DE 8-SECTIE STRUCTUUR

Ik bouw de PRD altijd in deze volgorde:

Sectie 1: Samenvatting (Executive Summary)

Inhoud: 1-2 alinea's. Wat is het? Waarom nu? Business case in 30 seconden.
Voor wie: Busy stakeholders, leadership.
Doorvraag: Zou een exexutive dit snappen zonder rest van PRD?

Sectie 2: Contactpersonen & Eigendom

Product Owner/PM (contactgegevens, verantwoordelijkheden)
Design Owner
Engineering Lead
Stakeholder(s)
Doorvraag: Wie is eindverantwoordelijk als beslissingen nodig zijn?

Sectie 3: Achtergrond & Producthypothese

Achtergrond: Wat leidde tot dit initiatief?
- Market signals (data, feedback, trends)
- Interne motivatie (OKR, strategie)
- Competitieve druk
Producthypothese: (De template uit stap 2)
Doorvraag: Wat is het bewijs voor deze hypothese?
Doorvraag: Welk experiment valideren we dit mee?

Sectie 4: Doelstelling (SMART OKRs)

Wat willen we bereiken? Measurable outcomes, niet activities.
Format: "Objective" (kwalitatief) + "Key Results" (kwantitatief, 3-5 per objective)

Voorbeeld:

Objective: Enterprise-customers sneller naar waarde

Key Results:
1. Time-to-first-login voor new enterprise-teams: < 5 minuten (nu: 20 min)
2. Workspace creation success rate: > 95% (nu: 78%)
3. Admin satisfaction score: 4.5+ (NPS-based)

Doorvraag: Hoe weten we dat dit klaar is?
Doorvraag: Wat zijn je stretch goals?

Sectie 5: Marktsegment & Waardepropositie

Marktsegment: Wie boeit dit? (Rollen, bedrijfsgroottes, industrie, geografie)
Huidge pijnpunten: Wat werkt niet goed nu?
Waardepropositie: Wat krijgen ze beter/anders/goedkoper?
Concurrentie context: Hoe zien anderen dit? (Differentiation?)
Doorvraag: Waar verdienen we hier geld mee? (Direct of indirect)
Doorvraag: Waarom zou je dit kopen vs. de concurrent?

Sectie 6: Oplossing (UX/Features/Technologie)

User Flows: Stap-voor-stap wat doet de user? (Tekst of diagram)
Features: Wat bouwen we precies?
- Feature A: beschrijving + scope (in/out of scope)
- Feature B: beschrijving + scope
- Etc.
Technische Aanpak: (Niet low-level details, maar strategische keuzes)
- Bestaande systemen gebruiken? Nieuwe service?
- Data flows, integraties?
- Performance constraints?
UI/Design Principes: (Niet full mocks, maar richtlijnen)
- Consistency met bestaand product?
- Accessibility?
- Mobile vs desktop focus?
Doorvraag: Kunnen we dit in fases leveren?
Doorvraag: Wat laten we buiten scope?

Sectie 7: Aannames (EIGEN SECTIE)

Dit is niet ondergesneeuwd in Oplossing, maar eigen behandeling.

Format:

Aanname	Type	Confidence	Test	Fallback
Enterprise admins willen workspaces per dept.	User behavior	Medium (60%)	User interviews (5-10)	Offer workspaces per project instead
We kunnen multi-tenancy in 8 weken builden	Technical	High (85%)	Arch review + spike	Use existing SAAS provider
Market willing to pay $X/user/month	Market	Low (40%)	Pricing survey, sales comps	Freemium model instead

Soorten aannames:

User behavior: Wat doen gebruikers? Wat willen ze?
Technical: Kunnen we dit bouwen? Performance? Reliability?
Market: Willen klanten dit? Prijsbereidheid? TAM?
Business: Winstgevendheid? Customer fit?

Confidence rating: Low (< 50%), Medium (50-75%), High (> 75%)

Test: Hoe valideren we dit? (Experiment, data, interview, prototype)

Fallback: Plan B als aanname fout is?

Doorvraag: Welke aanname kill het hele project als het fout is?
Doorvraag: Wat experimenteren we eerst?

Sectie 8: Release Plan & Metrics

Phasing: Hoe brengen we dit naar markt?
- MVP (phase 1): Wat is minimum viable? Wanneer?
- Phase 2+: Expansies, optimisaties
Rollout: Beta? Early access? Public launch?
Success Metrics: Link terug naar doelstellingen
Monitoring & Fallback: Wat doen we als metrics bad zijn?
Doorvraag: Kunnen we dit sneller? Wat kunnen we weglaten?
Doorvraag: Wat is het kill criterion (moment om te stoppen)?

4. CONDITIONAL: AI-FEATURES CHECKLIST

Alleen relevant als de PRD AI-features bevat.

Voeg onderaan een sectie toe: "AI Product Considerations"

Checklist:

[ ] Transparantie
    - Toont het systeem confidence scores/explainability?
    - Weet de user wanneer AI in beeld is?

[ ] Controle
    - Kan de user de AI-output negeren/overridden?
    - Zijn er fallbacks voor AI failures?

[ ] Verwachtingsmanagement
    - Communiceren we wat het AI-systeem kan/niet kan?
    - Trainingen voor users nodig?

[ ] Graceful Degradation
    - Wat gebeurt als AI-model faalt/hallucineert?
    - Fallback naar manual process? Show error?

[ ] Progressive Disclosure
    - Zien users eerst het resultaat of de uitleg?
    - Kunnen ze graven naar reasoning?

Voor elk item:

Status: Ja/Nee/In progress
Reden: Waarom is dit belangrijk voor dit product?
Owner: Wie verzorgt dit?

5. OUTPUT

Als de PRD klaar is, lever ik drie dingen:

De volledige PRD (Markdown formaat, copy-paste-ready)
Aannames-overzicht (Tabel met confidence, tests, fallbacks)
Open vragen lijst (Dingen die nog beantwoord moeten worden voordat we bouwen)

Bronnen

Marty Cagan, Inspired - Requirements gathering & hypothesis-driven product
Teresa Torres, Continuous Discovery Habits - Understanding user needs deeply
MIT xPRO AI Product Design - AI-specific PRD sections & responsible AI
Reforge, Product Strategy & PRD-writing (SMART OKRs, phasing)

prd-schrijven