Vang de gaten in je PRD op voordat reviewers dat doen
5 min leestijd
De meeste PRD's gaan de deur uit na één doorlezing door de persoon die ze schreef. Dat vangt typefouten, maar zelden het gat dat in de opmerkingen van elk document dat je verstuurt dezelfde verduidelijkende vraag oproept, omdat je het antwoord al kent en voorbij de plek leest waar het ontbreekt. Een PM die de context van een functie twee weken in zijn hoofd heeft gedragen, leest een PRD erover totaal anders dan een engineer die het document voor het eerst koud opent.
Waarschuwing
Een doorlezing door de auteur controleert of het document logisch is voor iemand die de functie al kent. Het controleert niet of het logisch is voor iemand die haar niet kent, en dat is de echte reviewer.
De PRD die je eigen doorlezing overleeft, is degene die je het minst kunt beoordelen.
Waarom dezelfde vraag in de review steeds terugkomt
Je schreef het document met de volledige context al in je hoofd, dus een gat in de requirements leest voor jou niet als een gat, het leest als vanzelfsprekend. De reviewer heeft die context niet, dus hetzelfde soort vraag, een onbehandeld randgeval, een onuitgesproken aanname, komt document na document terug. Als drie van je laatste vijf PRD's dezelfde opmerking kregen over hoe de functie zich moet gedragen voor een specifiek gebruikerstype, is dat geen pech, maar een patroon in hoe je de scope schrijft.
Neem een PRD voor een bulkexportfunctie die precies specificeert wat er gebeurt voor een standaardgebruiker die tot 10.000 rijen exporteert. Het zegt niet wat er bij 100.000 rijen gebeurt, of voor een gebruiker op een gratis abonnement met exportlimieten, omdat de auteur de hele tijd dat hij schreef aan het gewone geval dacht. Een engineer die het document oppakt, heeft geen manier om die antwoorden af te leiden, en de resulterende reactiedraad, “wat gebeurt er boven de rijlimiet?”, is dezelfde vraag die ook bij de laatste drie PRD's was gerezen, als iemand had bedacht het na te gaan.
Voor: de PRD schrijven, eenmaal lezen, besluiten dat hij duidelijk is, ter review sturen.
Na: hem aan Claude geven met de echte context van de functie, specifiek vragen of de scope duidelijk is en welke randgevallen ontbreken, en herstellen wat het vindt voordat een reviewer moet vragen.
Een werkwijze om een PRD voor de review te testen
- 1
Geef Claude het echte concept en de echte context
Plak de probleemstelling en requirements zoals geschreven, geen samenvatting, samen met voor wie deze functie is. Een PRD voor een interne beheertool heeft een andere randgevaldekking nodig dan een voor een publieke functie, en hetzelfde ontbrekende randgeval doet meer of minder ertoe afhankelijk van wie erdoor wordt geraakt.
- 2
Vraag specifiek of de scope duidelijk is
Een vaag “is dit logisch” krijgt een vaag antwoord. Vraag direct of iemand zonder voorkennis uit het document alleen kan opmaken wat binnen de scope valt en wat niet, want dat is de echte test waarvoor een engineer staat die het document koud oppakt.
- 3
Vraag om ontbrekende randgevallen, niet om een algemene kritiek
Vraag om de specifieke randgevallen die de requirements niet behandelen, niet om open feedback. Een ontbrekend randgeval is concreet en herstelbaar; “dit zou duidelijker kunnen” is dat niet.
- 4
Herstel de gaten voordat iemand anders het document ziet
Werk de requirementssectie direct bij op basis van wat Claude markeerde. De versie die een reviewer ziet, moet de vragen die je anders in de opmerkingen zou krijgen al weerspiegelen, zodat reviewtijd naar echte meningsverschillen gaat in plaats van naar basale verduidelijkingen.
Hier zijn de probleemstelling en requirementssectie van mijn PRD voor een bulkexportfunctie. Zeg me eerlijk of de scope duidelijk is en markeer elk randgeval dat ik niet heb behandeld.
”Bij een functie met een specifieke technische beperking die je al kent, een rate limit, een plafond voor datagrootte, een rechtengrens, is het de moeite waard Claude die direct te vertellen zodat de randgevalcontrole is gegrond in het echte systeem in plaats van in generieke gissingen.
Ons exportsysteem heeft op infrastructuurniveau een harde limiet van 500.000 rijen, die nergens in deze PRD wordt genoemd. Welke randgevallen rond rijlimieten moeten de requirements, gegeven die beperking, expliciet behandelen?
”
In Claude Tutorial
Een document toetsen aan een lezer zonder jouw context is overdraagbaar.
Nagaan of iets logisch is voor iemand zonder jouw achtergrond, in plaats van je eigen doorlezing te vertrouwen, geldt veel verder dan PRD's. De app heeft hier een volledige les over, met oefeningen die van toepassing zijn op elk document dat je schrijft zodat iemand anders erop kan handelen.
Wanneer de gaten steeds uit dezelfde sectie komen
Als randgevallen steeds in hetzelfde deel van je PRD's opduiken, is het de moeite waard dat als patroon op te merken, niet elke keer opnieuw van nul af aan te herstellen. Een terugkerend gat in bijvoorbeeld de rechtensectie betekent meestal dat die sectie een vaste checklist nodig heeft, niet nog een eenmalige review. Dezelfde categorie gat driemaal afzonderlijk herstellen is een teken dat de onderliggende gewoonte moet veranderen, niet alleen het huidige document.
Tip
Vraag Claude de gaten van deze PRD te vergelijken met die uit je laatste documenten, als je die hebt. Een patroon over meerdere PRD's is een sterker signaal dan de randgevallen van één document, en het vertelt je waar je een herbruikbare checklist moet bouwen.
Dit is de derde PRD op rij waarbij reviewers vroegen naar de afhandeling van rechten. Hier is de rechtensectie van dit concept. Wat ontbreekt er, en wat zou een vaste checklist voor deze sectie voortaan moeten dekken?
”Zodra zo'n checklist bestaat, is het de moeite waard de relevante sectie van elke nieuwe PRD er vóór de eerste review tegenaan te houden, in plaats van op het geheugen te vertrouwen om elke keer hetzelfde terugkerende gat te vangen.
Hier is de rechtenchecklist die we de vorige keer bouwden, en hier is de rechtensectie van een nieuwe PRD. Toets haar aan de checklist en markeer alles wat de checklist dekt en wat dit concept nog mist.
”Lees verder
- Een PRD schrijven vanuit een functieverzoek van één regel: de structuur vanaf het begin goed krijgen, vóór de review-en-herstelronde die dit artikel behandelt.
- Supporttickets omzetten in geprioriteerde thema's: waar de randgevallen die een PRD moet dekken in de eerste plaats vaak vandaan komen.
- Aan de slag met Claude: de onderliggende gewoonten, context, iteratie, specificiteit, waarop dit hele proces is gebouwd.