Du öppnade en Notion-sida i morse med rubriken "PRD: [funktionsnamn]." Tre timmar senare står det fortfarande "PRD: [funktionsnamn]."
Du känner till problemet. Du har lösningen klar. Du gick igenom den med din tekniska lead två gånger i går. Men i samma stund du sätter dig ner för att skriva, går det i stå.
Det är inte ett tankeproblem. Det är ett skrivproblem.
Produktchefer får inte betalt för att skriva. Du får betalt för att avgöra vad som ska byggas och varför. PRD:n är bara det dokument som fångar beslutet så att utvecklare, designers och ledning kan agera på det. Någonstans mellan att veta vad du ska skriva och att bli klar med dokumentet försvinner timmarna.
Det finns en snabbare väg. PRD:n är ett av de mest röstvänliga dokument en produktchef skriver. Det är i princip det du skulle säga framför en whiteboard när du förklarar funktionen. När du slutar skriva PRD:er på tangentbordet och börjar diktera dem rasar utkastdtiden.
Skrivskatten som ingen pratar om
Varje PRD du skriver konkurrerar med ett möte, en roadmap-genomgång och en Slack-tråd med en intressent. Själva skrivandet sker i tjuvade halvtimmar eller efter middagen.
Matematiken är brutal. En genomsnittlig person skriver cirka 40 ord per minut på tangentbordet. En genomsnittlig person talar runt 150. Det är ungefär 3,5 gångers skillnad innan du ens räknar in friktionen som gör skrivandet svårare: backsteg, omformuleringar och att tveka över samma mening tre gånger innan du går vidare.
En PRD på 1 500 ord som tar 90 minuter att skriva tar cirka 25 minuter att tala in. Tänkandet är detsamma. Resultatet är detsamma. Bara mekaniken förändras.
Därför är PRD:er perfekt formade för rösten
De flesta dokument straffar diktering eftersom de kräver precision: kod, tabeller, finansiella modeller. PRD:er är raka motsatsen. De är berättande dokument.
Tänk på den senaste PRD:n du skrev. Avsnittet "Problem" är två stycken som förklarar varför något spelar roll. "Lösningen" är en beskrivning av hur saken fungerar. "User stories" är meningar i formatet "Som en X vill jag Y, så att Z." Avsnittet "Gränsfall" är en lista av "vad händer när..."-scenarier.
Inget av det kräver tangentbordsprecision. Allt är sådant du skulle säga i ett möte. Formatet matchar redan hur en produktchef faktiskt kommunicerar arbetet.
Arbetsflödet för ett PRD-utkast på 30 minuter
Så här ser strukturen ut som fungerar: 1. Öppna ett tomt dokument med avsnittsrubrikerna på plats: problem, lösning, user stories, acceptanskriterier, gränsfall, utanför scope, öppna frågor. 2. Gå avsnitt för avsnitt. Diktera varje del som om du förklarar den för en ny utvecklare i teamet. 3. Redigera inte medan du talar. Den mentala växlingen mellan "talare" och "redaktör" är det som bromsar dig mest. 4. När alla avsnitt är dikterade, läs hela utkastet en gång uppifrån och ned. Stram åt språket. Fixa det som är faktiskt fel. 5. Skicka för granskning.
Disciplinen ligger i steg tre. Om du stannar för att fixa meningar längs vägen får du inte hastighetsvinsten. Då är du tillbaka på tangentbordstempo i ny förklädnad.
Avsnitt för avsnitt: så dikterar du varje del av en PRD
Vissa avsnitt är enklare att diktera än andra. Så här angriper du varje del.
Problembeskrivning
Det här är det enklaste avsnittet att diktera. Ren berättelse. Du förklarar vad som är trasigt, för vem det är trasigt och varför det är viktigt nu.
Säg det som om du briefar en ny kollega på stand-up. Nämn användarsegmentet, friktionen de stöter på och måttet det berör. Bry dig inte om språklig elegans. Det är redigeringens jobb.
Lösningsöversikt
Gå igenom den föreslagna lösningen som om du skissar den på en whiteboard. "Användaren klickar här, ser det här, och sedan..." Rösten hanterar det här flytande eftersom det matchar hur du redan skulle förklara det högt.
User stories
User stories låter mekaniska på grund av mönstret "Som en X vill jag Y, så att Z", men de fungerar bra att diktera om du håller dig till formatet. Säg varje story som en mening och gå sedan vidare till nästa.
Om du har tio stories – diktera alla tio i ett svep. Numrera dem inte medan du går. Låt dokumentredigeraren eller en AI-städning sköta formateringen.
Acceptanskriterier
Listor är den knepigaste delen av röstdiktering, men det är fullt görbart. Två angreppssätt:
Det första är att diktera kriterierna som hela meningar och låta AI-städningen göra om dem till en lista. Säg något i stil med: "Användaren ska kunna filtrera resultat efter datum, efter användare och efter status. Filterläget ska sparas mellan sessioner. Tomtillståndet ska visa ett tips."
Det andra är att uttryckligen tala punktstrukturen: "Punkt ett, filtrera efter datum. Punkt två, filtrera efter användare. Punkt tre, behåll mellan sessioner." Välj det som känns minst klumpigt i munnen.
Gränsfall
Det är här rösten verkligen briljerar. Gränsfall är precis den sorts tänka-högt-innehåll som blir prydligt när du pratar och klumpigt när du skriver. Frågor som "vad händer om användaren är offline" eller "vad gäller fall där datan är gammal" flyter mer naturligt i tal än i skrift.
Diktera varje gränsfall du kan komma på, även de som verkar självklara. Du kan rensa bort i redigeringen.
Utanför scope
Tre meningar. Kanske fyra. Rösten klarar det här på under en minut.
Öppna frågor
Det här avsnittet är underskattat. De flesta produktchefer hoppar över det för att de inte vill se osäkra ut. Låt bli. Avsnittet öppna frågor är där utveckling, design och din skip-level fångar upp det du inte hunnit tänka igenom än.
Rösten är rätt verktyg för det. Öppna frågor är precis de halvfärdiga tankarna som kommer ut fint när du pratar och känns konstigt tungrodda när du försöker skriva ner dem. Diktera varje tvivel högt, även de du misstänker har självklara svar. Hälften kommer att lösa sig på nästa standup. Den andra hälften räddar din lansering.
Matcha tonen till avsnittet
En PRD skrivs inte i ett enda tonläge. Sammanfattningen högst upp ska vara stram och strategisk. De tekniska specifikationerna ska vara precisa. Avsnittet "öppna frågor" får vara mer avslappnat.
När du dikterar växlar du naturligt mellan register. Rösten blir formell när du pratar strategi och lösare när du går igenom gränsfall. Problemet är att de flesta dikteringsverktyg spottar ur sig samma platta transkription oavsett kontext.
Det är precis här Voicrs Smart Rules kommer in. Du kan ställa in en "ren professionell spec"-stil för din dokumentredigerare, en "avslappnad brainstorming"-stil för dina Slack-trådar och en "teknisk tydlighet"-stil för din engineering-wiki. Voicr känner av den aktiva appen och tillämpar rätt stil automatiskt, så att samma utsagda tanke landar olika beroende på var den hamnar.
Specifikt för PRD:er: sätt upp en regel som ber om ren professionell prosa, tar bort utfyllnadsord och strukturerar punktlistor där du signalerar dem. Du säger det en gång. Dokumentet läses som om du skrivit det omsorgsfullt.
Där rösten inte hjälper
Ärlig avstämning: inte varje del av en PRD vinner på rösten.
Tabeller och matriser går fortfarande snabbare att skriva. Om din PRD innehåller en jämförelsetabell, en behörighetsmatris eller en estimeringstabell – skriv den.
Exakta tekniska strängar går också snabbare att skriva. API-endpoint-namn, kolumnnamn i databasen, versionsnummer – du kan diktera runt dem ("endpointen är, slash, users, slash, ID") men det blir knöligt. Skriv dem.
Diagram går uppenbarligen inte att diktera. Skissa dem i ditt verktyg och bädda in.
För allt annat – berättelse, user stories, gränsfall, beslut, motivering – vinner rösten på tempo, plus att du inte fastnar mitt i en mening i jakten på den perfekta formuleringen.
Mentaliteten: tänk högt, redigera sedan
Den största vinsten med att diktera PRD:er är inte matematiken kring ord per minut. Det är att du slutar polera medan du skriver.
När du skriver backar du. Du gör om en mening två gånger. Du stirrar på ett stycke som är "nästan rätt" i tio minuter. Det är där PRD:er går och dör: i glappet mellan utkast och redigering, där ingetdera blir riktigt klart.
När du dikterar bestämmer du dig. Du säger en mening, den landar på sidan och du går vidare. Det första utkastet blir rörigare än det du skulle skriva. Men du blir klar. Och ett rörigt färdigt utkast är dramatiskt mycket mer användbart än ett polerat ofärdigt.
När utkastet väl finns är redigering en helt annan och mycket snabbare aktivitet. Du kommer ofta lägga mer tid på att slipa än på att diktera, och det är okej. Att slipa ett komplett dokument är ett känt jobb. Att stirra på ett tomt är inte det.
Prova på nästa PRD
Välj en PRD du har skjutit upp. Öppna dokumentet, lägg in avsnittsrubrikerna och diktera uppifrån och ned utan att redigera. Sätt en 25-minuterstimer. Se vad du får.
Första gången du gör det kommer det att kännas konstigt. Du kommer att oroa dig för att resultatet inte är bra nog. Stå emot lusten att fixa saker mitt i flödet. Bara bli klar.
Om du vill att dikteringen ska komma ut så ren att du knappt behöver redigera sköter Voicr poleringen automatiskt. Håll ner FN var som helst på din Mac, prata genom ett avsnitt, släpp, och klistra in den putsade texten i dokumentet. Det tar bort utfyllnadsord, rättar grammatik och strukturerar dina tankar innan de hamnar i urklippet. Det PRD-utkast som tidigare tog en eftermiddag tar nu en sittning.
Dina PRD:er skriver sig inte själva. Men de behöver inte heller skrivas på tangentbordet.