PM, sviluppatori e IA: i ruoli si confondono, le responsabilità restano

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

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

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

Si potrebbe vederci due aneddoti isolati. Penso al contrario che sia l'inizio di un'inversione più profonda. I ruoli storici del product management, dello sviluppo e del design diventano meno netti. I confini si muovono. Ma contrariamente a ciò che si potrebbe credere, 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 possiamo costruire?»

Domani, diventa maggiormente: «Cosa bisogna costruire? Perché? Per chi? In quale 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ù velocemente.

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 certi compiti. Un team che aveva una capacità di delivery limitata può improvvisamente generare molte più cose da testare, arbitrare, rileggere, priorizzare.

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

Se tutto deve continuare a passare per il PM, questo diventa rapidamente il nuovo punto di saturazione del sistema. Non si tratta più solo di scrivere spec o seguire un backlog. Il carico si sposta verso la priorizzazione, la coerenza prodotto, la validazione del segnale cliente, l'arbitraggio di mercato, l'impatto utente, la strategia e la gestione delle conseguenze.

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

Ci sono tre risposte possibili.

La prima consiste nel reclutare più PM. È a volte necessario, ma non è sempre la risposta giusta. Se il modello resta lo stesso, si aggiunge solo uno strato di arbitraggio supplementare.

La seconda consiste nell'automatizzare una parte del lavoro operativo del PM: documentazione, release note, supporti di lancio, analisi iniziali, traduzioni, sintesi, video di demo, 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 prodotto verso coloro che costruiscono. È 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 automaticamente valore. Può persino creare più disordine se il workflow complessivo non cambia. Un team può generare più codice, più prototipi, più documenti e più ticket, pur prendendo decisioni peggiori.

Il flusso completo deve essere ripensato: idea, discovery, specifica, prototipazione, sviluppo, test, sicurezza, lancio, comunicazione, supporto e apprendimento.

Se si aggiungono agenti IA su un processo invariato, si rischia solo di spostare i colli di bottiglia. Il codice accelera, poi il prodotto blocca. Il prodotto accelera, poi il design blocca. Il design accelera, poi la validazione tecnica blocca. La validazione accelera, poi il go-to-market o il supporto non seguono più.

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

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

È per questo che i nuovi ruoli non si riducono a «PM che codifica» o «sviluppatore che fa il prodotto». Una parte dei nuovi bisogni riguarda l'orchestrazione dei workflow, la valutazione degli output IA, la memoria prodotto, la qualità delle decisioni, la leggibilità dei repository e la capacità di dare agli agenti un contesto affidabile.

Cosa l'IA banalizza nel product management

Per molto tempo, certi PM si differenziavano per sensibilità o competenze abbastanza distinte.

Alcuni erano molto bravi nella redazione. Altri nei dati. Altri nel benchmark, nel marketing prodotto, nella discovery, nel design dell'esperienza o nel coordinamento della delivery. Queste differenze non scompaiono completamente. Ma una parte del loro valore differenziale scende.

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

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

Queste competenze non diventano inutili. Un PM deve sempre saper giudicare una spec, sfidare 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 rapidamente una buona spec, un benchmark chiaro, una sintesi sfruttabile o un primo mockup. Domani, sarà maggiormente il livello minimo.

Questo rende vulnerabili i PM che erano soprattutto forti per la loro capacità di esecuzione intermedia. Quelli che coordinavano, redigevano, amministravano, seguivano, riformulavano e producevano artefatti corretti senza portare un giudizio prodotto forte rischiano di perdere una parte del loro valore.

Il mestiere prodotto non scompare. Ma il suo livello minimo sale.

Cosa resta difficile: il giudizio prodotto

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

È qui che il mestiere di PM mantiene il suo valore. Non nella capacità di generare più artefatti, ma nella capacità di scegliere, arbitrare e assumersi la responsabilità.

Cosa resta difficile:

• scegliere il problema giusto;
• capire un mercato;
• leggere il vero segnale dietro le richieste clienti;
• arbitrare tra breve termine e strategia;
• dire no;
• tenere una visione coerente;
• creare allineamento;
• assumersi le conseguenze prodotto, di business, tecniche e umane di una decisione.

Il PM strategico aumentato assomiglia sempre più a una forma di piccolo CPO. È meno nell'amministrazione della delivery, meno nella produzione meccanica di livrable, e maggiormente negli arbitraggi dove nessuna opzione è perfetta.

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

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

La differenziazione si sposta verso il segnale cliente

Se tutti possono costruire più velocemente, costruire veloce 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 verso ciò che i concorrenti non possono semplicemente generare:

• la qualità del segnale cliente;
• i dati proprietari;
• la conoscenza di business;
• 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 testa un vero segnale. Altrimenti, non fa che accelerare una direzione sbagliata.

La domanda strategica diventa quindi: su quale vantaggio proprio si costruisce?

Un team aumentato dall'IA può produrre molte cose. Ma se non legge meglio il proprio mercato, se non capisce meglio i propri utenti, se non sa distinguere un segnale forte da un rumore ben formulato, produrrà solo più velocemente cose mediocri.

È una ragione supplementare per cui il PM non scompare. Il ruolo si sposta verso la qualità di lettura del reale.

Gli sviluppatori salgono verso il prodotto

Gli sviluppatori non sono mai stati semplici esecutori.

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

In queste zone, gli sviluppatori prendono già decisioni prodotto.

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

È una delle ragioni per cui gli sviluppatori salgono verso il prodotto. Parlano maggiormente ai clienti, capiscono meglio i problemi, portano più ownership sulle proprie funzionalità, prendono decisioni locali più esplicite.

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

Se non ha accesso ai clienti, ai dati, al contesto di business e agli arbitraggi, rischia solo di diventare un operatore di agenti di codice. Più responsabilità, più pressione, ma non necessariamente più potere prodotto.

Il vero product engineer non è solo uno sviluppatore rapido. È qualcuno che porta una parte del giudizio prodotto il più vicino possibile alla costruzione.

I PM scendono verso la costruzione

Il movimento inverso esiste anche.

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

Questo cambia la natura del lavoro.

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

E a volte, non si tratta nemmeno solo di prototipare. Su casi semplici o ben inquadrati, si può codificare qualcosa di quasi reale: un dashboard, uno schermo in sola lettura, un miglioramento di interfaccia, un'automazione interna, una traduzione, un supporto di release.

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

Bisogna qui distinguere diversi livelli.

Il PM o PO prototypista trasforma un'intenzione di business in prototipo o POC.

Il Product Builder va oltre: costruisce artefatti tangibili, strumenti interni, dashboard, prime versioni, contribuzioni inquadrate.

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

Il criterio non è quindi il mestiere di origine. Il criterio è il livello di capacità d'azione.

La persona resta al livello del mockup? Produce un prototipo? Apre una PR? Porta un livrable producibile? Capisce abbastanza i rischi per far validare correttamente ciò che produce?

È questo continuum che è nuovo.

I ruoli si confondono, le responsabilità restano

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

Penso esattamente l'opposto.

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

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

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

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

L'organizzazione che funziona non è quella dove tutti fanno tutto nel proprio angolo. È quella dove ognuno può intervenire oltre il proprio dominio iniziale perché dei garanti pongono gli standard, i guardrail e i limiti.

Un PM può spingere una PR. Ma 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 questo tipo di contribuzione. Forse l'argomento è troppo rischioso. Forse anche il team tecnico non ha ancora messo in atto le direttive, gli strumenti o i guardrail che permettono ad altri profili di contribuire in modo sicuro.

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

Tutto dipende dal rapporto competenza / rischio

La buona domanda non è: «Un PM può spingere in produzione?»

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

Serve una gradazione semplice.

Basso rischio: traduzioni, contenuti, dashboard, schermi in sola lettura, strumenti interni non critici.

Rischio medio: piccole azioni in scrittura, workflow interni, modifiche di interfaccia inquadrate.

Rischio forte: pagamento, permessi, sicurezza, dati sensibili, logica di business critica, prodotto regolamentato, architettura.

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

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

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

La frattura tra profili PM

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

A breve termine, i PM con un background tecnico hanno un vantaggio. Sanno leggere un repository, capire un errore, dialogare con un agente di codice, interpretare ciò che è stato generato, individuare certe assurdità, chiedere una review tecnica nel posto giusto.

Un PM senza questa cultura può ovviamente imparare. Ma rischia di essere 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 totalmente ciò che succede sotto il cofano. Se non si capisce almeno un po' gli errori prodotti, diventa difficile superare il mockup affidabile.

Questo non vuol dire che i profili non tecnici siano condannati. A medio o lungo termine, può accadere persino l'opposto. Se gli agenti diventano molto più affidabili, profili provenienti dalla psicologia, dalle lettere, dalla filosofia, dal design, dalla ricerca o dal business potrebbero prendere il vantaggio grazie alla loro capacità di esprimere finemente una realtà umana, sociale o di business.

Ma nello stato attuale degli strumenti, la frattura esiste.

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

I nuovi mestieri non sono sempre mestieri

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

Tutti questi ruoli non diventeranno necessariamente 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 erano a volte implicite o secondarie: la valutazione degli output probabilistici, la documentazione sfruttabile dagli agenti, la memoria prodotto, l'orchestrazione dei workflow, la qualità del contesto, la leggibilità del repository, la chiarezza dei criteri di accettazione.

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

Il PM non scompare, il livello minimo sale

Il product management non scompare.

Ma il mestiere diventa meno tollerante per i profili che vivevano soprattutto di coordinazione, redazione, follow-up 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, quelli che sanno costruire abbastanza per accelerare l'apprendimento prodotto: prototipare, materializzare, testare, contribuire, a volte spingere fino a un livrable reale.

Dall'altro, quelli che sanno giudicare abbastanza bene per orientare un team che può costruire molto più velocemente di prima: capire il mercato, leggere il segnale, arbitrare, dire no, tenere una visione, proteggere la coerenza e assumersi le conseguenze.

Tra questi due poli, esisteranno molte combinazioni. Ma il livello minimo sale.

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

Appendice: catalogo dei futuri ruoli 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, gli arbitraggi, la coerenza prodotto e la lettura del segnale cliente.

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

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

PM o PO prototypista

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

Il suo valore è ridurre l'ambiguità tra business, product e tech.

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

Product Builder

Profilo prodotto capace di trasformare direttamente un'idea in artefatto testabile, prototipo funzionale, strumento interno o contribuzione inquadrata.

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

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

Product Engineer

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

Può venire da un background sviluppatore o da un background product sufficientemente tecnico.

Il suo valore è ridistribuire una parte del giudizio prodotto il più vicino possibile alla costruzione e ridurre il divario tra 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 agli arbitraggi; o credere che un PM possa diventare product engineer senza capacità di capire, far validare e mantenere un livrable di produzione.

Product Systems Designer

Ruolo che progetta i sistemi prodotto alimentati dall'IA: feedback, discovery, generazione di spec, routing degli insight, documentazione vivente e workflow di release.

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

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

AI Product Evaluator

Ruolo incaricato di valutare gli output IA nel prodotto: qualità, allucinazioni, UX di errore, robustezza, test di business e coerenza con l'intenzione prodotto.

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

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

Product Knowledge Curator

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

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

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

Product Ops agentique

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

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

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

Tre famiglie di ruoli

Si possono leggere questi ruoli in tre famiglie.

I ruoli di giudizio: PM strategico aumentato.

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

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

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

Per saperne di più

Quattro giorni di vibe coding nei panni di un PM arrugginito In 8 giorni ho capito che il mestiere di Product Manager stava per cambiare completamente L'IA non dovrebbe servire solo a produrre dieci volte di più. Dovrebbe anche obbligarci a capire dieci volte meglio ciò che produciamo Nel software, il vantaggio non sarà più la tecnologia. Sarà la comprensione del contesto.