Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Una documentazione sempre in ritardo
Lo abbiamo vissuto tutti: appare un bug, o bisogna gestire un'evoluzione funzionale. Il primo riflesso è consultare la documentazione. E, molto spesso, non è più aggiornata.
In realtà, sappiamo quasi in anticipo che non lo sarà. Lo schema è noto: si produce una documentazione, la si consegna con la specifica, poi inizia lo sviluppo. Nel percorso emergono domande, si prendono decisioni, alcuni punti evolvono, e gli sviluppatori talvolta prendono decisioni senza tornare sistematicamente dal product manager. È normale. Altrimenti il lavoro avanzerebbe al ritmo di una validazione permanente. Il risultato, però, è sempre lo stesso: documentazione e codice finiscono per divergere.
Questa divergenza dipende anche da un vincolo molto semplice. A ogni modifica, anche minima, nessuno ha davvero il tempo di andare a cercare la specifica giusta, il mockup giusto, il documento di supporto giusto o il changelog giusto per aggiornare tutto. Lavoriamo su un prodotto vivo, che evolve continuamente. In questo contesto, mantenere manualmente l'insieme degli artefatti diventa rapidamente troppo costoso rispetto al tempo disponibile.
Più il tempo passa, più il problema si aggrava. Oggi una funzionalità non viene concepita una volta per tutte: viene adattata, arricchita, corretta — a volte per mesi o anni. In queste condizioni, è poco realistico sperare di tenere perfettamente sincronizzati la specifica iniziale, gli scambi di progetto, il changelog, la documentazione di supporto, la documentazione commerciale e i mockup.
Il codice come fonte di verità
Il vero artefatto finale, in fondo, è il codice. Forse non è la formula ufficiale, ma è lui a descrivere lo stato reale del prodotto. Il resto cerca solo di seguirlo. Da questo punto di vista, l'espressione «Code is Law» rimane particolarmente calzante: https://framablog.org/2010/05/22/code-is-law-lessig/
A lungo, questa situazione era inevitabile. La documentazione in linguaggio naturale era la soluzione meno peggio, soprattutto perché la maggior parte dei product manager non lavora direttamente nel codice. Occorreva quindi uno strato intermedio, comprensibile da tutti, utilizzabile nelle riunioni, condivisibile con i team e usabile senza particolari competenze tecniche.
Cosa cambia l'IA
L'IA cambia ora questa equazione. Quando il codice è sufficientemente pulito e documentato, è possibile farne una fonte sfruttabile per ricostruire o aggiornare altri artefatti. Si può, per esempio, ripartire dal codice reale per aggiornare una documentazione di supporto dopo una consegna, generare un changelog più affidabile, o ricostituire una specifica funzionale a partire dallo stato attuale del prodotto anziché da un documento vecchio.
Il codice non è più solo l'artefatto finale: diventa l'elemento centrale, la fonte di verità attorno alla quale gravitano e si ricostruiscono gli altri artefatti di prodotto, in una logica veramente code centric.
La questione della cultura tecnica
Ma questo apre un'altra domanda: come può un product manager senza profilo tecnico trarre vantaggio da questa possibilità?
Gli strumenti attuali sono potenti, ma non si usano senza discernimento. Possono aiutare a produrre rapidamente, ad automatizzare certi compiti e a generare blocchi utili. Non appena però si tocca l'architettura, la coerenza d'insieme o la manutenibilità, i loro limiti emergono in fretta. Senza un minimo di cultura tecnica, il rischio è moltiplicare piccoli strumenti efficaci localmente ma mal collegati tra loro. Si guadagna tempo qua e là, poi lo si perde a far circolare i dati, gestire incoerenze o mantenere un insieme diventato difficile da comprendere.
La posta in gioco non è solo produrre più velocemente. È produrre in un quadro coerente. È questa coerenza a fare la differenza tra un accumulo di strumenti e un vero sistema di lavoro.
Da questo punto di vista, esiste probabilmente già un divario di capacità tra i PM con un percorso tecnico e quelli che non ce l'hanno. Non perché gli uni siano intrinsecamente migliori degli altri, ma perché i primi dispongono oggi di una leva in più: possono intervenire più direttamente sulla materia stessa del prodotto — cioè il codice — e usarla come base per generare, controllare o mettere in discussione altri artefatti.
Si potrebbe obiettare che i SaaS integreranno sempre più agenti capaci di automatizzare queste attività. È probabile, e sarà un vero progresso. Ma non credo che basterà a cancellare la differenza. La maggior parte di questi strumenti resterà specializzata.
È esattamente lì che emerge il limite. Uno strumento come Zendesk potrà probabilmente aiutare a produrre una documentazione di supporto migliore. Uno strumento come Figma resterà eccellente per progettare schermate. Ma nessuno dei due, da solo, ha una visione completa del prodotto reale così come esiste nel codice, così come evolve nelle merge requests, e così come deve essere compreso nel suo contesto di business.
Oggi, con gli strumenti giusti, posso per esempio incrociare più livelli di informazione: il codice sorgente, la cronologia delle evoluzioni, le merge requests e le regole di business che ho accumulato come product manager. Questo permette non solo di generare una documentazione più precisa, ma anche di mettere in discussione ciò che già esiste.
La stessa logica vale per la progettazione. Oggi si disegna un'interfaccia in Figma, poi la si sviluppa. Ma se sono in grado di ricostruire un design system a partire dal codice reale, di tenerlo aggiornato in base alle evoluzioni del repository e di aggiungervi le convenzioni di sviluppo del team, allora il mockup cambia status. Non è più solo una rappresentazione: può cominciare a diventare una prima base utilizzabile dagli sviluppatori front-end.
In altre parole, il confine tra progettazione, implementazione e documentazione inizia a ridursi. Non è solo una questione di produttività. È una trasformazione più profonda: il codice non è più semplicemente il risultato del lavoro — diventa anche la materia prima da cui ricostruire il resto.
Cosa cambierà il MCP
Non pretendo che questo modello sia già stabilizzato. Tra qualche mese potrebbe essere in parte superato. Il MCP, in particolare, può ancora cambiare l'equilibrio. Si può immaginare domani un ecosistema in cui ogni SaaS disponga del proprio strato di agenti, capace di dialogare con altri sistemi. Figma potrebbe, per esempio, recuperare contesto da un repository GitLab, leggere le evoluzioni recenti, capire le merge requests rilevanti e allineare meglio la progettazione alla realtà del prodotto. Non ci siamo ancora del tutto, ma la direzione diventa visibile.
È per questo che il MCP mi sembra importante. Così come le API sono diventate indispensabili quando i SaaS hanno smesso di vivere in compartimenti stagni, i MCP potrebbero diventare essenziali man mano che gli agenti si generalizzano. Ogni strumento conserverà la sua specialità, ma il valore reale verrà dalla sua capacità di dialogare con gli altri, recuperare contesto e agire in un ecosistema più ampio del proprio perimetro.
L'attitudine migliore, a questo stadio, è senza dubbio sperimentare sul serio. Non per seguire un effetto moda, ma per capire cosa permette già, concretamente, di creare valore. Perché il cambiamento in corso non è solo tecnologico. Tocca la natura stessa degli artefatti di prodotto, la loro fonte di verità e il ruolo del product manager nella loro produzione.
Per saperne di più
Aggiungere una memoria di sessione come in OpenClaw In 8 giorni ho capito che il mestiere di Product Manager stava per cambiare completamente La qualità appartiene a chi consegna La domanda prodotto deve partire dal codice sorgente