Cos’è un documento dei requisiti di prodotto (PRD)?

Una panoramica del documento prototipico di gestione del prodotto

Kenton Kivestu, ex-Google, ex-BCG, fondatore di RocketBlocks Pubblicato: 11 settembre 2019 | Ultimo aggiornamento: November 8, 2019

Fondamenti del PRD | Contenuti del PRD | PRD walkthrough | Esempio completo di PRD

Un PRD è un insieme strutturato di linee guida per ciò che un prodotto (o una caratteristica) dovrebbe essere.

In definitiva, i PRD sono i goldilocks dei documenti di sviluppo prodotto: non può essere troppo “pie in the sky” (es, un comunicato stampa) né può essere troppo tecnico (ad esempio, un piano dettagliato di implementazione ingegneristica).

Quindi, un modo utile per pensare a un PRD è il documento ponte che può prendere la visione di alto livello del prodotto e definirla e portarla abbastanza da permettere a un ingegnere di scrivere un piano di implementazione credibile a partire da essa.

Perché le aziende si preoccupano di scrivere i PRD? I PRD servono come un artefatto di base che stabilisce la ragione d’essere di un prodotto/funzione rispondendo a domande fondamentali: Perché dovremmo costruirlo? Quale problema risolverà? A cosa dovrebbe assomigliare? Come sarà il successo?

Quali aziende usano i PRD e chi li scrive? (Top)

Inoltre, la nomenclatura preferita varia da azienda ad azienda (e talvolta anche da team a team!). Per esempio, Google storicamente si riferisce a questi documenti come PRDs, mentre l’azienda di giochi Zynga si riferisce ad essi come specs, che è l’abbreviazione di product specifications.

Infine, i product manager sono spesso gli autori dei PRDs ma non è vero in tutti i casi. In particolare, nelle aziende più piccole e nelle startup, una PRD potrebbe essere scritta da un fondatore, un CTO, un capo ingegnere o un altro leader che aiuta nello sviluppo del prodotto. Ma, indipendentemente da chi scrive un PRD, l’input dei membri chiave del team interfunzionale è fondamentale per produrre un buon PRD.

Quali sezioni e contenuti dovrebbero essere inclusi in un PRD? (Top)

I team che usano i PRD tendono a stabilirsi su una lista di sezioni “must have” in un PRD che hanno senso per le dimensioni della loro organizzazione, la cadenza di rilascio, la fase del prodotto e la complessità. Qui ci concentreremo su una manciata di sezioni “sospette” che sono comunemente incluse in molti PRD:

• Contesto & logica: perché lo stiamo costruendo?
• Obiettivi & metriche di successo: qual è l’obiettivo concreto di fare questo?
• Casi d’uso: quali casi d’uso specifici dovrebbe abilitare?
• Requisiti: cosa deve essere costruito?
• Domande aperte: a quali domande bisogna rispondere prima di iniziare?

Per esaminare ciascuna di queste sezioni del PRD, immaginiamo di scrivere un PRD per una piccola aggiunta all’app mobile di Uber rivolta ai passeggeri. Immaginiamo di scrivere un PRD per aggiungere un piccolo frammento di testo descrittivo alla pagina che Uber mostra ai passeggeri quando aprono l’app dopo una corsa completata (screenshot sotto).

Esempio di PRD: aggiornamenti dell’app Uber per i motociclisti (in alto)

Ora, entriamo e passiamo attraverso ogni sezione e immaginiamo come potrebbe essere un PRD che affronta questo problema.

Sezione 1: Contesto & motivazione

Questa sezione dovrebbe delineare il contesto centrale che illumina il motivo per cui una particolare caratteristica o prodotto è stato preso in considerazione. Potrebbe includere aneddoti dal team di supporto, osservazioni dalla ricerca UX, dati di mercato di supporto o intuizioni del team sulla direzione in cui il prodotto ha bisogno di evolvere.

A seconda della cultura del team e dello scopo della caratteristica, questa sezione potrebbe essere abbastanza breve o lunga. Alcune organizzazioni amano eseguire analisi dettagliate e altamente quantitative per giustificare la funzionalità.

Per il nostro esempio di PRD di Uber, potremmo immaginare qualcosa di simile a quanto segue:

Le recenti sessioni di ricerca sugli utenti hanno mostrato che molti passeggeri spesso saltano la valutazione del loro autista su questa schermata perché non riescono a ricordare quale autista stanno valutando (ad es, molti passeggeri non vedono mai il loro autista faccia a faccia, dato che sono nel retro).

Siccome le valutazioni degli autisti sono un importante set di dati per i nostri algoritmi e operazioni, ogni “spinta” che possiamo dare agli utenti per valutare gli autisti avrà un importante impatto composito sul business.

Sezione 2: Obiettivi & metriche di successo

Prossimamente, la sezione degli obiettivi, senza sorpresa, esporrà l’obiettivo specifico (o gli obiettivi) da raggiungere con la funzione / prodotto. Mentre la sezione del contesto dipingerà un quadro del perché il team potrebbe pensare che lo sforzo sia importante, la sezione degli obiettivi dovrebbe mettere un paletto specifico nel terreno su come l’azienda / il team / il prodotto ne beneficerà e come misurarlo.

Ritornando al nostro PRD di Uber, la sezione degli obiettivi potrebbe assomigliare a:

Condurre un aumento del 5% dei piloti che valutano gli autisti di fronte a questa schermata di valutazione del completamento della corsa.

Sezione 3: Casi d’uso

I casi d’uso spiegano come i clienti interagiranno con i cambiamenti della funzionalità proposta. L’obiettivo è quello di descrivere il contesto specifico in cui i clienti sperimenteranno la funzionalità e come questa aiuterà i clienti a completare compiti specifici.

Torniamo ancora una volta al nostro esempio di schermata di valutazione del completamento della corsa di Uber:

Travis ha recentemente preso un Uber il venerdì sera tardi dopo essersi incontrato con gli amici. Non usa più Uber fino al mercoledì successivo, durante un’intensa giornata di lavoro, e a quel punto apre l’app e vede il punteggio di completamento della corsa di venerdì sera. Non ricorda quando ha preso Uber l’ultima volta e non riconosce l’autista. Come risultato, preme il pulsante “Skip” piuttosto che valutare il conducente.

Sezione 4: Requisiti

Questa potrebbe essere considerata la “carne” di un PRD, dove si delinea ciò che viene effettivamente costruito. A seconda della caratteristica o del prodotto in questione, questa sezione potrebbe includere wireframe delle caratteristiche, mockup a piena fedeltà, dettagli su quali cambiamenti dovranno essere fatti sul front-end (per esempio, app mobili) e/o sul back-end (per esempio, database, elaborazione, ecc.).

Vediamo come potrebbe essere per l’esempio di Uber:

Front-end

• Visualizza un nuovo frammento di testo descrittivo sotto la richiesta di valutazione corrente
• Copia (esempio): “La tua corsa di venerdì sera”

API

• Quando si richiedono i dettagli della corsa (es, autista, immagine dell’autista, ecc.), prendi anche il descrittore della corsa (non c’è bisogno di costruire una nuova logica qui, basta usare gli stessi descrittori di corsa che già mettiamo nei soggetti delle ricevute delle corse via e-mail, invece dei timestamp specifici).

Sezione 5: Domande aperte

Infine, le domande aperte sono una sezione usata come una sorta di “parcheggio” per sollevare domande su cui l’autore ha bisogno di indagare, prendere una decisione o ottenere un feedback prima di considerare il PRD completato.

• Quale colore e dimensione dovrebbe avere il testo descrittivo sullo schermo? Cc @design – puoi raccomandare i parametri giusti qui?
• Quanto sono granulari i descrittori di corsa che vengono generati (es, diventano più specifici di, diciamo, venerdì sera?)
• Se questa funzione non produce i risultati desiderati, quali passi successivi dovremmo considerare?

Mettere tutto insieme: un esempio di PRD completo (Top)

Se mettete insieme tutto quello che abbiamo discusso, alla fine otterrete un documento simile a quello qui sotto (link al documento fittizio qui). NOTA: Questo *non* è un vero PRD di Uber – è un esempio rappresentativo e fittizio basato su uno scenario plausibile.

Anche una funzione estremamente semplice come quella descritta potrebbe generare un PRD di oltre una pagina! Come potete immaginare, funzioni più complicate possono finire per generare PRD molto, molto più lunghi dell’esempio discusso qui.

Sommario: pensieri finali sul PRD

Quello che abbiamo esaminato sopra è un’istantanea rappresentativa di come appare un PRD oggi.

Come detto, è un campione rappresentativo, ma dovrebbe fornire un’idea precisa di come potrebbe essere un PRD. Non siate sorpresi, però, se vedete diversi formati là fuori o diversi tipi di contenuti inclusi (ad esempio, una sezione di stime di lavoro da parte di un capo ingegnere su quanto tempo ci vorrà per costruire, ecc.) Per esempio, ecco un ottimo modello di PRD messo insieme da Kevin Yien, un Product Lead di Square.

Infine, le moderne piattaforme di comunicazione e gli strumenti di produttività come Slack, Google Docs, Notion, Quip, Office Online, Dropbox Paper, Asana, avranno un impatto significativo sull’evoluzione delle PRD nei prossimi decenni. Abbiamo già visto i PRD evolversi fino a diventare documenti “viventi” che taggano i collaboratori chiave, sollecitano commenti e feedback in linea e incorporano dati aggiuntivi (ad esempio, tabelle, screenshot, ecc.).

Tuttavia, detto questo, una cosa fondamentale non cambierà: la necessità di un tipo di documento di prodotto per allineare gli stakeholder, servire come un progetto di alto livello e tradurre la visione in requisiti di prodotto concreti.