Een PRD schrijven vanuit een eenregelig featureverzoek
5 min leestijd
De meeste PRD's beginnen hetzelfde: een leeg document en een eenregelig idee zoals "laat gebruikers hun data exporteren." Vanaf daar is het makkelijk om vrij te schrijven wat als eerste opkomt, meestal de vereisten, en drie alinea's later te ontdekken dat er nergens in het document een probleemstelling of succesmetric staat. Een PM die enthousiast is over een featureidee begint vaak met de mechanica van hoe het zou moeten werken te schrijven, de exacte velden, de exacte knopplaatsing, lang voordat hij stilstaat om op te schrijven welk probleem het daadwerkelijk oplost.
Waarschuwing
Een leeg document herinnert je niet aan welke onderdelen een PRD nodig heeft. Het weerspiegelt alleen de volgorde waarin je dingen bedacht, en dat is zelden de volgorde die een reviewer verwacht te lezen.
Een featureidee is een zin. Een PRD is een structuur. Vrij schrijven levert je de zin op, uitgebreid.
Waarom vrij schrijven onderdelen overslaat zonder dat je het merkt
Schrijven vanaf een leeg document betekent dat je de structuur onderweg uitvindt, en het is makkelijk om de onderdelen te schrijven die voor de hand liggen, meestal de vereisten, en de onderdelen over te slaan die meer denkwerk vergen, zoals het echte probleem benoemen of een metric kiezen die bewijst dat de feature werkte. De sectie met vereisten is concreet en bevredigend om te schrijven, omdat het een lijst specifieke, controleerbare dingen is. De probleemstelling vereist een stap terug en onder woorden brengen waarom een van dat alles ertoe doet, wat een ander, moeilijker soort denkwerk is, en dat is het onderdeel dat het eerst wordt overgeslagen onder tijdsdruk.
Neem een eenregelig idee zoals "laat gebruikers hun data als CSV exporteren." Een PM die enthousiast is over het idee besteedt misschien twintig minuten aan precies uitwerken welke velden de export moet bevatten en wat de knop moet zeggen, en merkt pas bij het versturen van het document voor review dat er nergens een zin staat die uitlegt waarom dit ertoe doet, dat support al maandenlang handmatige exportverzoeken binnenkrijgt. Een reviewer die dat document opent, heeft geen manier om te beoordelen of de voorgestelde vereisten het echte probleem daadwerkelijk oplossen, omdat het echte probleem nooit werd opgeschreven.
Voor: open een leeg document, begin vereisten te schrijven voor het featureidee, merk later dat de probleemstelling en succesmetrics ontbreken.
Na: geef Claude het eenregelige idee en het probleem dat het oplost, en krijg een gestructureerd eerste concept terug, probleem, doelen, vereisten en metrics, met elk onderdeel al aanwezig om te verfijnen.
Een werkwijze voor een gestructureerd eerste concept
- 1
Benoem het featureidee en het probleem dat het oplost
Eén zin voor elk is genoeg om te beginnen. "Laat gebruikers hun data als CSV exporteren, omdat support er steeds handmatig naar gevraagd wordt" geeft Claude zowel het wat als het waarom.
- 2
Vraag om een vaste structuur, niet een open concept
Vraag specifiek om een probleemstelling, een klein aantal doelen, functionele vereisten en succesmetrics, in die volgorde. Een vaste structuur is wat het concept beoordeelbaar maakt in plaats van een essay.
- 3
Geef een echt getal voor doelen en metrics
Vraag om een specifiek aantal, drie doelen, twee metrics, in plaats van "wat doelen". Een getal dwingt prioritering af in plaats van een open lijst die blijft groeien.
- 4
Behandel het concept als een startstructuur, niet een definitief document
Lees het terug en herschrijf elk onderdeel in je eigen stem. De waarde van het eerste concept is dat niets ontbreekt, niet dat de formulering definitief is.
We willen gebruikers hun data als CSV laten exporteren. Stel een eenpagina-PRD op met een probleemstelling, drie doelen, functionele vereisten, en twee succesmetrics die we de eerste 30 dagen zouden kunnen volgen.
”Als het featureidee ontstond uit een specifieke, bekende bron, een cluster supporttickets, een klantverzoek, een concurrentiekloof, is het de moeite waard om dat expliciet aan Claude te vertellen, omdat een probleemstelling geworteld in een echte, benoemde bron veel geloofwaardiger leest voor een reviewer dan een plausibel klinkende maar generieke.
Dit idee kwam rechtstreeks uit 15 supporttickets van de afgelopen maand, allemaal met de vraag om hun data eruit te krijgen zonder contact met support. Herschrijf de probleemstelling zodat die specifiek naar die echte bron verwijst, niet een generieke omschrijving van de behoefte.
”
In Claude Tutorial
Starten vanuit een vaste structuur in plaats van een leeg document is overdraagbaar.
Werken vanuit een bekende set onderdelen, in plaats van structuur uitvinden terwijl je schrijft, gaat breder dan PRD's. De app heeft hier een volledige les over, met oefeningen die overgaan op elk document met een vorm die reviewers verwachten.
Wanneer de doelen niet bij de metrics passen
Een veelvoorkomende gat in een eerste concept is een doel zonder bijbehorende metric, of een metric die niet daadwerkelijk bewijst dat het gestelde doel gebeurde. Die mismatch is de moeite waard om te vangen voordat het document de deur uitgaat, niet nadat iemand vraagt hoe je zal weten dat de feature werkte. Een doel als "verminder de supportdruk" gekoppeld aan een metric als "aantal uitgevoerde exports" klinkt verwant maar bewijst het doel niet echt, omdat gebruikers voortdurend kunnen exporteren zonder dat één supportticket wordt voorkomen.
Tip
Vraag Claude elk doel rechtstreeks tegen zijn metric te checken: bewijst het halen van dit getal daadwerkelijk het doel, of iets wat er alleen mee samenhangt? Een metric die makkelijk te meten is, is niet automatisch de juiste.
Hier zijn de drie doelen en twee metrics uit dit PRD-concept. Zeg voor elk doel eerlijk of de metrics daadwerkelijk bewijzen dat het gebeurde, of alleen iets ernaast meten.
”Als een metric achteraf echt moeilijk te volgen blijkt met bestaande tooling, is het de moeite waard die beperking vroeg aan het licht te brengen, in plaats van een PRD te lanceren met een succesmetric die niemand daadwerkelijk kan meten zodra de feature live is.
Een van deze metrics zou tracking vereisen die we momenteel niet hebben. Stel een metric voor die hetzelfde doel bewijst maar realistisch te meten is met onze bestaande analyticsopstelling.
”Lees verder
- Een PRD Aanscherpen Voordat je hem Verstuurt voor Review: het gestructureerde concept dat dit artikel oplevert testen voordat het een reviewer bereikt.
- Een Roadmapdocument Schrijven dat de Trade-offs Uitlegt: wat er gebeurt zodra dit featureidee moet concurreren met andere voor een plek op de roadmap.
- Supporttickets Omzetten in Geprioriteerde Thema's: een bron van echte featureideeën om in de eerste plaats PRD's van te schrijven.