Il PO non è un mestiere, è una funzione — e l'IA non cambia nulla, accelera

Ho pubblicato una frase semplice su LinkedIn: la posizione di Product Owner mi sembrava già un'aberrazione organizzativa, e nell'era dell'IA sta diventando francamente difficile da difendere.

66.000 impressioni e una quarantina di commenti dopo, due cose sono chiare. La prima è che ho toccato un nervo scoperto. La seconda è che metà dei disaccordi si basa su un malinteso che voglio chiarire subito.

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

Il post originale e l'intera discussione sono qui. Questo articolo è la mia risposta costruita a chi ha preso il tempo di contraddirmi.

Quello che non dico

Non dico che l'IA sostituirà i Product Owner.

Mi hanno risposto, a giusto titolo, 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 dopo. Sono d'accordo. Completamente.

E non dico nemmeno che le persone con «PO» sul biglietto da visita non servano a niente. Ne conosco di eccellenti. Critico la divisione, 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 questa intenzione e la produzione succede sempre qualcosa. Ho sviluppato questo punto in La domanda prodotto deve partire dal codice sorgente:

Si fanno dei compromessi. Si aggiustano dei dettagli. Compaiono dei casi limite. Vengono prese delle decisioni durante lo sviluppo. Dei vincoli tecnici obbligano a modificare leggermente il comportamento. Degli scambi avvengono in una pull request o una merge request. Degli arbitraggi non risalgono sempre nella documentazione iniziale.

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

Non è grave. È anche normale: un prodotto vivo non si costruisce come un documento fisso.

Ma 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 prima della produzione non lavora sul prodotto. Lavora su un'intenzione. Non vede mai le scelte che, in realtà, definiscono quello 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 fino in fondo.

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

L'aberrazione non è il contenuto della posizione, è ciò che la sua esistenza rivela

Ciò che rende la posizione di PO indifendibile ai miei occhi non è quindi quello 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 la relazione con gli sviluppatori, sorvegliare il passaggio in produzione.

Questo è 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 divisione è scomparsa. 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 perfino sempre meno architetti separati dal resto del team.

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

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

Mi impongo la regola che impongo agli sviluppatori

C'è un argomento che devo affrontare prima di tutti gli altri, perché punta direttamente su di me.

In La qualità appartiene a chi consegna ho fissato una regola che considero non negoziabile dal lato engineering:

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

Non per punire. [...] Ma perché la responsabilità della correzione deve restare legata 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 disturba la pianificazione. Anche se rallenta la feature successiva.

La qualità consuma capacità. Nasconderlo non la rende gratuita.

Sarei mal posizionato a pretendere questo dagli sviluppatori e a esentare me stesso.

Un PM che concepisce 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 all'argomento 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 storta. Il ciclo non si chiude.

Ed è quel ciclo a creare qualità.

La qualità non si delega a posteriori. Né dal lato del codice, né dal lato del 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, arbitrare tra priorità contraddittorie, massimizzare il valore.

La mia risposta è sempre la stessa: questo si chiama Product Manager. Hai appena descritto il mio mestiere.

Se la tua definizione di PO copre la mia definizione di PM, allora siamo d'accordo nella sostanza e stiamo litigando su una parola.

Il problema è che non è questo che il mercato assume. Mi hanno 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 è dappertutto. Ed è la maggioranza.

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

Nessuno fonda 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 tenendolo, affinandolo e prioritizzandolo.

Solo che ho già demolito quella base altrove, senza parlare di 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 luogo dove si pensa il prodotto:

Strumenti come Jira, Notion o i loro equivalenti restano spesso strumenti a 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 luogo dove si pensa. È il luogo dove si spinge il risultato di un pensiero già strutturato.

Quindi, se il backlog non è né la memoria del prodotto, né il cervello del prodotto, né un asset durevole — come si fonda un mestiere sul tenerlo?

Si può fondare una funzione su un artefatto consumabile. Un mestiere, no.

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

Il nome conta, ed ecco perché

Mi hanno obiettato che PO è un ruolo dentro un quadro metodologico, mentre PM è un mestiere. Che l'importante è quello che fai, non come ti chiami.

In principio sono d'accordo. Ho fatto project management in un'epoca in cui non sapevo nemmeno 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 l'hanno formulato meglio di me nei commenti: il titolo di PO è servito spesso a compartimentare la responsabilità di prodotto senza dare il mandato di decisione.

Un PO senza mandato di arbitraggio non è un ruolo. È una posizione scomoda.

E qui riconosco un meccanismo che ho già descritto in Perché le organizzazioni preferiscono le decisioni morbide:

Una decisione chiara rende visibile la responsabilità. Espone chi arbitra. Si presta alla critica. Obbliga ad ammettere che certe richieste non sono state accolte.

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

Tagliare in due la responsabilità di prodotto è lo stesso riflesso applicato all'organigramma. Permette di avere qualcuno che porta la conseguenza senza aver avuto la scelta, e qualcuno che ha avuto la scelta senza portare la conseguenza.

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

Dove entra davvero l'IA

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

La divisione tra chi pensa e chi esegue aveva una giustificazione economica. Il lavoro di traduzione, documentazione, redazione e impaginazione costava molto tempo. Abbastanza caro da giustificare una posizione 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 di nuovo. Una parte del mestiere consisteva nel compensare gli attriti dell'organizzazione. Abbiamo finito per accettare come normale una massa di attività che non erano il cuore del mestiere, solo la sua infrastruttura tecnica.

Quel costo sta crollando.

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

È lì 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 pratica non ha tempo».

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

La sfumatura sulla redazione

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

Sull'arbitraggio è vero. Decidere non è mai stato un problema di redazione, e non pretenderò il contrario.

Ma in senso ampio non sono d'accordo. Sono l'unico PM di 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 — il lavoro è pazzesco. L'IA mi permette di fare cose per cui semplicemente non avevo tempo. Non era il collo di bottiglia della decisione. Ma era proprio un muro.

Io vedo l'IA come un'eccellente assistente personale. Raccoglie la mia riflessione, ingoia le fonti, fa il lavoro ingrato. Ma chi capisce con finezza, chi sceglie, chi si prende il rischio e chi ne risponde è il PM. Non l'IA.

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

Se sei una startup e la domanda è «andiamo al massimo 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 avanzare

Tre cose che mi porto dal dibattito.

Il mandato conta più del titolo. Diverse persone hanno riportato il tema 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 posizioni non risolve niente se il mandato non segue. La mia insistenza sul vocabolario non deve coprire questo.

Si può ripensare la posizione invece di sopprimerla. Un tech lead mi ha descritto il suo team, su un software sanitario regolamentato con una codebase legacy: non hanno soppresso la posizione, 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 gli sviluppatori dal bisogno reale — con il pretesto che i dev non dovrebbero capire il business, solo eseguire delle spec. Questo 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 ricevuta: non è proprietà del PO. L'ho trovata in CSM che venivano dal campo, in persone del supporto. Può stare da qualsiasi parte — e deve stare nel PM. Nel mio settore divoro libri e video di manutenzione industriale. Devo essere eccellente sul dominio, altrimenti non ho niente da arbitrare.

Dove non mi muovo

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

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

È esattamente per questo che ne diffido.

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

L'IA non rende vero questo argomento.

Lo rende impossibile da aggirare.

Per saperne di più

La qualità appartiene a chi consegna Il backlog non è una discarica: è uno strumento d'azione La domanda prodotto deve partire dal codice sorgente