Ho due libri che mi hanno formato sul prodotto: Inspired, di Marty Cagan, e Gestão de Produtos, di Joca Torres, con cui ho anche avuto la fortuna di fare mentorship. Per anni questi due sono stati la mia mappa: cos’è un PM, cos’è un product designer, cos’è un ingegnere, chi fa cosa. Ogni ruolo con un contorno chiaro.
Nell’ultimo anno, guardando il mio team lavorare con l’IA in Prolog, ho iniziato a sentire quei contorni scivolare via. Non che i libri siano diventati sbagliati: è che il livello in cui ogni ruolo accade è salito.
Nel primo testo della serie ho raccontato il disagio che mi ha fatto iniziare a ricostruire il tech in Prolog, e nel secondo, cos’è un harness, l’infrastruttura che fa rendere l’IA. Alla fine del primo avevo promesso di aprire una parte specifica: come il lavoro di ogni ruolo cambia quando l’IA diventa chi costruisce. È questo l’argomento qui.
Il lavoro non sparisce, sale di un livello
L’IA non sta cancellando il ruolo di ogni professione, sta cambiando il livello in cui accade.
La lettura facile, quella che vende paura, è “l’IA sostituirà il ruolo X”, e non è quello che ho visto accadere. Quello che ho visto è il contenuto del lavoro cambiare posto: ciò che prima era fare è diventato dirigere e criticare chi fa.
L’ingegnere, che scriveva il codice, adesso revisiona quello che ha scritto l’agente. Il PM, che scriveva la spec, adesso giudica il prototipo che ne è uscito in poche ore. La persona è la stessa, è lo strumento che ha in mano a essere cambiato.
Quando sono tornato a Cagan e Joca con questo in testa, ho afferrato la cosa in un altro modo. I due descrivono, con cura, l’esecuzione di ogni ruolo (il compito concreto, il deliverable, ciò che esce dalle tue mani a fine giornata), ed è esattamente questo che l’IA sta prendendo in carico. Ciò che resta all’umano è l’altra metà: decidere cosa merita di essere costruito, trovare il buco in ciò che è stato costruito, avere il gusto per sapere cos’è buono. Il giudizio, non l’esecuzione.
Quindi farò quello che ho fatto con me stesso: prendere la definizione di ogni ruolo dai libri, e chiedere cosa di essa l’IA si mangia e cosa di essa resta (e diventa più caro).
Il team dei tre, secondo i libri
Prima di separare ruolo per ruolo, vale la pena ricordare come i libri montano il team. Joca è diretto: un prodotto di successo deve essere desiderabile, sostenibile e fattibile, e questo definisce “le tre funzioni essenziali per creare un prodotto di successo” (cap. 2): designer di UX, product management e sviluppatore, il trio che lui chiama core team. Cagan, in Inspired, descrive gli stessi ruoli nel capitolo di apertura, “Key Roles and Responsibilities”.
I due insistono su un punto che riprenderò alla fine: non è un rapporto tra capo e subordinato. Nelle parole di Joca, “l’ingegneria di prodotto, il product management e la UX sono un team, non c’è alcun rapporto di subordinazione tra questi gruppi” (cap. 31), e in Cagan la stessa idea appare come PM e ingegneria che sono “pari, nessuna posizione è subordinata all’altra” (cap. 5, nella mia traduzione). E quando l’IA entra in mezzo al trio, è questa collaborazione a cambiare forma più di tutte.
Tabella: ogni professione nel tech sale di un livello. L'ingegneria passa da produttore di codice a critico dell'agente; il prodotto, da spec writer ad architetto di iterazione; il design, da produttore di schermate a direttore d'esperimento; la qualità, da tester a costruttore di validazione.
Il ruolo di ogni professione nel tech
Lo stesso ruolo, un livello più su
l'esecuzione passa all'agente · il giudizio resta a te: decidere, criticare, avere gusto
Ingegnere: da produttore di codice a critico dell’agente
Per l’ingegneria, quello che conta ha smesso di essere quanto codice produci: è diventato quanto bene critichi ciò che l’agente ha prodotto.
La definizione di Joca è così chiara che fa male rileggerla adesso: “l’ingegneria di prodotto è responsabile di sviluppare il prodotto e di tenerlo in funzione”, e, più avanti, l’ingegneria “costruisce il prodotto” (cap. 31). Costruire era il verbo. Cagan completa dall’altro lato, parlando del rapporto con il prodotto: “il product manager è responsabile di definire la soluzione, ma il team di ingegneria sa meglio cosa è possibile, ed è lui che alla fine consegna quella soluzione” (cap. 5, nella mia traduzione). Definire da un lato, consegnare dall’altro.
Adesso la consegna della prima versione è dell’agente. Ciò che non è cambiato, ed è diventato più caro, è tutto quello che Cagan attaccava all’ingegnere come fonte di innovazione: “gli ingegneri sanno meglio di chiunque cosa è possibile” (cap. 5). Sapere cosa è possibile, trovare il buco nel piano che l’agente ha proposto, vedere il trade-off di performance o sicurezza che lui non vede, decidere quando intervenire e quando lasciar correre. Questo pesa di più ogni mese. Memoria della sintassi, boilerplate a mano, spulciare Stack Overflow, volume di codice come trofeo personale: questo pesa di meno.
In Prolog l’ho detto a chiare lettere al team: nessuno sarà valutato in base alle righe di codice. Chi è sempre stato bravo a “trovare il buco” diventa più prezioso, e chi si identificava con “produrre tanto codice in fretta” dovrà ricalibrare dove investe. E questo non sminuisce l’ingegneria. Il suo valore è sempre stato più nel sapere cosa vale che nel produrre in fretta, e adesso questo diventa solo esplicito.
PM: da spec-writer ad architetto di iterazione
Il PM lo sente quando il prototipo costa poco: il suo lavoro smette di essere scrivere il documento e diventa scegliere quale idea merita il tempo del team.
Cagan è categorico sul cuore del lavoro: “qualcuno deve scoprire qual è la soluzione, il prodotto, incluse le funzionalità, l’esperienza utente e i criteri di rilascio. Quel qualcuno è il product manager, e questo compito è il cuore del suo lavoro” (cap. 1, nella mia traduzione). Joca dà il contorno largo: il product management è “la funzione responsabile di tutti gli aspetti di un prodotto software, per tutto il ciclo di vita di quel prodotto, dalla sua concezione fino alla fine della sua vita” (cap. 2).
Nota che in entrambi la parola chiave è scoprire, non specificare. Cagan ha un intero capitolo solo per sostenere che il lavoro è discovery, non “requisiti”: il software ha due stadi, “scoprire cosa costruire (il prodotto giusto) e costruire (il prodotto nel modo giusto). Il primo è dominato dal discovery, il secondo è esecuzione” (cap. 12, nella mia traduzione). Questo è sempre stato il suo messaggio, e l’IA l’ha solo reso letterale.
Perché quando la build collassa da settimane a ore, il collo di bottiglia smette di essere costruire e diventa decidere cosa vale la pena costruire. La spec lunga revisionata in comitato, il planning trimestrale chiuso, lo status report come deliverable, il controllo del traffico tra ingegneria e design: tutto questo pesa di meno. Ciò che pesa di più è il discovery rapido (prototipare per capire, non specificare per costruire), la curatela delle ipotesi (quale idea merita il tempo del team) e decidere cosa non fare, più spesso. Alcune aziende stanno già chiamando questo PM “Editor” o “Architetto”. Non è meno PM: è un altro PM, chi cura, chi decide con gusto, chi dà la direzione. Ciò che era centrale nel vecchio, scrivere la spec, è quello che è diventato leggero.
Product designer: da produttore di schermate a direttore d’esperimento
Nel design, l’unità di lavoro esce dalla schermata e va al sistema che produce schermate, e il product designer passa a scegliere quale variazione sopravvive.
In Joca, la definizione di UX è capire per progettare: “la UX è responsabile di capire a fondo l’utente e il problema che si vuole risolvere per quell’utente” (cap. 32). E il flusso che descrive è il rituale che tutti conoscono: prototipo su carta, poi wireframe, poi “il visual designer di UX comincia a mettere colore e forma su quelle schermate”. Cagan taglia il ruolo in due con la stessa logica: l’interaction designer “sviluppa una comprensione profonda degli utenti e crea i task, la navigazione e il flusso”, mappa questo in wireframe e passa al visual designer, che “mette carne sul wireframe” (cap. 4, nella mia traduzione).
Questa concatenazione, capire, abbozzare, rifinire schermata per schermata, è proprio ciò che l’IA accorcia. L’unità di lavoro smette di essere “la schermata” e diventa “il sistema che genera schermate”. Rifare la stessa variazione cinque volte in Figma, specificare componente per componente, l’handoff pixel-perfect come rito: pesa di meno. Prototipare a velocità d’iterazione (varie opzioni in parallelo, scartare quelle brutte), definire il sistema visivo invece di ogni schermata isolata, e la critica visiva rapida (vedere l’IA proporre qualcosa e cogliere al volo che è sbagliato prima che lo colga l’utente): pesa di più.
E qui Cagan dice, già nel 2008, una cosa che protegge il product designer dal pensare di essere diventato uno schiacciabottoni: il suo lavoro non è mai stato solo disegnare cose belle. “Un buon prodotto richiede una buona esperienza utente. E una buona esperienza richiede la stretta collaborazione tra prodotto e design” (cap. 4, nella mia traduzione). L’IA genera la variazione, e chi decide quale di esse merita di arrivare all’utente resta una persona con gusto.
QA: da tester a costruttore di validazione
Il QA è il caso più interessante, perché è il ruolo che i libri hanno quasi non isolato, ed è quello che l’IA muove di più.
Nota: nel trio di Joca (designer, PM, sviluppatore) e nei ruoli di Cagan, la qualità appare diluita, come responsabilità del team, non come una sedia propria con un metodo proprio. Per molto tempo ha avuto senso, ma adesso non ne ha più, e la ragione è semplice: se l’agente costruisce in fretta e la validazione resta manuale, hai solo prodotto debito tecnico ad alta velocità.
Allora il QA smette di essere chi esegue il caso di test a mano e diventa chi progetta il testing harness, il sistema che testa il sistema: configurare l’IA per scrivere test per il codice che un’altra IA ha scritto, rilevare le regressioni prima dell’utente, pensare a dove il difetto tende a comparire. Nella pratica, è diventata una domanda operativa che abbiamo adottato: ogni bug che sfugge diventa “come lo rileviamo automaticamente la prossima volta?”. Test manuale esaustivo di un flusso conosciuto, regressione eseguita a mano a ogni release, QA come cancello unico prima di andare in produzione: pesa di meno. La validazione come sistema, non come passaggio di palla a fine catena.
È il ruolo che sale di livello più di tutti proprio perché era il meno definito. Dove i libri non hanno inciso un contorno, l’IA ne sta disegnando uno nuovo.
La costante: ciò che i libri dicevano già contasse di più
C’è una cosa che non cambia, ed era nascosta in piena vista nei due libri: ciò che loro indicano come la caratteristica più importante è esattamente ciò che l’IA non fa.
Joca apre il capitolo sulle caratteristiche di un buon PM senza giri di parole: “la più importante di tutte è, senza alcun dubbio, l’empatia” (cap. 4). Non è una tabella di funzioni né un deliverable: è la capacità di mettersi nei panni di chi usa. Cagan, dal canto suo, spende l’intero libro a difendere discovery, taste e giudizio sopra il processo, e i due, ognuno a modo suo, stavano dicendo la stessa cosa: ciò che separa il bravo dal mediocre non è mai stata la parte meccanica del lavoro.
E la parte meccanica è proprio quella che è passata all’agente. Scrivere la spec, disegnare la schermata, scrivere il codice, eseguire il test. Ciò che è rimasto, ed è diventato più caro, è il senso critico, il taste (sapere cos’è buono), il giudizio nell’ambiguità, la curiosità, la cura per chi usa ciò che fai. Riassumendo nella frase che ho usato con il team: il contenuto del lavoro cambia, la persona che lo fa, no.
Diagramma a due livelli. In alto, ciò che è rimasto a noi ed è diventato più caro: taste (sapere cos'è buono), giudizio nell'ambiguità, empatia per chi lo usa, decidere cosa non fare, ciò che i libri dicevano già contasse di più. Il lavoro è salito di un livello. In basso, ciò che è passato all'agente: scrivere la spec, disegnare la schermata, scrivere il codice, eseguire il test manuale.
È rimasto a noi · ed è diventato più caro
ciò che i libri dicevano già contasse di più
il lavoro è salito di un livello
È passato all'agente
Cosa questo costerà (senza cliché)
Non voglio chiudere questa cosa in modo troppo bello, perché non lo è. Questo cambiamento costa cose concrete, e nessuna è comoda.
La prima è lasciarsi dietro abitudini di un decennio. Chi è da cinque, dieci anni nel vecchio modo si porta dietro schemi che hanno aiutato ad arrivare fin qui, e sono proprio questi schemi a pesare quando si cambia. Non c’è scorciatoia, e il disagio è previsto.
Poi, criticare l’IA tanto quanto creare con lei: accettare il suggerimento che è comparso non è lavoro; trovare il buco nel piano che ha proposto, sì. Ciò che è sempre stato caro (pensiero critico, taste, giudizio) diventa più caro.
C’è anche lo sbagliare come team, non come persona. Non licenziamo un ingegnere per un bug in produzione, miglioriamo la review, e quando l’IA sbaglia è l’harness che rafforziamo. Il bug dell’agente è processo, non persona: un impegno, non uno slogan.
E la più scomoda: accettare che alcune funzioni cambiano più di altre. Questo genera disagio in chi finora ha cambiato poco, e non si può fingere che sia tutto uguale. Quello che si può fare è portarlo in una conversazione aperta.
E per non suonare come chi è arrivato a destinazione: Prolog è ancora all’inizio di questo. Siamo ancora nell’AI-assisted, con un guadagno del 10-20%, non nell’AI-first da 5x o 10x. Sto raccontando una direzione che stiamo costruendo, con successi e con errori, non una vittoria.
Cosa mi porto da questo
I libri non sono diventati sbagliati. Descrivevano l’esecuzione di ogni ruolo con una precisione che ho capito davvero solo adesso (scrivere la spec, disegnare la schermata, costruire il prodotto, eseguire il test), e questa esecuzione adesso è dell’agente. E ciò che è rimasto all’umano è l’altra parte, giudicare, criticare, avere gusto, prendersi cura di chi usa, che, tornando a Cagan e Joca, è ciò che loro dicevano contasse di più fin dalla prima pagina.
Forse è questa la parte buona: il lavoro che l’IA ci ha tolto dalle mani è quello che era più ripetitivo, e ciò che ha lasciato è quello che è sempre stato più difficile, e più interessante. Continuerò a raccontare come va.
Fonti
- Marty Cagan, Inspired: How to Create Products Customers Love (1ª edizione, 2008). Le definizioni di ruolo vengono dai capitoli 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) e 12 (Product Discovery). Le traduzioni dei passaggi sono mie.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Le definizioni vengono dai capitoli 2 (Cos’è il product management di software?), 4 (Principali caratteristiche di un product manager), 31 (Ingegneria di prodotto e product management) e 32 (UX e product management).
- La lettura sul ruolo che sale di un livello sostiene la serie: OpenAI, Harness Engineering, e Peter Pang, CTO di CREAO.