Stamattina hai aperto una pagina Notion intitolata "PRD: [nome feature]". Tre ore dopo, c'è ancora scritto solo "PRD: [nome feature]".
Conosci il problema. Conosci la soluzione. Ieri l'hai spiegata due volte al tuo tech lead. Ma nel momento in cui ti siedi per metterla nero su bianco, ti blocchi.
Non è un problema di pensiero. È un problema di scrittura.
I PM non sono pagati per digitare. Sei pagato per decidere cosa costruire e perché. Il PRD è solo l'artefatto che cristallizza la decisione, in modo che engineering, design e leadership possano agire. Da qualche parte, tra il sapere cosa scrivere e finire il documento, spariscono ore.
Esiste una strada più rapida. Il PRD è uno dei documenti più adatti alla voce che un PM scriva. In sostanza, è quello che diresti davanti a una lavagna mentre spieghi la feature. Quando smetti di digitarli e inizi a dettarli, il tempo di stesura crolla.
La tassa nascosta sulla scrittura del PM
Ogni PRD che scrivi compete con una riunione, una revisione di roadmap, un thread Slack con uno stakeholder. La scrittura vera avviene in finestre rubate di mezz'ora, o dopo cena.
I numeri sono spietati. Una persona media digita circa 40 parole al minuto. La stessa persona ne parla circa 150. È un divario di 3,5 volte, ancora prima di considerare gli attriti che rendono la scrittura più lenta: il backspace, la riformulazione, il rileggere tre volte una frase prima di passare oltre.
Un PRD da 1.500 parole che richiede 90 minuti di digitazione si dice in circa 25 minuti. Il pensiero è lo stesso. L'output è lo stesso. Cambia solo il meccanismo.
Perché i PRD sono perfetti per la voce
La maggior parte dei documenti punisce la dettatura perché richiede precisione: codice, tabelle, modelli finanziari. I PRD sono l'opposto. Sono documenti narrativi.
Pensa all'ultimo PRD che hai scritto. La sezione "Problema" è composta da due paragrafi che spiegano perché qualcosa conta. La "Soluzione" descrive come funziona la cosa. Le "User story" sono frasi nel formato "Come X, voglio Y, in modo da Z". La sezione "Casi limite" è un elenco di scenari "cosa succede quando...".
Niente di tutto questo richiede precisione di tastiera. È tutto materiale che diresti in una riunione. Il formato corrisponde già al modo in cui un PM comunica davvero il lavoro.
Il workflow per una bozza di PRD in 30 minuti
Ecco la struttura che funziona: 1. Apri un documento vuoto con i titoli delle sezioni già pronti: problema, soluzione, user story, criteri di accettazione, casi limite, fuori scope, domande aperte. 2. Vai sezione per sezione. Detta ognuna come se la stessi spiegando a un nuovo ingegnere appena entrato nel team. 3. Non editare mentre parli. Lo switch mentale tra "oratore" ed "editor" è ciò che ti rallenta di più. 4. Dopo aver dettato tutte le sezioni, leggi l'intera bozza una volta, dall'inizio alla fine. Stringi il linguaggio. Correggi tutto ciò che è davvero sbagliato. 5. Mandala in revisione.
La disciplina sta nel punto tre. Se ti fermi continuamente per sistemare le frasi, perdi il vantaggio di velocità. Sei di nuovo alla velocità della tastiera, solo con un altro costume addosso.
Sezione per sezione: come dettare ogni parte di un PRD
Alcune sezioni sono più facili da dettare di altre. Ecco come affrontarle una per una.
Descrizione del problema
È la sezione più semplice da dettare. Pura narrativa. Stai spiegando cosa è rotto, per chi è rotto e perché conta adesso.
Parla come faresti per dare un briefing a un nuovo collega allo standup. Cita il segmento di utenti, l'attrito che incontrano, la metrica che tocca. Non preoccuparti dell'eleganza della prosa. Quello è lavoro dell'editing.
Panoramica della soluzione
Racconta la soluzione proposta come se la stessi disegnando su una lavagna. "L'utente clicca qui, vede questo e poi...". La voce gestisce tutto questo in modo fluido, perché ricalca esattamente il modo in cui lo spiegheresti a voce.
User story
Le user story sembrano meccaniche per via del pattern "Come X, voglio Y, in modo da Z", ma si dettano bene se ti impegni a rispettare il formato. Pronuncia ogni story come un'unica frase, poi passa alla successiva.
Se ne hai dieci, dettale tutte e dieci in un'unica sequenza. Non numerarle mentre vai avanti. Lascia che sia l'editor del documento o un passaggio di pulizia con l'AI a gestire la formattazione.
Criteri di accettazione
Gli elenchi sono la parte più scivolosa della dettatura, ma sono gestibili. Due approcci:
Il primo è dettare i criteri come frasi complete e lasciare che l'AI di pulizia li converta in un elenco. Dì qualcosa tipo: "L'utente deve poter filtrare i risultati per data, per utente e per stato. Lo stato del filtro deve persistere tra le sessioni. Lo stato vuoto deve mostrare un suggerimento".
Il secondo è esplicitare a voce la struttura a elenco: "Punto uno, filtro per data. Punto due, filtro per utente. Punto tre, persistenza tra le sessioni". Scegli quello che ti viene meno innaturale da pronunciare.
Casi limite
È qui che la voce dà il meglio di sé. I casi limite sono quel tipo di ragionamento ad alta voce che esce pulito quando parli e impacciato quando lo digiti. Domande come "cosa succede se l'utente è offline" o "e nei casi in cui i dati sono obsoleti" fluiscono molto più naturalmente parlate che scritte.
Detta ogni caso limite che ti viene in mente, anche quelli che sembrano ovvi. In fase di editing potrai sempre tagliare.
Fuori scope
Tre frasi. Quattro al massimo. A voce la chiudi in meno di un minuto.
Domande aperte
È una sezione sottovalutata. La maggior parte dei PM la salta perché non vuole sembrare insicura. Sbagliato. La sezione delle domande aperte è il posto in cui engineering, design e il tuo skip-level intercettano le cose che non hai ancora messo a fuoco.
La voce è lo strumento giusto. Le domande aperte sono esattamente quei pensieri a metà che vengono fuori bene quando parli e diventano stranamente pesanti quando provi a scriverli. Detta a voce ogni incertezza, anche quelle che pensi abbiano una risposta scontata. Metà si risolveranno al prossimo standup. L'altra metà salverà il tuo lancio.
Adattare il tono alla sezione
Un PRD non è scritto in un'unica voce. Il riassunto per il management in apertura deve essere asciutto e strategico. Le specifiche tecniche devono essere precise. La sezione "domande aperte" può essere più informale.
Quando detti, cambi naturalmente registro. La voce diventa formale quando parli di strategia e si scioglie quando ragioni sui casi limite. Il problema è che la maggior parte dei tool di dettatura restituisce sempre la stessa trascrizione piatta, indipendentemente dal contesto.
È esattamente qui che entrano in gioco le Smart Rules di Voicr. Puoi impostare uno stile "specifica professionale pulita" per il tuo editor di documenti, uno stile "brainstorming informale" per i thread Slack e uno stile "chiarezza tecnica" per il wiki di engineering. Voicr rileva l'app attiva e applica automaticamente lo stile giusto, così lo stesso pensiero parlato atterra in modo diverso a seconda di dove finisce.
Per i PRD nello specifico, crea una regola che chieda una prosa professionale pulita, rimuova le parole riempitive e strutturi gli elenchi puntati dove glielo segnali. Parli una volta sola. Il documento si legge come se l'avessi scritto con cura.
Dove la voce non aiuta
Diciamolo onestamente: non ogni parte di un PRD beneficia della voce.
Tabelle e matrici restano più rapide da digitare. Se il tuo PRD include una griglia di confronto tra feature, una matrice di permessi o una tabella di stime di sizing, scrivile a tastiera.
Anche le stringhe tecniche precise sono più rapide a tastiera. Nomi di endpoint API, nomi di colonne di database, numeri di versione: puoi dettarle aggirandole ("l'endpoint è, slash, users, slash, ID"), ma è macchinoso. Scrivile.
I diagrammi, ovviamente, non si dettano. Disegnali nello strumento che preferisci e incorporali.
Per tutto il resto — narrazione, user story, casi limite, decisioni, motivazioni — la voce vince sulla velocità, e sul fatto che non resti impantanato a metà frase mentre cerchi la formulazione perfetta.
Il cambio di mentalità: pensa ad alta voce, edita dopo
Il vantaggio più grande del dettare i PRD non è la matematica delle parole al minuto. È che smetti di lucidare mentre scrivi.
Quando digiti, premi backspace. Riscrivi una frase due volte. Fissi per dieci minuti un paragrafo che è "quasi giusto". È lì che muoiono i PRD: nel limbo tra stesura ed editing, dove né l'uno né l'altro succedono per davvero.
Quando detti, ti impegni. Pronunci una frase, atterra sulla pagina e vai avanti. Il primo passaggio è più disordinato di quello che digiteresti. Ma la bozza la finisci. E una bozza finita e disordinata è enormemente più utile di una bozza lucidata e mai chiusa.
Una volta che la bozza esiste, l'editing è un'attività diversa e molto più veloce. Spesso passerai più tempo a rifinire che a dettare, ed è giusto così. Rifinire un documento completo è un mestiere noto. Fissare un foglio bianco non lo è.
Provalo sul tuo prossimo PRD
Scegli un PRD che stai rimandando. Apri il documento, metti a posto i titoli delle sezioni e detta dall'inizio alla fine senza editare. Imposta un timer da 25 minuti. Guarda cosa ne esce.
La prima volta ti sembrerà strano. Avrai paura che il risultato non sia abbastanza buono. Resisti all'impulso di sistemare le cose mentre vai avanti. Limítati a finire.
Se vuoi che la dettatura esca così pulita da richiedere quasi zero editing, Voicr gestisce la rifinitura in automatico. Tieni premuto FN da qualsiasi punto del tuo Mac, parla di una sezione, rilascia e incolla il testo già ripulito nel documento. Rimuove le parole riempitive, sistema la grammatica e struttura i tuoi pensieri prima che arrivino agli appunti. La bozza di PRD che prima richiedeva un pomeriggio ora si chiude in un'unica seduta.
I tuoi PRD non si scriveranno da soli. Ma non devono nemmeno essere digitati.