Da diversi mesi gli sviluppatori intervistano i clienti senza passare dal Product Manager.

E tre giorni fa ho aperto la mia prima pull request sul nostro prodotto principale.

Queste due frasi riassumono, meglio di qualsiasi analisi, ciò che sta accadendo nei team di prodotto con l'IA. Gli sviluppatori risalgono verso il problema, il cliente e l'ownership di prodotto. I PM scendono verso il prototipo, il codice e a volte la produzione.

Si potrebbero leggere come due aneddoti isolati. Io credo al contrario che sia l'inizio di un rovesciamento più profondo. I ruoli storici del product management, dello sviluppo e del design diventano meno netti. I confini si muovono. Ma, al contrario di quanto si potrebbe pensare, questo non significa che tutti faranno tutto, né che le responsabilità spariranno.

Il vero tema non è che l'IA renda i team «più produttivi». Il vero tema è che aumenta fortemente la capacità di produrre. E quando la capacità di produrre aumenta, il collo di bottiglia si sposta.

Prima il vincolo era spesso: «Quanto riusciamo a costruire?»

Domani diventa piuttosto: «Cosa bisogna costruire? Perché? Per chi? In che ordine? Con quali rischi?»

È questo spostamento che confonde i ruoli.

Quando gli sviluppatori producono di più, il PM diventa il collo di bottiglia

Uno dei fattori scatenanti del tema è abbastanza semplice: con l'IA gli sviluppatori possono produrre più in fretta.

Non solo scrivere qualche riga più rapidamente. Produrre più opzioni, più varianti, più prototipi, più piccoli strumenti, più iniziative. Uno sviluppatore già autonomo può ritrovarsi capace di andare tre, quattro o sei volte più veloce su certe attività. Un team che aveva una capacità di delivery limitata può improvvisamente generare molte più cose da testare, da decidere, da rileggere, da prioritizzare.

Il problema è che la capacità di decidere non aumenta automaticamente allo stesso ritmo.

Se tutto deve continuare a passare dal PM, è lui a diventare in fretta il nuovo punto di saturazione del sistema. Non si tratta più solo di scrivere specifiche o di seguire un backlog. Il carico si sposta sulla prioritizzazione, la coerenza di prodotto, la validazione del segnale del cliente, le scelte di mercato, l'impatto sull'utente, la strategia e la gestione delle conseguenze.

Un'organizzazione può allora credere di aver risolto il suo problema di velocità perché gli sviluppatori producono di più. In realtà ha semplicemente spostato il blocco.

Ci sono tre risposte possibili.

La prima consiste nell'assumere più PM. A volte è necessario, ma non è sempre la risposta giusta. Se il modello resta lo stesso, si aggiunge soltanto un ulteriore strato di decisione.

La seconda consiste nell'automatizzare una parte del lavoro operativo del PM: documentazione, release notes, materiali di lancio, analisi iniziali, traduzioni, sintesi, video dimostrativi, screenshot, elementi di PR. Questo libera tempo, ma non basta a risolvere la questione di fondo.

La terza consiste nel ridistribuire una parte dell'ownership di prodotto verso chi costruisce. È qui che i ruoli cominciano davvero a confondersi.

Accelerare il codice non basta

Un errore sarebbe credere che l'IA trasformi l'organizzazione solo perché accelera lo sviluppo.

La velocità locale non crea valore in automatico. Può anzi creare più disordine se l'intero workflow non cambia. Un team può generare più codice, più prototipi, più documenti e più ticket, e allo stesso tempo prendere decisioni peggiori.

L'intero flusso va ripensato: idea, discovery, specifica, prototipazione, sviluppo, test, sicurezza, lancio, comunicazione, supporto e apprendimento.

Se si aggiungono agenti IA su un processo immutato, si rischia soltanto di spostare i colli di bottiglia. Il codice accelera, poi si blocca il prodotto. Il prodotto accelera, poi si blocca il design. Il design accelera, poi si blocca la validazione tecnica. La validazione accelera, poi il go-to-market o il supporto non tengono il passo.

Il tema quindi non è solo: «Come rendere gli sviluppatori più veloci?»

Il tema è: «Come rendere l'intero sistema capace di assorbire questa velocità senza perdere qualità, coerenza e responsabilità?»

Per questo i nuovi ruoli non si riducono al «PM che scrive codice» o allo «sviluppatore che fa prodotto». Una parte dei nuovi bisogni riguarda l'orchestrazione dei workflow, la valutazione degli output dell'IA, la memoria di prodotto, la qualità delle decisioni, la leggibilità dei repo e la capacità di dare agli agenti un contesto affidabile.

Cosa l'IA rende banale nel product management

Per molto tempo certi PM si sono differenziati grazie a sensibilità o competenze piuttosto distinte.

Alcuni erano bravissimi nella scrittura. Altri nei dati. Altri nel benchmark, nel marketing di prodotto, nella discovery, nel design dell'esperienza o nel coordinamento del delivery. Queste differenze non spariscono del tutto. Ma una parte del loro valore differenziale si abbassa.

Con l'IA molte capacità diventano più accessibili:

• scrivere una specifica corretta;
• produrre una prima analisi dei dati;
• fare un benchmark;
• redigere una release note;
• realizzare un mockup accettabile;
• sintetizzare interviste;
• produrre una prima versione di un percorso;
• trasformare un bisogno in prototipo.

Queste competenze non diventano inutili. Un PM deve sempre saper giudicare una specifica, mettere in discussione un'analisi, leggere un mockup, capire una sintesi di interviste o valutare un prototipo. Ma la produzione iniziale di questi artefatti diventa meno rara.

Prima un PM poteva essere fortemente differenziato perché sapeva produrre in fretta una buona specifica, un benchmark chiaro, una sintesi utilizzabile o un primo mockup. Domani sarà piuttosto il livello minimo.

Questo rende vulnerabili i PM che erano forti soprattutto per la loro capacità di esecuzione intermedia. Chi coordinava, redigeva, amministrava, monitorava, riformulava e produceva artefatti corretti senza esprimere un giudizio di prodotto forte rischia di perdere una parte del proprio valore.

Il mestiere del prodotto non sparisce. Ma il suo livello minimo sale.

Ciò che resta difficile: il giudizio di prodotto

Quando produrre diventa più facile, scegliere cosa produrre diventa più critico.

È qui che il mestiere del PM mantiene il suo valore. Non nella capacità di generare più artefatti, ma nella capacità di scegliere, decidere e assumersi ciò che segue.

Ciò che resta difficile:

• scegliere il problema giusto;
• capire un mercato;
• leggere il vero segnale dietro le richieste dei clienti;
• decidere fra breve termine e strategia;
• dire di no;
• tenere una visione coerente;
• creare allineamento;
• assumersi le conseguenze di una decisione sul prodotto, sul business, sulla tecnica e sulle persone.

Il PM strategico aumentato assomiglia sempre di più a una forma di piccolo CPO. Si occupa meno dell'amministrazione del delivery, meno della produzione meccanica di deliverable, e di più delle decisioni in cui nessuna opzione è perfetta.

Il ruolo diventa particolarmente importante quando non esiste una buona soluzione. Solo due o tre opzioni cattive, con costi diversi, rischi diversi, effetti politici diversi, impatti diversi sul cliente. In quei momenti l'IA può aiutare ad analizzare. Non può assumersene la responsabilità.

Il PM aumentato non è quindi semplicemente un PM che va più veloce. È un PM che deve giudicare meglio.

La differenziazione si sposta sul segnale del cliente

Se tutti possono costruire più in fretta, costruire in fretta non è più un vantaggio sufficiente.

La produzione grezza di codice diventa in parte una commodity. Non il software. Non l'ingegneria. Non l'architettura, la sicurezza o la manutenibilità. Ma la capacità di produrre rapidamente una prima versione diventa meno rara.

La vera differenziazione si sposta allora su ciò che i concorrenti non possono semplicemente generare:

• la qualità del segnale del cliente;
• i dati proprietari;
• la conoscenza del dominio;
• la distribuzione;
• la fiducia;
• i vincoli operativi;
• gli apprendimenti accumulati;
• la capacità di interpretare correttamente ciò che i clienti chiedono davvero.

Un prototipo rapido ha valore solo se mette alla prova un segnale vero. Altrimenti non fa che accelerare una direzione sbagliata.

La domanda strategica diventa quindi: su quale nostro vantaggio specifico stiamo costruendo?

Un team aumentato dall'IA può produrre moltissime cose. Ma se non legge meglio il suo mercato, se non capisce meglio i suoi utenti, se non sa distinguere un segnale forte da un rumore ben formulato, produrrà soltanto più in fretta cose mediocri.

È una ragione in più per cui il PM non sparisce. Il ruolo si sposta sulla qualità della lettura del reale.

Gli sviluppatori salgono verso il prodotto

Gli sviluppatori non sono mai stati dei semplici esecutori.

Una specifica completa è una finzione. Anche una buona specifica non descrive mai tutti i comportamenti attesi da un prodotto. Restano sempre zone mute: casi limite, messaggi di errore, comportamenti impliciti, regole di sicurezza, timeout, priorità invisibili, micro-interazioni, decisioni di fallback.

In quelle zone gli sviluppatori prendono già decisioni di prodotto.

L'IA rende questa realtà più visibile. Se un agente scrive una parte del codice, l'umano deve esplicitare il comportamento atteso, decidere sugli edge case, definire i criteri di accettazione, verificare il risultato. Le micro-decisioni che venivano assorbite in silenzio dentro l'implementazione diventano più visibili, e quindi più importanti da definire.

È una delle ragioni per cui gli sviluppatori salgono verso il prodotto. Parlano di più con i clienti, capiscono meglio i problemi, si fanno carico di più ownership sulle proprie funzionalità, prendono decisioni locali più esplicite.

Ma c'è una sfumatura importante: uno sviluppatore non diventa product engineer solo perché usa un agente di codice o perché consegna più in fretta.

Se non ha accesso ai clienti, ai dati, al contesto di business e alle scelte da prendere, rischia soltanto di diventare un operatore di agenti di codice. Più responsabilità, più pressione, ma non necessariamente più potere sul prodotto.

Il vero product engineer non è solo uno sviluppatore veloce. È qualcuno che si fa carico di una parte del giudizio di prodotto il più vicino possibile alla costruzione.

I PM scendono verso la costruzione

Esiste anche il movimento inverso.

Con l'IA un PM può materializzare un'idea molto più in fretta di prima. Un mockup, un prototipo, uno strumento interno, una dashboard, una traduzione, una modifica di interfaccia, a volte persino una PR delimitata e supervisionata.

Questo cambia la natura del lavoro.

Prima bisognava spesso passare per una sequenza lunga: formulare il bisogno, scrivere la specifica, fare un mockup, chiedere una stima, aspettare uno slot, far sviluppare, testare, aggiustare. Oggi, su certi temi, si può passare molto più rapidamente dall'intuizione a un artefatto manipolabile.

E a volte non si tratta nemmeno più solo di prototipare. Su casi semplici o ben definiti si può scrivere qualcosa di quasi reale: una dashboard, una schermata in sola lettura, un miglioramento di interfaccia, un'automazione interna, una traduzione, un materiale di release.

Questo non vuol dire che il PM diventi sviluppatore nel senso classico. Vuol dire che può intervenire in zone di costruzione che prima erano fuori dal suo ambito.

Qui bisogna distinguere diversi livelli.

Il PM o PO prototipista trasforma un intento di business in prototipo o POC.

Il Product Builder va oltre: costruisce artefatti tangibili, strumenti interni, dashboard, prime versioni, contributi delimitati e supervisionati.

Il Product Engineer va ancora oltre: può portare una responsabilità di prodotto fino al deliverable di produzione. E questo ruolo può nascere da due traiettorie. Uno sviluppatore che sale verso il prodotto. Oppure un profilo di prodotto abbastanza tecnico che scende verso la produzione.

Il criterio non è quindi il mestiere di partenza. Il criterio è il livello di azione.

La persona resta al livello del mockup? Produce un prototipo? Apre una PR? Porta un deliverable pronto per la produzione? Capisce abbastanza i rischi da far validare correttamente ciò che produce?

È questo continuum a essere nuovo.

I ruoli si confondono, le responsabilità restano

Il rischio sarebbe concludere che, siccome i ruoli si confondono, le responsabilità si dissolvono.

Io penso esattamente il contrario.

Più i ruoli si confondono, più bisogna chiarire le responsabilità.

Una scelta di prodotto resta una scelta di prodotto. Spetta al prodotto: visione, posizionamento, coerenza, decisioni, grandi principi, lettura del mercato, segnale del cliente.

Una scelta tecnica resta una scelta tecnica. Spetta alla tecnica: sicurezza, performance, scalabilità, architettura, manutenibilità, qualità della piattaforma.

Una scelta di esperienza resta una scelta di esperienza. Spetta al design o al front-end: design system, coerenza d'uso, accessibilità, livello di esigenza sulla UX.

L'organizzazione che funziona non è quella in cui ciascuno fa tutto per conto suo. È quella in cui ciascuno può intervenire oltre il proprio dominio iniziale perché esistono garanti che fissano gli standard, i guardrail e i limiti.

Un PM può aprire una PR. Ma quella PR viene riletta, accettata, corretta o rifiutata.

Se viene rifiutata dieci volte di fila, questo dice qualcosa. Forse il PM non ha ancora il livello per quel tipo di contributo. Forse il tema è troppo rischioso. Forse anche il team tecnico non ha ancora messo in piedi le direttive, gli strumenti o i guardrail che permettono ad altri profili di contribuire in sicurezza.

La PR o la MR diventa allora un meccanismo di governance. Non solo uno strumento tecnico.

Tutto dipende dalla coppia competenza / rischio

La domanda giusta non è: «Un PM può rilasciare in produzione?»

La domanda giusta è: «Su quale ambito, con quale competenza, quale rischio e quali guardrail?»

Serve una gradazione semplice.

Rischio basso: traduzioni, contenuti, dashboard, schermate in sola lettura, strumenti interni non critici.

Rischio medio: piccole azioni in scrittura, workflow interni, modifiche di interfaccia delimitate e supervisionate.

Rischio alto: pagamenti, permessi, sicurezza, dati sensibili, logica di business critica, prodotto regolamentato, architettura.

Anche in un prodotto regolamentato non tutto ha lo stesso livello di rischio. Una dashboard o una schermata di consultazione può essere relativamente sicura se le regole sono chiare e la validazione tecnica è presente. Al contrario, un prodotto apparentemente semplice può contenere una zona molto delicata se tocca i dati, i permessi o una decisione di business irreversibile.

L'analogia con uno sviluppatore junior è utile. Non si consegnano le chiavi del motore del prodotto a qualcuno fin dal primo giorno. Si comincia da ambiti semplici, poi si allarga progressivamente.

Il PM aumentato può seguire la stessa logica: traduzioni, sola lettura, dashboard, piccole scritture, poi eventualmente contributi più critici se la competenza, il contesto e i guardrail tengono il passo.

La frattura fra i profili PM

Non tutti i PM potranno diventare builder o product engineer allo stesso ritmo.

Nel breve termine i PM con un bagaglio tecnico sono avvantaggiati. Sanno leggere un repo, capire un errore, dialogare con un agente di codice, interpretare ciò che è stato generato, individuare certe assurdità, chiedere una revisione tecnica al punto giusto.

Un PM senza questa cultura può ovviamente imparare. Ma rischia di restare limitato al mockup o al prototipo superficiale finché non capisce abbastanza ciò che l'IA produce.

L'IA è ancora troppo poco affidabile perché si possa ignorare del tutto quello che succede sotto il cofano. Se non si capiscono almeno un minimo gli errori prodotti, diventa difficile andare oltre il mockup affidabile.

Questo non vuol dire che i profili non tecnici siano condannati. Nel medio o lungo termine può accadere anche il contrario. Se gli agenti diventeranno molto più affidabili, profili che vengono dalla psicologia, dalle lettere, dalla filosofia, dal design, dalla ricerca o dal business potrebbero ritrovarsi in vantaggio grazie alla loro capacità di esprimere con finezza una realtà umana, sociale o di business.

Ma allo stato attuale degli strumenti la frattura esiste.

I PM che non vogliono diventare builder dovranno probabilmente crescere moltissimo su altre dimensioni: strategia, mercato, discovery, influenza, comprensione umana, qualità dell'espressione, capacità di dire di no e di orientare un team.

I nuovi mestieri non sono sempre mestieri

Si parla spesso di «nuovi mestieri». Il termine è utile, ma può ingannare.

Non tutti questi ruoli diventeranno per forza titoli HR stabilizzati. Alcuni diventeranno posizioni. Altri resteranno competenze distribuite nel team. Altri ancora saranno assorbiti da Product Ops, Design, Engineering o QA.

Il punto importante non è il titolo. È la responsabilità.

Chi giudica?

Chi costruisce?

Chi garantisce?

Chi valuta?

Chi mantiene la memoria?

Chi orchestra i workflow?

L'IA rende visibili responsabilità che a volte erano implicite o secondarie: la valutazione degli output probabilistici, la documentazione utilizzabile dagli agenti, la memoria di prodotto, l'orchestrazione dei workflow, la qualità del contesto, la leggibilità del repo, la chiarezza dei criteri di accettazione.

Questi bisogni non sono periferici. Diventano centrali appena un team lavora con agenti.

Il PM non sparisce, il livello minimo sale

Il product management non sparisce.

Ma il mestiere diventa meno tollerante verso i profili che vivevano soprattutto di coordinamento, scrittura, monitoraggio e produzione di artefatti intermedi.

Domani ci sarà meno spazio per il PM amministrativo.

Ci sarà più spazio per due tipi di profili.

Da un lato, chi sa costruire abbastanza da accelerare l'apprendimento di prodotto: prototipare, materializzare, testare, contribuire, a volte spingersi fino a un deliverable reale.

Dall'altro, chi sa giudicare abbastanza bene da orientare un team capace di costruire molto più in fretta di prima: capire il mercato, leggere il segnale, decidere, dire di no, tenere una visione, proteggere la coerenza e assumersi le conseguenze.

Fra questi due poli esisteranno molte combinazioni. Ma il livello minimo salirà.

L'IA non elimina il product management. Costringe il mestiere a tornare quello che avrebbe sempre dovuto essere: una responsabilità di creazione, di giudizio e di impatto.

Appendice: catalogo dei futuri ruoli di prodotto

Questa appendice non cerca di prevedere i futuri titoli LinkedIn. Descrive piuttosto le zone di responsabilità che diventano visibili con l'IA.

PM strategico aumentato

PM che automatizza una parte dell'esecuzione intermedia per concentrarsi sulla visione, sulle decisioni, sulla coerenza di prodotto e sulla lettura del segnale del cliente.

Il suo valore è scegliere i problemi giusti, decidere quando nessuna opzione è perfetta, proteggere il posizionamento e mantenere l'allineamento fra mercato, strategia, utenti ed esecuzione.

Il suo rischio è di essere confuso con un semplice PM più produttivo, o di diventare il nuovo collo di bottiglia se ogni decisione continua a risalire fino a lui.

PM o PO prototipista

Profilo di prodotto capace di trasformare rapidamente un intento di business in prototipo, POC, strumento interno o primo percorso testabile con l'aiuto dell'IA.

Il suo valore è ridurre l'ambiguità fra business, prodotto e tecnica.

Il suo rischio è di restare al livello del mockup o di scavalcare troppo presto gli sviluppatori su temi che richiedono una vera riflessione tecnica.

Product Builder

Profilo di prodotto capace di trasformare direttamente un'idea in artefatto testabile, prototipo funzionante, strumento interno o contributo delimitato e supervisionato.

Il suo valore è ridurre il tempo fra intuizione e dimostrazione.

Il suo rischio è di confondere un prototipo che funziona con un prodotto manutenibile.

Product Engineer

Profilo capace di portare una responsabilità di prodotto fino al deliverable di produzione: comprensione dell'utente, scelta della soluzione, costruzione, consegna, misura e impatto.

Può venire da un background da sviluppatore o da un background di prodotto abbastanza tecnico.

Il suo valore è ridistribuire una parte del giudizio di prodotto il più vicino possibile alla costruzione e ridurre la distanza fra idea, prototipo e produzione.

Il suo rischio è doppio: credere che uno sviluppatore diventi product engineer senza accesso reale ai clienti, ai dati, al contesto di business e alle scelte da prendere; oppure credere che un PM possa diventare product engineer senza la capacità di capire, far validare e mantenere un deliverable di produzione.

Product Systems Designer

Ruolo che progetta i sistemi di prodotto alimentati dall'IA: feedback, discovery, generazione di specifiche, instradamento degli insight, documentazione viva e workflow di release.

Il suo valore è migliorare i meccanismi che permettono al team di prendere decisioni migliori in continuo.

Il suo rischio è di diventare una funzione troppo astratta se non viene collegata ai workflow reali del team.

AI Product Evaluator

Ruolo incaricato di valutare gli output dell'IA dentro il prodotto: qualità, allucinazioni, UX del fallimento, robustezza, test di business e coerenza con l'intento di prodotto.

Il suo valore è rendere testabile la qualità di un prodotto probabilistico.

Il suo rischio è di essere ridotto a QA classica, mentre la valutazione riguarda anche l'intento di prodotto, la fiducia e l'accettabilità.

Product Knowledge Curator

Ruolo che mantiene la memoria di prodotto in una forma utilizzabile dagli umani e dagli agenti.

Il suo valore è rendere davvero azionabili le decisioni passate, il segnale del cliente, i vincoli, le scelte fatte e la documentazione.

Il suo rischio è di produrre una documentazione pesante invece di una memoria viva.

Product Ops agentico

Product Ops specializzato nell'orchestrazione degli strumenti, delle automazioni e degli agenti che sostengono il lavoro di prodotto.

Il suo valore è mantenere i workflow IA che attraversano il product management: feedback, brief, discovery, release notes, documentazione, misura dell'impatto.

Il suo rischio è di automatizzare rumore se i criteri di qualità e l'ownership non sono chiari.

Tre famiglie di ruoli

Questi ruoli si possono leggere in tre famiglie.

I ruoli di giudizio: PM strategico aumentato.

I ruoli di costruzione: PM o PO prototipista, Product Builder, Product Engineer.

I ruoli di sistema: Product Systems Designer, AI Product Evaluator, Product Knowledge Curator, Product Ops agentico.

Il titolo conta meno della responsabilità. Nei team aumentati dall'IA la domanda centrale sarà meno «qual è il tuo ruolo?» e più «cosa sei capace di giudicare, costruire, garantire, valutare o mantenere?»