Che cos’è un product brief?

Un documento breve che dice cos’è un prodotto, quale problema risolve, per chi e cosa lascia volutamente fuori. Dà a chiunque lavori sul prodotto, persone e agenti, lo stesso punto di partenza.

In cosa un product brief è diverso da un PRD?

Il brief copre l’intero prodotto in una pagina. Un documento dei requisiti di prodotto (PRD) approfondisce una singola funzionalità o release e descrive esattamente come deve comportarsi. Parti dal brief; scrivi i PRD quando una funzionalità richiede quel livello di dettaglio.

Un agente di coding AI può usare questo brief?

Sì. Salva il file Markdown nel tuo repository e richiamalo da AGENTS.md oppure importalo in CLAUDE.md. AGENTS.md è semplice Markdown, e Claude Code legge CLAUDE.md all’inizio di ogni sessione.

Perché Markdown e JSON?

Il Markdown è facile da leggere per persone e agenti e viene visualizzato su qualsiasi piattaforma di hosting del codice. Il JSON ha lo stesso contenuto con chiavi fisse in inglese, così script e moduli possono leggerlo senza interpretare testo libero.

Il mio brief viene salvato o inviato da qualche parte?

Viene salvato solo nel local storage del tuo browser, così un ricaricamento non lo cancella. Nulla viene caricato o inviato a strumenti di analisi, e Cancella elimina la bozza.

Product brief template: modello gratuito Markdown e JSON

Di Aleksandar Vuk JovanovicAggiornato 30 settembre 2026Come verifichiamo e aggiorniamo

Compila il brief

Scrivi direttamente nei campi. Il Markdown e il JSON qui sotto si aggiornano mentre digiti e sono pronti da copiare o scaricare.

La bozza resta nel local storage di questo browser, così sopravvive a un ricaricamento. Non viene mai caricata. Cancella la rimuove.

Anteprima Markdown

# [Nome del prodotto]

> [Cosa fa, per chi, in una riga]

Ultimo aggiornamento: [data]

## Problema

[Chi fa fatica con cosa, oggi]

## Per chi è

[Utenti e acquirenti principali]

## Cosa fa

[Come il prodotto risolve il problema]

## Funzionalità principali

- [Fino a tre cose che fa già oggi]

## Al posto di

[Cosa si usa oggi e perché questo è meglio]

## Fuori perimetro

[Cosa volutamente non fa]

## Come capiamo che funziona

[Un segnale che puoi verificare]

## Link

[URL del sito o del repository]

Anteprima JSON

{
  "format": "product-brief",
  "version": 1,
  "language": "it",
  "updated": "",
  "name": "",
  "oneLiner": "",
  "problem": "",
  "audience": "",
  "solution": "",
  "features": [
    "",
    "",
    ""
  ],
  "alternative": "",
  "nonGoals": "",
  "success": "",
  "url": ""
}

File vuoti

Preferisci il tuo editor? Prendi il modello vuoto in uno dei due formati.

A cosa serve ogni campo

Dieci campi bastano per allineare persone e agenti su ciò che costruisci. Ognuno risponde a una domanda che altrimenti qualcuno ti farebbe.

Nome del prodotto: Tutti, agente compreso, devono scrivere il nome allo stesso modo. Scrivilo una volta qui.
Frase di presentazione: La riga che riutilizzerai nelle schede, nelle bio e sulla homepage. Se non riesci a scriverla, il prodotto non è ancora chiaro.
Problema: Il lavoro parte dal problema, non dalla funzionalità. Un problema chiaro permette ad altri di proporre soluzioni migliori della tua.
Per chi è: Un pubblico ristretto rende più facile ogni scelta successiva: parole, funzionalità, dove lanciare.
Cosa fa: Come il prodotto risolve il problema, in parole semplici. È la prima cosa che serve a chi arriva.
Funzionalità principali: Tre funzionalità che esistono oggi. Un agente che scrive testi non dovrebbe mai inventarne una quarta.
Al posto di: Le persone confrontano con ciò che fanno adesso. Nominare la soluzione di ripiego spiega il tuo valore meglio di una tabella di funzioni.
Fuori perimetro: Il campo che la maggior parte dei brief salta. Frena lo scope creep e impedisce a un agente di aggiungere funzionalità che non hai chiesto.
Come capiamo che funziona: Un segnale osservabile ti dice se il prodotto funziona e dà a un agente un obiettivo con cui confrontarsi.
Link: Un link permette a chi legge o a un agente di verificare i dettagli invece di indovinarli.

Verifica la tua tagline sui limiti di caratteri di ogni piattaforma →

Passa il brief al tuo agente

Gli agenti di coding leggono i file Markdown del tuo repository. Un brief breve accanto al codice dà loro il contesto di prodotto che il codice da solo non contiene.

Scarica il file Markdown e salvalo nel tuo repository, per esempio come docs/product-brief.md.
Indicalo al tuo agente: aggiungi una riga in AGENTS.md, oppure importalo in CLAUDE.md con @docs/product-brief.md.
Per GitHub Copilot, collega o copia l’essenziale in .github/copilot-instructions.md.
Tieni il JSON accanto quando uno script o un altro strumento deve leggere gli stessi fatti.
Aggiorna la riga della data a ogni modifica ed elimina le frasi che non sono più vere.

Tema	Dicitura ufficiale	Cosa significa per il tuo brief
Formato	AGENTS.md is just standard Markdown.	Un brief in semplice Markdown funziona come contesto per l’agente senza alcuna sintassi speciale.
Titoli	Use any headings you like; the agent simply parses the text you provide.	I nomi delle sezioni di questo modello sono un suggerimento. Rinominali se il tuo team usa altre parole.
Quando viene letto	You write these files in plain text; Claude reads them at the start of every session.	Claude Code carica CLAUDE.md all’inizio di ogni sessione, quindi un brief importato è sempre nel contesto.
Importazione	CLAUDE.md files can import additional files using @path/to/import syntax.	Basta una riga come @docs/product-brief.md in CLAUDE.md per includere il brief.
Lunghezza	target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.	Un contesto breve viene seguito meglio. Un brief di una pagina resta molto al di sotto di questa dimensione.
Copilot	Add natural language instructions to the file, in Markdown format.	Anche le istruzioni di Copilot sono in Markdown, quindi lo stesso testo va bene anche lì.
Codifica JSON	JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8	Il JSON scaricato è in UTF-8, quindi accenti, caratteri CJK ed emoji arrivano intatti in qualsiasi strumento.

Brief, PRD o file di contesto

Tre documenti che si confondono spesso. Rispondono a domande diverse e molti prodotti ne hanno bisogno di più di uno.

Documento	Risponde a	Lunghezza	Scritto da
Product brief (questo modello)	Cosa costruiamo, per chi e dove ci fermiamo	Una pagina, dieci campi	Founder o responsabile di prodotto
Documento dei requisiti di prodotto (PRD)	Come deve comportarsi esattamente una funzionalità o una release	Diverse pagine per funzionalità	Product manager insieme al team tecnico
File di contesto del prodotto	Quali fatti e testi approvati può pubblicare un agente	Cresce con ogni canale	Chi gestisce il lancio

Modello di piano di lancio →

Cosa lascia fuori questo modello

È un punto di partenza, non una specifica completa. Requisiti dettagliati, design e ricerche vivono nei loro documenti.
Prezzi, date di lancio e varianti dei testi di marketing sono volutamente esclusi.
La pagina non verifica se le tue affermazioni sono vere. Scrivi solo ciò che il prodotto fa oggi.
Non viene inviato nulla: la bozza resta in questo browser finché non premi Cancella.

Fonti

Abbiamo letto queste pagine il 30 settembre 2026 e le citiamo parola per parola qui sopra.

Pagina	Data sulla pagina	Verificato da noi
AGENTS.md	nessuna data indicata	30 set 2026
Claude Code Docs: How Claude remembers your project	nessuna data indicata	30 set 2026
GitHub Docs: Adding repository custom instructions for GitHub Copilot	nessuna data indicata	30 set 2026
RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format (December 2017)	nessuna data indicata	30 set 2026
CommonMark Spec, version 0.31.2	nessuna data indicata	30 set 2026

Domande frequenti

Che cos’è un product brief?: Un documento breve che dice cos’è un prodotto, quale problema risolve, per chi e cosa lascia volutamente fuori. Dà a chiunque lavori sul prodotto, persone e agenti, lo stesso punto di partenza.
In cosa un product brief è diverso da un PRD?: Il brief copre l’intero prodotto in una pagina. Un documento dei requisiti di prodotto (PRD) approfondisce una singola funzionalità o release e descrive esattamente come deve comportarsi. Parti dal brief; scrivi i PRD quando una funzionalità richiede quel livello di dettaglio.
Un agente di coding AI può usare questo brief?: Sì. Salva il file Markdown nel tuo repository e richiamalo da AGENTS.md oppure importalo in CLAUDE.md. AGENTS.md è semplice Markdown, e Claude Code legge CLAUDE.md all’inizio di ogni sessione.
Perché Markdown e JSON?: Il Markdown è facile da leggere per persone e agenti e viene visualizzato su qualsiasi piattaforma di hosting del codice. Il JSON ha lo stesso contenuto con chiavi fisse in inglese, così script e moduli possono leggerlo senza interpretare testo libero.
Il mio brief viene salvato o inviato da qualche parte?: Viene salvato solo nel local storage del tuo browser, così un ricaricamento non lo cancella. Nulla viene caricato o inviato a strumenti di analisi, e Cancella elimina la bozza.

Brief pronto? Porta il prodotto davanti alle persone.

LaunchRepo dà al tuo agente di coding un playbook per ogni piattaforma di lancio e directory, così il prodotto che hai appena descritto finisce dove il tuo pubblico guarda, e tiene traccia di quali schede sono online.

Vedi i prezzi