Colloquio da product manager nell'era dell'IA: come rispondere alle 5 domande più gettonate

In questi due anni ho fatto parecchi colloqui da product manager, e ne ho anche sostenuti. C’è uno schema così evidente che me lo ricordo ancora: appena arriva una domanda legata all’IA, otto su dieci cominciano immediatamente a recitare i concetti — cos’è il RAG, che differenza c’è tra fine-tuning e prompting, come funziona il meccanismo di attenzione del Transformer… Più la snocciolano fluida, più mi si raffredda dentro qualcosa, e ho praticamente già deciso che non lo prenderò.

Non perché abbia sbagliato la definizione. Ma perché queste domande non misurano mai cosa hai memorizzato, ma se sai ragionare. Se apri bocca e la prima cosa che esce è una definizione, stai dicendo a chi ti intervista: ho studiato questa roba come una nozione, ma non ci ho mai davvero preso una decisione sopra.

È qui che il ruolo di product manager IA si distingue di più da quello tradizionale. Nel software tradizionale, se ci hai ragionato bene, la cosa in sostanza si comporta come previsto; l’IA no — un modello che nei test dà risultati straordinari, in produzione può crollare; funziona benissimo per il 90% delle persone e spara assurdità al restante 10%; e spesso non sai nemmeno spiegare perché ha sbagliato, né puoi metterci una pezza e sistemarlo. Perciò quello che chi ti intervista vuole davvero sapere non è se conosci questi termini, ma come prendi decisioni di prodotto di fronte a una cosa che «sbaglia, è difficile da spiegare ed è difficile da riparare».

Le 5 domande qui sotto sono quelle che ho sentito e fatto più spesso in questi due anni. Non ti do risposte standard — su questi temi dell’IA quasi nessuna domanda ha una risposta standard: chi ti intervista valuta il tuo ragionamento, non la tua conclusione. Ti dico solo quale parte di te ciascuna domanda sta pesando, come risponderei io, e la risposta con cui si finisce più facilmente fuori strada.

1. «Questa funzione IA ogni tanto sbaglia: come decidi se può andare in produzione o no?»

È quasi sempre la prima domanda di un colloquio da product manager IA, ed è anche lo spartiacque.

Misura questo: sai accettare la premessa che “l’IA sbaglierà di sicuro” e ciononostante prendere una decisione responsabile. La logica del software tradizionale è «se c’è un bug lo sistemo finché non ce n’è più», ma una funzione IA non la porti mai a zero errori. Se nella tua risposta traspare «voglio portare l’accuratezza al 100% prima di rilasciare», sei praticamente fuori — vuol dire che non sei ancora entrato nel mondo dell’IA.

Come risponderei io: non punto a farla non sbagliare, punto a “quando sbaglia, il costo lo reggo io”. Prima mi faccio una domanda: se questa funzione sbaglia, nel peggiore dei casi cosa succede?

Un’IA che aiuta l’utente a bozzare un’email: se sbaglia, l’utente corregge e via, il costo è bassissimo, quindi con un’accuratezza dell’80% me la sento di rilasciare, perché il restante 20% se lo gestisce l’utente. Ma un’IA che addebita automaticamente soldi all’utente, o che suggerisce diagnosi al medico: un errore è un incidente, e lì non oso rilasciare nemmeno al 99%, ci vuole revisione umana, ci vuole una rete di sicurezza, ci vuole la via d’uscita del «se non sono sicuro non lo faccio». A parità di accuratezza, il fatto che possa andare in produzione dipende dal costo dell’errore, non da quel numero in sé.

La risposta con cui si sbaglia più facilmente: fissarsi solo su quel numero di accuratezza, senza parlare di cosa succede quando sbaglia. Trattare «l’IA è buona o no» come un problema di voto, e non come un problema di prodotto del tipo «nel caso peggiore reggo o non reggo» — questa è la mentalità del 2023, e chi ti intervista nel 2026 capisce al volo che non hai mai messo in produzione una funzione IA.

2. «Per questa esigenza usi prompting, RAG o fine-tuning? Perché?»

Questa esce con una frequenza assurda, soprattutto per i ruoli legati ai modelli di grandi dimensioni: la scelta a tre tra prompting/RAG/fine-tuning è quasi obbligata.

Molti pensano che misuri le competenze tecniche, ma in realtà misura se sai fare dei compromessi. Chi ti intervista non si aspetta affatto che tu sappia scrivere a mano il codice di fine-tuning; vuole vedere questo: dato un requisito, sai mettere in fila queste strade per costo, velocità di risultato e controllabilità, e poi spiegare perché scegli questa e cosa ti prendi in carico rinunciando all’altra.

Come risponderei io: parto sempre dalla soluzione più leggera e salgo, se posso risolvere con il prompting non tiro mai in ballo il fine-tuning. Perché il prompting è il più veloce da modificare, il meno costoso, oggi non va e domani lo sistemi; il RAG è adatto agli scenari in cui «la risposta deve basarsi su una mia raccolta di documenti e deve poter essere aggiornata in qualsiasi momento»; il fine-tuning è il più pesante, l’addestramento costa soldi e dati, ogni modifica ha cicli lunghi, e lo tocco solo quando «ho già provato i primi due, il risultato proprio non basta, e questa capacità vale l’investimento».

Il punto è l’ultima frase — devi saper dire a cosa rinunci con ogni strada. Se scegli il prompting, rinunci alla stabilità (la stessa domanda oggi funziona e domani no); se scegli il fine-tuning, rinunci alla flessibilità (per cambiare un comportamento devi riaddestrare). Se sai spiegare bene «ho scelto A, il costo è perdere B, ma per questa esigenza il costo vale la pena», hai fatto il pieno su questa domanda, anche se non sai scrivere una riga di codice di modello.

La risposta con cui si sbaglia più facilmente: partire subito con «beh allora per forza fine-tuning, dà i risultati migliori». Chi apre bocca e vuole subito la soluzione più pesante, chi ti intervista dà per scontato che non capisca i costi e non abbia mai sudato sul budget di un progetto reale.

3. «Raccontami una volta in cui hai deciso di “non” usare l’IA.»

Questa è particolarmente subdola, ma seleziona benissimo. In questi due anni tutto il mondo grida IA, e se un product manager non ha mai detto di sua iniziativa “qui l’IA non ci sta bene”, molto probabilmente sta rincorrendo la moda, non facendo prodotto.

Misura questo: consideri l’IA un fine o uno strumento. Chi ti intervista vuole avere la conferma che non infilerai a forza una funzione IA in un posto che non ne ha alcun bisogno solo perché «il capo vuole l’IA» o perché «così la storia per la raccolta fondi suona meglio».

Come risponderei io: racconterei un caso concreto — per esempio una certa funzione, in cui tutti volevano aggiungere un «suggerimento intelligente», e io ho fermato tutto. Perché in quello scenario l’utente aveva solo qualche opzione fissa, una regola cablata era veloce, precisa e non sbagliava mai, e appiccicarci sopra a forza un modello era lento, costoso e ogni tanto suggeriva la cosa sbagliata: IA per l’IA e basta. Alla fine abbiamo risolto con il più stupido degli if-else, e la considero una delle decisioni più giuste che ho preso quell’anno.

Avere una storia concreta del tipo «ho rifiutato l’IA» vale più che raccontare il RAG con mille meraviglie. Perché dimostra la cosa che chi ti intervista desidera di più ed è più difficile da testare: hai capacità di giudizio, l’IA non ti comanda, sei tu a usarla.

La risposta con cui si sbaglia più facilmente: rispondere «non mi viene in mente un caso del genere, secondo me l’IA in fondo migliora sempre l’esperienza». Con questa frase ti collochi da solo nella categoria dei «credenti dell’IA» — e nessun team maturo vuole un product manager che non sa distinguere quando l’IA non va usata.

4. «Costo e latenza: come li bilanci?»

Fino a qualche anno fa questo era considerato un problema di ingegneria — quanti token spendi, se la risposta è lenta, roba di cui doveva preoccuparsi il backend. Ma nel 2026 lo standard è cambiato: costo e latenza stanno proprio sul cruscotto del product manager IA, insieme a qualità ed esperienza, e vanno esplicitamente messi sul tavolo e bilanciati quando si fa la roadmap.

Misura questo: sai o no che una funzione IA brucia soldi veri a ogni chiamata, e che un secondo di lentezza in più può farti perdere un pezzo di utenti. Il software tradizionale, una volta scritto, non costa quasi nulla in più per ogni utente aggiuntivo; l’IA no, ogni chiamata costa soldi, più la usi più bruci. Un product manager che non guarda questo conto costruirà una funzione dall’ottima esperienza che l’azienda non può permettersi.

Come risponderei io: lo tratterei come un compromesso a tre esplicito — qualità, costo, velocità, di solito non li puoi avere tutti e tre. Mi chiederei su cosa vince davvero questa funzione: se vince sul «rispondere con precisione», allora le permetto di essere un po’ più lenta e più costosa, con un modello più forte; se vince sul «poterla usare al volo», allora forse scelgo un modello piccolo, economico e veloce, sacrificando un po’ di qualità in cambio di velocità di risposta e costo. Il punto è che devo sapere cosa sto scambiando con cosa, e non prendere di default sempre il modello più forte e più caro.

La risposta con cui si sbaglia più facilmente: «questo lo lascio ottimizzare al reparto tecnico». Scaricare costo e latenza sull’ingegneria — è proprio la risposta sbagliata che chi ti intervista sta aspettando, e appena la dici ti si appiccica l’etichetta «questo non capisce i conti del prodotto IA».

5. «Perché vuoi fare il product manager IA?»

Sembra la classica domanda di apertura di cortesia, e invece è un test di onestà.

Misura questo: ci hai davvero messo le mani sopra, o ti ha attratto la moda e lo stipendio e sei pronto a recitare una serie di frasi fatte. Perché ogni domanda tecnica di approfondimento che segue verificherà se questo tuo «perché» è vero.

Come risponderei io: non dirò «perché l’IA è il futuro, è la tendenza inarrestabile» e cazzate corrette del genere — chi ti intervista si sente queste frasi venti volte al giorno, è come non dire niente. Racconterei una piccola cosa concreta: la prima volta che con l’IA ho fatto davvero, in un pomeriggio, una cosa che covavo da tanto e che da solo non sapevo scrivere in codice, e ci potevo cliccare sopra, quella scossa del «basta che lo dico e diventa realtà». Una prima volta vera, concreta e un po’ goffa è sempre più convincente di una grande e giusta affermazione.

La risposta con cui si sbaglia più facilmente: recitare le tendenze del settore, recitare i paroloni. Più fai discorsi grandi e corretti, più chi ti intervista si convince che non l’hai mai fatto davvero — perché chi l’ha fatto davvero, apre bocca e parla di cose concrete, non di belle affermazioni.

Non dimenticare: il vero esame è nelle domande di approfondimento

Ognuna delle domande qui sopra, quando hai finito il primo giro, non è finita. Il punto in cui un colloquio da product manager IA misura davvero il tuo valore è quella frasetta leggera che chi ti intervista lancia subito dopo: «e poi?»

Tu dici «questa funzione con l’80% di accuratezza me la sento di rilasciare», e lui incalza: «e come gestisci concretamente quel 20%?» «E se dopo il rilascio scopri che in realtà è solo il 70%, cosa fai?» Tu dici «ho scelto il prompting e non il fine-tuning», e lui incalza: «e se comunque ottimizzi il prompt e il risultato resta bloccato al 60%, a che punto cambierai idea e passerai al fine-tuning? Dove tracci questa linea?»

Non ti sta mettendo in difficoltà, sta verificando: quella tua bella conclusione l’hai ragionata o l’hai memorizzata. Quella memorizzata, dopo due domande di approfondimento crolla — perché una risposta imparata a memoria non ha un livello successivo, hai solo una conclusione isolata e non sai rispondere a «se le condizioni cambiano come mi adatto». Quella ragionata, per quanto ti incalzino hai sempre di che parlare, perché hai davvero percorso quella strada fino in fondo nella tua testa.

Perciò quando ti prepari, non preparare solo la risposta, chiediti una volta di più “e poi?”: se questa decisione fosse sbagliata come rimedio, se le condizioni cambiano quando cambio idea, in base a cosa traccio questa linea. Se ti fai prima tu tutto il giro delle domande di approfondimento, al colloquio quel «e poi?» non è più uno scoglio, ma la tua occasione per mostrare quello che sai fare davvero.

In fondo, misurano tutte la stessa cosa

Se colleghi queste 5 domande, ti accorgi che ciò che chi ti intervista pesa ripetutamente è in realtà la stessa cosa: hai in mano una storia concreta o no — una decisione vera, un compromesso vero, meglio ancora se con un numero.

Con quanta accuratezza te la sei sentita di rilasciare e perché, perché hai scelto il prompting e non il fine-tuning, quella volta in cui hai fermato una funzione IA, se hai scambiato qualità con costo o costo con velocità, cosa ti ha scosso la prima volta con l’IA — su queste cinque domande, chi risponde bene sta tutto raccontando cose che ha davvero fatto, chi risponde male sta tutto recitando definizioni e tendenze. Le storie vuote fanno perdere l’offerta, le storie concrete la fanno ottenere, e questa frase, sul ruolo di product manager IA, è più spietata che su qualsiasi altro.

Perciò se ti stai preparando a colloqui di questo tipo, il mio consiglio non è di mandare a memoria un archivio di domande. È tornare indietro e tirar fuori una a una le cose legate all’IA che hai davvero fatto, e per ognuna capire bene: qual era la decisione di allora, a cosa hai rinunciato, com’è andata, c’era un numero. Metti insieme cinque o sei storie così, e non importa in che modo ti girino queste domande: avrai sempre qualcosa di vero da raccontare.

C’è una cosa su cui rimugino ancora adesso, e te la lancio così: quando l’IA abbassa la soglia per «fare qualcosa» a un livello così basso, quelle domande da colloquio del tipo «cosa hai fatto» diventeranno sempre più facili da rispondere — perché tutti riescono a fare qualcosa. E allora, la domanda che davvero separa le persone, cosa diventerà? Scommetto che andrà nella direzione di «cosa non hai fatto, e perché non l’hai fatto». Ma è solo la mia ipotesi, non ho ancora visto la risposta.