Diventare PM nell'era dell'IA 08 | L'IA non può trovare il vero problema al posto tuo

a16z ha scritto un articolo per i product manager, il cui titolo tradotto alla lettera suona «5 principi per i product manager che vogliono evitare l’obsolescenza nell’era dell’IA». Dentro c’è una frase che coglie nel segno: il lavoro del product manager è da sempre risolvere l’ambiguità, e l’IA non l’ha resa minore — ha solo cambiato gli strumenti.

Mettiamo insieme gli articoli precedenti: l’IA può aiutarti a giudicare (in realtà ti dà le opzioni, decidi tu), può aiutarti a realizzare i requisiti, può trasformare una frase in un prodotto. Ma c’è una cosa che da cima a fondo non tocca mai — trovare quel vero problema che vale la pena risolvere. Dove l’utente si blocca davvero, se è un vero problema, se vale la pena affrontarlo: a queste domande non ti dà risposta, perché la risposta non sta nei suoi dati di addestramento, sta nel mondo reale, in una persona concreta.

È anche il motivo per cui a16z dice che «il puro project manager verrà rimpiazzato, mentre chi ha una mentalità da costruttore ha leva»: chi sa sollecitare gli avanzamenti e allineare le persone, l’IA lo può sostituire in parte; chi sa trovare il vero problema e ha il coraggio di mettersi a verificarlo, non lo può sostituire. Questo articolo racconta quattro mosse concrete da seguire nella fase di scoperta.

1. Non lasciare che sia l’IA a pensare i requisiti al posto tuo: vai sul campo a vedere dove la gente si blocca

La pigrizia più facile è aprire l’IA e chiederle «quale funzione dovrei aggiungere al mio prodotto». Ti darà un elenco equilibrato e dall’aria credibile — tutte funzioni comuni viste in altri prodotti, nemmeno una nata dai tuoi utenti reali.

L’IA può solo ricombinare ciò che ha già visto, non riesce a vedere quel punto dolente che nessuno ha ancora messo in parole. Questa parte puoi farla solo tu: trova un utente reale, siediti accanto a lui, guardalo mentre usa la tua cosa (o il metodo maldestro di adesso) per fare quel lavoro, osserva in quale passaggio aggrotta la fronte, si ferma, impreca. Quel punto di blocco, l’IA non potrà mai vederlo al posto tuo.

2. Distingui «ciò che chiede a parole» da «ciò su cui è davvero bloccato»

La trappola più grande della fase di scoperta è prendere il requisito che l’utente dice a parole e considerarlo direttamente la funzione da fare.

C’è un vecchio esempio: l’utente dice di volere un cavallo più veloce, ma il vero problema è che vuole arrivare a destinazione più in fretta. Nelle parole dell’utente si nasconde il vero problema, ma raramente coincidono. Quando dice «si può aggiungere un export in Excel?», dietro potrebbe esserci «ogni settimana devo infilare questi dati in un altro sistema, e copiarli a mano è una sofferenza» — il vero problema è che i due sistemi non comunicano, l’export è solo la soluzione che gli è venuta in mente. Se segui alla lettera «aggiungo l’export», a lavoro finito lui continua a soffrire una volta a settimana.

Ascoltalo, ma tieni gli occhi su cosa fa. Il comportamento è più onesto delle parole.

3. Cerca i «metodi maldestri» — sono il segnale più solido del vero problema

Come si capisce se un problema vale davvero la pena di essere risolto? Guarda se c’è già qualcuno che si arrangia con un metodo maldestro.

Se qualcuno, pur di fare una certa cosa, preferisce esportare a mano una tabella ogni settimana, creare un gruppo WeChat caotico, annotare un mucchio di cose nelle note, oppure fare un lungo giro mettendo insieme tre strumenti — questi «metodi maldestri» sono il segnale più solido: quel dolore è reale, talmente reale che è disposto a spendere fatica extra. Quello che devi fare, spesso, è proprio sostituire quel metodo maldestro. Al contrario, se nessuno è disposto a spendere il minimo sforzo extra per un problema, probabilmente non fa così male come pensi, e per quanto l’IA sia veloce, quello che costruisci non lo userà nessuno.

4. Esplora con una mentalità da costruttore, non aspettare di avere tutti i requisiti

Una volta trovato un sospetto vero problema, non fermarti alla ricerca e ai documenti, e non aspettare di aver pensato a tutti i requisiti prima di metterti all’opera. La mentalità da costruttore di cui parla a16z, calata qui, è molto concreta: usa il言出法随 di cui ho parlato negli articoli precedenti per costruire lo stesso giorno una cosa minima e funzionante, e portala a quell’utente perché ci clicchi.

«Questo risolve la rogna che mi hai appena detto?» — fare questa domanda con qualcosa di cliccabile in mano è molto più preciso che con un questionario. Lui ci clicca due volte e dice «qui non va, in realtà io volevo…», e la tua comprensione del vero problema fa un altro passo avanti. Il vero problema lo si avvicina costruendo strada facendo, non pensandoci tutto in una volta dentro un documento.

Una cosa che puoi fare oggi: scegli una funzione che hai intenzione di fare, prima di tutto non aprire l’IA, vai a cercare un utente reale (anche un collega va bene), e chiedigli come ha fatto l’ultima volta a svolgere quel lavoro, con quale metodo maldestro si arrangia adesso. Quel suo metodo maldestro è proprio la porta d’ingresso al vero problema.

Per approfondire

• a16z, «5 Principles for Product Managers Fending Off Obsolescence in the AI Era» (mentalità da costruttore vs puro project manager): https://a16z.com/stay-relevant-in-ai/
• Quarto articolo della serie «Giudicare “se farlo o no”, la prima volta costa più che “se è fattibile o no”»: /it/blog/judgment-over-feasibility/
• Primo articolo della serie «Quali lavori del product manager se li prende l’IA, e quali invece valgono di più»: /it/blog/ai-pm-what-changed/