Diventare PM nell'era dell'IA 02 | Non capire di tecnica: perché è invece un vantaggio

Partiamo da una cosa fatta da chi non sa scrivere codice.

Marcus Rush gestisce un’agenzia immobiliare residenziale e di suo non è un programmatore. Con Claude e Zapier ha messo insieme un agent IA chiamato Russ: ogni mattina assegna un punteggio ai lead pescando tra più di 11.000 contatti, scrive per ciascun agente della sua squadra il piano di follow-up della giornata e per inciso gli gestisce anche l’agenda. Il titolare di un’agenzia ha realizzato un sistema interno che fa girare le operazioni quotidiane, senza scrivere a mano una sola riga di codice.

Non è un caso isolato. In una statistica del 2026, il 63% degli utenti attivi del vibe coding non sono sviluppatori. Un designer senza alcun background di programmazione ha messo online un suo prodotto usando Replit più IA, arrivando a 20.000 $/mese: più del doppio del suo vecchio stipendio.

Mettendo insieme questi casi si nota una cosa controintuitiva: sulla strada che porta «da un’idea a qualcosa che gira davvero», chi non capisce di tecnica a volte va più spedito dell’ingegnere.

L’ingegnere deve prima disinnescare una cosa

Qualcuno ha osservato come lavorano gli ingegneri esperti quando usano l’IA. Sono abituati a fare le pulci a ogni dettaglio implementativo, ribattono con «perché non usare X» «hai considerato Y?», mentre la reazione di default del modello è «va bene, allora lo aggiungo». L’istinto, allenato in vent’anni, di rispondere di ogni singola riga di codice, qui — nella collaborazione con l’IA — va prima disinnescato.

Per loro è difficile. Quello che bisogna mollare è quella punta di ossessione del tipo «ogni riga la devo scrivere io di mio pugno e revisionare con i miei occhi». In quell’esperimento di METR, 16 programmatori esperti hanno usato l’IA su progetti che mantenevano da anni e sono andati in realtà il 19% più lenti, pur credendo di essere il 20% più veloci. Più uno è esperto, più facilmente finisce per andare contro lo strumento.

Chi non capisce di tecnica non ha questo fardello. Non ha nulla da disinnescare.

«Questo è troppo difficile»: chi non capisce di tecnica non riesce a dirlo

In passato una parte del giudizio del product manager veniva dal «quanto è difficile realizzare questa funzione». Questa conoscenza ha un effetto collaterale: più sei chiaro su quante cose vada a toccare un’idea e quante buche ci siano da attraversare, più facilmente la affossi prima ancora di aprire bocca. Chi se ne intende è quello che si autocensura di più.

Chi non capisce di tecnica non si pone questo ostacolo. Non sa che è difficile, quindi prima dice con chiarezza ciò che vuole e lascia che l’IA si mangi la parte di difficoltà implementativa. È proprio quello di cui parla il 言出法随 di doaipm: dillo con chiarezza, e l’IA te lo realizza. Marcus non sapeva «quanto fosse difficile» scrivere una logica di scoring che attraversa 11.000 contatti, sapeva solo cosa voleva, e l’ha detto.

La scarsità sta nel dire chiaramente l’idea, non nello scrivere il codice

Che l’agent Russ giri non è perché Marcus sappia scrivere Python, è perché conosce bene il business: con quale criterio dare un punteggio ai lead, quali voci mettere nel piano di follow-up, quali contatti vanno in cima. Questi sono giudizi, non tecnica.

L’IA non deduce dalle omissioni. Se non lo dici con chiarezza, te ne tira fuori una versione di default, che il più delle volte non è quella che volevi. Chi sa esplicitare regole, confini e stati produce con una qualità di un ordine di grandezza superiore agli altri. E questa capacità non ha nulla a che vedere col saper programmare o meno. Tra i consigli di a16z ai product manager ce n’è uno: il puro process manager verrà rimpiazzato, solo chi ha una «mentalità da costruttore» avrà leva. Per mentalità da costruttore si intende la disponibilità a mettere mano in prima persona, a realizzare l’idea e portarla a validare — e il saper scrivere codice o meno non c’entra.

Il vantaggio non arriva gratis

Non capire di tecnica non vuol dire non dover capire nulla. Lo Zapier usato da Marcus, il Replit usato da quel designer, dietro hanno entrambi un mestiere da imparare bene: come spezzare i requisiti in piccoli passi che l’IA riesca ad afferrare al volo, come giudicare se quello che ti restituisce è giusto, dove fermarsi e lasciare che sia una persona a riprendere in mano.

La cosa che chi non capisce di tecnica si lascia sfuggire più facilmente è la rete di sicurezza. Nei prototipi non mettere dati reali dei clienti; i pulsanti come pubblica, cancella, paga — quelli che una volta premuti non si tornano indietro — lasciali premere a una persona. Il Russ di Marcus «scrive» il piano di follow-up per gli agenti, ma non gli fa «inviare» nulla a nessuno: quel clic lì lo fa ancora una persona.

Una cosa che puoi fare oggi: scegli una piccola idea per cui hai sempre pensato «qui ci vuole un ingegnere», non chiederti prima se sia difficile, scrivi una per una le cose che vuoi e passale all’IA perché ne faccia una prima versione. Prima guarda fin dove arriva, poi dai un giudizio.

Approfondimenti

• Zapier «Vibe coding examples: Real projects from non-developers» (caso Marcus Rush / Rush Home): https://zapier.com/blog/vibe-coding-examples/
• a16z «5 Principles for PMs in the AI Era» (mentalità da costruttore vs process manager): https://a16z.com/stay-relevant-in-ai/
• Primo articolo della serie «Quali compiti del product manager se li è presi l’IA, e quali invece valgono di più»: /it/blog/ai-pm-what-changed/