La maggior parte dei PRD non viene letta, ma una presentazione efficace del PRD viene notata. Con Trupeer, puoi risparmiare ore di comunicazione per i Product Manager iniziando con un modello di presentazione PRD gratuito, personalizzandolo con le tue linee guida del brand e trasformando i PRD in video di presentazione che allineano rapidamente gli stakeholder.

Che cos'è una presentazione PRD e in cosa si differenzia dal PRD?

Un documento dei requisiti del prodotto (PRD) stabilisce cosa si sta costruendo, per chi e quali condizioni devono essere soddisfatte per considerarlo completato. È scritto per il team che lo realizzerà, è dettagliato e viene letto anziché presentato.

Una presentazione PRD è un artefatto diverso con uno scopo differente. Si tratta di un numero ridotto di slide da presentare a una product review, a un comitato direttivo o a un forum esecutivo per ottenere una decisione, e non dovrebbe contenere quasi nulla del documento originale.

Confondere le due cose è l'errore più comune. La presentazione diventa la trasposizione del documento su più pagine, la riunione si trasforma in una lettura pagina per pagina e la decisione per cui la riunione è stata indetta non viene presa.

Se ciò di cui hai bisogno è il documento stesso, il nostro modello di PRD snello ne copre la struttura, incluso quali requisiti debbano essere vincolati e quali lasciati alla discrezione del team. Questa pagina riguarda invece i venti minuti di presentazione davanti ad altre persone.

Chi partecipa alla riunione non può valutare i tuoi requisiti

Ecco una cosa che nessuno dice mai sulle riunioni di revisione del prodotto.

Le persone presenti nella stanza (dirigenti, responsabili commerciali, capi reparto) non sono in grado di valutare se il requisito numero quattordici sia corretto. Non hanno parlato con i clienti, non hanno letto i ticket di supporto, non conoscono il sistema e vedono il materiale per la prima volta in uno spazio temporale condiviso con altri cinque argomenti.

Questa non è una critica nei loro confronti. È semplicemente il significato di delega. Ti è stato chiesto di fare questo lavoro proprio per evitare che dovessero farlo loro.

Ma se mostri a una platea trentuno requisiti diversi, questa si concentrerà su qualcosa, perché lo scopo di una revisione è proprio questo. E si concentrerà su ciò che può effettivamente valutare: il nome del prodotto, i colori dei grafici, se i clienti lo vogliono davvero, la data di rilascio e se l'esportazione debba essere in formato CSV o XLSX.

Quindi, una presentazione piena di requisiti non produce un'analisi attenta dei requisiti stessi. Produce un'analisi minuziosa di tutto ciò che vi ruota attorno, espressa con autorità da persone che sentiranno di aver dato il proprio contributo e si aspetteranno che questo venga rispettato.

Il compito della presentazione è mostrare solo ciò su cui la platea ha la competenza per deliberare.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente l'intero layout e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passaggio 6: Visualizza in anteprima e perfeziona il modello

Quando desideri vedere l'aspetto del tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente, se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di presentazione PRD puoi:

• Risparmiare ore di scrittura: Evita la pagina bianca grazie a una struttura pensata per la comunicazione di prodotto.

• Allineare rapidamente gli stakeholder: Le sezioni integrate coprono le esigenze di dirigenti e ingegneri.

• Mantenere la coerenza del brand: Applica il tuo logo, font e colori utilizzando il brand kit di Trupeer.

• Prendere decisioni migliori: Trasforma PRD densi di informazioni in presentazioni video che chiunque può comprendere facilmente.

• Standardizzare i processi per tutti i prodotti: Usa lo stesso modello per ogni revisione del PRD.

• Raggiungere team globali: Traduci i PRD in oltre 65 lingue con un solo clic.

Cosa può effettivamente decidere un comitato di revisione del prodotto

Costruisci la presentazione basandoti esclusivamente sulla colonna di sinistra. Ogni slide deve ricollegarsi a un elemento di quella colonna; qualsiasi slide che non lo fa rappresenta un contesto che andrebbe inserito in una lettura preliminare, piuttosto che nella riunione stessa.

La riga relativa ai compromessi è quella meno utilizzata dai Product Manager. I dirigenti sono davvero bravi a scegliere tra due opzioni con conseguenze diverse, e questo è il risultato di maggior valore che una revisione possa produrre. Presenta loro due opzioni reali anziché un'unica raccomandazione spacciata come inevitabile.

La presentazione PRD in sei slide per ottenere una decisione

Slide uno. La decisione richiesta. Una frase, con una data. "Chiediamo l'approvazione per sviluppare il modulo di reportistica, a partire dal 4 maggio, per un costo di nove settimane di sviluppo." Non un ordine del giorno, non una slide con il titolo. La richiesta prima di tutto, prima che chiunque si sia fatto un'opinione su qualcos'altro.

Slide due. Il problema, espresso con un numero. Cosa sta succedendo, con quale frequenza e quanto costa. Al massimo un grafico. Questo è ciò che giustifica la richiesta ed è l'unica slide a cui appartengono le prove oggettive.

Slide tre. Cosa proponiamo. Un paragrafo e, se utile, un'immagine. Non un elenco di funzionalità. Chi partecipa ha bisogno di capire la forma complessiva del progetto, non i suoi dettagli interni.

Slide quattro. I compromessi e le opzioni scartate. Due o tre scelte reali, con l'opzione non intrapresa e il relativo motivo. Questa è la slide che rende la riunione utile, ed è quella che la maggior parte delle presentazioni omette.

Slide cinque. Di cosa c'è bisogno. Persone, tempo, denaro e cosa queste persone smetteranno di fare per dedicarsi a questo progetto. Il costo opportunità è ciò che trasforma un facile "sì" in una decisione reale.

Slide sei. Cosa non faremo. Esplicitamente, includendo le cose che i presenti in questa stanza hanno precedentemente richiesto. Menzionarle impedisce che vengano aggiunte durante la riunione.

Sei slide, quindici minuti, e il PRD distribuito quarantotto ore prima a chiunque desideri approfondire i dettagli.

Modello di presentazione PRD gratuito: le slide da copiare

Copia da qui.

Titolo e decisione. Nome del prodotto o della funzionalità. Relatore. Data. La decisione richiesta, formulata come una frase completa con una data e un costo.

Problema. L'osservazione, la frequenza, il costo o l'opportunità, con un dato di supporto e la relativa fonte.

Proposta. Un paragrafo che descrive cosa esisterà che non esiste ora, scritto in modo che qualcuno esterno al team possa ripeterlo.

Compromessi. Due o tre righe: la scelta, l'opzione scelta, l'opzione rifiutata, le conseguenze di ciascuna.

Costo e impegno. Tempo di sviluppo, altre funzioni coinvolte, budget e il lavoro che verrà sostituito.

Fuori ambito (Out of scope). Ciò che questo progetto deliberatamente non include, elencando tutto ciò che è stato precedentemente richiesto dai presenti.

Appendice, non presentata. Metriche di successo, dipendenze, rischi, dettagli sulla roadmap. Disponibile in caso di domande, mai illustrata attivamente.

Lettura preliminare (Pre-read). Il PRD stesso, inviato almeno quarantotto ore prima, con una nota che indica quale decisione verrà richiesta.

Copia fino a qui. La regola d'oro per farlo funzionare: nessun requisito deve apparire nelle slide presentate. Se qualcuno fa domande, la risposta è che si trova nel documento, ed è un'ottima risposta.

La revisione con sessantuno commenti e nessuna decisione

Kirkwall Systems, un'azienda di software B2B di circa trecentocinquanta persone, teneva una revisione trimestrale del prodotto. Un Product Manager presentò un PRD per un nuovo modulo di reportistica con una presentazione di trentaquattro slide, che era essenzialmente il documento impaginato.

Nella stanza: l'amministratore delegato, il direttore finanziario, i responsabili delle vendite, dell'ingegneria e del customer success e due responsabili tecnici. Settantacinque minuti.

Qualcuno registrò i commenti in seguito. Sessantuno domande e commenti in totale.

Nove di questi riguardavano cose che i presenti potevano decidere: se sviluppare questo modulo ora, come si posizionava rispetto ad altre due iniziative, se acquistare uno strumento esistente e quale fosse il budget consentito.

Cinquantadue riguardavano cose che non potevano decidere. Il nome del prodotto. I colori in un mock-up di un grafico. Se i clienti lo volevano davvero, sostenuto in entrambe le direzioni senza alcuna prova concreta. La formulazione dei singoli requisiti. E una discussione di dodici minuti su se un'esportazione dovesse essere in formato CSV o XLSX, che è stata la singola voce più lunga della riunione, e che il PRD aveva esplicitamente indicato come decisione di competenza esclusiva del team.

Non fu presa alcuna decisione. L'azione registrata fu che il Product Manager avrebbe dovuto rivedere la presentazione e riproporla.

La seconda revisione, tre settimane dopo, utilizzò una versione di ventotto slide. Fu approvata, con due aggiunte all'ambito concordate sul momento senza che nessuno ne avesse calcolato i costi.

Il ritardo tra la prima revisione e l'inizio dei lavori è stato di sei settimane. Le due aggiunte non preventivate hanno comportato circa cinque settimane di sviluppo in più. Una funzionalità inizialmente stimata in nove settimane ne ha richieste circa venti dalla prima revisione alla consegna.

La svolta è stata l'adozione di uno standard per le presentazioni, piuttosto che un cambio di processo. Sei slide, la decisione presentata per prima, nessun requisito illustrato, PRD distribuito come lettura preliminare quarantotto ore prima.

Nei quattro trimestri successivi, sono state condotte diciannove revisioni di PRD secondo il nuovo formato. La durata media delle riunioni è scesa da settantacinque a trentaquattro minuti. La percentuale di casi in cui è stata effettivamente presa una decisione durante l'incontro è passata da circa il quaranta percento all'ottantanove percento. E l'ambito non preventivato aggiunto durante le riunioni è sceso da una media di 1,8 elementi per revisione a meno di uno ogni tre riunioni.

I requisiti non erano scritti meglio. Non erano mai stati loro il problema.

Cosa va inserito nel PRD stesso e non nella presentazione?

Tutto ciò che la presentazione esclude deliberatamente, ovvero la maggior parte della sostanza.

I criteri di accettazione, definiti in modo che tu e un ingegnere possiate concordare autonomamente sul fatto che siano stati soddisfatti. I requisiti vincolati, ciascuno con il motivo per cui deve essere così. Le aree esplicitamente delegate al team. L'elenco completo degli elementi fuori ambito. Le domande aperte con responsabili e scadenze. E le metriche che monitorerai dopo il rilascio.

Il nostro modello di PRD snello copre questa struttura in dettaglio, incluso l'approccio di tagging che separa ciò che il team deve fare da ciò che può decidere, e spiega perché specificare troppo costa più di quanto faccia risparmiare.

La relazione tra i due documenti va definita chiaramente. Il PRD è il contratto con il team. La presentazione è la richiesta all'azienda. Hanno lettori diversi, cicli di vita diversi e livelli di dettaglio diversi; l'unico contenuto che dovrebbero condividere è la definizione del problema e il paragrafo di proposta.

Come scrivere un documento dei requisiti di prodotto, passo dopo passo

Scrivi prima i criteri di accettazione, ovvero una frase che descrive cosa sarà vero dopo il rilascio che non lo è ora. Se non riesci a formularla, il lavoro non è ancora pronto per essere specificato.

Scrivi perché farlo ora, in due o tre frasi, perché è questo che il team userà per fare i cento piccoli compromessi di cui non verrai mai a conoscenza.

Elenca tutti i requisiti senza filtri, quindi decidi per ognuno se ti importa davvero del risultato. La maggior parte delle prime bozze pone molti più vincoli di quanti ne richieda l'effettiva opinione dell'autore.

Associa un motivo a ogni requisito vincolato. Qualsiasi cosa in cui il motivo si riveli essere "facciamo di solito così" non è un vincolo, è un'abitudine.

Scrivi l'elenco delle cose da non fare mentre hai ancora in mente ciò che le persone hanno chiesto.

Quindi leggi l'elenco dei vincoli come se fossi un ingegnere. Ovunque ti chiederesti il perché e il documento non risponde, aggiungi il motivo o rimuovi la riga.

Come non utilizzare un PRD o la sua presentazione

Come aggiornamento dello stato dei lavori. Una revisione del PRD senza alcuna decisione da prendere si trasforma in un report sullo stato di avanzamento condito da opinioni personali, il che è peggio di non fare alcuna riunione.

Come sostituto del dialogo con il team. Se la prima volta che gli ingegneri vedono i requisiti è durante una revisione, la revisione è il forum sbagliato e il pubblico sbagliato.

Come documento di persuasione. Un PRD scritto per ottenere l'approvazione nasconde l'incertezza, che è proprio ciò che il team ha bisogno di vedere.

Bloccato dopo l'approvazione. Le domande aperte trovano risposta durante lo sviluppo, e un documento che non può cambiare diventa un documento che nessuno consulta.

Come specifica per uno sviluppo regolamentato o critico per la sicurezza. Laddove vi siano normative, requisiti di sicurezza o obblighi contrattuali, hai bisogno di una specifica completa con tracciabilità piuttosto che di un PRD, e delegare i dettagli di implementazione è esattamente ciò che non puoi fare.

Presentato pagina per pagina. Ampiamente trattato sopra, ed è il più comune dei sei errori.

Errori comuni nella scrittura e nella presentazione di un PRD

Iniziare con il contesto anziché con la richiesta, così la platea si fa un'opinione prima ancora di sapere cosa le viene chiesto.

Presentare un'unica opzione come se fosse l'unica possibile, privando i presenti della possibilità di fare ciò in cui riescono meglio.

Nascondere il requisito davvero importante al numero trentaquattro, dove sembra solo un elemento opzionale.

Portare mock-up visivi a una riunione decisionale, il che finisce inevitabilmente per monopolizzare la discussione indipendentemente dall'ordine del giorno.

Omettere il costo opportunità, facendo sembrare l'approvazione priva di costi.

Non menzionare gli elementi fuori ambito precedentemente richiesti dalle persone presenti, il che equivale a un invito ad aggiungerli sul momento.

E accettare l'ampliamento dell'ambito durante la riunione senza calcolarne i costi, che è il modo in cui una funzionalità da nove settimane diventa da venti.

Modelli di PRD in Google Docs, Word e Confluence

Google Docs si adatta bene a un PRD su cui ci sarà da discutere, perché i thread dei commenti sono il luogo ideale per il confronto. Il punto debole è che le decisioni finiscono nei commenti risolti che nessuno legge più, quindi copia tutto ciò che ha modificato il documento nel campo del motivo del requisito prima di risolvere il commento.

Confluence è la piattaforma più comune nelle organizzazioni di ingegneria e il suo modello di PRD predefinito è convenzionale. Sostituire il corpo del testo con una struttura più snella funziona benissimo, e vale la pena mantenere le proprietà della pagina per lo stato e il proprietario.

Word è adatto alle organizzazioni in cui il PRD fa parte di un pacchetto di approvazione formale, e gestisce bene i requisiti numerati e i riferimenti incrociati.

Notion funziona bene se desideri gestire i requisiti sotto forma di database, poiché il tag "vincolato" o "delegato" diventa una proprietà che puoi filtrare e conteggiare nel corso del trimestre.

Per la presentazione vera e propria, usa lo strumento abituale della tua organizzazione e limitati alle sei slide. Lo strumento conta molto meno del fatto che i requisiti rimangano fuori dalla presentazione.

Posso ottenere un modello di PRD in Word, Excel o PDF?

Word o Google Docs per il PRD. Si tratta di testo con un elenco numerato e viene commentato.

Excel per il registro dei requisiti tra le varie funzionalità piuttosto che per un singolo PRD: funzionalità, requisito, vincolato o delegato, il motivo e se è stato rinegoziato durante lo sviluppo. Quest'ultima colonna è l'unica metrica del PRD che cambia concretamente il comportamento di qualcuno.

PDF per la versione allegata a un verbale di decisione o condivisa all'esterno dell'azienda, esportata una volta chiuse le domande aperte.

PowerPoint o Google Slides per la presentazione, sei slide, con il PRD inviato come lettura preventiva anziché incorporato. Per gli stakeholder che non possono partecipare alla revisione, converti la presentazione in un video tramite uno strumento di conversione da presentazione a video e condividi la registrazione. Se la presentazione è destinata a un pubblico esterno, come un partner o un consiglio di amministrazione, i brand kit garantiscono la coerenza visiva senza dover ricreare un modello da zero.

Come mostrare ciò che hai costruito dopo la decisione

Il PRD smette di essere letto il giorno stesso in cui iniziano i lavori, e la presentazione viene dimenticata la settimana successiva alla riunione. Ciò che nessuno produce è l'artefatto che chiude il cerchio: una breve dimostrazione di ciò che è stato effettivamente costruito, destinata a chi lo ha approvato e a tutti coloro che ora devono supportarlo o venderlo.

L'intelligenza artificiale di Trupeer rende tutto questo economico. Chi ha sviluppato la funzionalità registra il risultato finale una sola volta, e l'output è una guida scritta, un video per le note di rilascio e un documento per la tua knowledge base con la tua identità visiva. Quella singola registrazione serve al gruppo di revisione, al team di supporto e all'articolo per i clienti, argomenti coperti dai nostri modelli di articoli per la knowledge base.

Registra. Personalizza col brand. Traduci. Usa Trupeer.

Questo migliora anche la revisione successiva. Una registrazione di due minuti di ciò che la funzionalità approvata in precedenza è diventata realmente è molto più persuasiva, all'inizio di una revisione, di qualsiasi slide su ciò che quella futura potrebbe diventare. La documentazione tecnica copre il registro interno di ciò che è stato costruito. Le istruzioni di configurazione si trovano nella guida alla configurazione del modello di documento.

Domande Frequenti

Esiste un modello di PRD gratuito in Word?

La struttura del documento è coperta dal nostro modello di PRD snello e può essere incollata direttamente in Word o Google Docs. La struttura della presentazione descritta in questa pagina è di sei slide. Non è richiesto alcun download a pagamento né compilazione di moduli per nessuno dei due.

Esiste un modello di PRD per Google Docs?

Copia la struttura in un file Google Doc e salvala nel drive del tuo team come modello. Google Docs è un'ottima scelta proprio perché sui PRD si discute molto nei commenti, con l'avvertenza che qualsiasi decisione presa in un thread deve essere integrata nel documento prima che la discussione venga contrassegnata come risolta.

Esiste un modello di documento dei requisiti di prodotto in Excel?

Excel si adatta meglio al registro dei requisiti per diverse funzionalità piuttosto che a un singolo PRD. Colonne per funzionalità, requisito, se è vincolato o delegato, il motivo e se è stato rinegoziato durante lo sviluppo. Revisionare trimestralmente quest'ultima colonna mostra quali Product Manager tendono a specificare troppo i dettagli.

Esiste un esempio o un fac-simile di PRD in PDF?

Gli esempi pubblicati sono facili da trovare e utili da leggere per l'ordine delle sezioni piuttosto che per il contenuto, poiché i requisiti di qualsiasi vero PRD appartengono a uno specifico prodotto. L'esercizio più utile è prendere una funzionalità rilasciata di recente e scriverne retrospettivamente la presentazione in sei slide, il che di solito rivela che la decisione non era mai stata espressa chiaramente.

Vale la pena usare strumenti di intelligenza artificiale per i PRD?

Per la prima bozza, sì. Descrivi la funzionalità e la maggior parte degli strumenti attuali restituirà un documento strutturato con sezioni che potresti aver dimenticato. Quello che non possono fare è decidere quali requisiti ti interessano davvero, perché questo dipende da conoscenze che solo tu possiedi. Se lasciati a se stessi, producono un documento eccessivamente dettagliato, che è proprio l'errore da evitare.

Da quante slide dovrebbe essere composta una presentazione PRD?

Sei, da presentare in circa quindici minuti, con un'appendice da non illustrare. Presentazioni più lunghe producono più commenti e meno decisioni, come dimostrato dall'esempio pratico sopra riportato. Se le tue linee guida aziendali richiedono un formato fisso, mantieni comunque la decisione nella prima slide, indipendentemente da ciò che segue.

Chi dovrebbe presentare il PRD?

Il Product Manager che lo ha scritto, con il responsabile dello sviluppo presente ma non relatore. Avere il team di Engineering nella stanza è fondamentale per la slide dei compromessi, poiché la risposta credibile alla domanda "potremmo farlo più velocemente" è più efficace se proviene direttamente da loro.

Qual è la differenza tra un PRD e un documento dei requisiti?

Un PRD è orientato al prodotto: cosa verrà costruito, per chi e cosa si intende per completato. Un documento dei requisiti di business (BRD) si colloca a monte e descrive il problema di business e gli obiettivi che una soluzione deve raggiungere, prima che venga presa la decisione di sviluppo. Una specifica tecnica si colloca a valle e descrive come verrà costruita la soluzione. Cercare l'uno quando si ha bisogno dell'altro è un errore comune che produce documenti con un livello di dettaglio inadeguato.