Come si scrive un buon Product Requirements Document (PRD)?

Question

Accepted Answer

Un **Product Requirements Document (PRD)** spiega *cosa* stai costruendo, *perché*, e *come saprai che ha funzionato* — così l'ingegneria e il design possono costruire la cosa giusta senza continui chiarimenti. Un buon PRD è uno strumento di riflessione e un artefatto di allineamento, non una burocrazia.

## Una struttura PRD solida

```text
1. PROBLEM / CONTEXT → what problem, for whom, why now
2. GOALS & SUCCESS METRICS → what outcome, how measured
3. NON-GOALS → what this explicitly does NOT cover
4. USER STORIES / REQUIREMENTS → what it must do
5. UX → flows, wireframes, key states
6. EDGE CASES → errors, empty states, limits
7. DEPENDENCIES & RISKS → what could block or break this
8. OPEN QUESTIONS → known unknowns to resolve
```

## Inizia con il perché

La sezione più importante è quella del **problema e degli obiettivi**. Se il team comprende *perché* e *cosa significhi il successo*, spesso troveranno soluzioni migliori di quella che hai specificato. Un PRD che è solo una specifica di funzionalità perde questo aspetto.

## I non-obiettivi sono sottovalutati

Stabilire esplicitamente cosa è fuori portata previene lo scope creep e la trappola del "mentre siamo qui...". È altrettanto prezioso dei requisiti stessi.

## Insidie comuni

```text
✗ Over-specifying the HOW → boxes in engineering's better ideas
✗ No success metric → you can't tell if it worked
✗ Writing it alone → involve eng/design early to catch issues
✗ Treating it as fixed → a PRD is a living doc
```

## Perché è importante

La maggior parte dei rifacimenti proviene da disallineamento: il team ha costruito quello che gli è stato chiesto, non quello che era necessario.

Un PRD chiaro evidenzia questi gap *prima* che chiunque scriva codice.

Forza anche *te* a pensare il problema a fondo.

Se non riesci a scrivere chiaramente l'obiettivo e la metrica di successo, non comprendi abbastanza bene il problema per costruirlo ancora.