Il tuo team ricostruisce lo stesso modello di prodotto a ogni domanda, a ogni bug, a ogni gara d'appalto. Ecco come scriverlo una volta sola: 52 oggetti, 250 regole, meno di sei ore. E soprattutto come sapere di aver finito — i tre criteri di arresto che sembrano provare la completezza e non provano nulla, più l'unico che tiene.
LeggiAssumi un PO per tenere il backlog e fare da ponte con gli sviluppatori? Stai ottimizzando un circuito già obsoleto. Questo testo smonta la separazione tra chi pensa il prodotto e chi lo esegue: perché abbassa la qualità, perché il backlog non può fondare un mestiere, e perché l'IA toglie l'ultima scusa per conviverci.
L'IA aumenta la capacità di produrre — non quella di decidere. Gli sviluppatori salgono verso il prodotto, i PM scendono verso la costruzione. Questo slittamento confonde i ruoli senza sciogliere le responsabilità. Un giro completo di ciò che l'IA banalizza nel product management, di ciò che resta difficile, e un catalogo dei ruoli emergenti con i loro rischi reali.
Quattro giorni a costruire un vero prodotto con Claude Code — 180 commit, partito da zero. Cosa rivela: la velocità che esalta, le trappole che l'IA crea da sola, cosa cambia i test quando non si codifica in prima persona, e fin dove un PM può arrivare senza uscire dal proprio perimetro. Un ritorno dal campo, non una dottrina.
Produrre codice più velocemente non basta se nessuno capisce ciò che è stato costruito. L'IA automatizza esattamente le attività che formavano gli sviluppatori junior, e l'errore ritardata non insegna più niente quando il sistema è diventato troppo complesso. Alcuni punti di riferimento concreti per mantenere il controllo: contratti chiari tra API, test collegati al funzionale, ricostruibilità come criterio di qualità invece della semplice velocità di consegna.
I tuoi documenti non dicono tutto: la comprensione fine del campo resta nella testa del PM. Le fonti di sessione offrono un canale per versare questa conoscenza informale in un Context IA — una frase da corridoio, una sfumatura cliente, una tensione nascente — e trasformare l'accumulo di micro-segnali in note, ipotesi e decisioni meglio formulate.
I tuoi strumenti archiviano bene le informazioni, ma non capitalizzano ciò che ti insegnano. Questo testo spiega perché il futuro del sistema informativo non è un modulo migliore assistito dall'IA, ma uno spostamento verso i contesti: unità di memoria portabili, governate, capaci di collegare fonti, decisioni e ragionamenti invece di limitarsi a conservarli.
Perdi mezz'ora a testare in ambiente per rispondere a una domanda prodotto su Slack? Questo costo nascosto scompare quando l'IA interroga il codice sorgente, la vera verità del comportamento. Risposte ancorate a prove — funzioni, test, commit — piuttosto che a una documentazione obsoleta. A condizione che il codice parli il linguaggio del business.
Perdi il filo ogni volta che riapri una conversazione con un'IA su un argomento che dura? Questo articolo apre il cofano di un sistema di memoria strutturato: la differenza tra lo scopo e l'attenzione, le direttive, la coda offline, le tre memorie (diario, sintesi, checkpoint) e il ciclo di una sessione. Per capire come un'IA può davvero ricordare una missione.
Pensi che un mercato si apra traducendo il tuo prodotto? Il Brasile dimostra il contrario. Attraverso la scena più banale — pagare alla cassa — capirai perché credito quotidiano, numero fiscale, Pix ed economia informale formano un'infrastruttura culturale che nessuna traduzione riproduce. Quel che basta per evitare un errore strategico costoso nell'internazionalizzazione.
La nota tematica è l'anello di congiunzione tra il sistema di note e la scrittura. Non accumula tutto ciò che riguarda un argomento — sceglie un angolo e assembla più note atomiche per far emergere un motivo, una tensione o una linea argomentativa. Né cartella, né enciclopedia: una vista temporaneamente stabile su una rete di pensiero.
«Un'idea per nota» — la formula è nota, ma spesso porta fuori strada. Una nota atomica non è una nota breve: è una nota con un unico centro di gravità concettuale. Capire questa distinzione cambia il modo in cui si cattura, si riformula, si intitola e si collegano le proprie note. E in fin dei conti, il modo in cui si scrive.
Le stesse parole circolano tra prodotto, marketing, vendite e direzione — senza che ciascuna area dia loro lo stesso significato. Il glossario non è una raccolta di definizioni scolastiche: è uno strumento di precisione collettiva. Stabilizza i termini che reggono le decisioni, protegge i legami tra le note e riduce il costo delle conversazioni in cui ognuno difende un'idea diversa con lo stesso vocabolario.
Accumuliamo tab, link, note rapide — e non le rileggiamo mai. Il problema non è la quantità di informazioni, ma l'assenza di una decisione su cosa farne. Questo articolo distingue catturare da capitalizzare, e propone un ritmo semplice per trasformare le tue catture in conoscenza senza annegare in esse.
Avere un'ottima base di note non basta se le idee non sono davvero integrate. La flash card non è una piccola nota atomica: è un pilastro personale di pensiero, riconosciuto sul momento per la sua risonanza, e messo alla prova nel tempo dalle esperienze e dalle nuove fonti. Rara per definizione, struttura ciò che vuoi davvero avere dentro di te.
La maggior parte delle organizzazioni sa produrre documenti. Non sa capitalizzare il ragionamento che c'è dietro. A ogni decisione, riparte quasi da zero. Il PM architetto di contesto trasforma la conoscenza dispersa del cliente — trascrizioni, obiezioni, arbitraggi, segnali deboli — in un asset riutilizzabile. Il risultato: decisioni più rapide, più robuste e un vantaggio competitivo che i concorrenti non possono copiare subito.
Il vero problema dei bug non è che esistano, ma che l'organizzazione si abitua a tenerli. Li si prioritizza, li si rimanda, li si rivede in comitato — fino all'escalation del cliente. Una policy zero bug punta ad altro: zero bug noti senza decisione. O si corregge, o si stabilisce che non è un difetto. Quello che questa policy rifiuta è il terzo stato: sapere che un bug esiste e tenerlo in lista per dopo.
Un team di prodotto può accumulare studi, workshop e analisi senza che l'azienda sappia cosa ha priorità. La roadmap NNL risponde a questo problema: non pianificando date, ma rendendo visibili gli impegni, le direzioni serie, le possibilità — e soprattutto ciò che non verrà fatto. La sua forza sta nel vincolo di capacità e nel No implicito.
Certe decisioni di prodotto ritornano ovunque: nel comitato di roadmap, con i commerciali, nelle specifiche, con ogni grande cliente. Senza traccia scritta, l'azienda le ridecide continuamente, spesso con meno contesto. Il PDR — ispirato agli ADR tecnici — documenta queste regole di decisione trasversali. Raro, breve, immutabile: non dice cosa costruire, ma perché l'azienda ha scelto una regola. Elimina decine di discussioni inutili.
In molte organizzazioni, il backlog è diventato un cestino pulito: ci si mette tutto per non dimenticare nulla. Qualche mese dopo, 500 righe che nessuno capisce più. Un backlog non dovrebbe essere un deposito di idee, una base di segnali clienti né il cimitero dei bug non risolti. Serve a organizzare informazioni abbastanza mature da permettere a più persone di lavorare insieme. Entra in gioco quando il lavoro smette di essere individuale.
Una politica zero bug riduce lo stock di difetti noti. Ma se il team corregge più in fretta senza cambiare come produce, rimane intrappolato in un ciclo di riparazione. Il vero problema è a monte: responsabilizzare chi consegna, rifiutare le spec troppo vaghe, testare prima, dare a QA un ruolo di politica della qualità invece che di rete di sicurezza. La qualità non si delega a posteriori — appartiene a chi consegna.
Guardare cosa lanciano i competitor significa leggere output senza capire il ragionamento sottostante. Un monitoraggio utile comincia dal cliente target: i suoi bisogni, i suoi criteri di scelta, le sue alternative. I competitor diventano interessanti solo perché rivelano come un mercato risponde a quei bisogni. Copiare un gesto senza capire la logica dietro significa riprodurre una risposta senza essersi posti la domanda giusta.
Esci da una riunione con un piano d'azione, ma nulla è stato davvero deciso. È quello che chiamo una decisione morbida: una non-decisione travestita da consenso. Le organizzazioni la preferiscono spesso a un vero arbitraggio perché preserva l'apparenza dell'accordo senza rendere visibile la perdita. Questo testo esplora perché questo meccanismo è razionale nel breve termine, e perché costa così caro nell'esecuzione.
I tuoi team escono allineati dalla riunione — e ciascuno riparte con una versione diversa della decisione. Il problema non è la mancanza di riunioni, ma l'assenza di oggetti comuni. Glossario, one-pager, PR/FAQ, metriche gerarchizzate, registro delle decisioni, regole di escalation: questi strumenti non producono allineamento, costringono i disaccordi a diventare visibili prima che costino.
Il RAG classico riparte da zero a ogni domanda. Costruendo un Wiki IA — un wiki persistente mantenuto da un LLM — si capitalizza la conoscenza di settore una volta per tutte. Note atomiche, collegamenti tra concetti, rilevamento di contraddizioni: il sapere viene compilato, non riscoperto. Esperienza con 950 note estratte da fonti sulla manutenzione industriale, con le lezioni di calibrazione e gli usi concreti.
Gestire opportunità di prodotto in una rete di note senza confini significa perdere il controllo: errori che si propagano silenziosamente, finestra di contesto dell'IA che esplode, contraddizioni e decisioni introvabili. Il bounded context — mutuato dal DDD — offre un approccio migliore: ogni opportunità nel proprio spazio delimitato, verificabile, con una memoria strutturata.
Sei sommerso dalle email e perdi il filo degli argomenti in corso? Delegando la strutturazione a Claude — un file, qualche direttiva, poi una suddivisione progressiva — ho trasformato 500 email di condominio in una base di conoscenza interrogabile. Sette passi, dalla direttiva vaga al sistema multi-file, senza aver mai bisogno di un framework complesso.
La documentazione non segue mai il codice. Lo sappiamo, lo accettiamo, eppure costa tempo a ogni evoluzione. L'IA cambia l'equazione: quando il codice è pulito, diventa la fonte di verità da cui rigenerare gli altri artefatti — specs, changelogs, documentazione di supporto. Questo approccio code centric richiede una cultura tecnica minima, ma apre una leva concreta per i product manager che la padroneggiano.
Troppi sistemi di insight falliscono perché classificano tutto su un unico asse: le feature o gli obiettivi. Il feedback tattico si perde, i segnali strategici evaporano. Un framework a 4 livelli — obiettivo di business, caso d'uso, capacità di prodotto, punto di attrito — permette di catturare tutto senza complicare il sistema, e di collegare ogni segnale al giusto livello decisionale.
4 articoli più vecchi disponibili nell'archivio.