Journal

Nell'ultimo anno ho iniziato a costruire prodotti da sola, con l'AI, dall'idea alla produzione. Prima Bloom, un'app di allenamento che uso ogni giorno. Poi km7, un compagno vocale per chi corre. Prodotti veri, utenti veri, nessun team.

La cosa che nessuno ti dice del costruire con l'AI è che l'esecuzione non è mai stata la parte difficile. Sembrava la parte difficile, perché era la parte lenta. Mesi di sviluppo rendevano ogni decisione costosa, così siamo diventati bravi a pianificare, stimare, negoziare lo scope. L'AI rimuove gran parte di quell'attrito — e quello che resta, improvvisamente visibile, è la vera parte difficile: sapere cosa costruire.

Quando il codice diventa economico, le cose costose sono quelle che sono sempre state costose. Capire un problema abbastanza bene da descriverlo con precisione. Decidere cosa lasciare fuori. Accorgersi di quando stai costruendo per un utente immaginato invece che per uno reale. Quest'anno ho buttato via più funzionalità funzionanti che in tutta la mia carriera — non perché fossero rotte, ma perché costruirle era così veloce che potevo permettermi di scoprire che erano sbagliate.

Questa inversione cambia cos'è il product management. Il ruolo non è mai stato davvero coordinare l'output, ma le organizzazioni lo trattavano così perché l'output era il collo di bottiglia. Ora una singola persona può rilasciare quello che prima richiedeva un team per un trimestre. Il collo di bottiglia si è spostato sul giudizio: quale problema, quale scommessa, quale evidenza ti farebbe cambiare idea.

Cambia anche la discovery. L'AI comprime il tempo di costruzione, ma non comprime il tempo di apprendimento. Gli utenti hanno ancora bisogno di settimane per mostrarti come si comportano davvero. Semmai, l'esecuzione economica rende la discovery più importante, perché il costo di costruire con sicurezza la cosa sbagliata non è mai stato così basso — ora puoi costruire tre cose sbagliate nel tempo che prima serviva per costruirne una.

Continuo a incontrare product manager preoccupati che l'AI renda il loro ruolo obsoleto. Costruirci ogni giorno mi ha convinta del contrario: le parti del lavoro che l'AI assorbe sono le parti che non sono mai state il punto. Quello che resta — la selezione dei problemi, il gusto, la capacità di dire di no con le evidenze — è diventato silenziosamente tutto il lavoro.

I team che faranno fatica non sono quelli senza competenze AI. Sono quelli che non hanno mai imparato a decidere cosa vale la pena costruire, perché la lentezza dell'esecuzione ha sempre nascosto quella lacuna.

La product discovery è il lavoro che un team fa per capire quale problema vale la pena risolvere — e per chi — prima di impegnarsi a costruire una soluzione. Questa è tutta la definizione. Il resto è tecnica.

La maggior parte dei team che incontro non manca di metodi di discovery. Hanno guide per le interviste, opportunity tree, template per gli esperimenti. Quello che manca è la disponibilità a lasciare che la discovery gli faccia cambiare idea. La roadmap è già promessa, la feature ha già un nome, e la discovery diventa teatro: interviste condotte per confermare una decisione già presa.

Puoi distinguere la discovery vera dal teatro con una sola domanda: quale evidenza ti farebbe decidere di non costruire questa cosa? Se nessuno sa rispondere, non è discovery. È documentazione per una decisione che la precede.

Una buona discovery parte dalla decisione, non dal metodo. Cosa stiamo davvero cercando di decidere — se il problema esiste, se la nostra soluzione lo risolve, se le persone cambieranno comportamento per usarla? Ognuna di queste domande richiede evidenze diverse, e la maggior parte richiede molta meno macchina di quanto i team assumano. Non ogni domanda merita un A/B test. Ad alcune bastano cinque conversazioni oneste e la disciplina di ascoltare le risposte.

L'obiezione classica è che la discovery rallenta la delivery. La mia esperienza è l'opposto: i team saltano la discovery per andare veloci, e poi passano trimestri a rilasciare variazioni di qualcosa che nessuno ha chiesto. Rallentare all'inizio rende tutto quello che viene dopo più veloce, perché la direzione regge sotto pressione invece di spostarsi a ogni riunione con gli stakeholder.

L'AI ha reso tutto questo più vero, non meno. Ora puoi prototipare in ore quello che prima richiedeva settimane, il che significa mettere qualcosa di concreto davanti agli utenti quasi subito. È un regalo per la discovery — e una trappola. Costruire più velocemente significa anche poter validare più velocemente nella direzione sbagliata, scambiando la velocità di iterazione per la qualità dell'apprendimento.

I team che fanno bene la discovery non la trattano come una fase che finisce quando inizia lo sviluppo. La trattano come un ritmo — un'abitudine continua di verificare che il problema sia ancora reale, che la scommessa abbia ancora senso, e che le evidenze puntino ancora nella direzione in cui stanno andando.

La parte più interessante dell'insegnare ai futuri PM non è stata la teoria. È stato guardare come si scontravano con gli stessi muri che colpiscono i team esperti: assunzioni presentate come fatti, consenso raggiunto troppo presto, attività scambiata per evidenza.

A maggio 2026, sono entrata in un nuovo tipo di stanza. Hyper Island mi ha invitato a essere Industry Leader per il loro corso di Product Management — Collaborative Project & Stakeholder Management. Cinque settimane, un brief reale, una settimana finale in cui ogni team ha condotto un workshop con stakeholder reali di una vera azienda.

Sono entrata pensando di essere quella con le risposte. È successo il contrario. Una stanza piena di buone domande ti fa mettere le parole a cose che hai fatto d'istinto per anni. Ho imparato tanto su ciò che credo quanto ho insegnato.

I team che hanno fatto il lavoro più interessante sono stati quelli che si sono fermati di fronte al cliente. Hanno posto la domanda scomoda: questo è davvero il problema? Non hanno dato il brief per scontato. Hanno portato alla luce le assunzioni e aperto lo spazio delle opportunità prima di cercare soluzioni. Ciò che ha funzionato non era il metodo — era che avevano imparato a pensare insieme prima, a non essere d'accordo senza correre verso il consenso.

Questa è la parte del product management che nessun framework riesce davvero a catturare. Viviamo in un'epoca in cui l'AI rende lo shipping più rapido ogni mese. Il che rende alcune cose più importanti, non meno: quell'istinto di mettere in discussione il problema prima di costruire la soluzione, e la capacità di pensare insieme ad altre persone. Nessuna delle due può essere generata.

Tornerò a Hyper Island dopo l'estate come Industry Leader per un altro corso. A quanto pare insegnare è esattamente il tipo di cosa che sembra leggermente troppo grande — finché non lo fai.

L'AI non sta fallendo. Quello che vedo invece sono team che diventano molto bravi a muoversi velocemente in direzioni che non sono mai state chiaramente definite dall'inizio.

Tutti dicono di fare AI, ma guardando più da vicino, la maggior parte degli sforzi è concentrata sull'attività piuttosto che sui risultati. Si introducono strumenti, si lanciano pilot, i dashboard iniziano a riempirsi, e per un po' sembra che stia succedendo qualcosa di reale.

Poi passano qualche mese, e sorge la domanda scomoda: cosa è effettivamente cambiato per il business? In molti casi, la risposta è ancora poco chiara. Non perché la tecnologia non sia capace, ma perché il successo non è mai stato definito in un modo che potesse guidare le decisioni.

Di conseguenza, l'AI finisce per essere usata dove il progresso è più facile da dimostrare. I team scrivono più velocemente, rilasciano più velocemente e producono di più, il che crea un senso di momentum senza necessariamente migliorare nulla che conti.

Ciò che è molto più difficile, e significativamente più prezioso, è usare l'AI per capire i clienti più in profondità, connettere insight frammentati e migliorare la qualità delle decisioni prima che i team si impegnino a costruire. La velocità da sola non crea risultati migliori. Accorcia solo il percorso, sia che sia giusto o sbagliato.

I team che ho visto ottenere un impatto reale non sono quelli con gli strumenti più avanzati. Sono quelli che hanno preso il tempo di definire il risultato, chiarire chi possiede la decisione e connettere gli insight all'azione prima di scalare qualsiasi cosa. Senza questo, l'AI non diventa un moltiplicatore. Diventa rumore.

C'è qualcosa che succede quando le persone sono nella stessa stanza che non succede da nessun'altra parte.

Ho trascorso l'ultimo anno ad aiutare a costruire la community Data & AI Stockholm insieme a persone che tengono a creare spazio per conversazioni reali sull'AI nelle organizzazioni. Non l'hype. Il lavoro concreto: cosa serve per implementare bene, cosa fallisce e perché, quali problemi sono più difficili di quanto sembrassero nel pilot.

Quello che mi colpisce a ogni evento è quanto le persone abbiano bisogno di pensare ad alta voce insieme. Abbiamo più informazioni disponibili che in qualsiasi altro momento della storia. Ogni domanda ha una risposta da qualche parte. Ma l'informazione non ti dice a cosa prestare attenzione, e non ti aiuta a capire cosa credi davvero.

Le stanze fanno questo. La domanda che qualcuno fa dal pubblico. La conversazione che inizia durante la pausa e non finisce. Il momento in cui due persone che lavorano in contesti completamente diversi si rendono conto di lavorare sullo stesso problema.

Penso che le stanze stiano diventando più preziose, non meno, proprio perché tanto altro si è spostato online ed è diventato più veloce e più abbondante. La scarsità ora è la presenza. Il tempo che non è ottimizzato. La conversazione che non ha un output definito.

Questo è ciò che cerco sempre di creare. Spazio che rallenta le persone abbastanza da pensare insieme.

Quando l'AI accelera la costruzione, la domanda che prima viveva alla fine di uno sprint si sposta all'inizio: dovremmo costruire questo in primo luogo?

Ci penso da quando ho avuto una conversazione con il team di SeventyOne. Stavamo lavorando su cosa sta realmente cambiando per le organizzazioni mentre l'AI accelera la capacità di delivery. La risposta mi ha sorpreso per la sua semplicità: il vincolo si sta spostando.

Per anni, il collo di bottiglia nel prodotto era l'esecuzione. Avevi un'idea, sapevi più o meno cosa costruire, e la sfida era farlo bene e rilasciarlo abbastanza velocemente. I team ottimizzavano per il throughput. Le roadmap erano piene. La velocity era la cosa che tutti misuravano.

Quando costruire diventa davvero veloce, questo cambia. Puoi ancora riempire la roadmap. Puoi ancora rilasciare. Ma il divario tra rilasciare qualcosa e rilasciare la cosa giusta si allarga, e diventa più difficile da nascondere.

I team che vedo in difficoltà non faticano perché non riescono a usare gli strumenti. Faticano perché gli strumenti hanno esposto un gap che c'era sempre stato: nessun modo affidabile per trovare il problema giusto prima di costruire la soluzione.

Questa è una buona notizia per il product management. Significa che il lavoro che ha sempre contato — definizione del problema, discovery, decidere cosa non costruire — diventa sempre più difficile da saltare. La velocità lo rende visibile.

La domanda è se le organizzazioni rallenteranno abbastanza nella fase iniziale per trarne vantaggio.

C'è un tipo particolare di disagio che arriva quando si lascia un ruolo definito per qualcosa di aperto. Non il disagio del fallimento. Il disagio di non sapere ancora esattamente come appare il successo.

Ho iniziato a fare consulenza a febbraio. Non è stata una decisione drammatica. È stata più una decisione silenziosa: ci pensavo da un po', il momento sembrava giusto, e qualcosa in me sapeva che era il momento di smettere di aspettare che le condizioni fossero perfette prima di decidere.

Quello che non mi aspettavo era quanto la transizione mi avrebbe insegnato sulle mie stesse assunzioni. In un ruolo permanente, c'è sempre una struttura attorno a te: un team, una roadmap, un insieme di problemi che ti appartengono. Quella struttura è utile. È anche, mi sono resa conto, qualcosa dietro cui puoi nasconderti.

Non sapere cosa viene dopo richiede un diverso tipo di onestà.

Le prime settimane mi sembravano come reimparare a leggere una stanza. Ogni incarico è un nuovo contesto, un nuovo gruppo di persone, un nuovo problema da capire prima di provare ad aiutare. Non puoi presentarti con le risposte. Devi presentarti con domande, e sentirti a tuo agio nel restare nell'incertezza più a lungo di quanto sembri naturale.

Penso che fosse quello che cercavo, senza saperlo del tutto. Non l'incertezza in sé, ma ciò che richiede di te.

La fiducia è spesso discussa come un valore. In pratica, è un sistema operativo.

Quando la fiducia è presente, le persone parlano prima. Condividono i dubbi prima che si induriscano in problemi. Si assumono responsabilità perché si sentono al sicuro nel farlo. Il lavoro procede con meno frizione, meno loop difensivi e più onestà.

Quando la fiducia manca, tutto rallenta. Le riunioni diventano più pesanti. Le decisioni vengono rimandate. Le persone spendono energia a proteggersi invece di risolvere problemi.

Ho imparato che la fiducia non si costruisce con grandi gesti. Si costruisce in piccoli momenti costanti: come viene dato il feedback, come viene gestita l'incertezza, come vengono accolti gli errori. Si manifesta nel fatto che le persone si sentano ascoltate quando le cose sono poco chiare.

Nel mio lavoro, cerco di trattare la fiducia come infrastruttura. Qualcosa che si progetta, si mantiene e si protegge. Non perché fa sentire bene, ma perché senza di essa, anche la migliore strategia fatica a radicarsi.

La velocità è facile da celebrare. La velocity fa bella figura sulle slide. Ma la velocità senza direzione diventa rapidamente rumore.

Quello che ho imparato nel tempo è che i team efficaci non si muovono sempre velocemente. Si muovono insieme. Sanno quando spingere e quando fermarsi. Creano spazio per pensare, mettere in discussione, aggiustare. Quel ritmo è ciò che permette al momentum di durare.

Nel lavoro di prodotto, spesso confondiamo il movimento con il progresso. Riempiamo roadmap, rilasciamo funzionalità e chiudiamo ticket, eppure ci sentiamo ancora bloccati. Di solito è un segnale che il ritmo è sbagliato. Il lavoro si muove, ma l'allineamento manca.

I team sani prestano attenzione a questo. Rivisitano le assunzioni. Nominano l'incertezza. Permettono all'apprendimento di modellare la direzione invece di forzare i risultati a corrispondere a un piano creato troppo presto.

Per me, una buona product leadership non riguarda l'accelerazione costante. Riguarda la creazione delle condizioni in cui le persone possono fare il loro miglior pensiero, insieme, nel tempo.

È allora che il progresso diventa sostenibile.

Ci sono momenti in cui il lavoro diventa più silenzioso, non perché c'è meno da fare, ma perché qualcosa dentro di te rallenta abbastanza da notare ciò che conta davvero.

Per me, questo accade spesso in spazi che non hanno nulla a che fare con il lavoro in superficie. Cantare in un coro. Camminare senza cuffie. Sedersi in una stanza dove nessuno sta cercando di impressionare nessun altro. In quei momenti emergono pattern. Inizi a notare come le persone rispondono, dove l'energia scorre facilmente e dove si blocca.

Quell'attenzione non è separata da come lavoro. Ne è il fondamento.

Nel prodotto, parliamo molto di chiarezza, allineamento e focus. Ma quelle cose raramente appaiono perché qualcuno le ha forzate a esistere. Emergono quando creiamo spazio per ascoltare. Ciò che gli utenti stanno effettivamente facendo. Ciò che i team non dicono ad alta voce. Dove la frizione continua a ripetersi.

Ho imparato che le buone decisioni non vengono dalla certezza. Vengono dalla presenza. Dal restare con un problema abbastanza a lungo da capire la sua forma prima di provare a risolverlo.

Questo è il ritmo in cui cerco di lavorare. Non affrettato. Non statico. Attento.