Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Il bisogno
Lavorare con un LLM su un argomento complesso — un'opportunità di prodotto, un monitoraggio strategico, un processo di discovery — va rapidamente oltre la semplice conversazione. Si accumulano fonti, decisioni, ipotesi, contraddizioni. Si torna il giorno dopo e il LLM ha dimenticato tutto. Si copia e incolla un file context.md sempre più grande, e a un certo punto non regge più.
Il problema non è che al LLM manchi intelligenza. È che manca di memoria strutturata.
Come ci sono arrivato
Ho iniziato come tutti. Su ChatGPT, conversando. Il problema è emerso subito: a ogni scambio, l'IA rigenerava l'intero documento. O solo una parte, ma senza accesso a ciò che c'era prima. Le dicevo «mostrami quello che abbiamo fatto sopra», rigenerava tutto, si perdeva un tempo enorme e il contenuto finiva per divergere.
Il passo successivo è stato passare a Claude Code — uno strumento che permette di conversare con un LLM lasciandolo scrivere direttamente in un file Markdown. Di tanto in tanto gli chiedevo di ristrutturare, potevo rileggere facilmente, o anche modificare io stesso il testo. Era meglio. Ma un file lungo non bastava ancora.
E soprattutto, è emerso un problema di fondo: il file è organizzato o per l'essere umano o per l'IA — mai per entrambi. L'IA ha bisogno di punti di riferimento per riprendere una sessione da dove si era fermata, memorizzare decisioni, recuperare fonti. L'essere umano ha bisogno di aggregare informazioni, validarle, suddividerle per tema o per rischio. Non la stessa struttura, non le stesse esigenze.
Così ho avuto due file. Uno per l'IA, uno per l'essere umano. Ha tenuto un po'. Ma entrambi sono finiti per gonfiarsi, e c'era di tutto in ciascuno — fonti, decisioni, ipotesi, direttive, mescolate nello stesso flusso.
Ho cominciato a separare. Un file di direttive a parte, che non parlava di una feature ma di come l'IA deve lavorare. Poi un file di definizioni. Poi altri. E a un certo punto, il clic: non bisognava più pensare in termini di file, ma di sistema di organizzazione. E poiché i LLM sono ispirati al cervello umano, forse anche la loro memoria dovrebbe esserlo.
Ecco, in versione semplificata, come si presenta un contesto strutturato:
<contexte>/
├── 00_mission/
│ ├── mission.md ← perché siamo qui
│ ├── directives.md ← come deve lavorare l'IA
│ └── load_manifest.json ← cosa caricare, in quale ordine
├── 01_active/
│ ├── active.md ← stato attuale + piano
│ └── decisions.md ← decisioni prese e perché
├── 02_checkpoints/ ← istantanee del contesto
├── 03_sources/
│ └── source_catalog.md ← indice delle fonti grezze
├── 04_notes/ ← note atomiche, collegate tra loro
├── 05_memory/
│ ├── journal/ ← cosa è successo (episodico)
│ └── synthesis.md ← cosa se ne ricava (lungo termine)
└── 07_outputs/ ← output prodotti
Ogni cartella ha un ruolo preciso. Niente è mescolato. E soprattutto, non si carica tutto a ogni sessione — si carica il nucleo (00_mission + 01_active), il resto su richiesta.
Ciò che conta davvero è il contesto
Ma prima di spiegare perché questa struttura funziona, bisogna porre una verità più ampia.
Ciò che fa eccellere qualcuno in un ambito è raramente la tecnica. È la profondità del contesto che ha interiorizzato.
Un buon commerciale non vende meglio perché padroneggia uno script. Vende meglio perché comprende le esigenze del suo cliente — i suoi vincoli, le sue paure, il suo vocabolario, ciò che non dice. Un buon product manager non fa un prodotto migliore perché conosce i framework. Lo fa perché ha capito il contesto dell'utente — le sue abitudini, i suoi punti di attrito, ciò che aggira per mancanza di alternative. Un sociologo non capisce un movimento sociale leggendo statistiche. Lo capisce cogliendo il contesto vissuto di un gruppo — i suoi codici, le sue tensioni interne, il suo rapporto con il mondo.
Il contesto è ciò che trasforma l'informazione in comprensione. Il resto — la decisione, l'azione, la produzione — ne deriva quasi meccanicamente.
Ed è esattamente ciò che manca quando si lavora con un LLM su un argomento che si prolunga.
Non si può mettere tutto in un solo file
Il cervello umano non funziona caricando tutto quello che sa in ogni istante. Scompone. Ordina. Separa ciò che è stabile da ciò che è in corso. Distingue una fonte grezza da una convinzione personale. Dimentica i dettagli per conservare i pattern.
Un LLM è simile — ma peggio. La sua finestra di contesto è finita. E più la si riempie, più la sua attenzione si degrada su ciò che è sepolto nel mezzo. Non è un'intuizione: ricercatori di Stanford lo hanno dimostrato in Lost in the Middle (Liu et al., 2024). La loro conclusione: un LLM recupera molto meglio un'informazione posizionata all'inizio o alla fine del suo contesto rispetto a una sepolta nel mezzo. Caricare un file di 3000 righe sperando che «capisca tutto» è come leggere ad alta voce un libro intero a qualcuno chiedendogli di ricordare ogni frase.
Ciò che serve è caricare solo ciò che conta per il compito in corso. E per farlo, bisogna aver suddiviso il sapere in pezzi navigabili.
Caricare il minimo, con il massimo impatto
Se il problema è chiaro — non si può caricare tutto — la domanda diventa: cosa caricare, e come?
La soluzione è avere un nucleo compatto che si carica sistematicamente: la missione (perché siamo qui), lo stato attuale (dove siamo), il piano (dove andiamo), le decisioni prese, le contraddizioni aperte e una scheda di ripresa. Questo nucleo sta in qualche file breve. Dà al LLM tutto quello che serve per essere operativo immediatamente, senza rumore.
Poi, in base alla necessità della sessione, si carica su richiesta: una fonte precisa che si vuole analizzare, una nota che si vuole arricchire, un checkpoint vecchio che si vuole confrontare. Il resto — le decine di fonti, le note atomiche, i diari di sessione — rimane su disco, accessibile ma non nella finestra di contesto.
Perché funzioni, serve un meccanismo che dica all'IA cosa caricare, in quale ordine e con quale priorità. È il ruolo di un manifesto di caricamento — una sorta di playlist del contesto. Prima: missione e stato attuale (il nucleo, sempre). Poi: i file raccomandati in base alla fase corrente. Infine: i file disponibili ma caricati solo se la sessione lo richiede. È come il piano del chirurgo: gli strumenti essenziali sono già lì, gli altri sono a portata di mano, ma non si mette tutto sul tavolo.
È esattamente quello che fa un esperto umano. Non rilegge tutto il fascicolo prima di ogni riunione. Ha interiorizzato l'essenziale, e va a cercare un documento preciso quando ne ha bisogno. La differenza è che un LLM non può interiorizzare — ha solo ciò che gli si dà. Da qui l'importanza di dargli il sottoinsieme giusto, non tutto.
Separare le fonti da ciò che si produce
Un errore frequente: mescolare tutto. La trascrizione di un'intervista, l'ipotesi che ne si trae, la decisione che si prende, l'output che si genera — tutto nello stesso file, nello stesso flusso.
Il problema è la tracciabilità. Quando tutto è mescolato, non si sa più da dove viene cosa. Non si sa più se un'affermazione è un fatto documentato o un'interpretazione. Non si sa più se una decisione è ancora valida o è stata sostituita.
Separare le fonti (la materia grezza) dalla memoria (ciò che se ne ricava) e dagli output (ciò che si consegna) non è burocrazia. È ciò che permette di mantenere un ragionamento affidabile nel tempo.
Un contesto ben strutturato produce più di quanto gli si chiede
Un problema classico nel product management: si scrivono molti documenti, ma non si trova mai ciò che si cerca. Le note di discovery dormono in un Google Doc. Il brief di prodotto è in Notion. Il verbale della riunione strategica è da qualche parte in Slack. L'informazione esiste, ma è dispersa, non collegata, inutilizzabile.
Quando si struttura un contesto attorno a un argomento — separando fonti, note, decisioni, memoria — succede qualcosa di potente. Quel contesto diventa una base riutilizzabile. A partire dallo stesso nucleo di conoscenza, si possono generare output molto diversi: un brief di release, user stories, un pacchetto di comunicazione (sintesi, newsletter, post LinkedIn), una presentazione per il comitato di direzione.
Non si riscrive tutto ogni volta. Si combinano i blocchi giusti del contesto per rispondere a un'esigenza precisa. Il LLM non inventa nulla — assembla ciò che è già lì, con la giusta granularità e il giusto angolo. È la differenza tra dettare un documento da zero e chiedere a un assistente che conosce già tutto il fascicolo di adattarlo a un nuovo formato.
È qui che la strutturazione passa da «buona pratica» a vantaggio reale: un contesto ben organizzato non è solo leggibile — è produttivo.
La fine del sequenziale
Il product management classico funziona per fasi: prima la discovery, poi si scrivono le spec, poi si consegna, poi si comunica. Ogni tappa aspetta la precedente. È pulito su un diagramma, ma è lento — e non riflette la realtà sul campo.
Con un sistema di contesti e un LLM, questa sequenzialità salta. La discovery non si ferma mai davvero. Si dialoga in continuo con l'IA per affinare, mettere in discussione, riformulare. Il contesto matura in permanenza, e gli output migliorano nel corso di questa maturazione — non alla fine di una fase, ma durante. Si può produrre un primo brief già dalla seconda sessione, farlo evolvere man mano che il contesto si arricchisce, e l'output finale non è che l'ultima iterazione di un documento cresciuto insieme alla riflessione.
Ma l'effetto più interessante è altrove. Quando si lavora così, si aprono molti contesti. Opportunità di prodotto, esplorazioni, monitoraggi. Alcuni non diventeranno mai una funzionalità. Non «servono a nulla» nel senso classico del termine. Salvo che questi contesti non sono isolati. Sono connessi. Un'esplorazione sulle abitudini di manutenzione industriale alimenta una riflessione sulla gestione degli asset. Un monitoraggio sui modelli di pricing SaaS illumina un'opportunità sulla monetizzazione di un modulo. Tre contesti che sembravano indipendenti convergono un giorno verso un quarto, che non sarebbe mai stato così ricco senza di loro.
È un cambiamento di postura. Non si lavora più nella modalità «un'idea → un output». Si coltiva una rete di contesti che si fertilizzano a vicenda. E il giorno in cui bisogna prendere una decisione di prodotto, il terreno è già pronto.
Idee precise, collegate tra loro
Questa rete di contesti funziona su larga scala. Ma all'interno di ogni contesto, lo stesso principio si applica alla scala delle idee.
Ciò che fa l'intelligenza — umana o artificiale — non è accumulare sapere. È collegare idee precise tra loro. E soprattutto idee lontane.
Un esempio. Nel campo dell'ottimizzazione degli orari — assegnare aule, risorse, fasce orarie sotto molteplici vincoli — uno degli approcci più efficaci si chiama Simulated Annealing (ricottura simulata). Nel 1983, Kirkpatrick, Gelatt e Vecchi pubblicarono su Science un articolo fondamentale: dimostrarono che un processo metallurgico — riscaldare un metallo e poi raffreddarlo lentamente affinché i suoi atomi trovino una configurazione stabile — può essere trasposto in un algoritmo di ottimizzazione combinatoria. Nessun legame evidente tra una fonderia e un orario di aule — eppure, quel trasferimento ha cambiato un intero campo di ricerca. Il collegamento esiste, a condizione di averlo colto.
È esattamente la promessa dello Zettelkasten — quel sistema di note atomiche inventato dal sociologo tedesco Niklas Luhmann, che descriveva la sua schedatura come un «partner di comunicazione» (Luhmann, 1981). Ogni idea è isolata, precisa ed esplicitamente collegata ad altre. Non si archiviano blocchi di testo. Si archiviano unità di pensiero, ognuna con i suoi collegamenti. Ed è in questi collegamenti che emerge l'intelligenza: quando una nota su un fenomeno fisico incrocia una nota su un problema di pianificazione, quando un'osservazione sul campo incontra un'ipotesi teorica letta sei mesi prima.
Applicato a un sistema di contesti per LLM, questo significa: non scrivere lunghe sintesi monolitiche, ma note brevi, ben titolate, ben collegate. Ogni nota è un punto. La rete di collegamenti tra questi punti è la mappa. Ed è questa mappa che permette — a un essere umano come a un LLM — di fare connessioni che un file piatto non permetterebbe mai.
È anche l'intuizione dietro A-MEM (Xu et al., 2025) — un sistema di memoria per agenti LLM direttamente ispirato allo Zettelkasten. Note strutturate, indicizzate dinamicamente, collegate tra loro. Un'architettura che dà all'IA i mezzi per navigare nella propria memoria piuttosto che caricare tutto in blocco.
Memoria a breve termine, memoria a lungo termine e il diritto di risalire il filo
Un cervello umano non ha un'unica memoria. Ne ha diverse, che funzionano su scale temporali diverse. È ciò che Atkinson e Shiffrin hanno formalizzato già nel 1968 con il loro modello multi-store: un registro sensoriale, una memoria a breve termine, una memoria a lungo termine. Endel Tulving ha poi affinato la distinzione nel 1972 separando memoria episodica e semantica. In concreto: la memoria di lavoro trattiene ciò che accade ora — una conversazione, un calcolo in corso. La memoria episodica archivia gli eventi vissuti — cosa si è fatto martedì, cosa ha detto il cliente in riunione. E la memoria a lungo termine consolida le verità durature — i riflessi, le convinzioni, i pattern interiorizzati a forza di esperienza. Un conducente esperto non pensa più a come cambiare marcia. Un product manager senior non riscopre a ogni progetto che gli utenti mentono nelle interviste. Queste conoscenze sono diventate automatismi.
Un sistema di contesti per LLM riproduce questa architettura. Il diario di sessione è la memoria episodica: ciò che è successo, quando, in quale ordine. La sintesi consolidata è la memoria a lungo termine: le conclusioni stabili, le decisioni validate, i pattern estratti da decine di sessioni. E i checkpoint sono le istantanee — lo stato completo del contesto in un dato momento.
Ma c'è una differenza fondamentale con il cervello umano. Un cervello dimentica — è addirittura il suo punto di forza, gli evita di saturarsi. Un file system, invece, non dimentica nulla. Ed è qui che entra in gioco l'auditabilità. In un sistema ben strutturato, ogni informazione raffinata — una convinzione di prodotto, una decisione strategica, un'ipotesi validata — può essere ricondotta alla sua origine. Dalla sintesi si risale al checkpoint che l'ha prodotta. Dal checkpoint alle sessioni. Dalle sessioni alle fonti grezze — l'intervista, l'articolo, il dato.
È lo stesso principio della scienza: una conclusione ha valore solo se si può risalire al metodo e ai dati che l'hanno prodotta. Quando uno stakeholder chiede «perché questa decisione?», la risposta non è «perché l'IA l'ha detto». È: «ecco il percorso: fonte → analisi → sintesi → decisione». Tutto è tracciabile, tutto è verificabile. La memoria non è una scatola nera — è una catena di prove.
Cosa cambia in concreto
Prima, il mio mestiere di product manager consisteva in buona parte nel produrre documenti. Molta documentazione. Alcuni pezzi richiedevano competenza — inquadramento strategico, arbitraggi di architettura, prioritizzazione. Ma molti altri erano produzione di contenuto a partire da informazioni già esistenti: documentazione di supporto, articoli di blog, newsletter, note di release, comunicazione interna. Lavoro necessario, ma ampiamente automatizzabile quando si dispone di un contesto solido.
Oggi è in corso di automatizzazione. Non perché l'IA sia «magica», ma perché un contesto forte, coerente e completo permette di generare questi output in modo quasi autonomo. La documentazione di supporto si deduce dalle decisioni e dalle spec. La newsletter si costruisce a partire dalle note di release e dal contesto di prodotto. Alcuni output sono automatizzati quasi al 100 %. Altri — le user stories, per esempio — richiedono ancora una revisione umana, ma la prima bozza è già solida.
Il cambiamento più profondo non è nella produzione. È nella materia prima. Prima, si scrivevano documenti per fare prodotti. Si redigevano output per poter consegnare software. Era l'output che contava — il documento finale, fisso, validato.
Oggi si scrivono contesti. Si conversa con l'IA — spesso ad alta voce, davanti allo schermo — per creare, arricchire, affinare il contesto. L'output non è più il punto di partenza del lavoro, è un sottoprodotto. Ciò che ha valore è il contesto stesso — e, come abbiamo visto, la rete di contesti connessi che si fertilizzano a vicenda.
Verso dove porta questo
Ciò che si profila è un cambiamento di postura del product manager. Si passa da qualcuno che fa molte cose da solo — discovery, spec, comunicazione, coordinamento — a qualcuno che gestisce un team di IA. Si conversa, si spiega il contesto, si mettono in discussione i risultati, si arbitrano le scelte. Il quotidiano assomiglia meno alla redazione e più al management.
Ed è un esercizio impegnativo. Spiegare un contesto a un'IA che non sa niente costringe a verificare che lo si capisce davvero. Rispiegare, riformulare, precisare — è uno specchio impietoso. Se il contesto è confuso nella tua testa, il risultato sarà confuso. L'IA non compensa l'approssimazione — la amplifica.
Naval Ravikant parla di specific knowledge — quella conoscenza che non si può insegnare, che non si riduce a un processo. Si può insegnare la contabilità. Si può anche automatizzarla, affidarla a un'IA. Ma esistono competenze che non sappiamo formalizzare. Perché una certa persona è eccellente in un ambito che non riusciamo a riprodurre? È conoscenza specifica — costruita dall'esperienza, dall'intuizione, dal contesto vissuto.
Credo che sia lì che l'essere umano si ricentra. L'IA si occupa di ciò che è formalizzabile: la produzione di contenuto, l'aggregazione, la messa in forma. L'essere umano conserva ciò che non lo è: l'opinione. Perché fare prodotto significa incrociare dati quantitativi e qualitativi, raccogliere segnali deboli — ma alla fine, avere una convinzione. E una convinzione non si delega.
Avere un'opinione significa a volte rischiare in modo sproporzionato. In una startup, alcuni scelgono di avere l'1 o il 2 % di possibilità di diventare un unicorno — e il 99 % di possibilità di fallire. Quale IA prenderebbe questa decisione? Assumersi rischi, mantenere posizioni nette, puntare su una visione che i dati non confermano ancora — un'IA non sa farlo. Non oggi, almeno. Ed è esattamente questo che dà a un editore di software la sua cultura, il suo colore, il suo DNA. Ciò che rende un prodotto non intercambiabile con un altro, anche quando le feature si assomigliano. Non è l'IA a creare questa differenza — è l'essere umano che c'è dietro.
Questo sistema di contesti non è un fine in sé. È uno strumento perché l'essere umano possa concentrarsi su ciò che sa fare meglio — pensare, decidere, avere un punto di vista — delegando il resto a un'IA che finalmente ha i mezzi per ricordare.
Questo sistema gestisce l'upstream — la riflessione, la strutturazione, la decisione. Ma sul lato downstream, un'altra trasformazione è in corso.
L'abbiamo vissuto tutti: una documentazione viene prodotta al momento della specifica, poi lo sviluppo avanza, si prendono decisioni, si fanno aggiustamenti in corsa — e nessuno ha il tempo di tornare ad aggiornare ogni spec, ogni changelog, ogni documento di supporto. Il risultato è sempre lo stesso: documentazione e codice finiscono per divergere. Più il prodotto invecchia, più il divario si allarga.
Oggi l'IA permette di invertire questo flusso. Quando il codice è sufficientemente pulito e documentato, lo si può rendere la fonte a partire dalla quale si ricostruisce tutto il resto: aggiornare una documentazione di supporto dopo una consegna, generare un changelog più affidabile, o ricostruire una specifica funzionale a partire dallo stato reale del prodotto anziché da un documento vecchio.
È quello che si può chiamare un approccio code centric. Il codice non è più solo l'output finale — diventa l'elemento centrale, la fonte di verità attorno alla quale gravitano e si rigenerano gli altri artefatti del prodotto. La stessa logica vale per il design: se si è in grado di ricostruire un design system a partire dal codice reale e di mantenerlo aggiornato, il mockup cambia di statuto — non rimane una rappresentazione fissa, diventa una base sfruttabile.
Esploro questa idea più in dettaglio in questo articolo.
Per saperne di più
Il PM come architetto del Contesto Aggiungere una memoria di sessione come in OpenClaw