Come scrivere un product brief di una pagina che viene davvero usato

Dal team FabricLoop  ·  Maggio 2026  ·  4 min di lettura

La maggior parte dei brief di prodotto fa la stessa fine: scritti con cura prima che il progetto inizi, rivisti una volta in una riunione di kick-off e mai più riaperti. Quando il team è a metà sviluppo, il brief è ormai un reperto storico — citato ogni tanto nelle discussioni sull'ambito, ma di rado trattato come una guida viva per prendere decisioni.

Questo è un fallimento di processo, non di formato. Il brief non viene usato perché non è stato scritto per essere usato. È stato scritto per soddisfare un processo — per spuntare la casella "abbiamo definito i requisiti" — non per aiutare davvero il team a prendere decisioni migliori nell'incertezza.

Un brief che viene usato è breve, con una posizione chiara e strutturato intorno alle domande che il team si porrà davvero durante lo sviluppo: cosa stiamo risolvendo, per chi e come capiremo se ha funzionato?

Le cinque sezioni che contano

Tutto ciò che sta in un product brief dovrebbe rispondere a una di cinque domande. Se una sezione non risponde a nessuna di queste domande, probabilmente non appartiene a un brief di una pagina — appartiene a una specifica separata e più dettagliata.

Perché "fuori ambito" è la sezione più importante

I team dedicano molto tempo a scrivere ciò che costruiranno. Ne dedicano pochissimo a scrivere ciò che non costruiranno — e questa asimmetria è la causa della maggior parte dello scope creep. Quando il designer aggiunge un toggle per le "ore di silenzio" perché sembra ovvio, o l'ingegnere aggiunge impostazioni per workspace perché è già a lavoro in quell'area, di solito è perché nessuno ha deciso esplicitamente che erano fuori ambito.

Scrivere gli elementi fuori ambito costringe ad affrontare un confronto sui confini che altrimenti avverrebbe a metà sviluppo, quando cambiare rotta costa molto di più. Dà inoltre al PM una base chiara e documentata per dire no alle aggiunte: "Nel brief abbiamo deciso che era fuori ambito — ecco perché."

Domande aperte: la sezione che la maggior parte dei brief omette

Ogni progetto inizia con domande irrisolte. La maggior parte dei brief finge il contrario — sono scritti come se tutte le decisioni fossero state prese, anche quando l'autore sa che non lo sono. Il risultato è che i team scoprono le domande aperte durante lo sviluppo, quando sono più destabilizzanti.

Elencare esplicitamente le domande aperte ottiene due cose. Primo, fa emergere quali domande vanno risolte prima di iniziare il lavoro (bloccanti) e quali si possono decidere durante lo sviluppo (non bloccanti). Secondo, segnala al team che il brief è un documento di lavoro, non una specifica definitiva — il che rende più probabile che lo riprendano in mano e lo aggiornino man mano che si prendono le decisioni.