Ho pubblicato una frase semplice su LinkedIn: la figura del Product Owner mi sembrava già un'assurdità organizzativa, e nell'era dell'IA diventa francamente difficile da difendere.

66.000 impressioni e una quarantina di commenti dopo, constato due cose. La prima è che ho toccato un nervo scoperto. La seconda è che metà dei disaccordi nasce da un malinteso che voglio togliere di mezzo subito.

Non cercavo la polemica — del numero di visualizzazioni non mi importa nulla. E soprattutto: avevo esattamente questa posizione prima dell'IA. La menzione dell'IA ha cristallizzato le reazioni, ma non è il fondamento del mio argomento. Ne è l'acceleratore.

Il post originale e tutti gli scambi sono qui. Questo articolo è la mia risposta costruita a chi si è preso il tempo di contraddirmi.

Quello che non sto dicendo

Non sto dicendo che l'IA sostituirà i Product Owner.

Mi è stato risposto, a ragione, che un'IA non capisce un mercato, non anticipa un bisogno, non difende una visione davanti a uno sponsor, non tiene un NO GO e non rende conto sei mesi più tardi. Sono d'accordo. Completamente.

E non sto nemmeno dicendo che le persone con «PO» stampato sul biglietto da visita siano inutili. Ne conosco di eccellenti. Quello che critico è la separazione, non le persone che la subiscono.

Quello che dico: il prodotto è ciò che è in produzione

Una specifica descrive un'intenzione. Un PRD descrive un obiettivo, delle regole attese, degli scenari. Un mockup descrive un'interfaccia desiderata.

Ma tra quell'intenzione e la produzione succede sempre qualcosa. Ho sviluppato questo punto in La domanda di prodotto deve partire dal codice sorgente:

Si fanno compromessi. Si aggiustano dettagli. Compaiono casi limite. Durante lo sviluppo si prendono decisioni. Vincoli tecnici obbligano a modificare leggermente il comportamento. Ci sono scambi dentro una pull request o una merge request. Non tutte le scelte risalgono fino alla documentazione iniziale.

[...] la spec non è la verità del prodotto. È un'approssimazione utile in un dato momento. La verità è ciò che gira.

Non è un dramma. È persino normale: un prodotto vivo non si costruisce come un documento congelato.

Ma questo ha una conseguenza che ci rifiutiamo di guardare in faccia. Se la verità del prodotto si fabbrica tra l'intenzione e la produzione, allora chi resta a monte della produzione non lavora sul prodotto. Lavora su un'intenzione. Non vede mai le scelte che, in realtà, definiscono ciò che il cliente vivrà.

Il cliente non vede la tua discovery. Non vede il tuo framework di prioritizzazione, né la tua bella roadmap. Vede quello che esce in produzione. E la qualità di un prodotto sta in un accumulo di piccoli dettagli — e quei dettagli li vedi solo se segui la cosa fino in fondo.

Da qui la mia convinzione: chi pensa il prodotto deve essere anche chi lo consegna e chi lo accompagna dopo la consegna. Una sola e stessa persona. Ownership completo.

L'assurdità non è il contenuto della figura, è ciò che la sua esistenza rivela

Quello che rende la figura di PO indifendibile ai miei occhi non è dunque ciò che un PO fa ogni giorno. È il fatto che un'organizzazione abbia ritenuto utile separare la parte «nobile» — pensare il prodotto — dalla parte che si delega: seguire il backlog, tenere il rapporto con gli sviluppatori, sorvegliare la messa in produzione.

È taylorismo applicato al prodotto.

E questo film l'abbiamo già visto.

C'è stata un'epoca con gli analisti da una parte e i programmatori dall'altra. Gli uni pensavano, gli altri producevano codice a metro. Quella separazione è sparita. Oggi ci sono gli sviluppatori, che prendono un problema dall'inizio alla fine: l'architettura, il codice, la sicurezza, la consegna, il monitoraggio. Ci sono persino sempre meno architetti separati dal resto del team.

Nessuno rimpiange gli analisti-programmatori. Nessuno sostiene che si producesse software migliore quando la riflessione e l'esecuzione vivevano in due teste diverse.

Non vedo nessuna ragione perché il prodotto sfugga a questo movimento.

Applico a me stesso la regola che impongo agli sviluppatori

C'è un argomento che devo affrontare prima di tutti gli altri, perché mi riguarda direttamente.

In La qualità appartiene a chi consegna ho scritto una regola che considero non negoziabile lato sviluppo:

La regola più sana è semplice: chi crea il bug lo corregge.

Non perché bisogna punire. Non perché bisogna umiliare. Perché la responsabilità della correzione deve restare attaccata alla responsabilità della produzione.

E più avanti:

Nella maggior parte dei casi, se uno sviluppatore ha creato il difetto, deve correggerlo. Anche se è passato a un argomento importante. Anche se questo scombina la pianificazione. Anche se rallenta la feature successiva.

La qualità consuma capacità. Nasconderla non la rende gratis.

Avrei ben poco titolo per pretendere questo dagli sviluppatori ed esentarmene io stesso.

Un PM che progetta e poi affida a un PO il compito di portare la cosa fino in produzione fa esattamente quello che rimprovero allo sviluppatore che consegna e passa al tema successivo. Esternalizza il costo di quello che ha prodotto. Non vede mai dove la sua comprensione era insufficiente, dove la formulazione era ambigua, dove la scelta era traballante. Il cerchio non si chiude.

Ed è proprio quel cerchio a creare qualità.

La qualità non si delega a posteriori. Né lato codice, né lato prodotto.

«Stai descrivendo un cattivo PO»

È l'obiezione più frequente, ed è arrivata da diverse persone: il ruolo di un PO è capire il bisogno, definire le funzionalità dal punto di vista del cliente, portare una visione, decidere tra priorità contraddittorie, massimizzare il valore.

La mia risposta è sempre la stessa: quello si chiama Product Manager. Mi hai appena descritto il mio mestiere.

Se la tua definizione di PO coincide con la mia definizione di PM, allora siamo d'accordo nel merito e stiamo litigando su una parola.

Il problema è che non è quello che il mercato assume. Mi è stato rimproverato di descrivere un PO che non esiste. Apri gli annunci di lavoro: alimentare il backlog, scrivere le user story, fare da interfaccia tra il business e i dev, condurre le cerimonie. Quel PO lì è dappertutto. Anzi, è la maggioranza.

E qui c'è un punto che nessuno ha sollevato nei commenti.

Non si può fondare un mestiere su un artefatto usa e getta

L'argomento più usato per difendere il ruolo è quello del backlog: il PO massimizza il valore del prodotto tenendo, affinando e prioritizzando il backlog.

Solo che questa base l'ho già demolita altrove, senza nominare l'IA nemmeno una volta. In Il backlog non è una discarica:

Un item di backlog serve fino alla consegna. Dopo, perde gran parte del suo valore.

I ticket si desincronizzano. Le spec si desincronizzano. Le scelte cambiano durante la realizzazione. Il comportamento finale in produzione spesso differisce da quello che era stato scritto all'inizio.

[...] Il backlog non è una fonte di verità. È un supporto temporaneo di coordinamento.

E soprattutto, non è più il posto dove si pensa il prodotto:

Strumenti come Jira, Notion o equivalenti restano spesso strumenti di schede. Elaboratori di testo migliorati. [...] Possono essere utili per coordinare l'azione. Ma sono molto deboli per costruire una riflessione di prodotto.

[...] Il ticket non è più il posto dove si pensa. È il posto dove si deposita il risultato di un pensiero già strutturato.

Allora se il backlog non è né la memoria del prodotto, né il cervello del prodotto, né un asset duraturo — come si fonda un mestiere sul fatto di tenerlo?

Su un artefatto consumabile si può fondare una funzione. Non un mestiere.

Notate che questo argomento non ha niente a che vedere con l'IA. Era già vero nel 2020.

Il nome conta, ed ecco perché

Mi è stato obiettato che PO è un ruolo dentro un quadro metodologico, mentre PM è un mestiere. Che l'importante è quello che si fa, non come ci si chiama.

Sul principio sono d'accordo. Ho fatto project management in un'epoca in cui non sapevo che avesse un nome. Quello che si fa conta più dell'etichetta.

Ma il titolo fabbrica il mandato.

Nei fatti, i PO hanno meno ownership e meno autonomia. Quando sei PM sei owner del tuo scope, punto. Diverse persone lo hanno formulato meglio di me nei commenti: il titolo di PO è spesso servito a isolare la responsabilità di prodotto senza dare il mandato decisionale.

Un PO senza mandato per decidere non è un ruolo. È una posizione scomoda.

E lì riconosco un meccanismo che ho già descritto in Perché le organizzazioni preferiscono le decisioni deboli:

Una decisione chiara rende visibile la responsabilità. Espone chi decide. Offre appigli alla critica. Obbliga ad ammettere che certe richieste non sono state accolte.

Una decisione debole distribuisce quella responsabilità. La diluisce tra i partecipanti, le riunioni, i documenti, le formulazioni prudenti, le validazioni successive.

Separare in due la responsabilità di prodotto è lo stesso riflesso applicato all'organigramma. Permette di avere qualcuno che ne porta le conseguenze senza aver avuto la scelta, e qualcuno che ha avuto la scelta senza portarne le conseguenze.

L'espediente è comodo. È anche la ragione per cui nessuno è più davvero responsabile di niente.

Dove l'IA entra davvero in gioco

Il mio argomento sull'IA non è «sostituirà i PO». È più meccanico di così.

La separazione tra chi pensa e chi esegue aveva una giustificazione economica. Il lavoro di traduzione, di documentazione, di scrittura, di messa in forma costava caro in tempo. Abbastanza caro perché si creasse una figura dedicata ad assorbire quello strato operativo.

Per molto tempo il PM è stato uno snodo: raccogliere bisogni, riformulare, produrre documenti, chiarire ticket, rimettere ordine, coordinare, prioritizzare, seguire, sollecitare, documentare ancora. Una parte del mestiere consisteva nel compensare gli attriti dell'organizzazione. Abbiamo finito per accettare come normale una massa di compiti che non erano il cuore del mestiere, solo la sua idraulica.

Quel costo sta crollando.

E quando la giustificazione economica di una divisione del lavoro sparisce, la divisione del lavoro non sopravvive a lungo.

È qui che il mio disaccordo iniziale e l'IA si incontrano. L'IA non crea il problema: toglie l'ultima scusa pratica che avevamo per conviverci. Non si può più dire «sì, in teoria il PM dovrebbe seguire fino in produzione, ma in concreto non ha tempo».

Quindi continuare oggi ad assumere su una descrizione della figura costruita attorno alla trasmissione di informazioni significa ottimizzare un circuito già obsoleto.

La sfumatura sulla scrittura

Mi è stato risposto: «la scrittura non è mai stata il collo di bottiglia del mestiere».

Sulla decisione, è vero. Decidere non è mai stato un problema di scrittura, e non sosterrò il contrario.

Ma in senso ampio non sono d'accordo. Sono l'unico PM per tutta l'azienda. Quando bisogna produrre un video in quindici lingue con i sottotitoli, articoli in quattro o cinque lingue, i post, i brief sui vantaggi e sui punti da mettere in evidenza — è un lavoro folle. L'IA mi permette di fare cose per cui semplicemente non avevo il tempo. Non era il collo di bottiglia della decisione. Ma era un muro, eccome.

L'IA la vedo come un'ottima segretaria personale. Raccoglie la mia riflessione, ingoia le fonti, fa il lavoro ingrato. Ma la persona che capisce in profondità, che sceglie, che si prende il rischio e se lo assume, è il PM. Non l'IA.

E c'è una cosa che non farà mai: la scommessa.

Se sei una startup e la domanda è «ci buttiamo al 100% o moriamo», quella scelta appartiene a chi ha fondato l'azienda. Un'IA può analizzare l'opzione. Non può assumersela.

Dove chi mi ha contraddetto mi ha fatto progredire

Tre cose che mi porto via dal dibattito.

Il mandato conta più del titolo. Diverse persone hanno riportato il discorso su questo punto, e hanno ragione. Un PM chiuso nell'operativo e nella gestione delle urgenze, senza margine per definire una strategia di prodotto, sarà occupato senza produrre nulla di utile. Rinominare le figure non risolve niente se il mandato non segue. La mia insistenza sul vocabolario non deve nascondere questo.

Si può ripensare la figura invece di eliminarla. Un lead tecnico mi ha descritto il suo team, su un software sanitario regolamentato con una codebase legacy: non hanno eliminato la figura, l'hanno ridefinita. Lo sviluppatore porta una parte della visione di prodotto, il PO progetta. Le persone restano, il ruolo cambia. È probabilmente più giusto della mia formulazione iniziale, e vale la pena dirlo: ciò che diventa indifendibile è la cinghia di trasmissione, non le persone.

Il vero pericolo è lo strato di isolamento. Il problema non è che un PO esista. È quando diventa lo strato che taglia fuori gli sviluppatori dal bisogno reale — con la scusa che i dev non avrebbero bisogno di capire il dominio, ma solo di eseguire delle spec. Quello, l'IA lo renderà ancora più insostenibile. Da noi, gli sviluppatori intervistano i clienti direttamente da diversi mesi. E qualche giorno fa ho spinto la mia prima pull request sul nostro prodotto principale.

Sulla competenza di dominio, infine, correggo un'idea diffusa: non è proprietà del PO. L'ho trovata in CSM venuti dal campo, in persone del supporto. Può stare ovunque — e deve stare nel PM. Nel mio settore ingoio libri e video di manutenzione industriale. Devo essere eccellente sul dominio, altrimenti non ho niente su cui decidere.

Dove non mi muovo

Mi è stato detto che il PO che descrivo è probabilmente quello che sono stato io. È possibile.

E aggiungo una cosa più imbarazzante da ammettere: è molto comodo liberarsi del backlog, del monitoraggio dei dev, delle messe in produzione. Il PM ha un interesse oggettivo a che la figura di PO esista. Si tiene la parte che si racconta bene in riunione, si delega quella che costa.

È proprio per questo che me ne guardo.

Separare chi pensa da chi esegue è un'assurdità. Non perché arriva l'IA. Perché il prodotto è ciò che è in produzione — e perché non si delega la responsabilità di ciò che si è progettato.

L'IA non rende vero questo argomento.

Lo rende impossibile da aggirare.