Come scrivere un PRD per l’IA di codice (con un prompt)
Aggiornata il
Un PRD (documento dei requisiti di prodotto) dice cosa stai costruendo, per chi e come capirai che funziona. Per un’IA di codice includi obiettivo, utenti, funzioni in ordine di priorità, schermate, regole, dati e criteri di accettazione verificabili. Meno l’IA deve supporre, più il primo risultato sarà vicino a ciò che volevi.
Cos’è un PRD e perché aiuta un’IA
PRD sta per product requirements document, il documento dei requisiti di prodotto: un testo breve che descrive quale prodotto vuoi, cosa deve fare e cosa resta fuori. In un team serve a far sì che tutti capiscano la stessa cosa prima che qualcuno scriva codice.
Lo stesso vale quando lavori con un’IA di codice. Se chiedi «un’app di to-do», riempie ogni vuoto con le sue supposizioni. Un PRD chiaro riduce quelle supposizioni, ti dà un riferimento con cui controllare il risultato e funziona da punto fermo ogni volta che apri una nuova conversazione.
Le sezioni da includere
- Obiettivo: il problema che il prodotto risolve, in una o due frasi.
- Utenti: chi lo userà e in quale situazione.
- Funzioni: cosa deve fare, in ordine di priorità (indispensabili, utili, per dopo).
- Schermate o flussi: cosa vede e cosa fa l’utente, passo dopo passo.
- Regole e limiti: cosa non deve mai succedere, ad es. che un utente veda i dati di un altro.
- Dati: quali informazioni si memorizzano e quali campi sono obbligatori.
- Criteri di accettazione: come verificherai che ogni funzione sia completata.
- Fuori ambito: cosa non costruirai in questa versione.
La sezione più utile e più dimenticata è «fuori ambito». Senza di essa, gli strumenti di IA tendono ad aggiungere funzioni che non hai chiesto.
Criteri di accettazione: la parte che noterai di più
Un criterio di accettazione è un’affermazione che puoi verificare con un sì o con un no. «Il modulo è facile da usare» non lo è. «Se l’indirizzo email non è valido, compare un messaggio di errore e il modulo non viene inviato» lo è.
- Scrivi ognuno come una situazione e un risultato: «Dato X, quando Y, allora Z».
- Copri anche i casi di errore, non solo il percorso in cui va tutto bene.
- Punta ad almeno due o tre criteri per ogni funzione importante.
Un prompt per scrivere la bozza del PRD con l’IA
Non devi scrivere il PRD da zero. Racconta l’idea a un’IA e lasciati intervistare. Poi rivedi tu il risultato: l’IA propone, ma le decisioni sono tue.
Comportati da product manager esperto di piccoli prodotti digitali. Voglio scrivere un PRD per questa idea: [descrivi il tuo prodotto in due o tre frasi]. Utente principale: [chi è]. Prima di scrivere qualsiasi cosa, fammi tutte le domande che ti servono, una alla volta, finché obiettivo, funzioni principali e ciò che resta fuori ambito non sono chiari. Quando hai informazioni sufficienti, scrivi il PRD con queste sezioni: obiettivo, utenti, funzioni per priorità, schermate o flussi, regole e limiti, dati, criteri di accettazione (nel formato «dato, quando, allora») e fuori ambito. Non inventare requisiti che non ti ho dato. Se manca qualcosa, segnalalo come «da decidere».
Come usare il PRD con uno strumento di codice
Non incollare un PRD lungo aspettandoti che tutto venga bene al primo colpo. Usalo come una mappa e costruisci per parti.
- Tieni il PRD come file nel progetto, così lo hai sempre a portata di mano.
- Chiedi prima un piano di sviluppo a passaggi e rivedilo prima che venga generato qualsiasi codice.
- Realizza una funzione alla volta, con i suoi criteri di accettazione.
- Quando ognuna è finita, controlla i criteri uno per uno.
- Se cambi idea, aggiorna prima il PRD e solo dopo chiedi la modifica.
Ecco il PRD del mio progetto: [incolla qui il PRD] Realizza solo questa funzione: [nome della funzione]. Deve rispettare questi criteri di accettazione: [elenco dei criteri]. Non aggiungere nulla di ciò che compare in «fuori ambito». Quando hai finito, spiega quali file hai modificato e come posso verificare ogni criterio.
Errori comuni nei PRD
- Scrivere desideri invece di requisiti verificabili («rendilo intuitivo»).
- Mescolare troppe idee: un PRD, un prodotto, una versione.
- Non indicare le priorità, così l’IA tratta tutto come ugualmente importante.
- Dimenticare i dati personali: se memorizzi informazioni sugli utenti, decidi cosa conservi e perché, e verifica le norme sulla protezione dei dati che ti riguardano attraverso fonti ufficiali.
- Non aggiornare il documento quando il progetto cambia.
Dal modulo al PRD con un modello
Il modello di PromptNow per i PRD destinati all’IA di codice chiede in un modulo il tuo prodotto, gli utenti e le funzioni, e produce un prompt pronto da incollare con la struttura descritta sopra. Ti evita la pagina bianca, ma il contenuto resta tuo e merita di essere rivisto.
Se non sei sicuro di cosa debba entrare nella prima versione, parti dal modello per definire l’MVP della tua app e usalo come base per il PRD.
Domande frequenti
Che cos’è un PRD?
Un documento dei requisiti di prodotto. Descrive cosa verrà costruito, per chi, quali funzioni ha, come verificherai che siano pronte e cosa resta fuori dalla versione attuale.
Quanto deve essere lungo un PRD per un’IA di codice?
Non c’è una lunghezza fissa. Deve essere abbastanza dettagliato da non costringere l’IA a indovinare le parti importanti, ma abbastanza breve da poterlo rivedere. Per un MVP, di solito bastano una o due pagine.
Può un’IA scrivere il PRD al posto mio?
Può aiutarti a scriverne la bozza se le dai contesto e la lasci intervistarti, ma le decisioni su cosa costruire e cosa lasciare fuori sono tue. Rivedi sempre il risultato.
Qual è la differenza tra un PRD e un prompt?
Il PRD descrive il prodotto e serve da riferimento. Il prompt è l’istruzione specifica per un singolo compito. Di solito si usa il PRD come contesto e si chiede lo sviluppo per parti.