Een productvereistendocument (PRD) schrijven met AI (gratis template)

Een productvereistendocument (PRD) is een korte beschrijving in gewone taal van wat je bouwt, voor wie het is, wat het moet doen en hoe je weet dat het werkt. AI maakt het schrijven ervan veel sneller: je geeft ruwe aantekeningen en de AI maakt er gestructureerde onderdelen, user stories en edge cases van. Jouw taak is de beslissingen leveren die de AI niet kan nemen — het doel, de scope en wat je weglaat — en controleren wat de AI toevoegt.

Deze gids behandelt wat een PRD moet bevatten, een stapsgewijze manier om er een op te stellen met elke AI-assistent, prompts voor elk onderdeel en een invulbaar template dat je kunt kopiëren.

Waar een PRD voor dient (en waar niet)

Een PRD beantwoordt vier vragen:

1. Waarom bouwen we dit? Welk probleem, voor wie?
2. Wat moet het in de eerste versie doen?
3. Wat doet het nog níet?
4. Hoe weten we dat het werkt?

Het is geen technisch ontwerp. Er staat niet in welke database of welk framework je gebruikt — dat hoort in een aparte technische specificatie, als je die al nodig hebt. Het is ook geen marketingbriefing of ondernemingsplan. Door de PRD bij het gedrag van het product te houden, is hij bruikbaar voor iedereen die hem leest: een ontwerper, een ontwikkelaar, een stakeholder die akkoord geeft, of een AI app builder die er code van maakt.

Wie heeft er een nodig?

• Solo-oprichters die scope creep willen voorkomen voordat die begint.
• Kleine teams die één plek nodig hebben waar „wat we hebben afgesproken” staat.
• Wie een freelancer of bureau inhuurt, want een duidelijke PRD levert duidelijkere offertes op. Zie een ontwikkelaar inhuren of met AI bouwen.
• Wie met AI bouwt, want de user stories en datalijst in een PRD maken betere prompts dan een ongestructureerd verlanglijstje.

Wat AI goed kan — en wat niet

De meest voorkomende fout is de op een na laatste rij omgedraaid: de AI vult met overtuiging gaten in met plausibele gissingen over je gebruikers. Behandel alles wat de AI schrijft over gebruikers, marktomvang of gedrag als een vraag die je moet verifiëren, niet als feit.

Stap 1: Zet op papier wat je weet

Voordat je iets vraagt aan de AI, schrijf je ruwe aantekeningen. Opsommingstekens zijn prima. Behandel:

• Het probleem, in één of twee zinnen, vanuit het standpunt van de gebruiker.
• Wie het heeft. Wees specifiek: „freelance boekhouders met 10 tot 40 klanten”, niet „kleine bedrijven”.
• Wat ze nu doen (een spreadsheet, e-mail, een tool die ze niet mogen).
• Het ene resultaat dat versie één tot een succes maakt.
• Dingen waarvan je al weet dat je ze niet gaat doen.
• Harde randvoorwaarden: deadline, budget, moet op telefoons werken, moet koppelen met een tool die je al gebruikt.

Als je nog niemand hebt gesproken die dit probleem heeft, doe dat eerst. Een app-idee valideren beschrijft een praktische manier. Een PRD die op gissingen rust, is een goed opgemaakte gissing.

Stap 2: Vraag de AI om een eerste concept

Plak je aantekeningen en vraag om een concept in een vaste structuur. Een prompt die goed werkt:

Hier zijn mijn aantekeningen over een product. Zet ze om in een productvereistendocument met precies deze onderdelen: Samenvatting, Probleem, Gebruikers, Doelen en succesmetrieken, Scope (in / uit), User stories met acceptatiecriteria, Data, Rechten, Edge cases, Open vragen. Houd het onder twee pagina’s. Verzin geen feiten over gebruikers of de markt — waar mijn aantekeningen het niet zeggen, zet je de vraag onder Open vragen.

De laatste instructie is belangrijk. Als je de AI vertelt onbekende zaken onder „Open vragen” te zetten in plaats van ze in te vullen, krijg je een veel eerlijker concept.

Stap 3: Scherp elk onderdeel aan

Loop het concept onderdeel voor onderdeel door. Deze vervolgprompts helpen:

Probleem en gebruikers

Herschrijf de probleemstelling in één of twee zinnen vanuit het standpunt van de gebruiker. Geen oplossingswoorden.

Als de probleemstelling je product noemt, beschrijft hij een oplossing, geen probleem.

Doelen en succesmetrieken

Stel drie succesmetrieken voor versie één voor die ik in de eerste maand met een klein aantal gebruikers kan meten. Zeg bij elk hoe ik het zou meten.

Kies er één of twee. „Twintig boekhouders gebruiken het wekelijks een maand lang” is meetbaar. „Productiviteit verbeteren” is dat niet.

Scope

Zet op een lijst alles in deze PRD dat naar een latere versie kan zonder de kernflow te breken.

AI-tools neigen ertoe functies toe te voegen. Deze prompt laat ze het omgekeerde doen. Wees streng: de meeste PRD’s voor een eerste versie zijn te groot. Wat is een MVP legt uit waarom kleine eerste versies je meer leren.

User stories en acceptatiecriteria

Schrijf elke eis als user story („Als [gebruiker] wil ik [actie] zodat [resultaat]”) met twee tot vier acceptatiecriteria in Gegeven / Wanneer / Dan-vorm.

Acceptatiecriteria zijn de checklist waartegen je later test. „Gegeven een geboekt tijdslot, wanneer een andere klant de agenda bekijkt, dan wordt het tijdslot niet getoond” is testbaar. „Boeken werkt goed” niet.

Edge cases en rechten

Beschrijf voor elke user story wat er gebeurt bij lege data, ongeldige invoer, een trage of mislukte netwerkaanvraag, en een gebruiker die geen toegang mag hebben.

Hier verdient AI zijn geld. Het ziet snel de lege staten en de gaten in rechten die mensen vergeten.

Stap 4: Lees het kritisch na

Lees het hele document nog één keer en controleer:

• Elke bewering over gebruikers komt van jou of uit onderzoek, niet van de AI.
• Scope „uit” is minstens zo lang als scope „in”.
• Elke user story heeft acceptatiecriteria die iemand kan testen zonder jou te vragen.
• Het datagedeelte noemt elk soort record dat de app bewaart en wie het mag zien.
• Open vragen hebben een eigenaar en een datum.
• Niets technisch is stiekem binnengeslopen, tenzij het een echte randvoorwaarde is („moet offline werken” is een eis; „gebruik Redis” is het niet).

Deel het daarna met één persoon die het product gaat gebruiken of bouwen en vraag wat onduidelijk is. Hun vragen zijn de gaten.

Invulbaar PRD-template

Kopieer dit in een document en vervang de haken. Verwijder onderdelen die echt niet van toepassing zijn.

Productnaam: [naam] Eigenaar: [persoon die verantwoordelijk is voor beslissingen] Status: [concept / in beoordeling / akkoord] — Laatst bijgewerkt: [datum]

1. Samenvatting

[Twee of drie zinnen: wat dit is, voor wie en het belangrijkste resultaat.]

2. Probleem

[Het probleem vanuit het standpunt van de gebruiker. Wat ze nu doen en waarom dat pijn doet.]

3. Gebruikers

4. Doelen en succesmetrieken

• Doel: [het resultaat dat versie één moet halen]
• Metriek: [hoe je het meet, en het streefcijfer]
• Niet-doel: [iets wat mensen misschien denken dat deze versie doet, maar niet doet]

5. Scope

In versie één:

• [functie]
• [functie]

Niet in versie één:

• [functie, en waarom die kan wachten]
• [functie, en waarom die kan wachten]

6. User stories

Story 1: Als [gebruiker] wil ik [actie] zodat [resultaat].

• Gegeven [context], wanneer [actie], dan [resultaat].
• Gegeven [context], wanneer [actie], dan [resultaat].

Story 2: Als [gebruiker] wil ik [actie] zodat [resultaat].

• Gegeven [context], wanneer [actie], dan [resultaat].

7. Data

8. Rechten

[Wie kan inloggen, welke rollen er zijn en wat elke rol kan zien en wijzigen.]

9. Edge cases

• [Lege staat: wat er wordt getoond als er nog geen data is]
• [Ongeldige invoer: wat er gebeurt bij een verkeerd e-mailadres of een ontbrekend veld]
• [Toegang: wat er gebeurt als iemand een pagina opent die hij niet mag zien]

10. Koppelingen en randvoorwaarden

[Betalingen, e-mail, bestaande tools, deadlines, budget, apparaten waarop het moet werken.]

11. Open vragen

Van PRD naar prompts

Een goede PRD vertaalt zich bijna rechtstreeks naar prompts voor een AI app builder:

• De samenvatting, gebruikers en datatabel worden je eerste prompt.
• Elke user story wordt één vervolgprompt.
• Elk acceptatiecriterium wordt iets wat je in de preview test.
• De lijst „niet in versie één” is wat je nog niet vraagt.

Bouwen per story en de acceptatiecriteria controleren voordat je verdergaat, is veel betrouwbaarder dan de hele PRD plakken en om alles tegelijk vragen. Hoe schrijf je prompts voor AI app builders gaat dieper in op het prompten.

Veelgemaakte fouten

• De oplossing als probleem opschrijven. „Gebruikers hebben een dashboard nodig” is een oplossing. „Eigenaren kunnen niet zien welke facturen te laat zijn zonder ze één voor één te openen” is een probleem.
• Geen sectie „buiten scope”. Zonder die sectie wordt elk gesprek weer een discussie over de scope.
• De AI gebruikers laten verzinnen. Personas die de AI bedenkt voelen echt aan en zijn dat niet.
• Metrieken die je niet kunt meten. Als je het niet kunt tellen, is het geen metriek.
• Nooit bijwerken. Een PRD die niet meer overeenkomt met wat je bouwt, is erger dan geen PRD. Houd een datum „laatst bijgewerkt” bij en pas hem aan als beslissingen veranderen.

Een PRD gebruiken met Mythex

Als je bouwt in Mythex, kun je je PRD rechtstreeks in de chat plakken. De modus Plan past goed bij een PRD: de agent leest hem, stelt een aanpak voor en een stappenlijst die je in een plantab kunt nakijken, en begint pas met bestanden wijzigen als je op Bouwen drukt. Je kunt ook de onderdelen die altijd gelden — doelgroep, merk, regels — opslaan als projectkennis, zodat je ze niet in elke chat hoeft te herhalen. De chatdocumentatie legt de modi Bouwen, Plan en Vragen uit, en de templates zijn een snelle manier om te zien hoe een eerste versie eruit kan zien voordat je het volledige document schrijft.

Veelgestelde vragen