Una giornata da product manager nell'era dell'IA: come ho trasformato una frase in un prototipo cliccabile

Comincio da una cosa concreta. Mercoledì scorso, nel pomeriggio, mi è saltata in testa un’idea vaga: «vorrei un affarino per tenere i conti al volo.» Poco più di due ore dopo, un mio collega ci cliccava davvero, sul mio telefono: tocca «aggiungi spesa», inserisce l’importo, sceglie la categoria, torna alla home e vede quanto ha speso questo mese, con un grafico a torta diviso in fette. Senza scrivere una riga di codice.

Racconto questa cosa non per dire quanto sia magica l’IA. Voglio dire una cosa controintuitiva: in tanti pensano che, arrivata l’IA, il product manager debba correre a studiare programmazione per non essere spazzato via. Ma la mia sensazione in questi ultimi mesi è esattamente l’opposta: la barriera dello «scrivere codice» sta crollando a velocità pazzesca, e quello che diventa davvero prezioso, e davvero raro, è un’altra cosa: saper spiegare una faccenda così chiaramente che l’IA la fa giusta al primo colpo.

Qui non faccio il discorso su questo principio in sé, racconto come ho fatto concretamente. Uso proprio quell’affarino per i conti come esempio e te lo smonto passo per passo, buche comprese. Se anche tu hai in testa un’idea che covi da tempo senza mai muoverti, dopo aver letto probabilmente riuscirai a provarci da solo.

Primo passo: non farlo fare subito, prima fatti interrogare

Quando ho iniziato a costruire cose con l’IA, l’errore che facevo più spesso era buttarle addosso di getto quella frase confusa che avevo in testa — «fammi un’app per i conti» — e poi aspettarmi un prodotto finito.

Il risultato era sempre lo stesso: mi dava quello che lei credeva volessi, lontano mille miglia da quello che avevo in testa io. Io la correggevo un pezzetto alla volta, lei sbandava un pezzetto alla volta, e restavamo lì a indovinarci a vicenda, finché non mi girava.

Poi ho cambiato un’abitudine — una sola frase, ma di un’efficacia assurda: non le faccio più fare la cosa direttamente, prima la faccio interrogarmi. Dico: «Voglio fare un piccolo strumento per tenere i conti, ma per ora non scrivere niente. Prima fammi 5 domande, tira fuori le cose che ti servono per capire ma che io non ti ho ancora detto.»

E allora mi chiede: per chi è, solo per te o serve a più persone? Vuoi le categorie, le decidi tu o te ne preimposto qualcuna? Gli importi vanno divisi tra entrate e uscite? I dati basta salvarli in locale sul telefono, o devi poterli vedere cambiando dispositivo? Vuoi un avviso sul budget?

Vedi, queste domande sono tutte i punti che nella mia testa erano una poltiglia, cose che non avevo pensato fino in fondo. È lei che, al posto mio, ha tirato fuori con la forza «cosa voglio davvero». Una volta risposto a quelle 5 domande, la forma di questa cosa era diventata chiara prima di tutto dentro di me. E a quel punto, quando la lascio lavorare, la probabilità che venga giusta al primo colpo è molto più alta.

Una buca in cui sono caduto: i due minuti che risparmi saltando questo passo, dopo li ripaghi con due ore. Una volta mi ero stufato di tutte quelle domande e le ho detto di fare e basta: ne è uscita una cosa con tutte le funzioni ma per niente quella che volevo, e a rifare tutto alla fine avrei fatto prima a ricominciare da zero. Adesso questo passo non lo salto mai.

Secondo passo: cambia una cosa sola alla volta

Esce la prima versione, si può cliccare, ma di sicuro c’è qualcosa che non va. Ed è qui che ti aspetta la seconda buca: sparare in una volta sola tutte e dieci le cose che non ti piacciono.

«Il colore della home è troppo chiaro, le icone delle categorie sono brutte, voglio cambiare i colori del grafico a torta, il pulsante «aggiungi spesa» è troppo piccolo, ah e l’importo può mettere in automatico i decimali, e già che ci siamo aggiungi una ricerca…»

Prima facevo così, per fare in fretta. Il risultato: fa le modifiche, il colore va a posto, ma si dimentica del pulsante; oppure sistema il pulsante e crolla di nuovo il grafico a torta. Quando le modifiche sono tante, perde il filo, e nemmeno tu capisci più quale frase ha fatto effetto e quale si è persa per strada senza dirtelo.

Adesso invece dico una sola modifica per volta, la dico e poi clicco subito sul telefono, confermo che quel punto è giusto, e solo dopo passo al prossimo. Lento? A vederlo sembra lento. Ma ogni passo è saldo, non si torna indietro. Ho fatto i conti: procedendo così, alla fine è molto più veloce che «dire tutto in una volta e poi rifare tutto insieme», e per tutto il tragitto so esattamente a che punto sono.

Non è un trucco per l’IA, è la regola più elementare di chi fa prodotto: passi piccoli, ogni passo verificabile. Solo che l’IA ha schiacciato il costo di ogni passo quasi a zero, quindi hai ancora meno scuse per strafare.

Una parentesi: come dire ogni modifica perché l’IA la capisca

Sopra ho detto «cambia una cosa sola alla volta», ma «una sola» non basta: la chiave è come la dici, quella una. È il punto che considero più pratico di tutto l’articolo, e anche quello che dà i risultati più immediati.

La buca più grossa in cui sono caduto è dare istruzioni all’IA con gli aggettivi. «Fai la home più bella», «fai il pulsante più imponente», «fai i colori più eleganti» — nel momento in cui pronuncio queste frasi, ho appena restituito tutto il potere di giudizio a lei, perché «bello» ed «elegante», per lei, hanno diecimila soluzioni possibili, ne pesca una a caso, e quasi sempre non è quella che vuoi tu.

Poi mi sono costretto a cambiare in due modi: dai un riferimento, dai lo stato, non dare aggettivi.

Dare un riferimento vuol dire: non dire «più bello», di’ «per le card della home, l’aria intorno prendila come su « WeChat Read », tre o quattro voci per schermata, non ammassate». Lei capisce all’istante cosa vuoi, perché le hai dato una cosa concreta con cui allinearsi, e non un giudizio vago che può interpretare a piacere.

Dare lo stato vuol dire: non dire «gestisci il caso in cui non ci sono spese», di’ «quando non c’è nemmeno una spesa, al centro della home mostra una riga di testo grigio ‘Ancora nessuna spesa registrata, tocca aggiungi in basso a destra’, e non far vedere un grafico a torta vuoto». Dì com’è che deve apparire concretamente lo schermo in ognuno degli stati — com’è con i dati, com’è senza dati, com’è mentre carica, com’è quando dà errore. Più sei concreto, meno spazio le lasci per «improvvisare» qualcosa che non volevi.

Il controllo che faccio ora è: finita di dire un’istruzione, la rileggo e cerco se dentro c’è un aggettivo. Se c’è un «bello, imponente, elegante, ottimizza un po’», mi fermo e lo traduco in «prendi a riferimento chi, e concretamente com’è fatto». Questo piccolo gesto vale più di qualsiasi trucco per l’IA io abbia imparato.

Terzo passo: già la prima versione su dati veri, niente «testo di esempio»

Questo è il punto che secondo me viene ignorato più facilmente ma che incide di più sul risultato.

In tanti, quando fanno un prototipo, hanno l’abitudine di far tirare su all’IA prima uno «scheletro» — dentro ci sono robe finte tipo «Titolo 1», «segnaposto contenuto», «¥000.00» — pensando «intanto la struttura è giusta, il contenuto lo riempio dopo».

Io non lo faccio più. Già la prima versione la faccio girare su dati veri. Nell’esempio dei conti, le ho fatto preimpostare direttamente le spese vere che ho fatto io ieri: colazione 12, taxi 28, spesa al mercato 63, e una che fa un po’ male, i 2000 del corso che ho pagato per mio figlio.

Perché? Perché i dati finti ti ingannano. Quando è tutto «¥000.00», l’interfaccia sembra pulita e ordinata, e pensi «dai, va bene». Ma appena ci metti dentro un numero vero come «2000», con cifre di lunghezza diversa, i problemi saltano fuori tutti in un colpo: se l’importo è lungo, a destra va a sbattere contro il bordo dello schermo; il grafico a torta, schiacciato da quella spesa da 2000, riduce le altre voci a fette così piccole da essere quasi invisibili; se il nome di una categoria è appena un po’ lungo, deforma tutto il layout.

Queste buche, con i dati finti non ne vedi neanche una, e a prodotto lanciato ti esplodono tutte in faccia agli utenti reali. Con i dati veri, escono già nella prima versione tra le tue mani, e prima escono più costa poco sistemarle — a questo punto è questione di cambiare una riga, mentre cambiarla dopo che gli utenti ti hanno insultato è tutta un’altra storia. La mia abitudine adesso è: se posso usare un numero vero non uso mai un segnaposto, più realistico ed estremo è meglio è — il nome più lungo, l’importo più grande, lo stato più vuoto (com’è l’interfaccia quando non c’è nemmeno una spesa?) — voglio vederli tutti già nella prima versione.

Quarto passo: devi assolutamente cliccarci sopra tu stesso, sul dispositivo vero

Finito il prototipo, di solito l’IA ti dice tutta sicura «fatto, le funzioni sono tutte implementate».

A questa frase non credere nemmeno a una parola. Non è che menta, è che non ha le mani: non può davvero cliccare.

Ci sono rimasto fregato. Una volta mi ha giurato che registrazione, cancellazione e statistiche erano tutte pronte, ho guardato la logica del codice e non ci trovavo difetti, e le ho creduto. Poi il collega lo prende in mano, aggiunge una spesa, ok; poi tocca quella spesa per cancellarla — niente. Il pulsante di cancellazione l’aveva disegnato, ma l’azione «quando ci clicchi la cancella davvero» se l’era persa, e lei non ne sapeva assolutamente niente, e mi diceva pure «fatto».

Da allora mi sono fatto una regola di ferro: qualsiasi «è fatto» conta solo dopo che io stesso, sul dispositivo vero, ho percorso a mano il percorso chiave. Aggiungo una spesa, la vedo comparire nella lista, la cancello, guardo le statistiche cambiare di conseguenza — finché non percorro a mano tutta questa catena, per me non è finito. Questo passo non ruba nemmeno tre minuti, ma è l’unico muro tra te e il «se ne accorgono gli utenti a prodotto lanciato».

Su come percorrerlo ho anche un metodo un po’ rozzo: prima di mettere mano, mi prendo un foglio e scrivo i due o tre percorsi più importanti di questa cosa. Per i conti, ho scritto: «① poter aggiungere una spesa e vederla ② poter cancellare una spesa ③ i numeri della home e il grafico a torta cambiano di conseguenza». Solo questi tre. Finito il lavoro, non guardo cosa dice l’IA: prendo in mano questo foglio e li clicco a uno a uno sul telefono. Un percorso che va, lo depenno; quello che non riesco a depennare è quello non finito.

Non sottovalutare quel foglio. Ti costringe, prima di mettere mano, a chiarirti «su quali poche cose questa roba sta davvero in piedi» — tante persone si perdono a metà strada proprio perché non hanno mai fissato su carta questi due o tre percorsi principali, e strada facendo si fanno portare via dai mille dettagli, finché si ritrovano un mucchio di funzioni ma il percorso più centrale che non va. Prima chiarisciti quali percorsi devono assolutamente funzionare, poi fai fare all’IA, e alla fine verifica a mano proprio quei percorsi — questi due fogli, uno in testa e uno in coda, contano più di tutto il codice che ha scritto lei in mezzo.

Quinto passo: la linea di collaudo è «si riesce a cliccare fino in fondo?», non «sembra giusto?»

Se metti in fila i passi qui sopra, in fondo è sempre lo stesso giudizio che ritorna: su cosa mi baso, in fin dei conti, per decidere se questa cosa va o non va?

La risposta che mi sono dato è: se si riesce davvero a percorrere fino in fondo, cliccando, un percorso completo — non se «sembra» giusto.

«Sembra giusto» è la cosa più ingannevole che ci sia. Fai uno screenshot, lo mandi nel gruppo, tutti dicono che è bello, e magari nemmeno una persona ci ha davvero registrato una spesa. «Si riesce a cliccare fino in fondo», invece, è duro: una persona vera, dall’aprire l’app al registrare una spesa fino a vedere il risultato, senza inceppi lungo il tragitto e senza nemmeno un pulsante morto — se questo percorso fila, allora questa cosa sta davvero in piedi.

Ed è anche il punto che secondo me il product manager dell’era dell’IA deve difendere di più. Quando il costo di costruire viene schiacciato quasi a zero, «tirar fuori una cosa che sembra a posto» non vale più niente, ce n’è pieno lo schermo. Quello che vale è se sei ancora capace di giudicare: questa cosa che sembra a posto è davvero usabile, oppure sembra e basta. Questo giudizio l’IA non può farlo al posto tuo, perché è proprio lei quella che ti dice tutta sicura «è fatto» dimenticandosi il pulsante di cancellazione.

Quindi, alla fine bisogna imparare a scrivere codice?

Torniamo alla domanda dell’inizio.

La mia risposta è: non ti serve imparare a scrivere codice, ma devi imparare a dire le cose così bene che l’IA le fa giuste al primo colpo — sono due cose diverse. La prima è imparare un mestiere che si sta svalutando; la seconda è allenare una capacità di giudizio sempre più rara: spingere un’idea confusa fino a renderla chiara, avanzare un solo passo alla volta, verificare con cose reali, cliccare fino in fondo con le proprie mani prima di crederci.

Questi punti, a dirla tutta, non è che siano «tecnici». Assomigliano di più alle abitudini che dovrebbe avere di suo una persona che ha capito bene cosa vuole ed è disposta a verificarlo passo dopo passo. L’IA non fa che amplificare di molte volte la ricompensa di queste abitudini: più pensi chiaro, più preciso è quello che ti dà; più tiri via, più tira via anche lei con te.

Ancora oggi ci sono cose che non mi sono chiarite, e te le lancio così: quando «trasformare un’idea in una cosa cliccabile» diventa così veloce che in un pomeriggio ci fai su più giri, allora la linea tra il product manager e «una persona qualsiasi che ha capito bene cosa vuole» dove la tracciamo, di preciso? Anch’io sto ancora cercando la risposta. Ma almeno so che quella linea non sta nel «saper scrivere codice o no» — quell’affarino per i conti della settimana scorsa, dall’inizio alla fine, non ho toccato una riga di codice.