Vraag Claude Code om een applicatie te bouwen en je krijgt een applicatie. Dat is het probleem. Zonder plan bouwt een taalmodel wat het dénkt dat je wilt, en dat kan flink afwijken van wat je echt wilt.
Voor kleine wijzigingen is dat geen ramp. Bij een website of app bouwen met AI wel: je merkt pas na een uur bouwen dat de helft niet nodig was en dat het belangrijkste onderdeel ontbreekt.
Een product requirements document, kortweg PRD, lost dit op. En anders dan de naam suggereert is het geen zwaar document van dertig pagina's.
Wat er in een PRD hoort
Vier onderdelen zijn genoeg:
| Onderdeel | De vraag die het beantwoordt |
|---|---|
| Probleemstelling | Welk probleem los je op, vanuit de gebruiker? |
| Oplossing | Hoe wordt dat probleem opgelost? |
| Kernfunctionaliteiten | Wat moet de app minimaal kunnen? |
| Out-of-scope | Wat bouw je expliciet níet? |
Dat laatste onderdeel is het belangrijkste en wordt het vaakst vergeten. Een AI-assistent bouwt uit zichzelf door: je vraagt om een receptenapp en krijgt een boodschappenlijst, meal planning en een deelfunctie voor sociale media. Allemaal niet gevraagd, allemaal code die je moet begrijpen en onderhouden.
Zet je in het PRD dat je geen boodschappenlijst wilt, dan komt die er niet.
Stap 1: laat Claude eerst vragen stellen
De grootste winst zit in een stap die niets met schrijven te maken heeft. Laat Claude je idee eerst bevragen:
Ik wil een webapplicatie maken op basis van historische KNMI-data.
Het idee: een keuzehulp waarmee gebruikers kunnen zien welke activiteit,
locatie of periode historisch het meest geschikt is.
Stel me eerst kritische vragen om het idee scherper te maken.
Schrijf nog geen PRD en schrijf geen code.Die laatste twee regels zijn nodig, anders begint Claude gewoon te bouwen.
Wat je terugkrijgt zijn vragen die je zelf ook had moeten stellen. Voor wie is dit? Wat betekent "geschikt weer" precies: een temperatuurgrens, een neerslaggrens, een combinatie? Wat is een goede score? Wat laat je weg in versie 1?
Het antwoord op die vragen is jouw werk. Claude kan het idee scherpen, maar hij weet niet voor wie je bouwt.
Stap 2: het PRD schrijven
Nu pas laat je het document schrijven. Met een limiet:
Schrijf nu een compact PRD voor versie 1 van deze app (max 350 woorden).
Neem op: probleemstelling, oplossing, kernfunctionaliteiten, out-of-scope,
en minimaal 15 user stories in het format:
als <rol> wil ik <functionaliteit> zodat ik <waarde>.
Gebruik begrijpelijke taal, geen onnodige technische details.
Sla het op als PRD.md.Die woordlimiet doet echt iets. Een taalmodel produceert makkelijk pagina's tekst die nergens naar verwijzen, en dat werkt twee kanten op tegen je: jij leest het niet goed, en het vult de context waardoor de belangrijkste punten verdunnen.
Lees het document daarna kritisch. Is de doelgroep concreet genoeg? Is de scope klein genoeg? Klopt de hoofdvraag met wat jij voor ogen had? Stuur bij waar het afwijkt.
Stap 3: prioriteren met MoSCoW
Vijftien user stories is te veel om te bouwen. Laat ze indelen:
Zet de user stories in een tabel met nummer, user story en prioriteit.
Prioriteer volgens MoSCoW: Must have, Should have, Could have, Won't have.Bekijk die indeling zelf en verplaats wat je anders ziet. Leg daarbij uit waarom, dan neemt Claude die redenering mee in de rest van het gesprek. De Must-haves zijn wat je vandaag bouwt. De rest is voor later of nooit.
Stap 4: per story een bouwplan
De laatste stap voor je gaat bouwen:
Maak voor de top 3 Must have-stories een apart bouwplan.
Sla elk plan op als een apart markdown-bestand.
Voorzie elk plan van acceptatiecriteria.Aparte bestanden hebben een reden. Een plan in een markdown-bestand kun je morgen in een nieuwe sessie oppakken, terwijl een plan in een chatgesprek verdwijnt zodra je de sessie sluit.
De acceptatiecriteria zijn het onderdeel waar je zelf naar moet kijken. Ze bepalen wanneer een feature klaar is, en later zijn ze de basis voor je tests.
Een PRD moet schrappen
De belangrijkste vuistregel: een goed PRD maakt de opdracht kleiner, niet groter.
Merk je dat je document features toevoegt die je nog niet had bedacht, dan is er iets misgegaan. Vraag Claude dan expliciet om scope te schrappen, niet om aan te vullen.
De reden dat dit werkt, is niet dat het document zo goed is. Het is dat je door het schrijven gedwongen wordt om na te denken over je eigen idee. Dat je daarbij een assistent hebt die goede vragen stelt, maakt het sneller. Om je prompts scherper te krijgen helpt prompt engineering.
Wil jij dit ook leren?
In onze Vibe Coding Training leer je in twee dagen websites en apps bouwen met AI, zonder programmeerervaring. Wil je specifiek met Claude werken? Bekijk dan de Claude Code Training. En voor een complete basis in AI zonder programmeren is er de 5-daagse AI Opleiding.
Terry is full-stack AI-ontwikkelaar en data scientist. Hij geeft gestudeerd aan de TU Delft. In zijn carrière richt hij zich al 10+ jaar op het optimaal waarde halen uit data door toepassing van machine learning en AI.
