Idea principale

Si sta aprendo un divario di capacità tra i Product Manager con un percorso tecnico e gli altri. Non riguarda la comprensione del mercato, né la qualità del giudizio, né la capacità di dare un nome a un problema — i terreni su cui di solito si gioca il mestiere.

Riguarda un accesso. Chi sa leggere un repository, seguire le merge request e interrogare una cronologia di commit può lavorare direttamente sulla materia del prodotto: generare un artefatto a partire da essa, verificare che un documento dica il vero, smentire un'affermazione mostrando il codice. Chi non lo sa fare deve passare da qualcun altro, e l'andata e ritorno costa abbastanza da fargli rinunciare nella maggior parte dei casi.

Il divario è quindi di strumenti, non di valore. È una distinzione importante, perché i due casi richiedono rimedi opposti: una carenza di attitudine si colma assumendo, una carenza di accesso si colma imparando o dotandosi di strumenti.

Contributo di «PM, sviluppatori e IA: i ruoli si confondono, le responsabilità restano» (2026-08-01). Il divario di accesso si allarga ancora quando il Product Manager si mette a costruire. Leggere un repository, capire un errore, dialogare con un agente di codice, individuare un'assurdità in ciò che è stato generato e chiedere la giusta revisione tecnica condizionano tutto ciò che va oltre il mockup: finché gli strumenti restano fallibili, non si può ignorare ciò che succede sotto il cofano. Il confine è legato a questa fase e può invertirsi: se gli agenti diventeranno molto più affidabili, profili che vengono dalla psicologia, dalle lettere, dal design o dalla ricerca tornerebbero in vantaggio grazie alla loro capacità di esprimere con finezza una realtà umana e di business.

Perché è importante

Evita la lettura identitaria — «i PM tecnici sono migliori» — che chiude la discussione, e la sostituisce con una domanda trattabile: di quale accesso ha bisogno un PM non tecnico, e a quale prezzo può ottenerlo?

Dice anche che cosa succede se non si fa nulla: il divario non si riassorbe da solo, perché si accumula. Ogni verifica fatta direttamente affina la comprensione del prodotto, il che rende più rapida la verifica successiva.

Sfumature e limiti

L'accesso non è un vantaggio senza rovescio: il PM tecnico può mettersi a trattare i problemi che sa risolvere con il codice, a scapito di quelli che riguardano il mercato.

E il confine si sposta. Gli strumenti che rendono un repository interrogabile in linguaggio naturale abbassano il costo dell'accesso senza eliminarlo — la cultura tecnica resta necessaria per sapere che cosa chiedere e per giudicare la risposta.

Domande aperte

• Chi decide che un Product Manager ha il diritto di intervenire nel repository, e con quale motivazione questo diritto gli viene negato quando succede?