Scrivere un PRD da una richiesta di funzionalità in una riga
6 min di lettura
La maggior parte dei PRD inizia nello stesso modo: un documento vuoto e un'idea in una riga come "lascia che gli utenti esportino i loro dati". Da lì è facile scrivere liberamente tutto ciò che viene in mente prima, di solito i requisiti, e rendersi conto dopo tre paragrafi che non c'è da nessuna parte nel documento una dichiarazione del problema o una metrica di successo. Un PM entusiasta di un'idea di funzionalità tende a iniziare a scrivere la meccanica di come dovrebbe funzionare, i campi esatti, il posizionamento esatto del bottone, molto prima di fermarsi a scrivere quale problema stia davvero risolvendo.
Attenzione
Un documento vuoto non ti ricorda quali sezioni servono a un PRD. Riflette solo l'ordine in cui ti sono venute in mente le cose, che raramente è l'ordine in cui un revisore si aspetta di leggerle.
Un'idea di funzionalità è una frase. Un PRD è una struttura. Scrivere liberamente ti dà solo la frase, ampliata.
Perché scrivere liberamente salta sezioni senza che te ne accorga
Scrivere da una pagina vuota significa inventare la struttura man mano, ed è facile scrivere le parti che sembrano ovvie, di solito i requisiti, saltando le parti che richiedono più riflessione, come nominare il problema reale o scegliere una metrica che dimostri che la funzionalità ha funzionato. La sezione dei requisiti è concreta e gratificante da scrivere, perché è un elenco di cose specifiche e verificabili. La dichiarazione del problema richiede di fare un passo indietro e articolare perché tutto questo conti, un tipo di pensiero diverso e più difficile, ed è la parte che viene saltata prima sotto pressione di tempo.
Prendi un'idea in una riga come "lascia che gli utenti esportino i loro dati come CSV". Un PM entusiasta dell'idea potrebbe passare venti minuti a dettagliare esattamente quali campi includere nell'esportazione e cosa dovrebbe dire il bottone, e rendersi conto solo mentre invia il documento per la revisione che non c'è da nessuna parte una frase che spieghi perché questo conta, che il supporto gestisce manualmente richieste di esportazione da mesi. Un revisore che apre quel documento non ha modo di giudicare se i requisiti proposti risolvano davvero il problema reale, perché il problema reale non è stato mai scritto.
Prima: apri un documento vuoto, inizia a scrivere i requisiti per l'idea di funzionalità, scopri più tardi che manca la dichiarazione del problema e le metriche di successo.
Dopo: dai a Claude l'idea in una riga e il problema che risolve, e ottieni una prima bozza strutturata, problema, obiettivi, requisiti e metriche, con ogni sezione già al suo posto da perfezionare.
Un processo per una prima bozza strutturata
- 1
Dichiara l'idea di funzionalità e il problema che risolve
Una frase per ciascuno basta per iniziare. "Lascia che gli utenti esportino i loro dati come CSV, perché il supporto continua a riceverne richieste manuali" dà a Claude sia il cosa che il perché.
- 2
Chiedi una struttura fissa, non una bozza aperta
Chiedi specificamente una dichiarazione del problema, un piccolo numero di obiettivi, requisiti funzionali e metriche di successo, in quell'ordine. Una struttura fissa è ciò che rende la bozza revisionabile invece di un saggio.
- 3
Dai un numero reale per obiettivi e metriche
Chiedi un numero specifico, tre obiettivi, due metriche, invece di "alcuni obiettivi". Un numero costringe a stabilire priorità invece di un elenco aperto che continua a crescere.
- 4
Tratta la bozza come una struttura di partenza, non un documento finale
Rileggila e riscrivi ogni sezione con la tua voce. Il valore della prima bozza è che non manca nulla, non che la formulazione sia definitiva.
Vogliamo lasciare che gli utenti esportino i loro dati come CSV. Scrivi un PRD di una pagina con una dichiarazione del problema, tre obiettivi, requisiti funzionali e due metriche di successo che potremmo monitorare nei primi 30 giorni.
”Se l'idea di funzionalità proviene da una fonte specifica e conosciuta, un insieme di ticket di supporto, una richiesta di un cliente, una lacuna competitiva, vale la pena dirlo esplicitamente a Claude, dato che una dichiarazione del problema radicata in una fonte reale e nominata risulta molto più credibile per un revisore di una generica che suona solo plausibile.
Questa idea proviene direttamente da 15 ticket di supporto nell'ultimo mese, tutti con la richiesta di un modo per estrarre i propri dati senza contattare il supporto. Riscrivi la dichiarazione del problema facendo riferimento specifico a quella fonte reale, non a una descrizione generica del bisogno.
”
Dentro Claude Tutorial
Partire da una struttura fissa invece che da una pagina vuota è trasferibile.
Lavorare da un insieme noto di sezioni, invece di inventare la struttura mentre scrivi, si applica ben oltre i PRD. L'app ha una lezione completa su questo, con esercizi che si trasferiscono a qualsiasi documento con una forma che i revisori si aspettano.
Quando gli obiettivi non corrispondono alle metriche
Una lacuna comune in una prima bozza è un obiettivo senza alcuna metrica associata, oppure una metrica che non dimostra davvero che l'obiettivo dichiarato sia stato raggiunto. Vale la pena individuare questo disallineamento prima che il documento venga inviato, non dopo che qualcuno chiede come saprai che la funzionalità ha funzionato. Un obiettivo come "ridurre il carico di supporto" accoppiato a una metrica come "numero di esportazioni eseguite" suona collegato ma non dimostra davvero l'obiettivo, dato che gli utenti potrebbero esportare dati costantemente senza evitare un solo ticket di supporto.
Consiglio
Chiedi a Claude di controllare ogni obiettivo rispetto alla sua metrica direttamente: raggiungere questo numero dimostra davvero l'obiettivo, o solo qualcosa correlato a esso? Una metrica facile da misurare non è automaticamente quella giusta.
Ecco i tre obiettivi e le due metriche di questa bozza di PRD. Per ciascun obiettivo, dimmi onestamente se le metriche dimostrano davvero che sia accaduto, o misurano solo qualcosa adiacente.
”Se una metrica si rivela genuinamente difficile da monitorare con gli strumenti esistenti, vale la pena far emergere presto questo vincolo invece di pubblicare un PRD con una metrica di successo che nessuno può davvero misurare una volta che la funzionalità è attiva.
Una di queste metriche richiederebbe un monitoraggio che al momento non abbiamo. Suggerisci una metrica che dimostri lo stesso obiettivo ma sia realistica da misurare con la nostra configurazione di analytics esistente.
”Continua a leggere
- Affinare un PRD prima di inviarlo in revisione: testare la bozza strutturata prodotta da questo articolo prima che arrivi a un revisore.
- Scrivere un documento di roadmap che spiega i compromessi: cosa succede quando questa idea di funzionalità deve competere con altre per un posto nella roadmap.
- Trasformare i ticket di supporto in temi prioritizzati: una fonte di idee di funzionalità reali da cui scrivere PRD fin dall'inizio.