Come scrivere un PRD che aiuti a far crescere un business

Come scrivere un PRD? Ma soprattutto a cosa serve un PRD?

Saper scrivere un PRD in modo corretto è alla base del management aziendale dove i Product Manager hanno la responsabilità ultima di capire cosa costruire e di assicurarsi che sia d’impatto.

In teoria è semplice, ma non è facile.

I PM devono raccogliere ed elaborare idee da tutte le direzioni, razionalizzare e sostenere quali investimenti hanno senso e mantenere la convinzione della propria tabella di marcia, pur rimanendo flessibili per poter cambiare le cose man mano che imparano.

Cosa è un documento PRD

Per decenni, il Product Requirement Doc (PRD) è stato lo strumento del mestiere, l’unica fonte di verità su cosa costruire e perché.

Negli anni ’90, i PRD si estendevano per 20-30 pagine e dovevano essere la registrazione definitiva di ogni modifica dettagliata. Con l’evoluzione dello sviluppo agile e l’accelerazione delle aziende incentrate sul software, i team di prodotto hanno capito che i documenti statici non sono lo strumento migliore per rappresentare il lavoro creativo dinamico.

I PRD hanno miracolosamente prevalso, ma i Product Manager si affidano ancora al concetto obsoleto di un singolo documento statico, che li fa finire in una delle due fazioni inefficaci.

Per assurdo un Product Manager ansioso passerà troppo tempo a cercare di creare un documento perfetto che assomiglia a una tesi di dottorato in attesa di approvazione. Questa modalità di fallimento comune si manifesta nei team che mancano di fiducia interna o che hanno una proprietà poco chiara.

Il PRD diventa uno strumento di processo per risolvere un problema di persone.

All’estremo opposto, il Product Manager troppo zelante passerà troppo poco tempo ad articolare il proprio pensiero, ignorando la scrittura come un processo superfluo che rallenta tutto. Questa modalità di fallimento comune si verifica nei team che vedono un processo come una barriera al progresso, per poi ritrovarsi con un mucchio di domande e problemi irrisolti da risolvere a valle.

Nessuna delle due visioni è ideale per i moderni team di prodotto, il cui lavoro assomiglia a qualsiasi altra attività creativa: richiede abbastanza vincoli per iniziare, ma anche abbastanza flessibilità per consentire nuovi approcci o soluzioni durante l’esplorazione.

Lo staff di Vector Management è d’accordo e si chiede tutti i giorni se non sia il caso di tornare a fare le PRD per riprendere la “disciplina di documentare ciò che stiamo costruendo e perché”.

In questo articolo aiuteremo i PM a pensare alle PRD come strumenti che consentono di progredire piuttosto che dettare piani prescrittivi.

Per arrivarci, vi guideremo attraverso:

• Perché un ottimo PRD facilita il lavoro di costruzione
• Le 3 evoluzioni di un PRD dinamico e in evoluzione
• Come sapere se si è sulla strada giusta con il proprio team

Naturalmente, condivideremo anche un esempio approfondito di PRD dinamico, che potrete utilizzare come modello per il futuro.

Ottimi PRD rendono più facile la costruzione dei prodotti

Innanzitutto, definiamo cosa intendiamo quando parliamo di Product Requirements Docs (PRD).

I PRD sono comunemente un termine generico per indicare un documento in evoluzione che guida il processo di sviluppo centralizzando in un unico luogo le informazioni chiave necessarie per l’allineamento e le prime fasi di esecuzione.

Un PRD aiuta a rispondere a “Devo costruire questo? E come devo pensare a questo sforzo?”.

Come scrivere un PRD che aiuti davvero a costruire i prodotti

Invece di pensare a un PRD come a uno strumento per affinare il proprio pensiero e fare progressi, i Product Manager vedono i PRD come:

• Un processo burocratico o una casella di controllo da superare
• Un esercizio inutile, perché le cose cambiano in ogni caso
• Un’opportunità non richiesta per gli altri di fornire un feedback non utile.
• Una presentazione per mostrare la genialità del proprio prodotto
• Un registro delle decisioni o delle storie degli utenti

Un buon PRD può involontariamente alleviare alcuni di questi problemi, ma un ottimo PRD non si concentra su nessuno di essi.

Come scrivere un PRD che vi aiuti davvero a costruire i prodotti – Cosa sbloccano i grandi PRD
Un PRD efficace sblocca tre vantaggi chiave che facilitano la costruzione:

• Permette l’allineamento tra leader e team
  I PRD eccellenti forniscono ai team e ai singoli individui le informazioni e la fiducia di cui hanno bisogno per sollevare segnalazioni, porre domande e iterare con un minimo di cambiamenti nelle decisioni.
• Sblocca la creatività e la collaborazione interfunzionale
  Le ottime PRD lasciano spazio a partner interfunzionali come progettisti e ingegneri per definire la soluzione insieme ai PM, con un risultato migliore per il cliente.
• Chiarisce e mette alla prova il vostro pensiero
  L’atto stesso di scrivere costringe il nostro cervello a pensare in modo logico e strutturato, che gli altri possono poi consumare e interpretare. Questo ci permette di verificare se risolviamo efficacemente il problema del cliente, se abbiamo un piano ponderato e se abbiamo abbastanza dettagli per fare il primo passo verso l’esecuzione.

Questi vantaggi possono sembrare piacevoli, ma a lungo termine fanno risparmiare molto tempo.

Infatti, i team che non li hanno subiranno le seguenti conseguenze:

• Non ricorderete cosa avete deciso (e perché) o cosa avete imparato: Si scopre che gli esseri umani non preferiscono pensare razionalmente. Rallentare per scrivere, articolare, chiarire, discutere e documentare il vostro processo decisionale impegna il vostro Sistema 2 di pensiero in modo che possiate fare scelte più consapevoli e logiche. Tra sei mesi, quando il vostro team si troverà a rivedere gli stessi problemi, potrete ringraziare il vostro passato per aver documentato efficacemente il vostro pensiero, in modo da non commettere sempre gli stessi errori.
• Non riuscirete a costruire un’intelligenza collettiva e un’intuizione di prodotto: I grandi team di prodotto si muovono in modo più efficiente nel tempo perché hanno sviluppato una comprensione collettiva di come i clienti pensano e usano il loro prodotto. Mettere per iscritto il vostro pensiero e coinvolgere gli altri vi aiuterà a costruire prodotti migliori.
• Non creerete fiducia: Le persone vogliono sapere che avete pensato a qualcosa in modo coerente. Quanto più è facile per gli altri vedere il vostro lavoro, tanto meno saranno scettici nel fidarsi del vostro pensiero. Se non hanno idea di come siete arrivati alle conclusioni che avete tratto, dovranno colmare le lacune da soli.

Sarà difficile ottenere un aiuto e un feedback efficaci: Se le persone non sanno come state pensando a un problema o dove vi state bloccando, può essere difficile sapere come aiutarvi. Pensate al vostro PRD come a un’impalcatura che permette agli altri di “salire” per raggiungervi dove siete. Un PRD mediocre rende difficile a chi non è coinvolto intervenire e offrire un feedback utile.

Se vi concentrate meno sulla PRD come perdita di tempo e più come strumento per aiutarvi a essere più efficaci nel lungo periodo, potete facilmente evitare queste conseguenze.

Come un PRD dinamico e in evoluzione può aiutarvi a costruire business

Qual è il modo giusto di pensare ai PRD?

Evitate di cercare di completare documenti statici, lunghi e opprimenti. Dovreste invece considerarli come un artefatto dinamico e in evoluzione che aiuta a sbloccare la fase successiva del ciclo di sviluppo.

Preoccupatevi che il vostro PRD sia sufficiente per iniziare, non che sia finito o perfetto. Quindi aggiornate continuamente il PRD man mano che imparate di più.

Esistono tre principali evoluzioni di un PRD che rispecchiano il ciclo di sviluppo del prodotto.

1. Brief di prodotto: chiamati anche memo di prodotto o 1-pager. Come suggerisce il nome, si tratta in genere di documenti concisi di una sola pagina, a volte con pagine aggiuntive in appendice. Servono a chiarire lo spazio del problema e a raccogliere l’allineamento iniziale sull’area di interesse dell’investimento.
2. Specifiche di prodotto: chiamate anche Lean PRD. Sono in genere di 2-3 pagine e hanno lo scopo di ispirare e consentire una conversazione con i leader interfunzionali sullo spazio della soluzione.
3. PRD completi: detti anche 6-pager o PRD tradizionali. Possono essere lunghi 5-6 pagine o più. In ultima analisi, si tratta di sbloccare l’esecuzione e di iniziare effettivamente a costruire qualcosa.

È importante ricordare che questi tre elementi non devono essere considerati documenti completamente diversi.

Questi archetipi rappresentano invece l’evoluzione da un brief di prodotto a un PRD completo. La versione su cui lavoriamo dipende dal punto in cui ci troviamo nel ciclo di sviluppo di una caratteristica o di un prodotto.

Vediamo come si evolve il documento nel passaggio da una fase all’altra.

1. È meglio iniziare con un brief di prodotto quando stiamo risolvendo lo spazio del problema.
   Lo spazio del problema è il luogo in cui ci si concentra sull’identificazione e la prioritizzazione dei problemi più importanti da risolvere per ottenere risultati aziendali specifici.

Un brief di prodotto è il più appropriato in questa fase, perché si tratta di ottenere il parere della leadership aziendale sull’opportunità di investire nella soluzione del problema. Un brief di prodotto conciso ci permette di ottenere un feedback costruttivo senza entrare in troppi dettagli inutili, lasciando spazio all’indagine e al dialogo.

Iniziare con un brief di prodotto è comune per i progetti di ampio respiro, come il lancio di un nuovo programma, il miglioramento dell’onboarding degli utenti o l’aumento della retention del prodotto.

Un brief di prodotto include tipicamente le descrizioni di quanto segue:

• Opportunità: Qual è il problema che stiamo cercando di risolvere? Per quale/i segmento/i di pubblico? Perché stiamo dando priorità alla sua risoluzione?
• Prove di supporto: Quali prove abbiamo per convalidare questa opportunità e perché siamo nella posizione migliore per risolverla?
• Metriche di successo: Quali sono gli indicatori qualitativi e quantitativi chiave che ci diranno se abbiamo affrontato o meno questa opportunità?
• Non obiettivi: Cosa non stiamo risolvendo e perché? Dato che non stiamo risolvendo queste cose, che impatto ha sul possibile successo o fallimento?

Alcuni brief includono anche ipotesi emergenti sulla portata della soluzione o sull’esperienza dell’utente.

2. È comune espandere un brief di prodotto in una specifica di prodotto una volta risolto lo spazio del problema e spostata la nostra attenzione sullo spazio della soluzione.
   Lo spazio della soluzione è quello in cui ci si concentra sulla soluzione di problemi importanti che sono già stati identificati e assegnati.

Una specifica di prodotto è più appropriata in questa fase, perché abbiamo spostato la nostra attenzione sulla creazione della visione complessiva della funzione o del prodotto con i responsabili interfunzionali, nonché sull’allineamento di un approccio di alto livello.

L’uso di una specifica di prodotto è comune quando si desidera suddividere i progetti di ampio respiro in parti più piccole e di medio respiro. Continuando con l’esempio precedente, potrebbe trattarsi di migliorare l’onboarding degli utenti correggendo l’autenticazione OTP (one-time password) o di aumentare la retention del prodotto migliorando i livelli di servizio.

Per trasformare il vostro brief in una specifica di prodotto, dovrete fare quanto segue:

Riassumere o collegare i documenti che coprono l’area del problema.

Concentrare il resto della specifica sui seguenti punti:

• Ambito: Quali sono le storie chiave dell’utente a cui si rivolge questa funzione? Quali sono i requisiti funzionali che rientrano nell’ambito di questo progetto? Quali di questi requisiti sono indispensabili e quali invece sono da considerare come “piacevoli”?
• Esperienza: Come vogliamo che sia il flusso dell’esperienza utente?
• Rischi: Quali presupposti o ipotesi potrebbero rivelarsi falsi e come pensiamo di testarli? Quali sono le domande aperte a cui dobbiamo rispondere e come pensiamo di farlo?

Non è necessario che le specifiche del prodotto siano finalizzate prima di poter procedere con lo sviluppo. Dovete solo documentare abbastanza informazioni per avviare una conversazione significativa e poi iniziare a costruire.

È giusto, e anzi incoraggiato, tornare sulle specifiche del prodotto e iterarle in seguito, man mano che si costruisce e si scoprono intuizioni che non si conoscevano prima.

Ad esempio, quando Natalie stava costruendo un nuovo prodotto per il mercato dei contenuti presso Quizlet, il suo team inizialmente pensava che fosse un requisito per consentire agli studenti di noleggiare anziché acquistare i contenuti, in modo da spendere meno. Quando il team ha iniziato a testare i prototipi, è emerso chiaramente che gli studenti in realtà odiavano questo concetto e ritenevano che il noleggio fosse una fregatura economica.

3. Possiamo evolvere ulteriormente la nostra specifica di prodotto in un PRD completo una volta che abbiamo una visione e un approccio generale alla soluzione.
   Un PRD completo è più appropriato in questa fase perché ora dobbiamo collaborare con i CI interfunzionali per definire il piano di lancio e i dettagli di esecuzione per dare vita alla soluzione.

Per far evolvere la vostra specifica in un PRD completo:

• Inserire il riepilogo dello spazio del problema
• Includere la versione più recente e perfezionata delle sezioni Ambito, Esperienza e Rischi.

Aggiungere quanto segue:

• Implicazioni tecniche: Che cosa, se c’è qualcosa nei requisiti funzionali, ci aspettiamo che alteri significativamente l’esperienza dell’utente? Quali metriche devono essere strumentate all’interno del prodotto per raccogliere dati sull’utilizzo delle funzionalità?
• Piano GTM: Qual è il programma di lancio delle funzionalità per gli utenti? Per ogni fase, quanti utenti raggiungeremo e per quanto tempo?
• Piano di sviluppo: Quali sono i prossimi passi o le azioni necessarie per realizzare questo piano GTM? Chi è il responsabile diretto (DRI) di ogni azione? Quando deve essere realizzato ogni elemento?

È importante creare questi nuovi componenti – implicazioni tecniche, piano GTM e piano di sviluppo – in collaborazione con le controparti di progettazione e ingegneria.

Lo scopo del PRD non è quello di imporre il modo in cui il resto del team lavorerà. Al contrario, deve essere utilizzato per fornire uno spazio in cui il team possa costruire collettivamente un piano di esecuzione che vada bene per tutti.

Come sapere se il PRD permette di progredire

I team di prodotto più esperti sanno che la costruzione è raramente un processo lineare. Cercare di descrivere esattamente ciò che si incontrerà prima di iniziare un progetto è una follia e crea un falso senso di certezza nel processo.

“I migliori PRD che ho visto illustrano la montagna che stiamo cercando di scalare, i primi passi che siamo disposti a fare e le considerazioni generali che stiamo facendo mentre ci muoviamo lungo il percorso sconosciuto che ci attende”.

Antonio Manzo

Ecco perché vi invitiamo a considerare il vostro PRD come uno strumento che consente di progredire, piuttosto che come uno strumento che impone un piano prestabilito.

Per verificarlo, ecco alcune domande di riflessione per voi e per il vostro team:

I vostri PRD consentono l’allineamento?

Riuscite ad articolare chiaramente ciò che state cercando di fare e perché?

Riuscite a modificarlo in modo appropriato per i diversi destinatari?

Riuscite a evidenziare dove è probabile che ci sia accordo o disaccordo?

In caso contrario, iniziate con il brief di prodotto, quindi identificate le aree in cui il vostro team è d’accordo e in disaccordo prima di andare avanti.

I vostri PRD sbloccano la collaborazione interfunzionale?

Ricevete feedback e opinioni preziose da marketer, analisti, data scientist o chiunque altro sia fondamentale per questo progetto?

Le riunioni e le discussioni generano chiarezza, fiducia o connessione?

In caso contrario, iniziate con le specifiche del prodotto, quindi identificate quali collaboratori x-funzionali devono essere inclusi e cosa renderebbe più facile il loro coinvolgimento.

I vostri PRD mettono alla prova il pensiero?

Siamo diventati più intelligenti riguardo allo spazio del problema, allo spazio della soluzione o al motivo per cui pensiamo che questo sia un lavoro utile da fare?

È chiaro agli altri perché lo stiamo facendo?

Siamo in grado di avere conversazioni significative sui compromessi e sui rischi che portino effettivamente a un processo decisionale?

In caso contrario, chiedete a qualcuno al di fuori del vostro team (magari un altro PM) di leggere la vostra specifica di prodotto o il PRD completo e di evidenziarvi quali sono le aree meno chiare e dove si sono confusi.

I vostri PRD sbloccano l’esecuzione?

I designer, gli ingegneri e gli addetti al marketing hanno abbastanza chiarezza su ciò che stiamo costruendo e perché, in modo da poter fare passi significativi verso la costruzione?

Siamo in grado di tenere conto di obiettivi e tappe chiare?

In caso contrario, tornate alle vostre specifiche di prodotto e lavorate con i vostri designer e ingegneri per identificare i grandi rischi e gli ostacoli all’inizio.

I vostri PRD chiariscono cosa si intende per successo?

Abbiamo chiarito cosa si intende per successo, in modo da non illuderci a posteriori e non cadere nella fallacia del Texas Sharpshooter?

In caso contrario, assicuratevi che il brief di prodotto, le specifiche di prodotto e il PRD completo siano tutti allineati sull’aspetto del successo. Assicuratevi che tutti i membri del team siano in grado di definire il concetto di successo prima di iniziare a costruire.

Creare PRD migliori per il futuro

Analizziamo il punto in cui siamo arrivati.

In primo luogo, le PRD dovrebbero rendere più facile la costruzione dei prodotti. E costruire prodotti è più facile quando si ha ben chiaro cosa si vuole costruire

• Capite perché è importante risolvere quel problema e come sarà il mondo quando lo risolverete.
• Chiarite i rischi e le cose che state facendo per mitigare questi problemi

Può prevedere quali saranno gli ostacoli che si frapporranno alla realizzazione del progetto e può chiedere supporto quando ne ha bisogno.

Imparare da ciò che si è fatto e non commettere più gli stessi errori.

Questi risultati sono più facili se i PM vedono i PRD come uno strumento dinamico di riflessione piuttosto che come un documento statico.

L’evoluzione di un PRD può seguire l’evoluzione ideale dello sviluppo di un prodotto, iniziando con un brief di prodotto per allinearsi sul problema che si sta risolvendo e sul perché è importante. Poi, una specifica e un PRD completo possono fornire l’impalcatura per decidere quale soluzione perseguire e, infine, per costruirla.

Una volta che iniziate a considerare il PRD come una guida in evoluzione per sbloccare la fase successiva di sviluppo, vi toglierete la pressione di cercare di renderlo perfetto e potrete accontentarvi di un risultato sufficiente.

Se siete alla ricerca di un ulteriore supporto su come costruire un PRD dinamico, siamo a vostra disposizione. Contattaci subito