AI Product Building

Capire un cambiamento per guidarlo

Da CPTO ho visto l'AI invalidare un piano strategico in tre mesi. Così ho lasciato tutto per capire quanto può diventare piccola l'unità capace di costruire qualcosa di grande.

· 8 minuti di lettura

La newsletter

Ciao, sono Marco. Studio come l’AI sta cambiando il modo in cui costruiamo prodotti, lavoriamo in team e guidiamo le organizzazioni.

Ogni settimana condivido esperimenti, idee e framework per capire come diventano persone e team quando l’AI moltiplica la loro capacità di execution.

Luglio 2025. Avevo appena chiuso il documento strategico per il 2026: obiettivi, roadmap e l'assunzione di due nuovi sviluppatori per sostenere la crescita. Ero Chief Product & Technology Officer, e quel piano era il distillato di mesi di ragionamenti. Solido, presentabile, di quelli che si difendono bene davanti a un board.

Tre mesi dopo, ad ottobre, sono tornato dal team con un messaggio: dobbiamo cambiare tutto. Non servivano nuovi dev; serviva riallocare quelli che avevamo per stare dietro all'output che l'AI rendeva possibile, e servivano persone con competenze più orizzontali (PM con competenze tech o tech people con competenze product).

In quei giorni ho capito che non potevo più osservare il cambiamento da manager. Se volevo guidarlo, dovevo viverlo. Così ho lasciato tutto, ho aperto partita IVA e mi sono dato un obiettivo misurabile: One Million Goal, arrivare a €1M costruendo prodotti sfruttando al massimo l'AI, da solo o con un micro-team.

Oggi ho superato i €320.000 di fatturato, porto avanti tre applicazioni attive con altre due in arrivo, e da questa esperienza è nata la domanda che attraversa tutto quello che scrivo:

Quanto può diventare piccola l'unità capace di costruire qualcosa di grande?

Per risponderti devo portarti indietro di qualche anno.

Il seme: un articolo di Wired e un materasso gonfiabile a Sunnyvale

Al primo anno di università un professore ci mostrò delle slide sulle Zip Car di New York: automobili che si prenotavano da un'applicazione, si aprivano col telefono e si guidavano. Era il 2009, e in Italia i primi car sharing sarebbero arrivati solo nel 2013.

ZipCar: una delle prime app per il Car Sharing.

Grazie a lui acquistai il mio primo Wired, e nel numero di luglio 2011 lessi un articolo che cambiò la mia strada.

Raccontava la storia di Loris Degioanni, un ragazzo torinese che per la tesi universitaria aveva sviluppato un software open source per il monitoraggio delle reti aziendali. Ottantamila download prima ancora che si laureasse, poi un professore della UC Davis che, usando quel software, lo invita a proseguire la ricerca in California, costruiscono un'azienda e, pochi anni dopo, la vendono con un'exit milionaria.

Chiusi la rivista con un pensiero che non mi ha più abbandonato: che privilegio poter costruire un’ambizione scelta da te e vederla diventare qualcosa di reale.

Luglio 2011: il numero di Wired che ha innescato tutto

Un anno dopo partecipai al mio primo Startup Weekend, a Povo, vicino Trento (credo fosse addirittura il primo Startup Weekend organizzato in Italia). Lì conobbi Davide, che portava avanti in Silicon Valley un progetto chiamato Wedding Snap: un'app per far scattare foto agli invitati di un matrimonio e condividere l'album con gli sposi, in un'epoca in cui gli album condivisi semplicemente non esistevano.

Wedding Snap, primi screenshot :)

Tornato a casa entrai nel loro sito e gli mandai una lista di feedback, tutte le cose che avrei cambiato. Pochi giorni dopo mi rispose invitandomi a raggiungerli in California.

Era settembre 2012, avevo 21 anni. Vivevamo tutti nello stesso appartamento a Sunnyvale, un po' come si vede nei film: io su un materasso gonfiabile nella camera del founder, un altro dev in salotto. Ogni mattina andavamo al Plug & Play in mezzo ad altre startup, nei weekend si andava a San Francisco o a fare Pilates a Palo Alto con altri founder.

Quell'aria me la sono portata a casa: al rientro fondai un Talent Garden a Pordenone, la mia città, per riprodurne anche solo una parte minima.

Night Building

Non avevo la propensione al rischio, né i risparmi, per fondare una startup a tempo pieno. Così lavoravo, tanto, e nei ritagli costruivo side project. Uno di questi iniziò a funzionare: Ammesso.it, un'app per aiutare gli studenti a preparare i test di ammissione all'università.

Screenshot di Ammesso.it

Pochi mesi dopo il lancio avevo 6.000 studenti registrati organicamente. Negli anni successivi sarebbe diventata un'app da 150.000 studenti organici che girava su un'istanza Django da 15€ al mese su Digital Ocean, fino alla micro-exit da €220.000 nel 2021. Per un solo founder che ha costruito tutto di notte e nei weekend, non sono pochi.

Arrivare alla versione finale, però, mi ha richiesto diversi anni e due refactoring completi: le API migrate da Django a NextJS, l'app passata da Ionic a Xamarin per chiudere su Flutter. Ogni decisione su una feature la pesavo al millimetro, perché sapevo esattamente quanto tempo mi sarebbe costata.

Quattro anni della mia vita, dal 2017 al 2021, rubati alle notti e ai weekend.

L'incompletezza

Nel frattempo la mia carriera era decollata, rientrato dall'Italia avevo prima lavorato come Product Engineer per una startup Spagnola, e poi per un acceleratore in provincia di Trento, fino a diventare Chief Technology Officer di una startup hardware.

Il mio problema, in quegli anni, è che mi sentivo costantemente incompleto.

Progettavo interfacce con Sketch e poi con Figma, sviluppavo in tecnologie diverse, costruivo strategie di growth, leggevo libri di leadership per guidare meglio il mio team. Grazie a Raffaele Gaito scoprii nel 2018 di essere un multipotenziale, e capii perché mi sentivo stretto nell'etichetta "Tech". Non volevo essere solo Tech.

Cercai una figura che coniugasse più discipline e scoprii il Product Management. Frequentai diversi corsi, e capii di avere una caratteristica rara tra i product manager: sapevo sviluppare, sapevo progettare interfacce, capivo gli utenti, sapevo coordinare un team. Diventai Head of Product della divisione Education di Talent Garden, dove dai miei manager ho imparato tantissimo su adaptive leadership e su come si coordina un'azienda (P.s. Grazie! 🙏). Poi arrivò un'opportunità che non potevo lasciarmi sfuggire: il ruolo di CPTO nella scale-up edtech che aveva acquisito la mia app.

Sono stati due anni intensi, in cui ho messo a terra tutto quello che avevo imparato, in termini di leadership e soprattutto di strategia. Ma con l'avanzare dell'AI mi sentivo di nuovo limitato: avevo troppo poco tempo per metterci le mani davvero. E continuavo a farmi la stessa domanda: come posso guidare un team attraverso questa trasformazione se non la sto vivendo in prima persona?

Così, a ottobre 2025, ho lasciato tutto.

La rivoluzione, vista dal di dentro

Non appena lasciata la posizione da CPTO si è presentata subito un'opportunità, diventare co-founder di Anapana, un'applicazione di mindfulness in Italiano. Qui ho iniziato ad utilizzare in modo estensivo l'AI... però voglio essere onesto su com'è andata, perché la mia non è una storia di amore a prima vista con l'AI.

Quando ho iniziato a costruire Anapana, l'AI nel flusso di sviluppo non mi convinceva per niente. Faceva errori, dovevo ricontrollare costantemente l'output, e sinceramente non mi piaceva lavorarci. Poi è uscito Claude Opus 4.5, e con le versioni successive mi sono accorto che le cose stavano cambiando: ho iniziato a fidarmi di quello che produceva e a controllare solo le parti più core.

Il salto vero è arrivato il 9 giugno 2026, il giorno del rilascio di Claude Fable 5. Quella sera ho scritto un intero PRD e ho lasciato il modello libero di lavorare tutta la notte. La mattina dopo il progetto era lì. Non un prodotto finito, sia chiaro: un punto di partenza avanzato su cui iterare usando le competenze accumulate in dieci anni di mestiere. Ma per arrivare a quel punto, prima, servivano settimane di coding.

Ripensa ad Ammesso.it: quattro anni, due refactoring, ogni scelta di prodotto pesata perché il costo in tempo era enorme. Oggi, se dovessi ricostruire la stessa app in React Native e le stesse API in NextJS, mi servirebbe al massimo una settimana. E la maggior parte del mio tempo verrebbe dedicata alla parte di product growth, non al codice.

Questa per me è la vera rivoluzione, e non è la velocità in sé:

Il lavoro operativo si comprime. Il tempo liberato va dove l'AI non arriva: strategia, design, parlare con gli utenti.

Costruire non è più il collo di bottiglia. E quando costruire smette di essere il collo di bottiglia, il valore si sposta.

Cosa succede a persone e organizzazioni

Le app, alla fine, sono solo il mio laboratorio. La domanda che mi interessa davvero è cosa succede alle persone e alle organizzazioni quando la capacità di execution cambia così in profondità. E qui voglio separare con cura quello che ho visto con i miei occhi da quello che ipotizzo.

Ho visto un piano strategico da CPTO, scritto a luglio, diventare carta straccia entro ottobre: da "assumiamo due dev" a "non servono nuovi dev, va riallocato il team e servono product manager orizzontali". Tre mesi.

Ho visto Anapana, un'app mobile usata da migliaia di persone, essere portata avanti da due persone in tutto: prodotto, growth, operations, finance, ogni cosa.

Non ho ancora visto, invece, questo cambiamento dall'interno di una grande corporate. Da formatore per aziende con centinaia di dipendenti posso però osservare come si stanno muovendo: tranne poche realtà illuminate, gli altri si stanno muovendo molto lentamente. È la tensione che attraversa tutto questo articolo: il cambiamento è già qui, le organizzazioni no.

Esempio di come potrebbe cambiare un team. Quando l'execution si comprime, la forma del team cambia prima delle sue dimensioni.

"Sì, ma funziona solo perché sei tu"

Il lettore più scettico, magari un CTO navigato, a questo punto starà pensando: "Bello, ma tu sei un full-stack con dieci anni di mestiere alle spalle. Per me, per il mio team, per chi parte da zero, questa roba non si applica."

Ha ragione in parte, e voglio dirgli esattamente dove.

Le competenze accumulate in questi anni mi permettono di creare applicazioni diverse da quelle dei vibe coder: ho un occhio allenato su experience, design, sicurezza, privacy, flussi di conversione, e so guidare l'AI dentro il flusso di sviluppo. Ma va detta anche l'altra metà della verità: l'AI ormai sviluppa meglio di moltissimi dev junior e mid, e in certi casi anche senior. Sul codice, quello che offro oggi è un guardrail in più.

L'esperienza serve ancora, e parecchio, in tre punti.

Nel design, perché l'AI produce proposte belle ma omologate, e senza una guida forte ogni prodotto finisce per assomigliare a tutti gli altri. Nel marketing e nei flussi di conversione, perché le idee che l'AI propone sono affascinanti ma senza un vero razionale, e capire perché un utente converte richiede anni passati a osservare utenti veri. E nella direzione architetturale, perché senza qualcuno che indica la rotta l'AI genera volentieri codice in più che non serve a nulla.

Quindi no... i miei dieci anni non sono un prerequisito, sono un acceleratore: velocizzano ulteriormente ciò che l'AI fa, ma non sono la condizione per fare quello che sto facendo io. La barriera d'ingresso si è abbassata per tutti; quello che non si è abbassato è il valore del giudizio.

Cosa farne, lunedì mattina

Se guidi un team o un'azienda, usa questo articolo come pretesto per ripensare la struttura organizzativa del tuo team prodotto. Prima di aprire la prossima posizione da sviluppatore, chiediti se il collo di bottiglia è davvero lì, o se ti servono piuttosto persone capaci di muoversi in orizzontale tra prodotto, design, dati e AI.

Se vuoi confrontarti su come applicarlo alla tua realtà, scrivimi: questi ragionamenti mi appassionano, e rispondo.

Se invece sei un dev, un designer, un builder, il messaggio è il seguente: non puoi più permetterti di restare verticale. La profondità in una sola disciplina era un rifugio sicuro; oggi il valore sta nel rendere orizzontali le tue competenze, perché il lavoro operativo della tua verticale è esattamente ciò che l'AI sta comprimendo. A me sembra la più grande opportunità di espansione che la nostra generazione di builder abbia mai avuto.

Ma allora... quanto può diventare piccola l'unità capace di costruire qualcosa di grande?

Sam Altman ha raccontato, nel 2023, che nella chat con i suoi amici CEO del tech esiste un betting pool sull'anno in cui vedremo la prima one-person billion-dollar company: un'azienda da un miliardo di dollari costruita da una sola persona, impensabile prima dell'AI (fonte).

Io una risposta alla domanda su quando accadrà ce l'ho, e me la gioco volentieri: molto presto.

Se ti incuriosisce come sto utilizzando l'AI per costruire iscriviti alla mia newsletter.

Marco

Condividi

Continua a leggere

La newsletter di

Marco Santonocito

Ogni settimana, idee dal campo sul nuovo modo di costruire nell’era AI.

Trasformo esperimenti reali, dati, errori e decisioni in framework utili per founder, product leader e builder.

Newsletter gratuita, letta da 1.000+ lettori. Puoi disiscriverti quando vuoi. Per saperne di più, leggi la privacy policy.