Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Introduzione
Il «secondo cervello» potenziato dall'IA è ovunque in questo momento. Il principio: dai le tue fonti a un'IA, lei genera decine di note atomiche (un'idea per nota) e le collega tra loro per creare una rete di conoscenza connessa, ricca di significato.
Sulla carta è allettante. In pratica, per la gestione delle opportunità nel product management, credo che sia un approccio sbagliato.
Il mondo è complesso
Per capire perché, bisogna prima visualizzare l'aspetto di una rete di note atomiche su un argomento reale.
Ecco una piccola parte delle mie note su Pierre Bourdieu, tratte dai miei studi di sociologia:
Quando si comincia a confrontare con un altro sociologo — qui Niklas Luhmann, il padre del Zettelkasten — la complessità esplode:
E anche cercando di semplificare per grandi concetti, i legami restano densi. Implicazioni, antagonismi, legami deboli, relazioni indirette... Tutto è connesso, ma non nello stesso modo.
Il mondo è complesso. E il product management non fa eccezione.
Perché non funziona per il product management
Sono contrario a questo approccio per due ragioni.
La propagazione degli errori è incontrollabile
Quando si lavora con un'IA, bisogna sempre poter verificare ciò che produce. In una rete di note dove tutto è collegato, un errore in una singola nota può propagarsi silenziosamente attraverso le connessioni. Ti ritrovi a difendere un'opportunità basata su un'informazione falsa, senza nemmeno saperlo.
Con un insieme limitato di file — 30, 40 file in una directory dedicata a un'opportunità — hai la capacità umana di verificare, di fare un audit. In un grafo di centinaia di note interconnesse, è un'illusione.
La finestra di contesto esplode
L'altro problema è tecnico. Quando studi un'opportunità, hai bisogno che l'IA rimanga concentrata: il file di missione, i fatti acquisiti, i prossimi passi da validare. È un contesto leggero e controllabile.
Metti quella stessa IA di fronte a una rete di note senza confini: salterà da una connessione all'altra, farà crescere la sua finestra di contesto, cercherà la «giusta» informazione in un oceano di link. Troppa informazione uccide l'informazione.
Una rete di note non si gestisce da sola
E c'è un problema ancora più profondo. Una rete di note collegate tra loro non si mantiene per magia. Non appena il volume cresce, emergono nuove domande:
- Le incoerenze: due note si contraddicono. Quale fa fede? Senza un meccanismo esplicito per tracciare le contraddizioni, l'IA (e tu) costruite su fondamenta instabili.
- Le lacune: un'intera zona dell'argomento non è documentata. Ma come saperlo in un grafo di centinaia di note? Una lacuna invisibile è più pericolosa di una lacuna identificata.
- Le decisioni: hai scelto tra due opzioni tre settimane fa. Dove è annotato? La decisione è ancora valida? Chi l'ha presa?
Un file piatto o una rete di note non rispondono a queste domande. Serve una struttura di memoria dedicata — con file che traccino esplicitamente le contraddizioni, lo stato di completezza, le decisioni e le loro giustificazioni.
Ho dettagliato questo approccio in un articolo precedente: Dal file unico al sistema di contesti — perché la memoria di un LLM non sta in un singolo documento. Il principio: ogni missione ha il proprio spazio strutturato — missione, stato attuale, fonti, note, memoria cumulata, deliverable — con meccanismi espliciti per gestire ciò che la rete di note lascia nell'angolo cieco.
Quando si decide di studiare un'opportunità, si scommette su una tematica, una feature, un impatto. Si riduce lo scope volontariamente. Il sistema di note dovrebbe riflettere questa riduzione, non combatterla.
L'alternativa: il bounded context
Per questo preferisco un approccio in cui ogni opportunità vive nel proprio spazio delimitato, con i propri file. Se ho bisogno di informazioni provenienti da un altro dominio, non creo un link verso la fonte originale — copio e adatto quelle informazioni al contesto della mia opportunità.
Questo approccio riprende esattamente il concetto di bounded context del Domain-Driven Design.
Prendiamo un esempio concreto. Un sistema di paghe deve conoscere i giorni di ferie presi dai dipendenti questo mese. Invece di creare un link diretto verso il sistema di gestione delle ferie, si integrano quei dati nel dominio «variabili di pagamento». Si ottengono così delle ferie coerenti con il dominio della busta paga, invece di cercare di far entrare un concetto con tutto il suo contesto originale in un altro dominio.
Per il product management, la logica è la stessa. Ogni opportunità ha il proprio contesto, i propri file, la propria verità locale. Le informazioni esterne vengono importate e adattate, non collegate dinamicamente.
Essere vicini — o addirittura calcare — i metodi di sviluppo evita i livelli di astrazione tra dev e product. Non si storcono più i concetti a ogni passaggio da un contesto all'altro.
Conclusione
Il secondo cervello centralizzato, senza confini tra le opportunità, non è adatto al product management. La complessità che espone è reale, ma la risposta non è collegare tutto — è delimitare in modo intelligente.
Spazi dedicati, verificabili, in cui l'IA lavora su un perimetro controllabile: è questo che permette di mantenere il controllo su ciò che si costruisce e su ciò che si difende.
Per quali domini il secondo cervello funziona davvero bene? Ne parlerò in un prossimo articolo.
Per saperne di più
Dal file unico al sistema di contesti: perché la memoria di un LLM non sta in un solo documento Gli strumenti di coerenza organizzativa Il PM come architetto del Contesto Cos'è una nota atomica?
Fonti
- Metodo Zettelkasten: https://en.wikipedia.org/wiki/Zettelkasten
- Domain-Driven Design — Bounded Context: https://martinfowler.com/bliki/BoundedContext.html
- Dal file unico al sistema di contesti: https://malorean.net/articles/2026-04-21-du-fichier-unique-au-systeme-de-contextes-pourquoi-la-memoire-dun-llm-ne-tient-pas-dans-un-seul-document.html