Du åbnede en Notion-side i morges med titlen "PRD: [feature-navn]." Tre timer senere står der stadig "PRD: [feature-navn]."
Du kender problemet. Du kender løsningen. Du gennemgik den med din engineering lead to gange i går. Men i samme øjeblik du sætter dig for at skrive den ned, går det i stå.
Det er ikke et tankeproblem. Det er et taste-problem.
Produktchefer er ikke betalt for at taste. Du er betalt for at træffe beslutninger om hvad der skal bygges og hvorfor. PRD'en er bare det artefakt, der indfanger beslutningen, så engineering, design og ledelsen kan handle på den. Et sted mellem at vide hvad du vil skrive og at færdiggøre dokumentet forsvinder timerne.
Der findes en hurtigere vej. PRD'en er et af de mest stemme-egnede dokumenter, en produktchef skriver. Det er stort set det, du ville sige stående ved et whiteboard og forklare feature'en. I det øjeblik du holder op med at taste PRD'er og begynder at diktere dem, falder din udkast-tid.
Den skrive-skat på produktchefer, som ingen taler om
Hver PRD du skriver konkurrerer med et møde, en roadmap-gennemgang, en stakeholder-tråd i Slack. Selve skrivearbejdet sker i stjålne halvtimes-vinduer eller efter aftensmaden.
Regnestykket er brutalt. En gennemsnitlig person taster omkring 40 ord i minuttet. En gennemsnitlig person taler omkring 150. Det er groft sagt en faktor 3,5 før du tæller al den friktion med, der gør det at skrive sværere: backspace, omformulering, at gætte tre gange på en sætning før du går videre.
En PRD på 1.500 ord, der tager 90 minutter at taste, tager omkring 25 minutter at tale ind. Tænkningen er den samme. Resultatet er det samme. Kun mekanismen ændrer sig.
Hvorfor PRD'er er perfekt formet til stemme
De fleste dokumenter straffer diktering, fordi de kræver præcision: kode, tabeller, finansielle modeller. PRD'er er det modsatte. De er narrative dokumenter.
Tænk på den sidste PRD, du skrev. "Problem"-afsnittet er to afsnit, der forklarer hvorfor noget betyder noget. "Løsningen" er en beskrivelse af hvordan tingen virker. "User stories" er sætninger i formatet "Som X vil jeg Y, så Z." "Edge cases"-afsnittet er en liste over "hvad sker der når..."-scenarier.
Intet af det kræver præcision på tastaturet. Det hele er den slags ting, du ville sige på et møde. Formatet matcher allerede den måde, en produktchef faktisk kommunikerer arbejdet på.
Workflow til en PRD-kladde på 30 minutter
Her er strukturen, der virker: 1. Hav et tomt dokument klar med afsnitsoverskrifter på plads: problem, løsning, user stories, acceptkriterier, edge cases, out of scope, åbne spørgsmål. 2. Gå afsnit for afsnit. Diktér hvert af dem, som om du forklarede det til en ny engineer, der lige er kommet til teamet. 3. Redigér ikke mens du taler. Det mentale skift mellem "taler" og "redaktør" er det, der bremser dig mest. 4. Når du har dikteret alle afsnit, læs hele kladden igennem en gang, fra top til bund. Stram sproget. Ret det, der reelt er galt. 5. Send til gennemsyn.
Disciplinen ligger i punkt tre. Hvis du hele tiden stopper for at rette sætninger, får du ikke fart-fordelen. Så er du tilbage på taste-hastighed i en anden forklædning.
Afsnit for afsnit: sådan dikterer du hver del af en PRD
Nogle afsnit er nemmere at diktere end andre. Sådan griber du hvert af dem an.
Problemformulering
Dette er det nemmeste afsnit at diktere. Ren fortælling. Du forklarer hvad der er gået i stykker, for hvem det er gået i stykker, og hvorfor det betyder noget nu.
Sig det, som du ville briefe en ny kollega ved stand-up. Nævn brugersegmentet, friktionen de møder, det metric det rører ved. Pas ikke på prosaens elegance. Det er redigeringens job.
Løsningsoverblik
Gå den foreslåede løsning igennem, som om du skitserede den på et whiteboard. "Brugeren klikker her, ser dette, og så..." Stemme klarer det her flydende, fordi det matcher den måde, du allerede ville forklare det på højt.
User stories
User stories lyder mekaniske på grund af "Som X vil jeg Y, så Z"-mønstret, men de dikterer godt, hvis du forpligter dig til formatet. Sig hver story som én sætning, og gå videre til den næste.
Hvis du har ti stories, så diktér alle ti i én ombæring. Nummerér dem ikke undervejs. Lad dokument-editoren eller dit AI-cleanup-pass tage sig af formateringen.
Acceptkriterier
Lister er den vanskeligste del af stemmediktering, men det er gørligt. To tilgange:
Den første er at diktere kriterier som hele sætninger og lade AI'en polere dem om til en liste. Sig noget i stil med: "Brugeren skal kunne filtrere resultater efter dato, efter bruger og efter status. Filterstatus skal bevares på tværs af sessioner. Den tomme tilstand skal vise et tip."
Den anden er eksplicit at sige bullet-strukturen: "Bullet et, filtrér efter dato. Bullet to, filtrér efter bruger. Bullet tre, bevar på tværs af sessioner." Vælg det, der føles mindst akavet i din mund.
Edge cases
Det er her stemmen virkelig skinner. Edge cases er den slags højttænknings-indhold, der kommer rent ud, når du taler, og klodset ud, når du taster. Spørgsmål som "hvad sker der, hvis brugeren er offline" eller "hvad med tilfælde, hvor dataene er forældede" flyder mere naturligt i tale end på skrift.
Diktér alle de edge cases, du kan komme i tanke om, også dem der virker åbenlyse. Du kan altid skære fra i redigeringen.
Out of scope
Tre sætninger. Måske fire. Stemme klarer dette på under et minut.
Åbne spørgsmål
Dette afsnit er undervurderet. De fleste produktchefer springer det over, fordi de ikke vil virke usikre. Lad være. Afsnittet med åbne spørgsmål er der, hvor engineering, design og din skip-level fanger de ting, du ikke har tænkt igennem endnu.
Stemme er det rigtige værktøj til det. Åbne spørgsmål er præcis de halvfærdige tanker, der kommer fint ud, når du taler, og føles mærkeligt tunge, når du forsøger at taste dem. Diktér hver eneste usikkerhed højt, også dem du har mistanke om har åbenlyse svar. Halvdelen vil løse sig selv ved næste standup. Den anden halvdel vil redde din launch.
Tilpas tonen til afsnittet
En PRD er ikke skrevet i én stemme. Exec-resuméet i toppen skal være stramt og strategisk. De tekniske specifikationer skal være præcise. Afsnittet med "åbne spørgsmål" må gerne være mere uformelt.
Når du dikterer, skifter du naturligt register. Din stemme bliver formel, når du taler om strategi, og løsere, når du går edge cases igennem. Problemet er, at de fleste dikteringsværktøjer udskriver den samme flade transskription uanset kontekst.
Det er præcis her, Voicrs Smart Rules kommer ind. Du kan sætte en "ren professionel spec"-stil for din dokument-editor, en "casual brainstorming"-stil for dine Slack-tråde og en "teknisk klarhed"-stil for din engineering-wiki. Voicr registrerer den aktive app og anvender den rigtige stil automatisk, så den samme tanke lander forskelligt afhængigt af, hvor den ender.
Specifikt for PRD'er: sæt en regel op, der beder om ren professionel prosa, fjerner fyldord og strukturerer bullet-lister, hvor du markerer dem. Du taler én gang. Dokumentet læses, som havde du skrevet det omhyggeligt.
Hvor stemme ikke hjælper
Ærlig melding: ikke alle dele af en PRD har gavn af stemme.
Tabeller og matricer er stadig hurtigere at taste. Hvis din PRD indeholder et feature-sammenligningsgitter, en rettighedsmatrix eller en sizing-tabel, så tast den.
Eksakte tekniske strenge er også hurtigere at taste. API-endpoint-navne, kolonnenavne i databaser, versionsnumre — du kan godt diktere omkring dem ("endpointet er, skråstreg, users, skråstreg, ID"), men det er akavet. Tast dem.
Diagrammer kan åbenlyst ikke dikteres. Skitsér dem i dit foretrukne værktøj og indlejr dem.
For alt det andet — fortælling, user stories, edge cases, beslutninger, rationale — vinder stemmen på hastighed, og på at du ikke sidder fast midt i en sætning og prøver at formulere noget perfekt.
Mindset-skiftet: tænk højt, redigér bagefter
Den største gevinst ved at diktere PRD'er er ikke WPM-regnestykket. Det er, at du holder op med at polere imens du skriver.
Når du taster, sletter du. Du omskriver en sætning to gange. Du stirrer på et afsnit, der er "næsten rigtigt" i ti minutter. Det er der, PRD'er går hen for at dø: i mellemrummet mellem udkast og redigering, hvor ingen af delene rigtig sker.
Når du dikterer, forpligter du dig. Du siger en sætning, den lander på siden, og du går videre. Det første gennemløb er rodet sammenlignet med det, du ville taste. Men du gør kladden færdig. Og en rodet færdig kladde er drastisk mere brugbar end en poleret ufærdig en.
Når kladden først eksisterer, er redigering en helt anden og meget hurtigere aktivitet. Du vil ofte bruge mere tid på at finpudse end på at diktere, og det er fint. At finpudse et færdigt dokument er et kendt job. At stirre på et tomt et er ikke.
Prøv det på din næste PRD
Vælg en PRD, du har udskudt. Åbn dokumentet, sæt afsnitsoverskrifterne på plads, og diktér fra top til bund uden at redigere. Stil et ur på 25 minutter. Se hvad du får.
Første gang du gør det, vil det føles mærkeligt. Du vil bekymre dig om, at resultatet ikke er godt nok. Modstå trangen til at rette undervejs. Bare gør det færdigt.
Vil du have, at dikteringen kommer ud så ren, at du knap behøver redigere, klarer Voicr poleringen automatisk. Hold FN nede hvor som helst på din Mac, tal et afsnit igennem, slip, og sæt den oprydde tekst ind i dit dokument. Den fjerner fyldord, retter grammatikken og strukturerer dine tanker, før de rammer dit clipboard. Den PRD-kladde, der plejede at tage en eftermiddag, tager nu én sætning.
Dine PRD'er kommer ikke til at skrive sig selv. Men de behøver heller ikke at blive tastet.