Modello di documento dei requisiti di prodotto (PRD)
Sei documenti collegati che portano una funzionalità dal problema al lancio: per chi è, cosa deve fare, come si svolge, come capirai che ha funzionato e ogni decisione lungo la strada. Scaricali come file Markdown: si aprono in qualsiasi editor, mostrano il loro diagramma su GitHub e in Obsidian e si importano in Nodary come una mappa.
6 file Markdown in un .zip, 6 kB
Gratis, senza account e senza email. Usalo, modificalo, condividilo.
Leggi ogni pagina prima di scaricarla
La panoramica sta in una schermata e collega cinque parti: sviluppo, design e supporto trovano ciascuno la propria pagina, e una modifica resta piccola. Le righe in corsivo dicono cosa scrivere; gli esempi seguono una sola funzionalità di esempio, link di condivisione che scadono.
Documenti
File Modello di PRD/Documento dei requisiti di prodotto.md
Documento dei requisiti di prodotto
Come usare questo modello: le righe in corsivo sono indicazioni. Sostituiscile con parole tue, poi cancellale. I valori tra parentesi quadre sono da compilare. Tieni questa pagina in una schermata: è ciò che legge per primo chi ha fretta, chi è appena arrivato o un agente IA.
In breve
| Campo | Questa funzionalità |
|---|---|
| Funzionalità | [Nome] |
| In una frase | [Cosa può fare l’utente una volta uscita] |
| Responsabile di prodotto | [nome] |
| Responsabile tecnico | [nome] |
| Responsabile design | [nome] |
| Stato | [bozza, in revisione, approvato, rilasciato] |
| Versione prevista | [data o versione] |
Problema
Chi ha il problema, quanto gli costa oggi e come lo sai. Un problema senza prove è un’ipotesi: collega la ricerca in Utenti e prove.
Esempio (una funzionalità di esempio): Alcune persone condividono un documento con un cliente per una revisione, poi dimenticano che il link esiste. Mesi dopo si apre ancora. Nell’ultimo trimestre tre clienti hanno chiesto come far smettere di funzionare un link in una certa data.
[Il problema, in due o tre frasi]
Obiettivi e non obiettivi
Gli obiettivi dicono cosa cambia per l’utente, non cosa costruisce il team. I non obiettivi sono le decisioni che impediscono al perimetro di crescere in silenzio.
- Obiettivo: [cosa l’utente può fare, o non deve più fare]
- Obiettivo: [...]
- Non obiettivo: [cosa questa versione lascia fuori di proposito]
- Non obiettivo: [...]
Il successo in una riga
La misura che ti dirà, un mese dopo il lancio, se ha funzionato. L’elenco completo è in Lancio e metriche.
[Metrica] passa da [valore iniziale] a [obiettivo] entro [data].
Il resto del PRD
Ogni parte è un documento a sé. Collegala invece di copiarla, così ogni fatto vive e cambia in un solo posto.
- Utenti e prove: per chi è la funzionalità e la ricerca dietro il problema
- Requisiti: cosa deve fare, con priorità e criteri di accettazione
- Design e flussi: il flusso, le schermate, gli stati e i casi limite
- Lancio e metriche: metriche, rilascio e checklist di lancio
- Decisioni e domande aperte: cosa è stato deciso, da chi e perché, e cosa resta aperto
Questo modello è libero da usare, modificare e condividere. Viene da Nodary, dove questi file si importano come una mappa di documenti collegati.
File Modello di PRD/Documento dei requisiti di prodotto/01 Utenti e prove.md
Utenti e prove
Per chi è la funzionalità e cosa sai di queste persone. Ogni affermazione qui deve rimandare alla sua fonte.
Per chi
| Chi | Cosa cerca di fare | Cosa glielo impedisce |
|---|---|---|
| [Utente principale] | [...] | [...] |
| [Utente secondario] | [...] | [...] |
Esempio (una funzionalità di esempio): Una account manager condivide la bozza di un’offerta con un cliente per una settimana di commenti. Oggi si mette un promemoria per disattivare il link, e a volte se ne dimentica.
Oggi, senza la funzionalità
Cosa fanno oggi gli utenti, passo per passo, scorciatoie comprese. La scorciatoia è spesso la migliore specifica che avrai.
- [Passo]
- [Passo]
- [Scorciatoia]
Prove
| Fonte | Cosa dice | Data | Link |
|---|---|---|---|
| [Intervista a un cliente] | [...] | [data] | [...] |
| [Ticket di supporto] | [...] | [...] | [...] |
| [Dati di utilizzo] | [...] | [...] | [...] |
Domande aperte
- [Domanda], [chi risponde], [entro quando]
File Modello di PRD/Documento dei requisiti di prodotto/02 Requisiti.md
Requisiti
Una riga per requisito, scritta come qualcosa che l’utente può fare. La priorità è obbligatorio, importante o facoltativo: una versione esce quando ogni obbligatorio è soddisfatto.
User story
| ID | Come | Voglio | Così da | Priorità |
|---|---|---|---|---|
| R1 | [utente] | [...] | [...] | [obbligatorio, importante, facoltativo] |
| R2 | [...] | [...] | [...] | [...] |
| R3 | [...] | [...] | [...] | [...] |
Esempio (una funzionalità di esempio): R1. Come persona che condivide un documento, voglio scegliere il giorno in cui un link smette di funzionare, così che un cliente perda l’accesso alla fine del progetto. Obbligatorio.
Criteri di accettazione
Per ogni requisito obbligatorio, le verifiche che dimostrano che funziona. Scrivile in modo che un tester, o un agente IA, possa eseguirle senza chiederti nulla.
| Requisito | Dato che | Quando | Allora |
|---|---|---|---|
| R1 | [una situazione di partenza] | [un’azione] | [il risultato che qualcuno può verificare] |
| R1 | [...] | [...] | [...] |
Requisiti non funzionali
| Ambito | Requisito |
|---|---|
| Prestazioni | [...] |
| Sicurezza e privacy | [...] |
| Accessibilità | [...] |
| Lingue | [...] |
| Compatibilità | [browser, dispositivi, versioni] |
Fuori perimetro
- [Cosa non fa questa versione, e perché]
- [...]
Domande aperte
- [Domanda], [chi risponde], [entro quando]
File Modello di PRD/Documento dei requisiti di prodotto/03 Design e flussi.md
Design e flussi
Collega i file di design invece di incollarli. Tieni qui il flusso e le decisioni che lo spiegano, così testo e schermate non si contraddicono mai.
Flusso utente
Il percorso principale, da dove parte l’utente a ciò che ottiene. Se il team non sa disegnarlo, non è ancora deciso.
- Punto di ingressoPrima azione
- Prima azioneScelta chiave
- Scelta chiaveConferma
- ConfermaRisultato
Mermaid
flowchart LR n0["Punto di ingresso"] n1["Prima azione"] n2["Scelta chiave"] n3["Conferma"] n4["Risultato"] n0 --> n1 n1 --> n2 n2 --> n3 n3 --> n4
Schermate
| Schermata | Scopo | Link al design | Stato |
|---|---|---|---|
| [Schermata] | [...] | [...] | [schizzo, mockup, finale] |
| [Schermata] | [...] | [...] | [...] |
Stati
Ogni schermata ha più stati del percorso felice. Spunta ciascuno quando è disegnato, o scrivi perché non può capitare.
- Vuoto: ancora niente da mostrare
- Caricamento
- Errore, con cosa può fare l’utente dopo
- Nessun permesso
- Connessione lenta o persa
- Testo molto lungo e numeri molto grandi
Casi limite
| Caso | Cosa succede |
|---|---|
| [...] | [...] |
| [...] | [...] |
Esempio (una funzionalità di esempio): Qualcuno apre un link un minuto dopo la sua data di fine: vede che il link è scaduto e a chi chiederlo, mai una pagina di errore.
Domande aperte
- [Domanda], [chi risponde], [entro quando]
File Modello di PRD/Documento dei requisiti di prodotto/04 Lancio e metriche.md
Lancio e metriche
Una metrica principale, due o tre secondarie e una metrica di guardia: qualcosa che non deve peggiorare mentre la principale migliora.
Metriche
| Metrica | Tipo | Valore iniziale | Obiettivo | Misurata con | Data di verifica |
|---|---|---|---|---|---|
| [...] | [principale] | [...] | [...] | [...] | [data] |
| [...] | [secondaria] | [...] | [...] | [...] | [...] |
| [...] | [di guardia] | [...] | [...] | [...] | [...] |
Rilascio
| Fase | Chi la riceve | Data | Si va avanti quando |
|---|---|---|---|
| [Interna] | [il team] | [...] | [...] |
| [Beta] | [...] | [...] | [...] |
| [Tutti] | [...] | [...] | [...] |
Checklist di lancio
- Articolo di aiuto scritto
- Team di supporto informato
- Nota di rilascio preparata
- Eventi di analytics verificati
- Ritorno indietro provato
Ritorno indietro
Cosa ti farebbe spegnere la funzionalità, e come. Decidilo prima del lancio, quando nessuno è ancora legato al risultato.
- Torniamo indietro se: [...]
- Come: [un flag, una versione, uno script]
- Chi decide: [nome]
File Modello di PRD/Documento dei requisiti di prodotto/05 Decisioni e domande aperte.md
Decisioni e domande aperte
Quando una decisione cambia il PRD, aggiungi una riga qui e aggiorna la pagina interessata. Il registro dice perché; la pagina dice cosa è vero adesso.
Registro delle decisioni
| Data | Decisione | Decisa da | Perché | Pagina modificata |
|---|---|---|---|---|
| [data] | [...] | [...] | [...] | [...] |
Esempio (una funzionalità di esempio): I link funzionano fino alla fine del loro ultimo giorno nel fuso orario del proprietario, non fino alla mezzanotte UTC. Deciso dalla responsabile di prodotto e dal responsabile tecnico, perché nella beta i clienti di altri fusi orari perdevano l’accesso un giorno prima. Pagina modificata: Requisiti.
Domande aperte
| Domanda | Chi risponde | Entro quando | Risposta |
|---|---|---|---|
| [...] | [nome] | [data] | [...] |
Come usarlo
Scrivi il problema prima della soluzione
Compila prima problema, obiettivi e non obiettivi della panoramica, con lo sviluppatore e la designer che costruiranno la funzionalità. Se voi tre non siete d’accordo sul problema, fermatevi lì.
Rendi verificabile ogni requisito obbligatorio
Dai a ogni requisito obbligatorio criteri di accettazione che un’altra persona possa verificare. Un requisito che nessuno può testare è un desiderio.
Fallo revisionare, poi tienilo aggiornato
Chiedi una revisione quando i requisiti sono pronti e aggiorna il PRD quando una decisione li cambia. Un PRD fermo al kickoff è sbagliato al lancio.
Annota cosa è cambiato e perché
Ogni decisione va nel registro delle decisioni con chi l’ha presa. Quando qualcuno chiede perché la funzionalità funziona così, la risposta è a un link di distanza.
Importalo in Nodary come mappa
Nodary è uno spazio di lavoro nativo per l’IA in cui i documenti di un team si collegano invece di accumularsi. Importa lo .zip e il PRD arriva con le sue cinque parti sotto di sé, i link tra le pagine mantenuti e il diagramma disegnato. Mettilo in revisione e chiedi a un proprietario o a un amministratore dello spazio o del progetto di approvarlo, guarda cosa è cambiato dalla tua ultima visita e lascia che gli agenti IA collegati via MCP leggano i requisiti prima di scrivere codice.
- Apri la mappa di un progetto e scegli «Importa».
- Scegli la scheda «Cartella o ZIP», poi «Scegli uno ZIP».
- Seleziona il file scaricato, controlla l’albero e importa.
Il piano Free contiene dieci documenti per spazio di lavoro, inclusa la pagina del progetto: i sei del modello entrano in un nuovo spazio con posto per altri tre. Nodary ha anche un modello di specifica di prodotto (PRD) di una pagina integrato.
Nodary per i team di prodotto e di sviluppo
Scrivere un PRD che il team usa davvero
Un PRD fallisce in due modi: descrive una soluzione che nessuno ha messo in discussione, oppure smette di essere aggiornato dopo il kickoff. Queste abitudini evitano entrambi.
Parti dal problema
Scrivi chi ha il problema e quanto gli costa prima di qualsiasi soluzione. I team d’accordo sul problema discutono meno delle schermate.
Di’ cosa non farai
Anche i non obiettivi sono decisioni. Scriverli è ciò che impedisce a una funzionalità di crescere di settimana in settimana.
Rendi i requisiti verificabili
“Veloce” e “semplice” non si possono verificare. “Il link smette di aprirsi entro un minuto dalla data di fine” si può costruire e testare.
Dai priorità: obbligatorio, importante, facoltativo
Una versione esce quando ogni requisito obbligatorio è soddisfatto. Importante e facoltativo sono ciò che scambi quando la data si avvicina.
Collega le prove
Ogni affermazione sugli utenti rimanda all’intervista, al ticket o ai dati da cui viene, così chi revisiona la verifica invece di crederci.
Tienilo vivo
Aggiorna il PRD quando una decisione lo cambia e annota perché. Alla fine deve descrivere ciò che è uscito, non ciò che era previsto la prima settimana.
Domande sul PRD
Che cos’è un PRD?
Un documento dei requisiti di prodotto (product requirements document, PRD) descrive una funzionalità o un prodotto prima che venga costruito: il problema che risolve, per chi è, cosa deve fare, come si misura il successo e cosa resta fuori. Di solito ne è responsabile un product manager; lo leggono sviluppatori, designer, supporto e, sempre più spesso, gli agenti IA di programmazione.
Cosa deve contenere un PRD?
Almeno il problema e le prove, obiettivi e non obiettivi, gli utenti, requisiti con priorità e criteri di accettazione, i flussi principali e i casi limite, le metriche di successo, il piano di rilascio e un registro di decisioni e domande aperte. Questo modello ha un documento per ogni gruppo.
Quanto deve essere lungo un PRD?
Abbastanza perché il team costruisca e testi la funzionalità senza farti due volte la stessa domanda. La panoramica deve stare in una schermata; i requisiti crescono con le decisioni, non con le idee.
Che differenza c’è tra un PRD e un documento di design tecnico?
Il PRD dice cosa deve fare la funzionalità e perché. Il documento di design tecnico dice come lo farà il sistema: architettura, dati, interfacce e rischi. Scrivi prima il PRD, poi collega i due.
Gli agenti IA possono usare il PRD?
Sì. Un PRD in documenti collegati dà a un agente il contesto di cui ha bisogno. In Nodary, gli agenti collegati via MCP, come Claude, ChatGPT o Cursor, leggono i requisiti e il registro delle decisioni con i tuoi permessi prima di scrivere.
Posso usare il modello fuori da Nodary?
Sì. I file sono semplice Markdown: Obsidian apre la cartella decompressa come un vault con tutti i link funzionanti, e GitHub mostra i file con il loro diagramma. Gli strumenti che importano il Markdown un file alla volta conservano testo e tabelle; verifica come trattano i link tra file.
Tieni i requisiti dove lavora il team.
Importa il modello in Nodary e il PRD diventa una mappa che il tuo team e i tuoi agenti IA tengono aggiornata. Gratis con due membri, un progetto e dieci documenti, senza carta.