Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Questo articolo è lo sviluppo teorico dell'esempio presentato nell'articolo Un file, qualche direttiva, e Claude fa il resto — come ho strutturato 500 email senza fatica Sviluppato in questo articolo Dal file unico al sistema di contesti: perché la memoria di un LLM non sta in un solo documento
Le organizzazioni di prodotto sanno già produrre documenti. Sanno scrivere PRD, inquadrare brief, alimentare roadmap, formulare ticket, documentare decisioni e preparare revisioni di prioritizzazione. In un'azienda di prodotto matura, il problema non è che nulla sia scritto.
Il problema è che molto di ciò che è scritto non capitalizza davvero il ragionamento.
Un PRD risponde a un'opportunità. Spiega cosa si vuole fare, per chi, perché, perché adesso, con quali ipotesi, quali rischi, quali impatti attesi e quali vincoli. È utile. Può persino essere indispensabile per allineare un team, un comitato di prodotto, una direzione o un'organizzazione go-to-market.
Ma una volta presa la decisione, gran parte di ciò che ha permesso di produrre quel PRD si disperde. I feedback dei clienti rimangono nelle trascrizioni. Le obiezioni commerciali rimangono nella testa dei sales. I vincoli di adozione rimangono presso i CSM. Gli arbitraggi rimangono in un verbale. I segnali deboli rimangono nel supporto. Le ragioni profonde della decisione rimangono nella memoria del PM.
Sei mesi dopo, l'organizzazione riparte quasi da zero.
Recupera documenti, torna a chiedere spiegazioni, ricostruisce argomenti, rilegge note, interroga di nuovo le stesse persone — o decide con una versione impoverita del contesto. Il costo non è solo documentale. È strategico: le prossime decisioni sono più lente, ma anche peggiori, perché non beneficiano pienamente del contesto già accumulato dall'azienda.
La posta in gioco non è quindi documentare meglio il prodotto. È costruire un sistema che riduca il costo delle prossime decisioni e ne migliori la qualità mobilitando tutto il contesto disponibile: feedback dei clienti, arbitraggi passati, segnali convergenti, conoscenza di settore, fonti affidabili, obiezioni commerciali, vincoli di adozione ed esempi provenienti da altri segmenti o situazioni.
Questa capacità diventa un vantaggio competitivo.
Il PM architetto di contesto non si distingue perché parla con i clienti. Si distingue perché trasforma la conoscenza del cliente in un asset organizzativo riutilizzabile: catturato, strutturato, collegato, condiviso e reiniettato nelle decisioni di prodotto e go-to-market.
In un mercato dove la tecnologia è più accessibile, il vantaggio non viene più solo da ciò che si può costruire. Viene dalla qualità del contesto che guida ciò che si sceglie di costruire.
Perché questo tema diventa strategico adesso
Per molto tempo, l'accesso a certe tecnologie poteva creare un vantaggio competitivo diretto. Un'azienda in grado di finanziare un'infrastruttura costosa, un database performante o sistemi complessi poteva andare più veloce dei suoi concorrenti, elaborare più volume o offrire capacità che altri non avevano.
Questo vantaggio era anche legato al capitale iniziale. A volte bisognava sborsare una somma importante prima ancora di aver validato il mercato o acquisito abbastanza clienti. Il costo di accesso alla tecnologia creava una barriera.
Quel mondo non esiste più. I blocchi tecnici sono molto più accessibili. Cloud, API, SaaS, IA…: gran parte dell'infrastruttura moderna si consuma per utilizzo. Si paga progressivamente, in funzione dell'uso, invece di dover finanziare massicciamente la capacità prima di aver validato il mercato.
La conseguenza è semplice: l'accesso alla tecnologia è meno spesso il fattore differenziante duraturo. Due concorrenti possono mobilizzare gli stessi cloud, gli stessi modelli di IA…
Produrre qualcosa non basta più. Produrre in fretta non basta sempre nemmeno.
La differenza si gioca nella pertinenza di ciò che si costruisce.
E questa pertinenza dipende dalla comprensione del contesto del cliente: le sfide reali, i vincoli economici, la regolamentazione, gli obblighi di prova, la cultura aziendale, le alternative, le abitudini organizzative, la distribuzione reale delle responsabilità, i costi nascosti, gli obiettivi, le paure e le cose non dette.
Le fonti pubbliche danno una base comune. Tutti possono leggere gli stessi white paper, le stesse pagine web, gli stessi rapporti e gli stessi contenuti di riferimento. Ciò che è molto meno copiabile sono le conversazioni private, le trascrizioni, le obiezioni, i racconti del quotidiano, i vincoli interni, le tensioni di adozione e gli arbitraggi realmente vissuti dai clienti.
La conoscenza del cliente diventa allora un asset strategico, a condizione di non restare materia prima.
Una conversazione, un verbatim o un segnale del cliente non diventano automaticamente contesto. Per essere riutilizzabili, devono essere trasformati in idee chiare, con fonte e collegate: un'obiezione, una sfida, un vincolo, una prova, un'alternativa, un arbitraggio. È questo lavoro di strutturazione che fa passare la conoscenza del cliente da materia prima ad asset organizzativo.
Il problema: il PRD è spesso una spesa, non un capitale
Il PRD è un buon esempio del problema.
In molte organizzazioni, serve a prendere una decisione o a lanciare un tema. Raccoglie abbastanza contesto per rispondere a un'opportunità precisa. Poi diventa un documento di riferimento locale, legato a un progetto, un'iniziativa, un periodo, un team.
Ma il ragionamento sottostante non viene sempre capitalizzato.
Prendiamo un PRD che giustifica una nuova capacità di reporting finanziario. Può contenere una sintesi chiara: problema, obiettivo, soluzione, dipendenze, rischi. Ma ciò che ha permesso di arrivare a quella sintesi è spesso molto più ricco.
L'approccio per contesto consiste nell'estrarre da questi documenti e conversazioni unità di conoscenza riutilizzabili: note atomiche, note tematiche, glossari, collegamenti (rete di conoscenza), prove, esempi e arbitraggi. Il PRD non è più l'unico luogo dove esiste il ragionamento. Diventa un output visibile di un capitale di conoscenza più profondo.
Una nota atomica è una nota centrata su un'unica unità di pensiero: un concetto, un'affermazione, una relazione tra due idee o una domanda precisa.
Non è necessariamente breve. È atomica perché ha un unico centro di gravità concettuale: tutto ciò che contiene serve la stessa idea.
Per un'organizzazione, il suo interesse è molto concreto: può essere compresa senza riaprire la fonte originale, collegata ad altre note, riutilizzata in più decisioni e arricchita nel tempo con nuovi esempi, fonti o contesti. Una nota atomica non è quindi né una citazione, né un estratto, né un riassunto di documento. È un blocco di ragionamento riutilizzabile.
Questa logica cambia l'economia del lavoro di prodotto.
Senza contesto capitalizzato, ogni PRD è uno sforzo locale. Con un contesto strutturato, ogni PRD arricchisce il successivo. La conoscenza non riparte da zero. Si densifica.
Cos'è un contesto, concretamente
Un contesto non è un sistema documentale.
Un sistema documentale archivia documenti. Un contesto di prodotto fa emergere, stabilizza e collega idee elementari provenienti da più fonti: feedback dei clienti, trascrizioni, sales call, ticket di supporto, note dei CS, decisioni passate, analisi competitive, dati d'uso, fonti affidabili e conoscenza di settore.
Un contesto non è un magazzino. È un sistema di interpretazione.
Lo si può leggere su tre livelli:
- I materiali grezzi: interviste, ticket, chiamate, verbatim, dati d'uso, fonti, decisioni.
- Le unità di capitalizzazione: note atomiche, note tematiche, glossari, prove, arbitraggi.
- Gli usi di business: PRD, roadmap, posizionamento, sales narrative, onboarding, analisi strategica.
Il sistema documentale conserva soprattutto il primo livello. Il contesto crea il passaggio tra tutti e tre.
Il contesto non aggiunge uno strato documentale. Trasforma materiali dispersi in blocchi di ragionamento riutilizzabili.
In un sistema documentale classico, un'idea può restare prigioniera di un documento lungo. Si sa vagamente che un argomento è già stato studiato, ma nessuno sa dove, con quale conclusione, a partire da quali prove, né in quali condizioni quella conclusione potrebbe essere riutilizzata.
In un sistema di contesto, il ragionamento viene scomposto in blocchi collegati. Una nota atomica stabilizza un'idea autonoma. Una nota tematica assembla più blocchi attorno a un angolo o a una tensione. Un glossario chiarisce i termini per evitare che ognuno usi le stesse parole con significati diversi.
Il formato conta meno del principio: atomicità, fonte, collegamento, riutilizzo.
Un'idea atomica può alimentare un PRD oggi, un arbitraggio di roadmap domani, una sales narrative tra tre mesi, un onboarding tra sei mesi o un articolo strategico più tardi. Può essere rafforzata da una nuova fonte, sfumata da un nuovo segmento, contraddetta da un caso limite o collegata a una decisione successiva.
Ecco perché l'approccio per contesto non chiede di documentare di più. Chiede di capitalizzare meglio.
L'IA accentua questo punto. Per un dirigente, il tema non è capire tecnicamente concetti come il RAG. Il tema è dare all'IA accesso ai giusti blocchi di conoscenza interna per recuperarli, ricollocarli nel giusto contesto e ricombinarli in una decisione, un brief, un posizionamento o un'analisi.
Il RAG permette di recuperare conoscenza per prossimità di idee, non solo per parole chiave.
L'interesse è semplice: anche se i team non usano lo stesso vocabolario, l'IA può recuperare le note, le prove o le decisioni che parlano di idee simili. Il RAG collega le idee più che le parole.
Un'IA collegata a un ammasso documentale produce sintesi fragili. Un'IA collegata a un contesto strutturato può aiutare l'organizzazione a recuperare i segnali giusti, gli arbitraggi giusti, gli esempi giusti e le prove giuste.
La qualità dell'IA dipende quindi dalla qualità del contesto che l'azienda ha costruito.
Come il contesto migliora la decisione
L'approccio per contesto non garantisce che una decisione sarà buona. Ma aumenta le probabilità che venga presa con una materia più completa, più collegata e più robusta.
Migliora la decisione su quattro dimensioni.
1. Riduce il costo della riscoperta. L'organizzazione non deve ogni volta ricostruire gli stessi argomenti, gli stessi vincoli o le stesse prove.
2. Migliora la qualità di lettura. Una richiesta attuale può essere confrontata con segnali passati, situazioni comparabili, decisioni precedenti, obiezioni commerciali e vincoli di adozione già osservati.
3. Rende più visibili i punti ciechi. Un PM può mancare una sfumatura. Un team può vedere soprattutto il proprio punto di vista. Ma un contesto che aggrega i feedback di PM, PMM, Sales, CS, Support, clienti e fonti esterne aumenta la probabilità di individuare ciò che una singola persona non avrebbe visto.
4. Rende gli arbitraggi più difendibili. Una decisione non è più sostenuta solo da un'intuizione o dalla memoria di qualcuno. Può essere collegata a prove, a segnali convergenti, a sfide di segmento e a scelte strategiche esplicite.
La prova non è una certezza matematica. Si costruisce per convergenza.
Il contesto non serve solo a decidere più in fretta. Serve a decidere con una memoria migliore, più prove, più sfumature e meno punti ciechi.
La meccanica: catturare, strutturare, collegare, condividere, reiniettare
Il PM architetto di contesto non è un documentalista. Non è nemmeno solo un intervistatore, un prioritizzatore o un redattore di PRD.
Il suo ruolo è trasformare una conoscenza dispersa in asset organizzativo.
Questa trasformazione si articola in cinque movimenti. È la modalità operativa minima di un'organizzazione che vuole fare del contesto un capitale.
Catturare. Il contesto si nutre di interviste, trascrizioni, sales call, feedback del supporto, scambi con i CS, monitoraggio di settore, intelligence competitiva, fonti affidabili, dati d'uso, decisioni passate e segnali deboli. Tutte le funzioni possono catturare informazioni sul cliente, ma non le analizzano con la stessa prospettiva.
Strutturare. Una richiesta diventa un segnale. Un segnale viene collegato a una situazione. Una situazione rivela una sfida. Una sfida viene associata a un segmento, a una strategia, a un vincolo, a una prova o a un'alternativa. Strutturare non significa ordinare con cura. Significa rendere l'informazione pensabile e azionabile.
Collegare. Un contesto utile connette oggetti che altrimenti resterebbero separati: un'obiezione commerciale e un limite di posizionamento, una friction di adozione e un vincolo culturale, una richiesta di feature e una sfida regolamentare, un ticket di supporto e un debito di comprensione del prodotto, un'alternativa competitiva e una categoria di mercato.
Condividere. Il contesto del cliente non può restare nella testa del PM. Deve circolare verso Product Marketing, Sales, CS, Support, direzione, design e ingegneria. Ma deve circolare senza impoverirsi. Una sintesi è utile, ma il materiale grezzo deve restare accessibile quando è necessario reinterpretare.
Reiniettare. Il contesto ha valore solo se torna nelle decisioni: roadmap, posizionamento, categoria, messaging, sales narrative, onboarding, servizio, contenuto, pricing, packaging, arbitraggi strategici.
Questa meccanica dà una direzione concreta. Non si tratta di creare una grande biblioteca di prodotto. Si tratta di costruire un ciclo che trasformi ciò che l'azienda impara in migliori decisioni future.
In pratica, un'organizzazione può iniziare con una domanda semplice: per ogni decisione importante, quali blocchi di contesto sono stati catturati, strutturati, collegati, condivisi e reiniettati? Se la risposta è vaga, il sistema dipende ancora troppo dalle persone e non abbastanza da un capitale collettivo.
Cosa cambia per il go-to-market
Il contesto del cliente non è solo un asset di prodotto. È un asset go-to-market.
Lo stesso blocco di contesto può essere riutilizzato da più funzioni — ma non per produrre lo stesso deliverable.
Una sfida regolamentare ricorrente può alimentare una decisione di roadmap lato Product, un messaggio di differenziazione lato Product Marketing, una prova di valore lato Sales, un percorso di adozione lato CSM e un contenuto rassicurante lato marketing. Il valore non viene dal copiare la stessa informazione ovunque. Viene dal fatto che l'organizzazione dispone di un capitale comune, che ogni funzione può ricombinare secondo il proprio uso.
È un cambiamento importante. Senza contesto condiviso, ogni funzione ricostruisce la propria versione del cliente: il PM vede un problema di prodotto, il PMM vede un problema di percezione, il Sales vede un'obiezione, il CSM vede una friction di adozione. Queste letture sono tutte utili, ma restano deboli se non si connettono.
Con un contesto capitalizzato, queste prospettive arricchiscono la stessa memoria. Product capisce meglio cosa deve costruire. Product Marketing capisce meglio come rendere visibile il valore. Sales capisce meglio come far risuonare quel valore in una situazione concreta. Il CSM capisce meglio come il contesto evolve dopo l'acquisto.
Il contesto diventa allora un'infrastruttura comune di decisione e narrazione: alimenta la roadmap, il posizionamento, la sales narrative, l'onboarding, i contenuti, il pricing, il packaging e gli arbitraggi strategici.
Cosa cambia per il cliente
La conoscenza del cliente non serve solo a vendere meglio o a prioritizzare meglio. Può anche essere restituita al cliente sotto forma di capacità.
Si possono distinguere tre flussi:
- la conoscenza sui clienti: i loro segmenti, vincoli, comportamenti, obblighi, organizzazioni;
- la conoscenza proveniente dai clienti: i loro racconti, obiezioni, usi, aggiramenti, frustrazioni, arbitraggi;
- la conoscenza per i clienti: ciò che il prodotto restituisce loro per renderli più capaci.
Questa terza dimensione è spesso sottovalutata.
Un modulo di audit regolamentare, per esempio, non serve solo a spuntare una casella funzionale. Se aiuta il cliente a capire cosa deve fare, ad automatizzare parte del lavoro, a produrre prove e a sentirsi coperto da una base di conoscenze affidabile, lo rende più sereno, più produttivo e più competente.
Il buon prodotto non si accontenta di eseguire un compito. Migliora la capacità del cliente di far fronte al suo contesto.
Non costruire macchine fotografiche migliori; costruisci fotografi migliori. — Kathy Sierra, Badass: Making Users Awesome
Cosa deve cambiare in un'organizzazione
La domanda pratica è dunque: cosa deve cambiare in un'organizzazione che vuole funzionare per contesto?
Deve innanzitutto smettere di considerare il PRD come il luogo principale del ragionamento di prodotto. Il PRD resta utile, ma deve diventare un output di un sistema di conoscenza più profondo.
Deve poi organizzare i materiali di conoscenza attorno a ciò che illumina davvero le decisioni: sfide, situazioni, prove, arbitraggi, segmenti coinvolti e decisioni passate.
Deve rendere accessibili le fonti grezze quando sono necessarie: trascrizioni, verbatim, sales call, ticket di supporto, feedback dei CS. Le sintesi sono utili, ma non devono eliminare la possibilità di reinterpretare.
Deve anche creare blocchi riutilizzabili: note atomiche, note tematiche, glossari, mappe di collegamenti, fasci di prove. Questi blocchi devono poter alimentare più deliverable: PRD, roadmap, posizionamento, sales narrative, onboarding, analisi strategica.
Deve infine instaurare un ciclo tra le funzioni. PM, PMM, Sales, CS e Support non devono possedere ciascuno una versione diversa del cliente. Devono contribuire a una memoria comune, mantenendo le proprie prospettive.
Il beneficio atteso non è solo documentale. È operativo e strategico:
- decisioni più rapide;
- decisioni più robuste;
- meno riscoperta;
- migliore onboarding di PM, PMM e leader;
- migliore coerenza tra prodotto, marketing e sales;
- migliore capacità di rilevare le sfide di segmento;
- migliore sfruttamento della conoscenza cliente non pubblica;
- migliore utilizzo dell'IA, perché la conoscenza interna è meglio strutturata.
Il contesto diventa allora un capitale.
Conclusione: il contesto è l'asset, il PRD è un output
Il backlog resta utile. Il PRD resta utile. Il brief resta utile. La roadmap resta utile. Nessuno di questi artefatti scompare.
Ma non dovrebbero essere il centro del sistema.
Dovrebbero essere gli output visibili di un capitale di conoscenza più profondo: un contesto di prodotto vivo, strutturato, interrogabile e riutilizzabile.
In un ambiente dove la tecnologia è più accessibile, dove i concorrenti possono mobilizzare gli stessi blocchi, dove i clienti confrontano più in fretta e dove le alternative si moltiplicano, la differenza si gioca nella capacità di capire con precisione cosa crea valore per un dato segmento.
Questa comprensione non può restare nella testa di poche persone. Deve diventare un asset organizzativo.
Il PM architetto di contesto è chi rende possibile questa trasformazione. Cattura i segnali, risale alle sfide, conserva gli arbitraggi, struttura le idee, collega le prove, rende visibili le contraddizioni, alimenta il posizionamento, illumina le sales narrative, nutre la roadmap e costruisce una memoria che l'organizzazione può riutilizzare.
Questo ruolo diventa tanto più strategico quanto più l'IA rende più facile la produzione di artefatti. Se tutti possono generare più velocemente brief, ticket, sintesi o varianti di messaggi, la differenza non verrà dal volume degli artefatti prodotti. Verrà dalla qualità del contesto su cui quegli artefatti si appoggiano.
Un'organizzazione di prodotto che sa trasformare le sue conversazioni private, i suoi arbitraggi e i suoi segnali convergenti in memoria riutilizzabile possiede qualcosa che i suoi concorrenti non possono copiare subito.
Non documenta solo il suo passato.
Costruisce la sua capacità futura di decidere.
Per saperne di più
Nel software, il vantaggio non sarà più la tecnologia. Sarà la comprensione del contesto. Perché una sola classificazione non basta per strutturare il feedback dei clienti Wiki IA: perché ho costruito una base di conoscenza mantenuta da un'IA Il secondo cervello è un vicolo cieco per il product management Cos'è una nota atomica? Cos'è una voce di glossario? Cos'è una nota tematica?