Vanochtend opende je een Notion-pagina met de titel "PRD: [feature naam]." Drie uur later staat er nog steeds "PRD: [feature naam]."
Je kent het probleem. Je kent de oplossing. Gisteren heb je je engineering lead er twee keer doorheen gepraat. Maar zodra je gaat zitten om het uit te werken, loop je vast.
Dit is geen denkprobleem. Het is een typprobleem.
PM's worden niet betaald om te typen. Je wordt betaald om beslissingen te nemen over wat we bouwen en waarom. De PRD is gewoon het document dat die beslissing vastlegt zodat engineering, design en leadership ermee aan de slag kunnen. Ergens tussen weten wat je wilt schrijven en het document afronden verdwijnen er uren.
Er is een snellere route. De PRD is een van de meest voice-vriendelijke documenten die een PM schrijft. Het is in feite wat je zou zeggen als je voor een whiteboard de feature zou uitleggen. Zodra je stopt met PRD's typen en begint met dicteren, daalt je drafttijd.
De verborgen schrijfbelasting van een PM
Elke PRD die je schrijft concurreert met een meeting, een roadmap-review, een Slack-draadje met stakeholders. Het echte schrijfwerk gebeurt in gestolen halfuren of na het avondeten.
De rekensom is meedogenloos. De gemiddelde persoon typt zo'n 40 woorden per minuut. De gemiddelde persoon spreekt rond de 150. Dat is grofweg een factor 3,5 verschil, nog voor je rekening houdt met alle wrijving die schrijven extra moeilijk maakt: backspacen, herformuleren, een zin drie keer betwijfelen voordat je verder gaat.
Een PRD van 1.500 woorden waar je 90 minuten over typt, spreek je in ongeveer 25 minuten in. Het denkwerk is hetzelfde. De output is hetzelfde. Alleen het mechanisme verandert.
Waarom PRD's perfect gevormd zijn voor voice
De meeste documenten straffen dicteren af omdat ze precisie vragen: code, tabellen, financiële modellen. PRD's zijn het tegenovergestelde. Het zijn narratieve documenten.
Denk aan de laatste PRD die je schreef. De "Probleem"-sectie bestaat uit twee alinea's die uitleggen waarom iets ertoe doet. De "Oplossing" is een beschrijving van hoe het werkt. De "User stories" zijn zinnen in het format "Als X wil ik Y, zodat Z." De "Edge cases"-sectie is een lijst van "wat gebeurt er als..."-scenario's.
Niets daarvan vraagt om toetsenbordprecisie. Het is precies het soort dingen dat je in een meeting zou zeggen. Het format past al bij hoe een PM het werk daadwerkelijk communiceert.
De 30-minuten PRD-draftworkflow
Dit is de structuur die werkt: 1. Open een leeg document met de sectiekoppen al op hun plek: probleem, oplossing, user stories, acceptatiecriteria, edge cases, out of scope, open vragen. 2. Werk sectie voor sectie. Dicteer elk onderdeel alsof je het uitlegt aan een nieuwe engineer die net bij het team komt. 3. Bewerk niet terwijl je praat. De mentale switch tussen "spreker" en "editor" is wat je het meest vertraagt. 4. Lees na het dicteren het volledige draft één keer door, van boven naar beneden. Scherp de taal aan. Corrigeer wat echt fout is. 5. Stuur het rond voor review.
De discipline zit in stap drie. Als je steeds stopt om zinnen te herschrijven, krijg je het snelheidsvoordeel niet. Dan ben je weer terug op typsnelheid, alleen in een ander jasje.
Sectie voor sectie: hoe je elk onderdeel van een PRD dicteert
Sommige secties laten zich makkelijker dicteren dan andere. Zo pak je elk onderdeel aan.
Probleemstelling
Dit is de makkelijkste sectie om te dicteren. Pure verhaalvorm. Je legt uit wat er kapot is, voor wie het kapot is en waarom het nú belangrijk is.
Spreek het uit zoals je een nieuwe collega zou bijpraten bij de stand-up. Noem het gebruikerssegment, de wrijving die ze ervaren, de metric die het raakt. Maak je geen zorgen om mooie volzinnen. Dat is werk voor de editfase.
Oplossing in grote lijnen
Loop door de voorgestelde oplossing alsof je hem op een whiteboard tekent. "De gebruiker klikt hier, ziet dit en daarna..." Voice handelt dit moeiteloos af, omdat het aansluit bij hoe je het sowieso hardop zou uitleggen.
User stories
User stories klinken mechanisch door het "Als X wil ik Y, zodat Z"-patroon, maar ze laten zich prima dicteren als je je aan het format houdt. Spreek elke story als één zin uit en ga dan door naar de volgende.
Heb je tien stories, dicteer ze dan allemaal in één keer. Nummer ze niet hardop. Laat de docs-editor of je AI-cleanuppass de opmaak doen.
Acceptatiecriteria
Lijsten zijn het lastigste onderdeel van voice-dicteren, maar het werkt. Twee aanpakken:
De eerste is om criteria als volzinnen te dicteren en de AI-polish het in een lijst te laten omzetten. Zeg bijvoorbeeld: "De gebruiker moet resultaten kunnen filteren op datum, op gebruiker en op status. De filterstatus moet over sessies heen behouden blijven. De lege staat moet een tip tonen."
De tweede is om de bullet-structuur expliciet uit te spreken: "Bullet één, filter op datum. Bullet twee, filter op gebruiker. Bullet drie, behouden over sessies." Kies wat het minst onhandig in je mond ligt.
Edge cases
Hier komt voice pas echt tot zijn recht. Edge cases zijn precies dat hardopdenken dat schoon op papier komt als je praat en juist krukkig wordt als je typt. Vragen als "wat gebeurt er als de gebruiker offline is" of "wat als de data verouderd is" rollen veel natuurlijker uit je mond dan uit je vingers.
Dicteer elke edge case die je kunt bedenken, ook degene die voor de hand lijken te liggen. Bij het editen kun je snoeien.
Out of scope
Drie zinnen. Hooguit vier. Voice handelt dit in minder dan een minuut af.
Open vragen
Deze sectie wordt onderschat. De meeste PM's slaan hem over omdat ze niet onzeker willen lijken. Doe dat niet. De sectie met open vragen is precies waar engineering, design en je skip-level de dingen oppikken die jij nog niet helemaal hebt doordacht.
Voice is hier het juiste gereedschap voor. Open vragen zijn precies die half gevormde gedachten die er prima uit komen als je praat, maar die verdacht zwaar voelen zodra je probeert te typen. Dicteer elke onzekerheid hardop, ook die waarvan je vermoedt dat er een duidelijk antwoord is. De helft lost zich op in de volgende stand-up. De andere helft redt je launch.
De toon op de sectie afstemmen
Een PRD is niet in één stem geschreven. De exec summary bovenaan moet strak en strategisch zijn. De technische specs moeten precies zijn. De sectie met open vragen mag losser.
Tijdens het dicteren wissel je vanzelf van register. Je stem wordt formeler bij strategie en losser bij edge cases. Het probleem is dat de meeste dictation-tools dezelfde vlakke transcriptie produceren, ongeacht de context.
Hier komen Voicr's Smart Rules om de hoek kijken. Je kunt een "strakke professionele spec"-stijl instellen voor je docs-editor, een "casual brainstorm"-stijl voor je Slack-draadjes en een "technische helderheid"-stijl voor je engineering-wiki. Voicr detecteert welke app actief is en past automatisch de juiste stijl toe, zodat dezelfde uitgesproken gedachte anders landt afhankelijk van waar hij terechtkomt.
Stel voor PRD's specifiek een regel in die vraagt om schone, professionele zinnen, stopwoorden verwijdert en bullet lists structureert waar je dat aangeeft. Je spreekt één keer. Het document leest alsof je het zorgvuldig hebt geschreven.
Waar voice níet helpt
Eerlijk is eerlijk: niet elk onderdeel van een PRD wordt beter met voice.
Tabellen en matrices typ je nog steeds sneller. Bevat je PRD een feature comparison grid, een permissions-matrix of een ingeschatte estimation-tabel, typ die dan.
Exacte technische strings zijn ook sneller getypt. API-endpoint-namen, kolomnamen van databases, versienummers — je kunt eromheen dicteren ("het endpoint is, slash, users, slash, ID") maar het is onhandig. Typ die.
Diagrammen kun je überhaupt niet dicteren. Schets ze in de tool van je keuze en embed.
Voor al het andere — narratief, user stories, edge cases, beslissingen, onderbouwing — wint voice op snelheid, en op het feit dat je niet halverwege een zin vastloopt omdat je iets perfect probeert te formuleren.
De mindset-switch: hardop denken, later bewerken
De grootste winst van het dicteren van PRD's zit niet in de WPM-rekensom. Het is dat je stopt met polijsten tijdens het schrijven.
Tijdens het typen backspace je. Je herschrijft een zin twee keer. Je staart tien minuten naar een alinea die "bijna goed" is. Daar gaan PRD's dood: in het gat tussen draften en editen, waar geen van beide echt gebeurt.
Bij dicteren commit je. Je spreekt een zin uit, hij landt op de pagina en je gaat door. De eerste versie is rommeliger dan wat je zou typen. Maar je krijgt het draft af. En een rommelig afgerond draft is dramatisch nuttiger dan een gepolijst onafgerond document.
Zodra het draft bestaat, is editen een andere en veel snellere bezigheid. Je bent vaak meer tijd kwijt aan bijschaven dan aan dicteren, en dat is prima. Een compleet document bijschaven is een bekend klusje. Starend zitten naar een leeg document niet.
Probeer het bij je volgende PRD
Pak een PRD die je voor je uit hebt geschoven. Open het document, zet de sectiekoppen klaar en dicteer van boven naar beneden zonder te editen. Zet een timer van 25 minuten. Kijk wat je krijgt.
De eerste keer voelt het raar. Je vraagt je af of de output wel goed genoeg is. Weersta de drang om dingen tussendoor te corrigeren. Maak het gewoon af.
Wil je dat het gedicteerde zo schoon binnenkomt dat je nauwelijks hoeft te editen, dan regelt Voicr het polijsten automatisch. Houd FN ingedrukt vanuit elke app op je Mac, praat een sectie in, laat los en plak de opgeschoonde tekst in je document. Stopwoorden worden eruit gehaald, grammatica wordt rechtgetrokken en je gedachten worden gestructureerd voordat ze je klembord raken. De PRD-draft waar je een hele middag mee bezig was, is nu het werk van één zitting.
Je PRD's gaan zichzelf niet schrijven. Maar ze hoeven ook niet getypt te worden.