Product Decision Record: tracciare le decisioni di prodotto che strutturano l'azienda

Certe decisioni di prodotto ritornano ovunque.

Ritornano nel comitato di roadmap. Ritornano con i commerciali. Ritornano nel supporto. Ritornano nelle specifiche. Ritornano nei ticket. Ritornano con ogni nuovo grande cliente, con ogni nuova opportunità, con ogni caso limite un po' visibile.

Bisogna privilegiare il cliente o il fornitore in un marketplace?

Bisogna tradurre il prodotto in tutte le lingue richieste dai prospect?

Bisogna accettare un'eccezione per un segmento che potrebbe portare molto?

Bisogna aprire un perimetro se il prodotto non potrà ancora gestirlo correttamente?

Queste domande non sono feature. Non sono ticket. Non sono dettagli di esecuzione. Sono decisioni strutturanti.

E quando non sono documentate chiaramente, l'azienda le ridecide continuamente.

A volte con le stesse persone. A volte con altre. A volte con meno contesto. A volte sotto pressione commerciale. A volte nell'urgenza. A volte con una memoria parziale di ciò che era già stato arbitrato.

Il problema non è solo la perdita di tempo. Il problema è la perdita di coerenza.

Una decisione di prodotto importante non deve dipendere dalla memoria orale di chi era nella riunione.

Questo è precisamente il ruolo di un Product Decision Record.

L'ispirazione: gli ADR sul lato tecnico

I team tecnici conoscono già una pratica simile: gli ADR, Architecture Decision Records.

Un ADR è un documento breve che traccia una decisione architetturale. Spiega il contesto, le opzioni considerate, la decisione adottata e le sue conseguenze.

L'utilità è semplice: diversi mesi o anni dopo, una persona può capire perché è stata fatta una scelta tecnica.

Prendiamo un esempio.

Un'applicazione subisce un aumento di carico. I clienti sono più numerosi. Le consultazioni aumentano. I rallentamenti diventano frequenti. Il team decide allora di implementare una tecnologia di coda messaggi per elaborare certi messaggi in modo asincrono.

Questa scelta non è una feature.

Per un mese, gli sviluppatori lavoreranno forse su un progetto puramente tecnico. Dovranno formarsi. Dovranno modificare parte dell'architettura. Non consegneranno immediatamente un valore di business visibile per l'utente finale.

Ma questa decisione può eliminare un collo di bottiglia importante. Può permettere di assorbire dieci, venti o trenta volte il carico attuale aggiungendo server. Può anche liberare il commerciale, che potrà vendere nuovi accessi clienti senza temere che l'applicazione si blocchi.

Un ADR permette di documentare questa decisione.

Perché è stata presa? Quali opzioni sono state scartate? Quali conseguenze si accettano? Cosa permette? Cosa vincola?

Il Product Decision Record riprende questa logica, ma sul lato del prodotto.

Un PDR non è una decisione di feature

Un Product Decision Record documenta una decisione di prodotto strutturante.

Non un'opportunità.

Non una card Jira.

Non una specifica.

Non una feature.

Un PDR traccia una regola di decisione che l'azienda assume e che guiderà diversi prodotti, team o situazioni future.

Non dice: «ecco la funzionalità da costruire».

Dice piuttosto: «in questo tipo di situazione, ecco la regola che applichiamo».

Questa è una differenza importante.

Se si usano i PDR per documentare ogni arbitraggio locale, lo strumento diventa burocrazia. Perde la sua forza. Un buon PDR deve riguardare una decisione abbastanza strutturante da evitare decine di ridiscussioni.

Il suo valore sta nella sua rarità.

Un'azienda non dovrebbe produrre cinquanta PDR a trimestre. Pochi all'anno sono sufficienti. Cinque, dieci, quindici, venti al massimo secondo la dimensione e la complessità dell'organizzazione.

Un PDR deve essere abbastanza importante da essere tenuto a mente, o trovato rapidamente quando una domanda ritorna.

Esempio: marketplace, cliente o fornitore?

Su un marketplace esiste una tensione strutturale.

Quando nasce un conflitto, bisogna privilegiare il cliente o il fornitore?

Si può provare a fare entrambe le cose. Si può cercare un compromesso ogni volta. Si può trattare ogni caso come un'eccezione. Ma in molte situazioni bisogna scegliere.

Se l'azienda non documenta questa decisione, ogni team rischia di interpretarla a modo suo.

Il supporto vorrà preservare la relazione con il cliente.

Il team partnership vorrà proteggere i fornitori.

Il prodotto vorrà evitare di complicare le regole.

I commerciali spingeranno l'opzione che aiuta l'account più strategico del momento.

E ad ogni conflitto, la stessa domanda ritornerà.

Un PDR permette di fissare una linea guida:

In caso di conflitto, privilegiamo il cliente.

Questa decisione non descrive una feature. Non descrive nemmeno un flusso di lavoro preciso. Ma influenzerà decine di decisioni: regole di rimborso, politiche di contenzioso, messaggi di supporto, priorità di prodotto, arbitraggi operativi, comunicazione con il cliente.

Questo è esattamente il livello giusto per un PDR.

Documenta una decisione trasversale.

Rende esplicita la scelta.

Permette ai team di avanzare senza riaprire il dibattito ad ogni caso limite.

Esempio: le lingue in un SaaS

Prendiamo un altro caso, molto frequente nelle aziende SaaS.

I team commerciali vogliono vendere in diversi paesi. Un prospect tedesco chiede un'interfaccia in tedesco. Un prospect spagnolo chiede lo spagnolo. Un grande cliente italiano chiede l'italiano. Ogni opportunità sembra interessante.

Ma sul lato del prodotto, tradurre un'applicazione non consiste solo nel sostituire del testo.

Bisogna tradurre l'interfaccia. Mantenere le traduzioni. Testare le schermate. Adattare la documentazione. Formare il supporto. Gestire le email. Verificare i messaggi automatici. Seguire le evoluzioni. Evitare che alcune lingue diventino versioni degradate del prodotto.

Senza una decisione chiara, ogni nuovo prospect può riaprire il tema.

Un PDR può fissare la regola.

# PDR 004 — Lingue supportate per default

## Stato
Validato

## Decisione
Il prodotto è supportato per default in francese e in inglese. Qualsiasi altra lingua richiede una soglia minima di fatturato annuo firmato.

## Contesto
I team commerciali incontrano opportunità in diversi paesi. Ogni lingua aggiunge un costo di traduzione, manutenzione, supporto, documentazione e qualità del prodotto.

## Alternative considerate
- Tradurre tutte le lingue richieste: troppo costoso e difficile da mantenere.
- Supportare solo il francese: troppo limitante per lo sviluppo commerciale.
- Supportare francese e inglese per default, poi aprire le altre lingue sotto condizione.

## Decisione adottata
Francese e inglese sono supportati per default. Le altre lingue vengono aperte solo se i contratti firmati superano una soglia definita.

## Conseguenze
- Migliore controllo della qualità.
- Meno promesse commerciali difficili da mantenere.
- Alcune opportunità commerciali saranno rifiutate o rinviate.

## Condizioni di rivalutazione
La decisione sarà rivalutata se l'IA riduce fortemente il costo di traduzione mantenendo un livello di qualità accettabile, o se un nuovo segmento strategico impone una lingua.

Questo PDR non chiude definitivamente il tema.

Dà una regola attuale.

Permette ai commerciali di sapere cosa possono vendere. Permette al prodotto di rifiutare richieste senza rifare tutta l'argomentazione. Permette alla direzione di capire il costo reale di un'apertura linguistica.

E contiene una condizione di rivalutazione.

Se l'IA rende possibili traduzioni affidabili a basso costo, la decisione può cambiare. Se un nuovo segmento strategico impone una lingua, la decisione può cambiare. Se diversi contratti firmati giustificano l'investimento, la decisione può cambiare.

Ma se cambia, non si riscrive il vecchio PDR.

Se ne crea uno nuovo.

Cosa merita un PDR

Non tutte le decisioni di prodotto meritano un PDR.

Questo è anzi il punto più importante.

Un PDR deve rimanere raro. Altrimenti diventa una forma di documentazione aggiuntiva che nessuno legge.

Una decisione merita probabilmente un PDR se è trasversale, strutturante, duratura, costosa da invertire, suscettibile di essere ridiscussa, utile a diversi team, e abbastanza importante da influenzare diverse decisioni future.

Al contrario, una decisione probabilmente non merita un PDR se è locale, puntuale, legata a una sola feature, già coperta da una regola esistente, senza conseguenze durevoli, o troppo ovvia per essere ridiscussa.

Il test è semplice:

Se la decisione non eviterà nessuna ridiscussione futura, probabilmente non ha bisogno di un PDR.

Un PDR non è lì per documentare tutto ciò che decide il Product Manager.

È lì per documentare le scelte che strutturano il quadro in cui Product Manager, commerciali, supporto, operazioni e a volte la direzione prenderanno poi le loro decisioni locali.

Un formato breve, strutturato, sufficiente

Un PDR deve rimanere breve.

Il formato serve a evitare le dimenticanze, non a produrre un fascicolo burocratico.

Un template utile può assomigliare a questo:

# PDR <numero> — <titolo>

## Stato
Proposto | Validato | Sostituito da PDR <numero> | Abbandonato

## Data
YYYY-MM-DD

## Decisione
Una frase chiara.

## Contesto
Perché questa decisione è necessaria ora.

## Alternative considerate
- Opzione A: ...
- Opzione B: ...
- Opzione C: ...

## Decisione adottata
Cosa sceglie l'azienda.

## Ragioni della scelta
- ...
- ...

## Conseguenze
### Positive
- ...

### Negative
- ...

### Rischi
- ...

## Condizioni di rivalutazione
Cosa potrebbe giustificare un nuovo PDR.

## Decisori e persone consultate
- Decisore:
- Consultati:

## Riferimenti
- ...

Il contenuto esatto può variare.

Ma l'essenziale deve essere sempre presente: il contesto, la decisione, le alternative, le ragioni della scelta, le conseguenze, i decisori, e ciò che potrebbe far evolvere la decisione.

Il PDR non deve diventare un PRD.

Non deve descrivere tutta l'esecuzione.

Deve documentare il perché.

Non si riscrive la storia

Un PDR validato non si cancella.

Non si riscrive per nascondere un cambiamento di posizione.

Se occorre cambiare la decisione, si crea un nuovo PDR che sostituisce il precedente.

È essenziale.

Il PDR non è lì per dimostrare che l'azienda aveva sempre ragione. È lì per capire perché ha deciso quello che ha deciso in un dato momento.

Nell'esempio delle lingue, il primo PDR può dire: solo francese e inglese per default, altre lingue sotto condizione di fatturato firmato.

Due anni dopo, l'IA può cambiare il costo di traduzione. La qualità può diventare sufficiente. Il supporto può dotarsi di strumenti adeguati. Il prodotto può decidere che le lingue secondarie saranno ormai tradotte automaticamente, con revisione umana sui percorsi critici.

Non è una contraddizione.

È una nuova decisione in un nuovo contesto.

Il vecchio PDR rimane utile, perché spiega perché l'azienda aveva inizialmente rifiutato di tradurre ovunque. Il nuovo PDR spiega perché quel rifiuto non è più adatto.

Questa tracciabilità evita l'amnesia di prodotto.

Evita anche i processi interni assurdi: «Perché non l'abbiamo fatto prima?» Forse perché prima, il costo, la qualità, le risorse e il contesto commerciale non permettevano di farlo correttamente.

PDR, PRD, roadmap, backlog: non mescolarli

Un PDR non è un PRD.

Un PRD descrive cosa si vuole costruire.

Un PDR spiega perché l'azienda ha scelto una regola di decisione.

Una roadmap mostra cosa l'azienda fa, prepara, considera o rifiuta in un dato orizzonte.

Un backlog organizza il lavoro eseguibile, o presto eseguibile.

Un ticket scompone un'azione operativa.

Il PDR è a monte.

Può influenzare una roadmap. Può vincolare un PRD. Può spiegare perché certi ticket esistono o non esistono. Ma non li sostituisce.

È proprio perché rimane a questo livello che è utile.

Se un PDR scende troppo in basso, diventa una specifica travestita.

Se una roadmap cerca di fare il ruolo di un PDR, mescola comunicazione e regola di decisione.

Se un ticket porta una decisione strutturante, la rende invisibile al resto dell'azienda.

Ogni strumento deve rimanere al suo livello.

Il PDR non è burocrazia

È facile usare male i PDR.

Se ne possono creare troppi. Renderli troppo lunghi. Trasformarli in verbali. Usarli per coprirsi. Farli validare da troppe persone. Scriverli a posteriori per giustificare una decisione già imposta.

In quel caso, sì, il PDR diventa burocrazia.

Ma non è questo il suo uso normale.

Un buon PDR elimina burocrazia.

Evita di ripetere cinquanta volte la stessa spiegazione.

Evita di riaprire lo stesso arbitraggio con ogni grande prospect.

Evita di dipendere dalla memoria di una persona.

Evita ai team di navigare tra regole implicite, eccezioni non dette e decisioni contraddittorie.

La documentazione non è il problema.

La cattiva documentazione è il problema.

Un PDR breve, raro, chiaro e immutabile non appesantisce l'organizzazione. Le dà una colonna vertebrale decisionale.

Conclusione

Un'azienda di prodotto non manca solo di priorità.

Spesso manca di memoria sulle sue decisioni.

Sa cosa ha fatto, ma non ricorda sempre perché l'ha fatto. Ricorda una conclusione, ma non il contesto. Applica una regola localmente, poi la dimentica altrove. Riapre una discussione perché nessuno trova l'arbitraggio iniziale.

Il Product Decision Record serve a evitare questo.

Trasforma una decisione implicita in una regola esplicita.

Documenta le scelte di prodotto che strutturano l'azienda.

Permette di dire: «Abbiamo già deciso su questo tema. Ecco perché. Ecco le conseguenze che accettiamo. Ecco le condizioni che potrebbero farci cambiare.»

Un buon PDR non aggiunge uno strato di documentazione.

Elimina decine di discussioni inutili.

Per saperne di più

Perché le organizzazioni preferiscono le decisioni morbide Il PM come architetto del Contesto Gli strumenti di coerenza organizzativa La domanda prodotto deve partire dal codice sorgente