Scrivere un PRD: Guida Completa in 10 Passi + Prompt AI per la Scrittura
Perché i documenti dei requisiti di prodotto (o PRD) sono strumenti così vitali per i team di prodotto? Perché, per quanto chiaramente tu possa immaginare lo stato futuro del tuo prodotto, nessuno stakeholder lo percepirà mai nello stesso modo.
Sono certo che ci siano migliaia di storie dell'orrore raccontate da product manager che si sono resi conto troppo tardi di non aver comunicato in modo efficace gli elementi critici di un nuovo prodotto o funzionalità.
È per questo che un Product Requirements Document (PRD) è così importante. Utilizza un approccio dettagliato e sistematico per allineare tutti su cosa dovrebbe rappresentare il successo.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
In questa guida, ti aiuteremo a creare un PRD eccezionale con obiettivi chiari, requisiti e un piano ben studiato. Inoltre, per aiutarti a risparmiare tempo prezioso, abbiamo anche una serie di prompt LLM che genereranno la maggior parte del PRD per te (o almeno ti forniranno una solida bozza iniziale!).
Cos'è un Product Requirements Document (PRD)?
Semplicemente, un product requirements document descrive le funzionalità e le caratteristiche che devono essere incluse in una specifica release del prodotto. È un punto di riferimento fondamentale per tutti i team coinvolti nella progettazione e nello sviluppo di un determinato prodotto. È anche essenziale per informare la roadmap di prodotto.
Tradizionalmente utilizzato in un ambiente di progetto con metodologia Waterfall—dove il processo di sviluppo prodotto è sequenziale—può essere usato anche nella gestione di prodotto Agile.
Tutto si riduce davvero a questa aspettativa della leadership su come dovrebbe essere eseguito il prodotto… ciò che sta realmente accadendo sul campo con i product manager che eseguono e c’è questa disconnessione… chiamata product-process gap, ma in realtà è la distanza tra le aspettative e la realtà.
Altri documenti possono essere creati partendo dalle informazioni raccolte nel PRD. Il reparto ingegneristico può creare un Documento dei Requisiti Tecnici che dettagli le specifiche di prodotto e i requisiti di sistema.
Gli analisti di business possono creare un Documento dei Requisiti Funzionali dettagliando cosa succede quando un utente interagisce con il sistema, inclusi wireframe per mostrare il design del prodotto.
Gli specialisti di esperienza utente (UX) potrebbero creare un Documento dei Requisiti dell'Interfaccia Utente che spiega come dovrebbe apparire e funzionare il prodotto.
Quali sono i vantaggi della stesura di un PRD e cosa contiene?
Scrivere un PRD completo comporta numerosi vantaggi. Vediamone alcuni:
- Allinea tutti gli stakeholder sulla stessa pagina.
- Rende chiaro ciò che è fuori ambito.
- Favorisce la collaborazione tra i team.
- Mette la prospettiva del cliente al centro del prodotto.
In termini di struttura, un PRD tipico dovrebbe contenere quanto segue:
- Metadati del documento come data di modifica, cronologia delle versioni, ecc.
- Obiettivi di prodotto che si vogliono raggiungere.
- Dati di ricerca sui clienti, come le personas di riferimento.
- Elenco prioritario delle funzionalità che si desidera sviluppare.
- Ambito negativo delle funzionalità che non saranno sviluppate.
- Metriche principali per testare queste ipotesi.
- Ipotesi principali che le tue funzionalità devono testare.
- Strategia di rilascio che mostra quando e come la funzionalità verrà distribuita.
Sebbene la maggior parte dei PRD contenga questi elementi, è assolutamente corretto aggiungere o rimuovere elementi in base alle proprie esigenze e alla realtà del proprio prodotto.
Qual è un esempio di Product Requirements Document?
A volte è più semplice capire cosa includere in un documento usando un supporto visivo, quindi ecco un esempio di PRD compilato.
Come scrivere un Product Requirements Document (Con Un Piccolo Aiuto Dagli LLM)
Anche con tutte le informazioni condivise finora, creare il tuo primo PRD può sembrare scoraggiante. Non preoccuparti; ci pensiamo noi! Ecco la nostra checklist in 10 passaggi per l’uso dell’AI nella raccolta dei requisiti e per la creazione di un PRD a prova di bomba. Inoltre, abbiamo incluso anche un modello per aiutarti a raccogliere tutte le informazioni necessarie.
Passaggio 1: Chiarisci il problema
Prima di fare qualsiasi altra cosa, è cruciale avere chiaro il problema che si intende risolvere e le personas utente a cui si rivolge la soluzione. Questo influenzerà le funzionalità effettive da includere nel prodotto e le caratteristiche da prioritizzare per la release.
Il Business Requirements Document dovrebbe contenere una dichiarazione dei bisogni che descriva il problema riscontrato e come il prodotto dovrebbe agire per risolverlo. Esaminare il BRD e chiarire esattamente ciò di cui il business ha bisogno dal prodotto è importante prima di redigere il PRD.
Passaggio 2: Rivedi le ricerche di mercato e utente
Una volta che stai redigendo un PRD, dovresti già avere a disposizione la ricerca di mercato e le personas. Tuttavia, a volte la persona di riferimento per una funzionalità specifica può differire da quella generale che hai già individuato. Quindi, se questo è il tuo caso, generiamo una descrizione della persona utilizzando questo prompt LLM:
Ecco le trascrizioni di diverse interviste di product discovery che ho condotto con i miei utenti.
{carica le tue trascrizioni come file txt in questo messaggio}
Per favore, esamina queste trascrizioni, analizza i tratti comuni tra esse e genera una descrizione della persona seguendo questa struttura (delimitata da tag XML):
<USER_PERSONA_STRUCTURE>
1. Nome:
(Fittizio ma realistico, ad esempio Anna, la Commercialista Indaffarata)
2. Dati Demografici:
• Età
• Genere (opzionale)
• Località
• Occupazione
3. Obiettivi:
• Obiettivo/i principale/i che vuole raggiungere
• Obiettivi secondari o collegati
4. Sfide/Punti Dolenti:
• Principali ostacoli che affronta
• Frustrazioni o bisogni
5. Comportamenti:
• Abitudini, preferenze, modelli di utilizzo rilevanti
6. Strumenti/Piattaforme Preferite:
• App, siti web, dispositivi usati con frequenza
7. Una Breve Citazione (Opzionale ma Potente):
Una frase che riassume come si sente riguardo ai suoi bisogni.
(Esempio: “Voglio solo un sistema che mi faccia risparmiare tempo senza dover leggere un manuale.”)
</USER_PERSONA_STRUCTURE>
Esempio:
Nome: Anna, la Commercialista Indaffarata
Dati Demografici: 34 anni, vive a Chicago, CPA in un piccolo studio
Obiettivi: Terminare il lavoro con i clienti più velocemente, ridurre al minimo le attività amministrative manuali
Sfide: Troppa burocrazia, software poco intuitivi, pressione sui tempi
Comportamenti: Lavora fino a tardi durante la stagione fiscale, preferisce app semplici e accessibili dal mobile
Strumenti Preferiti: QuickBooks, Slack, Google Drive
Citazione: “Se non è semplice, non ho tempo per usarlo.”
Requisiti per la generazione della persona:
- per favore usa solo le informazioni fornite nelle trascrizioni e non inventare informazioni non presenti.
- usa solo le caratteristiche che sono presenti in almeno l'80% delle trascrizioni che ti ho condiviso.
- se non trovi abbastanza informazioni per un elemento specifico della persona, lascialo vuoto.
Di conseguenza, otterrai una descrizione della persona che puoi includere nel documento dei requisiti di prodotto. Tuttavia, ti consiglio di controllare attentamente i contenuti generati dall’IA poiché potrebbero contenere errori.
Passo 3: Coinvolgi gli stakeholder funzionali
Come abbiamo già detto, i migliori PRD vengono sviluppati in collaborazione. Convoca una riunione trasversale per raccogliere input da diverse aree del business da utilizzare nella stesura del documento dei requisiti.
Questa è un’ottima occasione per gli stakeholder per evidenziare eventuali assunzioni, sollevare dubbi riguardo a rischi o vincoli e individuare dipendenze che potrebbero avere impatto sul processo di sviluppo del prodotto.
Passo 4: Definisci la tua ipotesi principale e le metriche di prodotto
Qualunque sia il tipo di funzionalità che realizzi, ti aspetti che abbia un certo impatto sui tuoi utenti o sulla tua azienda. Per poter misurare tale impatto e verificare se la funzionalità abbia avuto successo o meno, devi innanzitutto definire un’ipotesi verificabile.
Il mio formato preferito per le ipotesi si chiama If-then-because. Si struttura così:
Crediamo che, se [sviluppiamo la funzionalità A], allora [la metrica B principale] [aumenterà/diminuirà] di [C quantità] perché [spiegazione].
Ad esempio, se sto lavorando per Spotify, potrebbe essere così.
Crediamo che, se sviluppiamo le playlist per la routine mattutina, allora la retention giornaliera aumenterà del 5% perché più persone useranno Spotify ogni mattina.
Per automatizzare questo processo con l’IA, basta spiegare a parole tue ciò che ti aspetti dalla funzionalità e chiedere di formularlo nel formato If-then-because. Ecco il prompt:
{inserisci qui la tua spiegazione della funzionalità}
Per favore, formula un’ipotesi utilizzando il formato if-then-because.
Requisiti:
- L’ipotesi non deve superare le 100 parole.
- Usa solo il contesto che ti ho fornito.
Una volta pronta l’ipotesi, devi anche definire le metriche di prodotto che vuoi misurare per quella funzionalità.
Ovviamente vuoi misurare la metrica su cui la tua ipotesi si concentra (nel caso di Spotify, la retention). Ma ci sono anche 3 metriche chiave che ti servono per ogni funzionalità:
- Adozione
- Retention
- Engagement
Puoi chiedere all’IA di aiutarti a scegliere la metrica giusta insieme agli eventi che il tuo strumento di analytics dovrà registrare per misurare queste metriche. Ecco un prompt che puoi utilizzare a tal fine.
{inserisci qui la tua spiegazione della funzionalità}
Ecco l’ipotesi:
{inserisci qui la tua ipotesi dal prompt precedente}
Per favore suggerisci metriche da tracciare insieme ai rispettivi trigger di evento. Suggerisci metriche in queste categorie:
- Adozione
- Retention
- Engagement
Considera che aggiungerò queste metriche nel Product Requirements Document per la funzionalità che ho descritto.
Nell’esempio di Spotify, le metriche sarebbero le seguenti:
Adozione: % di utenti che hanno avviato una playlist mattutina. Il trigger dell’evento è il momento in cui l’utente avvia la playlist.
Retention: % di utenti che hanno utilizzato la playlist mattutina per 7, 14 e 30 giorni. Il trigger dell’evento è il momento in cui l’utente avvia la playlist.
Engagement: Minuti medi di ascolto della playlist da parte degli utenti. I trigger degli eventi sono l’avvio e l’arresto della playlist.
Passo 5: Prepara i tuoi design
Nessun PRD è completo senza il design, se la funzionalità lo richiede. Alcuni team allegano i design finali; altri preferiscono includere solo concetti ad alto livello o un prototipo, perfezionando i dettagli successivamente con il team.
Entrambi gli approcci presentano vantaggi e svantaggi. I design finali offrono chiarezza ma rallentano la consegna del PRD. I concetti iniziali accelerano il passaggio ma rischiano interpretazioni errate e rielaborazioni.
Il punto di equilibrio? Condividi design che coprono il percorso principale dell’utente e gli stati principali, saltando elementi minori come stati vuoti o di errore. Fortunatamente, i moderni strumenti di UX design permettono di ottenere sia un prototipo che un design allo stesso tempo.
Così puoi fornire design e PRD al tuo team prima, minimizzando il rischio di ambiguità.
Fase 6: Suddividi la tua idea in funzionalità indipendenti
Non credo sia necessario spiegare ai PM più esperti i vantaggi di suddividere una grande funzionalità in user story più piccole e gestibili. Se sei nuovo nel product management, eccone alcuni:
- Le storie piccole sono più facili da stimare per il tuo team.
- Sono più semplici da consegnare poiché il team può concentrarsi su una storia alla volta e completarle senza intoppi.
- Si testano più velocemente, perché i QA possono testare una storia mentre il team lavora sulla successiva - parallelizzando il lavoro di tester e sviluppatori.
- Ti danno la flessibilità di rimuovere quelle meno importanti dall’ambito per velocizzare la consegna.
Scomporre la funzionalità è positivo, ma rappresenta solo metà del lavoro. L’altra metà consiste nel prioritizzarle. Non tutte le storie sono uguali. Alcune parti della funzionalità rappresentano il percorso principale, altre sono semplici aggiunte opzionali. Nel nostro esempio di Spotify, ecco come apparirà la lista delle storie importanti e non importanti tramite il metodo di prioritizzazione MoSCoW.
Guardando questa lista, è chiaro che la possibilità per gli utenti di vedere la playlist mattutina e accedervi con un solo tap è molto più importante rispetto alla possibilità di modificarla.
Quindi, se devi rispettare una scadenza e spedire rapidamente, puoi rimuovere la user story relativa alla modifica dalla release e rimandarla alle future versioni.
Alcuni creano questa lista su un foglio di calcolo. Ma io consiglio di usare un tool di product roadmap specializzato che include anche funzioni nativamente pensate per prioritizzazione e integrazione.
Fase 7: Definisci la strategia di rilascio
Le release nella vita reale sono raramente lineari: completare l’intera funzionalità e portarla subito in produzione. Il più delle volte, la release di una funzionalità complessa (che merita un proprio PRD) è un processo multi-fase, che può includere:
- Sviluppo della versione MVP contenente solo le user story imprescindibili e rilascio in beta.
- Raccolta dei feedback, risoluzione dei problemi, aggiunta delle storie importanti e preparazione per il rilascio in produzione.
- Rilascio graduale in produzione tramite più fasi.
- Aggiunta di funzionalità opzionali se si rileva una reale necessità.
Per velocizzare la creazione di una strategia di rilascio, puoi chiedere aiuto al tuo LLM usando questo prompt.
Voglio costruire {inserisci qui la spiegazione della tua funzionalità}.
Ecco un elenco di user story per quella funzionalità, prioritizzate utilizzando il metodo MoSCoW:
{inserisci l'elenco delle funzionalità dal passaggio precedente qui}
Per favore, crea una strategia di rilascio per questa. La strategia dovrebbe:
- Raggruppare le funzionalità nell'elenco sopra in più release, includendo la versione MVP.
- Se lo ritieni necessario, prevedi una fase di beta release
- Se lo ritieni necessario, prevedi un rollout graduale suddiviso in 2 o più fasi, includendo le tempistiche, le percentuali di utenti a cui rilasciare nelle fasi, oltre alla descrizione delle tipologie di utenti da includere in ogni fase di rollout.
Criteri per decidere se è necessario un Beta Release (in formato CSV, delimitato da tag XML):
<BETA_RELEASE_CRITERIA>
Criterion,Beta Release,Rilascio Diretto in Produzione
User Risk,Medio-Alto – impatto utente incerto o potenziali regressioni,Basso – la funzionalità è ben testata e a basso rischio per gli utenti
Feature Maturity,MVP o sperimentale; può mancare di rifinitura o UX completa,Completamente sviluppata e stabile
Feedback Need,Alto – il feedback degli utenti early è critico per validare direzione o scelte di UX,Basso – fiduciosi nel valore e nell'usabilità della funzionalità
QA Confidence,Moderata – necessita di test nel mondo reale per integrare la QA interna,Alta – accuratamente testata internamente
Business Impact Uncertainty,Non chiaro se influenzerà i principali KPI (retention, conversione, ecc.),Impatto positivo o neutro atteso, supportato da validazione pregressa
</BETA_RELEASE_CRITERIA>
Criteri per decidere se è necessario un Gradual Release (in formato CSV, delimitato da tag XML):
<GRADUAL_RELEASE_CRITERIA>
Criterion,Gradual Release,Rilascio Immediato Completo
User Risk,Alto – La funzionalità potrebbe causare regressioni, bug o confusione se rilasciata su larga scala,Basso – Minima interruzione per l'utente anche in caso di problemi imprevisti
System Load Risk,Alto – La funzionalità può aumentare il carico su server o backend; comportamento di scalabilità sconosciuto,Basso – Le prestazioni sono validate alle condizioni di carico attese
Change Scope,Ampio – Tocca percorsi critici, flussi principali UX o logica backend,Ridotto – Autonomo, opzionale o limitato in ambito
Monitoring Readiness,Metriche, alert e log sono pronti a rilevare problemi su piccoli cohort,Non essenziale – basso rischio di errori silenziosi o di regressioni di difficile rilevamento
Rollback Complexity,Alta – Difficile da annullare una volta rilasciata completamente (es. migrazioni di schema, modifiche ai dati),Bassa – Facile da disabilitare o correggere in caso di problemi
</GRADUAL_RELEASE_CRITERIA>
Molto probabilmente, le tempistiche fornite dal LLM sarebbero irrealistiche. Sentiti quindi libero di modificarle in base alla capacità del tuo team e agli obiettivi di prodotto.
Passaggio 8: Redigere il PRD
Utilizzando le informazioni raccolte nel passaggio precedente, ora puoi redigere il PRD.
Ancora una volta, per risparmiare tempo, chiederemo alla LLM di nostra scelta di farlo per noi utilizzando questo prompt.
Per favore, crea un Documento dei Requisiti di Prodotto utilizzando questa struttura (delimitata da tag XML):
<PRD_STRUCTURE>
1. Obiettivo
- Vision
- Obiettivi
- Persona(e)
2. Funzionalità (tabella con le seguenti colonne)
- Nome breve user story
- Breve descrizione user story
- Priorità user story
3. User Flow e Design
- Lasciare qui un testo segnaposto "inserire qui user journey e link di design"
4. Strategia di rilascio
- Fasi di rilascio con relativo campo di applicazione. Includere beta release se ho fornito un esempio nel contesto del rilascio qui sotto
- Strategia di rollout graduale se ho fornito un esempio nel contesto del rilascio qui sotto. Se il rollout graduale è rilevante, includere le percentuali di utenti da coinvolgere nelle fasi e la descrizione delle tipologie di utenti da includere in ciascuna fase di rilascio.
5. Analytics
- Ipotesi principali
(tabella contenente queste colonne)
- Metrica
- Variazione target
- Evento trigger
</PRD_STRUCTURE>
Per favore, usa questi contesti per generare il PRD (delimitati da tag XML):
<USER_PERSONAS>
{inserisci qui la descrizione del persona}
</USER_PERSONAS>
<CORE_HYPOTHESIS>
{copia e incolla l'ipotesi principale dai passaggi precedenti qui}
</CORE_HYPOTHESIS>
<KEY_METRICS>
{copia e incolla l'elenco delle metriche chiave dai passaggi precedenti qui}
</KEY_METRICS>
<USER_STORIES>
{copia e incolla l'elenco delle user story dai passaggi precedenti qui}
</USER_STORIES>
<RELEASE_STRATEGY>
{copia e incolla la strategia di rilascio dai passaggi precedenti qui}
</RELEASE_STRATEGY>
Tutto quello che ti resta da fare è esaminare rapidamente il contenuto del PRD. In particolare, presta attenzione a vision e obiettivi poiché la LLM cercherà di generarli in base alle tue descrizioni delle funzionalità. Se non ti convincono, sentiti libero di modificarli.
Passaggio 9: Ottieni l'approvazione
Una volta completato il PRD, assicurati che venga approvato dal cliente. Per un progetto interno, questo potrebbe essere lo sponsor del progetto o il team dirigente senior. Questo aiuta a garantire allineamento aziendale e supporto per il processo di sviluppo del prodotto.
L'accettazione dei criteri di rilascio è di fondamentale importanza, così da evitare fraintendimenti su ciò che effettivamente il prodotto sarà in grado di offrire in termini di funzionalità, usabilità e performance al termine dello sviluppo.
Passaggio 10: Condividi e comunica
Dopo che il PRD è stato approvato, condividi dove verrà archiviato e comunica il processo per l’accesso, la consultazione e la modifica del PRD durante il processo di sviluppo del prodotto.
Il PRD finalizzato dovrebbe essere utilizzato come punto di riferimento durante tutto il progetto e può essere aggiornato in tempo reale se cambiano i requisiti. Tuttavia, dovrebbe sempre essere possibile identificare cosa era stato concordato originariamente e ogni modifica dovrebbe essere ben documentata e accompagnata dal motivo del cambiamento.
Best practice per i documenti dei requisiti di prodotto
Speriamo di aver chiarito esattamente cosa deve contenere un PRD, quindi passiamo ad alcune best practice per la sua redazione.
- Cerca il contributo delle parti interessate. I migliori PRD sono creati con il contributo di tutti gli stakeholder chiave. Non ha senso stilare un lungo elenco di funzionalità critiche solo per poi sentirsi dire dagli ingegneri che non sono supportabili. Coinvolgere altri team sin dalle prime fasi porta chiarezza e permette di segnalare assunzioni, vincoli e dipendenze.
- Sfrutta gli strumenti moderni. Fortunatamente, oggi esistono molti strumenti di documentazione orientati al software che ci aiutano nella creazione e gestione dei PRD. Notion, ad esempio, include template di PRD già pronti da usare insieme a tabelle con formattazione avanzata dove puoi elencare assunzioni o funzionalità. Confluence, invece, offre integrazione nativa con Jira e BitBucket, consentendo di incorporare attività e rilasci direttamente nel documento.
- Itera quando necessario. Il PRD è pensato come un documento vivo. Cambiamenti nei requisiti dei clienti o del mercato possono richiedere l’aumento, il cambio di priorità o l’eliminazione delle funzionalità di prodotto. Le tempistiche potrebbero dover essere compresse per garantire la priorità sul mercato o estese se una supposizione non si realizza.
- Usa il controllo di versione. Anche se è importante rivedere e modificare il PRD quando necessario, è fondamentale che il product manager possa sempre fare riferimento a quanto concordato inizialmente. Utilizzare il controllo di versione e garantire livelli di accesso appropriati consente di mantenere un registro storico di ciò che è stato concordato originariamente, delle modifiche apportate e dei motivi di tali modifiche.
- Tienilo visibile. Un PRD non è un documento da realizzare una volta e poi abbandonare in un cassetto dopo la riunione di pianificazione del progetto: è una risorsa critica per la gestione del progetto. Come abbiamo visto, il PRD funge da punto di riferimento per tutti i membri del team che lavorano al prodotto, quindi è fondamentale che sia sempre accessibile.
More Articles
- L’IA nella Ricerca sugli Utenti: Come l’Intelligenza Artificiale Sta Trasformando le Analisi sugli Utenti
- Spedire Prodotti Global-First Senza il Mal di Testa Globale: Come Integrare la Localizzazione nel Tuo Flusso di Lavoro di Prodotto
- L’IA nella Pianificazione dello Sprint: Come l’IA Migliora l’Efficienza del Team
Template per il Documento dei Requisiti di Prodotto
Per concludere, ecco un template di PRD che puoi utilizzare per cominciare a redigere subito il tuo primo documento dei requisiti di prodotto.
Assicurati di personalizzarlo in base alle esigenze del tuo progetto, aggiungendo o rimuovendo sezioni secondo necessità per offrire maggiore chiarezza.
Template Documento dei Requisiti di Prodotto
Ottieni chiarezza sui requisiti di prodotto oggi stesso
Se hai letto con attenzione tutte le informazioni sopra, sei già sulla buona strada per creare un eccellente Documento dei Requisiti di Prodotto.
Anche se può richiedere un po’ di tempo all’inizio, i benefici ripagheranno lo sforzo, e il nostro template di esempio può aiutarti a pianificare e sviluppare il tuo prossimo grande prodotto.
Siamo una community di product people (proprio come te!), quindi se hai trovato utile queste informazioni, iscriviti alla nostra newsletter. Ti terremo aggiornato con articoli utili, guide pratiche, recensioni di strumenti e molto altro ancora.
