[Video Youtube] Il mio 2025 da Fractional CTO

Ho messo a nudo tutto il mio 2025 da Fractional CTO. I numeri del business, i contenuti, i clienti persi per colpa mia, e la nascita di mia figlia che ha cambiato tutto.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Quando ero piccolo esisteva una rivista chiamata “Giochi per il mio computer.”

Assieme ad essa, dentro potevi trovare un CD con le demo dei giochi da provare, di solito erano cinque o sei e una volta che li avevi provati potevi decidere se comprarne uno. Ci pensavi bene, perché se ti sbagliavi erano ben cinquantamila lire buttate, mica poche.

Oppure c’erano i totem al supermercato, quei cosi con delle cuffie attaccate dove potevi ascoltare I CD prima di comprarli.

Poi te ne stavi lì in piedi, con delle cuffie che avevano usato almeno altre duecento persone prima di te (igienico… ‘na merda…) e ascoltavi tre o quattro tracce per capire se valesse la pena proseguire con l’acquisto.

Quel modello ti poneva di fronte a una conseguenza importante: dato che dovevi spendere una grossa cifra in un colpo solo, prima di comprare ci pensavi prima (bene). Valutavi, leggevi qualche recensione sulla rivista, magari chiedevi anche all’amico che l’aveva già comprato.

Ogni decisione di spesa diventava consapevole e non ti concedevi lo sbaglio perché altrimenti avresti perso i soldi.

Inoltre, non meno importante, ciò che compravi diventava effettivamente tuo: il CD era tuo, il gioco era tuo, e persino roba come Photoshop che costava un botto (se lo acquistavi) diventava tuo per sempre.

Non era meglio e non voglio fare il nostalgico rompicoglioni, però era diverso e quella diversità aveva delle conseguenze sul modo in cui ragionavamo prima di comprare qualcosa.

Come siamo finiti a noleggiare tutto

Il passaggio è stato graduale e all’inizio sembrava una cosa fantastica.

In realtà c’è stata una fase intermedia che nessuno racconta mai: la pirateria. Prima di Spotify, prima di Netflix, c’è stato Napster. E poi eMule, i Torrent, Megaupload (ve lo raccontavo in questa newsletter)

Per una generazione intera, il passaggio dal “compro il CD” al “pago l’abbonamento” è passato attraverso il “scarico tutto gratis”. E onestamente, la pirateria ha dimostrato una cosa fondamentale: le persone non vogliono rubare, vogliono accesso facile. Quando Spotify è arrivato e ha offerto un’alternativa comoda e legale a 9.99 al mese, milioni di persone hanno smesso di scaricare e hanno iniziato a pagare. Lo stesso con Netflix per i film.

La promessa è bellissima: paghi poco, hai accesso a tutto e hai sempre l’ultima versione.

Per un po’ ha funzionato davvero. Non dovevi più scegliere quale album comprare perché potevi ascoltarli tutti. Non dovevi più scegliere quale film noleggiare perché li avevi tutti. Adobe Creative Cloud ha tolto la barriera dei 2.000 euro per Photoshop e l’ha sostituita con 60 euro al mese. Era un upgrade enorme rispetto a prima e non lo nego.

Il problema è che quel modello ha funzionato così bene che tutti hanno voluto copiarlo. E quando dico tutti, intendo proprio tutti. Software, musica, film, serie TV, giornali, app di meditazione persino l’app della bibbia. Raga, ci sono app per il meteo in abbonamento. BMW ha provato a vendere il riscaldamento dei sedili in abbonamento. I sedili riscaldati della tua auto, in subscription. Ci rendiamo conto?

Se ci pensi è ironico: siamo passati dalla pirateria agli abbonamenti perché volevamo accedere in modo comodo ai contenuti, ma adesso stiamo iniziando a odiare gli abbonamenti (o almeno, io sono tra questi) perché sono diventati un modo “comodo” per svuotarci il conto.

E quindi, alla fine, qualcosa si è rotto.

La tassa silenziosa

La situazione è bella infame perché spendi di più su importi più piccoli e non sfrutti tutto.

Nessun singolo abbonamento sembra caro. “Sono solo 9.99”, “sono solo 12.99”, “sono solo 24.99”. Presi singolarmente sono cifre ridicole. Sommati a fine mese diventano centinaia di euro che escono dal conto senza che tu ci abbia pensato neanche un secondo.

E poi c’è il free trial. Quel meccanismo geniale per cui ti iscrivi per provare, ti dimentichi di cancellare, e dopo 14 giorni ti ritrovi un addebito. Di chi è la colpa? Di entrambi. Del sistema, che è progettato apposta per sfruttare la tua inerzia e tua, perché lo sapevi e l’hai fatto lo stesso. Io per primo dimentico di cancellare i free trial, non sono immune a sta roba, eh.

C’è anche il vincolo annuale: paghi l’abbonamento annuale perché costa meno del mensile, ma poi sei bloccato per un anno anche se dopo due mesi ti rendi conto che non lo usi. I tuoi dati sono dentro quella piattaforma, le tue abitudini sono costruite attorno a quel tool, e migrare è una rottura pazzesca.

E il costo non è neanche solo economico. C’è tutta la parte mentale: gestire quindici abbonamenti, ricordarsi le scadenze, valutare se rinnovare o no, tenere traccia di quale carta è collegata a cosa. È lavoro che non produce niente, energia che sprechi per gestire roba che dovrebbe semplificarti la vita e invece te la complica.

Il paradosso della scelta

C’è un effetto collaterale della subscription economy di cui si parla poco: quando tutto costa poco al mese, provi tutto. E quando provi tutto, non impari a usare bene niente.

Lo vedo su di me. L’anno scorso per il mio business avevo abbonamenti per: Anthropic, OpenAI, Google, Mistral, Perplexity e Grok. Sei abbonamenti AI. Saltavo da uno all’altro, provavo il modello nuovo, tornavo al vecchio, poi ne usciva un altro e ricominciavo il giro. Una giostra infinita che mi dava l’illusione di essere aggiornato quando in realtà stavo solo spendendo soldi.

Quest’anno ho fatto una spending review serie e il risultato è stato questo: alla fine avevo bisogno solo di Anthropic e Google, due abbonamenti soltanto. Ho scalato da sei a due. Non male, no? La cosa sorprendente però è che lavoro anche meglio perché conosco questi strumenti in profondità, so dove funzionano e come, ho costruito dei workflow solidi invece di rincorrere la novità dell’ultima settimana. Avere meno scelta mi ha reso più efficace, senza “distrazioni”, perché il modello subscription ti spinge nella direzione opposta: prova tutto, paga poco per ognuno, ma non impegnarti e non approfondire niente.

Che poi, se ci pensi, è la stessa dinamica delle app di dating… ma questa è un’altra newsletter.

La promessa tradita

E qui arriviamo al punto che mi fa più incazzare, perché le aziende che hanno creato il modello subscription lo sanno benissimo che funziona così. Ci contano.

La promessa iniziale era: paghi meno, hai sempre l’ultimo aggiornamento, sei più libero di prima. Facciamo il punto su come è andata.

I prezzi salgono. Netflix è partito a 7.99, adesso per il piano senza pubblicità siamo quasi al doppio. E sì, se non paghi di più ti mettono la pubblicità dentro un servizio che stai già pagando. Spotify aumenta, Adobe aumenta, tutti aumentano. E tu paghi, perché ormai sei dentro e uscire costa più che restare.

Le feature peggiorano o finiscono dietro paywall. Roba che prima era inclusa adesso diventa un add-on. È come se il tuo padrone di casa a un certo punto ti facesse pagare un extra per usare il balcone. Lo stesso balcone che c’era già quando hai firmato il contratto.

Ti faccio un esempio concreto con Notion. Che io uso e pago volentieri, sia chiaro. Ma a un certo punto hanno introdotto l’AI dentro al prodotto, una feature che nessuno aveva chiesto, e l’hanno messa come add-on a 10 dollari al mese per persona. Se hai un team di dieci persone sono 100 dollari in più al mese per qualcosa che prima non esisteva e che probabilmente non userai mai a pieno regime. È il classico meccanismo: ti aggiungo qualcosa, te lo faccio provare gratis per un mese, poi vediamo se te ne accorgi quando inizia a costarti.

E la libertà? Quella è la parte più grossa della promessa tradita. Sei meno libero di prima. Quando compravi Photoshop in scatola, Adobe poteva anche fallire il giorno dopo e tu continuavi a usare il software. Oggi se Adobe decide di cambiare i termini del servizio, tu non hai alternative. I tuoi file, i tuoi progetti, le tue abitudini di lavoro sono tutti dentro il loro ecosistema. Non possiedi più niente di quello che usi tutti i giorni, e la cosa che mi fa impazzire è che ci siamo arrivati un passo alla volta senza quasi accorgercene.

Quando il pricing diventa una decisione di prodotto

Questa spending review che ho fatto sui miei tool AI mi ha costretto a ragionare su una cosa che vedo anche nel mio lavoro con le startup.

Qualche mese fa un founder mi ha chiesto consiglio sul pricing del suo prodotto. La prima cosa che mi ha detto è stata: “Facciamo un abbonamento mensile, come fanno tutti.” Gli ho chiesto perché. Mi ha guardato come se la risposta fosse ovvia: “perché è il modello standard.”

Abbiamo ragionato insieme e alla fine ha scelto un modello diverso: una versione gratuita con le feature base e un upgrade one-time per le feature avanzate. Niente abbonamento, niente rinnovo, niente “sono solo X euro al mese”. I primi numeri gli stanno dando ragione, perché i suoi utenti avevano già troppi abbonamenti e un acquisto singolo era una barriera psicologica molto più bassa.

Il punto è che il mercato è cambiato. I potenziali clienti di quel founder hanno già 30 abbonamenti e la loro soglia di tolleranza per aggiungerne un altro è molto più bassa di qualche anno fa. Il subscription model non è sbagliato in sé, ma non è l’unica opzione e non è automaticamente la migliore. La domanda “perché un abbonamento e non un’altra forma?” andrebbe fatta sempre, e quasi nessuno se la fa.

Dall’altro lato c’è il tema del make vs buy, di cui ho parlato nella newsletter su come ho risparmiato 788 euro l’anno costruendomi i tool con l’AI. Saper valutare cosa comprare, cosa costruire internamente e cosa eliminare del tutto è una competenza che quasi nessuno sviluppa. Io stesso ci ho messo anni a costruirmela, e ancora adesso a volte sbaglio. L’anno scorso ho tenuto un abbonamento per mesi convinto che “prima o poi mi sarebbe servito” (e non mi è mai servito). È che cancellare qualcosa ti dà l’ansia di perdertelo, anche quando non lo usi. È lo stesso meccanismo per cui tieni vestiti nell’armadio che non metti da tre anni “perché non si sa mai”.

La maggior parte delle persone e delle aziende non fa mai questo esercizio. Rinnovano tutto in automatico perché “si è sempre fatto così” o perché “sono solo 10 euro al mese”. Moltiplicato per 20 tool fanno 200 euro al mese che forse non servono a niente.

Uscire dalla trappola

E qui ti sembrerà che io stia dicendo che gli abbonamenti sono il male: ma non è questo il punto, anche perché alcuni hanno senso e li pago pure voilentieri. Per esempio YouTube Premium per me vale ogni centesimo, lo uso ogni giorno, idem Notion. Non tutto va eliminato, e non tutto va costruito da zero.

Ma non è per forza giusto che tutto sia in abbonamento. Ci siamo abituati a questo modello come se fosse l’unica possibilità e non lo è. Ci sono segnali di inversione: alcuni developer stanno tornando al one-time purchase per i loro tool, il freemium intelligente sta guadagnando terreno, e i consumatori stanno iniziando a cancellare abbonamenti che davano per scontati da anni.

Io ho iniziato a fare una cosa semplice: una volta ogni sei mesi apro il conto, guardo tutti gli addebiti ricorrenti e mi chiedo per ognuno se mi serve davvero. La mia spending review. Non è che sia un esercizio piacevole, tra l’altro. Ti ritrovi davanti a cose che paghi da un anno e che non apri da mesi. Ti senti pure un po’ scemo, però funziona.

Quando compravi il CD al supermercato dopo averlo ascoltato al totem con le cuffie, ci pensavi prima di spendere quei soldi. Quella attenzione non è sparita, è solo sepolta sotto una montagna di “sono solo 9.99 al mese”.

Quanti abbonamenti stai pagando adesso che non ricordi nemmeno di avere?

Rispondi a questa mail, sono curioso di sapere com’è messa la tua lista.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

[Piccola interruzione] Ho pubblicato il mio primo video

Perché ho deciso di fare video? Perché proprio ora? In questo primo video rispondo proprio a questa domanda. Mi raccomando iscriviti, metti like e lascia un commento con qualsiasi feedback o con la tua opinione.

[Guarda il video]

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.

Ogni mattina la prima cosa che apro è GitHub. Non le mail e nemmeno LinkedIn. Ma GitHub. Fa talmente parte della mia routine che a volte mi dimentico che c’è stato tutt’altro mondo prima.

GitHub è gratis. Per me, per te, per tutti gli sviluppatori del pianeta. Puoi caricare tutto il codice che vuoi, collaborare con chi vuoi, e non paghi un centesimo.

Eppure Microsoft ha pagato 7,5 miliardi di dollari per comprarlo e oggi gli genera più di 2 miliardi di dollari all’anno.

Qualcosa non torna, no? O forse torna fin troppo bene. E la storia di come ci sono arrivati è una delle più belle che abbia mai studiato.

Prima di GitHub: il medioevo del codice

Per capire perché GitHub è stato rivoluzionario, bisogna capire com’era la vita prima del 2008. E fidati, non era bella.

Il controllo del versionamento esisteva. C’era SVN, c’era CVS. Sistemi centralizzati dove tutto il codice stava su un singolo server. Se il server andava giù, non potevi fare niente. Se eri offline, non potevi nemmeno salvare le modifiche. E fare il merge del codice tra colleghi era una bella rottura.

Contribuire a un progetto open source poi era un’impresa. Dovevi scaricare il codice, fare le modifiche, creare un file di patch, formattarlo nel modo giusto, mandarlo via mail a una mailing list, e sperare che qualcuno lo leggesse. Se avevi fortuna ti rispondevano dopo qualche settimana.

SourceForge esisteva ma era pensato per scaricare software, non per collaborare. L’interfaccia era brutta, lenta, e non c’era nulla di sociale.

Poi nel 2005 Linus Torvalds, il creatore di Linux, si trovò in una situazione assurda: il tool che usava per gestire il kernel gli revocò la licenza gratuita. E Linus, da Linus, cosa fece? Si scrisse il suo sistema di controllo versione in una decina di giorni.

Lo chiamò Git. Potentissimo, ma anche ostico da morire. Comandi a riga di comando che sembravano scritti in aramaico. Per un programmatore esperto andava bene, per tutti gli altri era come guidare una Formula 1 quando al massimo sapevi andare in bicicletta.

Mancava qualcosa: un pezzo che rendesse Git… umano.

Quattro tizi in un bar di San Francisco

Ottobre 2007. Tom Preston-Werner e Chris Wanstrath si ritrovano allo Zeke’s Sports Bar di San Francisco dopo un meetup Ruby che si chiamava, giuro, “I Can Has Ruby”.

Preston-Werner stava lavorando su una libreria Ruby per interfacciarsi con Git e aveva un’idea: creare un posto sul web dove caricare i repository Git, navigarli con un’interfaccia grafica, e collaborare senza dover configurare server Unix e chiavi SSH a mano.

Un “hub” per Git. GitHub.

Wanstrath acconsentì immediatamente e iniziarono a scrivere codice lo stesso mese. Il 19 ottobre Wanstrath fece il primo commit della storia di GitHub. A gennaio si unì PJ Hyett seguito da Scott Chacon, uno dei massimi esperti di Git al mondo.

Registrarono la società come “Logical Awesome LLC” (forse il miglior nome mai dato a un’azienda, anche se purtroppo poi lo cambiarono) e nell’aprile del 2008 la aprirono al pubblico.

Preston-Werner all’epoca lavorava in una startup che si chiamava Powerset. Quando Microsoft acquisì Powerset nel 2008, gli offrì un bonus da 300.000 dollari per restare. Lui rifiutò per concentrarsi su GitHub, che in quel momento non generava praticamente nulla. Dieci anni dopo la stessa Microsoft pagò 7,5 miliardi per quel side project. Vorrei tanto aver visto la faccia del manager di Powerset quel giorno.

Il primo giorno fecero 1.000 dollari di ricavi. Senza un investitore, senza un ufficio, senza nemmeno pagarsi lo stipendio. Lavoravano dai bar del quartiere North Beach e comunicavano su Campfire di 37signals.

Geoffrey Grosenbach, uno dei primi utenti, si offrì letteralmente di spedirgli un assegno per posta perché si sentiva in colpa a non pagare.

Quando i tuoi utenti ti pregano di farli pagare, hai capito che hai qualcosa tra le mani.

La pull request che ha cambiato il modo di scrivere codice

Tecnicamente GitHub non ha inventato niente di nuovo, Git esisteva già e l’hosting del codice pure.

Quello che hanno realmente inventato è stato il modo in cui le persone possono collaborare sul codice. E non è roba da poco.

Hanno preso il “fork”, che nella cultura open source era praticamente una parolaccia (significava spaccare una community, creare un progetto rivale, roba da scisma religioso), e l’hanno trasformato in un bottone. Clicchi Fork, ti crei la tua copia, fai esperimenti e quello che vuoi senza rompere niente a nessuno.

E poi hanno costruito la pull request come la conosciamo oggi.

Prima di GitHub, proporre una modifica a un progetto significava formattare una patch e mandarla per email a una mailing list. Con la pull request di GitHub clicchi un bottone, scrivi cosa hai cambiato e perché, le persone commentano direttamente sulle righe di codice, si apre una discussione, e alla fine qualcuno fa merge con un click.

Sembra scontato adesso, ma nel 2008 era fantascienza. La pull request ha abbassato la barriera d’ingresso all’open source in un modo che prima era impensabile. Chiunque poteva proporre una modifica a qualsiasi progetto al mondo, direttamente dal browser.

E poi c’era tutto il social layer: profili sviluppatore con activity feed, i famosi “quadratini verdi” dei contributi (che hanno creato più dipendenza di un raid settimanale su WoW), stelle ai repository, follower. GitHub non era solo un posto dove mettere il codice, era diventato un social network per chi scrive software e il tuo profilo, alla fine, diventava il tuo curriculum.

Scott Chacon, uno dei co-fondatori, ha detto una cosa che mi è rimasta in testa: “È quasi impossibile ricordare com’era l’open source prima di GitHub.”

Ha ragione. È come cercare di ricordare com’era cercare qualcosa su internet prima di Google.

Va che numeri

Partiamo da dove sono partiti loro: 1.000 dollari il primo giorno. A luglio 2009, 100.000 utenti. Il 95% del traffico era organico. Niente marketing, niente ads, niente sales team.

Oggi:

• Più di 150 milioni di sviluppatori

• Oltre 420 milioni di repository

• 2 miliardi di dollari di fatturato annuo

• Il 90% delle aziende Fortune 100 lo usa

• 4,7 milioni di abbonati paganti a Copilot

• Circa 230 nuovi repository creati ogni minuto

Da quattro persone in un bar a 6.000 dipendenti.

E la parte che mi ha stupito di più: per quattro anni non hanno preso un centesimo da investitori esterni. Erano profittevoli dal primo giorno.

Il paradosso del bootstrap

Questa è la parte della storia che mi ha fatto riflettere.

GitHub per quattro anni è stata un’azienda bootstrapped e profittevole. I fondatori giravano le conferenze a parlare di quanto fosse pericoloso prendere soldi dai VC troppo presto. Preston-Werner diceva: “Crediamo ancora che prendere troppi soldi troppo presto possa essere dannoso per un’azienda. Siamo passati quattro anni e mezzo definendo noi stessi prima di accettare capitale esterno.”

Poi nel luglio 2012 hanno preso 100 milioni di dollari da Andreessen Horowitz. La più grande Serie A che a16z avesse mai scritto in quel momento. Valutazione: 750 milioni.

Ipocriti? Non proprio.

Quando hanno preso quei soldi, GitHub era già GitHub. Avevano 1,7 milioni di utenti, erano profittevoli, avevano un brand fortissimo nella community degli sviluppatori. Non avevano bisogno dei soldi per non morire. Li hanno presi per scalare l’offerta enterprise e aprire mercati nuovi.

Come disse Preston-Werner: “La nostra azienda è profittevole da anni, cresce veloce e non ha bisogno di soldi. Allora perché prenderli? Perché vogliamo essere migliori.”

Quando negoziare con i VC è una scelta e non una questione di sopravvivenza, è tutto un altro sport raga.

Nel 2015 arrivò un Series B da 250 milioni guidata da Sequoia, valutazione 2 miliardi. Totale raccolto: 350 milioni. Sei anni dopo il Series A, Microsoft pagò 7,5 miliardi. Solo a16z fece un ritorno di circa un miliardo sul loro investimento da 100 milioni.

La monetizzazione al contrario

Repository pubblici? Gratis, illimitati. Pull request, issue, hosting, collaborazione? Tutto gratis. Alla fine hanno reso gratuiti anche i repository privati per uso individuale (ci arriviamo).

I soldi arrivano quando il team ha bisogno di controlli di sicurezza avanzati, SSO, compliance, governance, e tutta quella roba che serve a far dormire tranquilli i CISO e i dipartimenti legali.

E qui scatta il meccanismo geniale.

Uno sviluppatore usa GitHub nel weekend per i suoi progetti personali. Il lunedì arriva in ufficio, si ritrova a combattere con il SVN aziendale, e pensa: “Ma perché non usiamo GitHub?” Ne parla al team, il team ne parla al CTO, il CTO chiede un budget, e il contratto enterprise si chiude praticamente da solo.

GitHub non ha mai avuto bisogno di un grande team di vendita che facesse cold call ai dirigenti. Gli sviluppatori erano il team di vendita e ogni utente gratuito era un potenziale champion dentro la propria azienda.

Chris Wanstrath la metteva con più ironia: “I nostri amici volevano pagare, ed era una cosa nuova, perché avevo passato anni cercando di fare soldi da loro senza riuscirci.”

Entro il 2016 GitHub Enterprise generava il 50% dei ricavi, con una crescita vicina al 300% annuo nei primi anni. Non vendevano hosting Git, quello era diventato una commodity. Vendevano l’accesso a un ecosistema che i loro sviluppatori usavano già, con le garanzie di sicurezza e compliance che il reparto IT pretendeva.

Il nemico diventa alleato (per 7,5 miliardi)

Il 4 giugno 2018 Microsoft annuncia l’acquisizione di GitHub per 7,5 miliardi in azioni.

L’ironia era colossale. L’ex CEO Steve Ballmer nel 2001 aveva definito Linux “un cancro”. E adesso Microsoft pagava 7,5 miliardi per la piattaforma dove vive praticamente tutto l’open source del mondo.

La community reagì come ti aspetteresti. GitLab vide 10 volte il volume normale di migrazioni. In una singola ora, 13.000 progetti vennero spostati via, c’era gente che parlava di un “abbraccio mortale” di Microsoft. Petizioni, thread furiosi, meme ovunque.

Nat Friedman, il nuovo CEO scelto per guidare GitHub, andò su Reddit e disse una frase che valeva più di qualsiasi comunicato stampa: “Se Microsoft rovina questa cosa, perderemo la fiducia degli sviluppatori per un’intera generazione.”

E poi Microsoft fece la mossa più intelligente possibile: rese i repository privati gratuiti per tutti.

Pensa alla scena: tu compri un’azienda per 7,5 miliardi e la prima cosa che fai è rendere gratis qualcosa che prima era a pagamento.

Follia? No, strategia pura. Ogni sviluppatore in più sulla piattaforma è un futuro cliente Azure, Copilot, enterprise. Tutto l’ecosistema Microsoft ne beneficia.

I numeri gli hanno dato ragione in modo spettacolare. Da 28 milioni di utenti al momento dell’acquisizione a più di 150 milioni oggi. Da circa 250 milioni di fatturato a 2 miliardi. E Copilot, il tool di AI per scrivere codice, da solo genera più ricavi di quanti ne facesse tutta GitHub prima dell’acquisizione.

Satya Nadella aveva capito una cosa che Ballmer non avrebbe mai capito: gli sviluppatori non li possiedi, li conquisti diventando così utile che non possono più fare a meno di te.

Il pattern che si ripete

Se ci fai caso, è lo stesso copione ogni volta.

Slack: gli sviluppatori lo adorano, lo portano in azienda, l’azienda paga. Venduto a Salesforce per 27,7 miliardi.

MongoDB: Community Edition gratuita, la usi sul tuo progetto, quando devi andare in produzione l’azienda compra Atlas. Oggi 1,6 miliardi di fatturato.

Docker: miliardi di download gratuiti, poi le aziende pagano per le funzionalità enterprise e la sicurezza.

Ma attenzione, non tutti ci riescono. Docker per anni ha provato a vendere top-down all’enterprise, con un team di vendita tradizionale, e ha quasi fallito con 335 milioni investiti e meno di 75 milioni di fatturato. Solo quando è tornato al modello bottom-up, dal developer all’azienda, è passato da 11 a 135 milioni in due anni.

La cosa che ho capito lavorando con le startup è che la differenza tra chi crea miliardi con questo approccio e chi ci brucia i soldi è una sola: la pazienza. La stragrande maggioranza dei tuoi utenti non pagherà mai, e vanno trattati come il bene più prezioso che hai, perché sono loro che costruiscono il network effect che rende il prodotto indispensabile.

La domanda che mi porto a casa

Ogni volta che lavoro con una startup e parliamo di pricing, c’è sempre quel momento in cui qualcuno dice: “Ma se lo diamo gratis, come facciamo soldi?”

Preston-Werner aveva una frase per rispondere: “GitHub Everywhere.” Gratis per chiunque facesse open source, studiasse, o lavorasse per conto suo. Le aziende, quelle sì, pagano.

Alla fine, “everywhere” è esattamente dove sono finiti. 150 milioni di sviluppatori, 2 miliardi di fatturato.

La domanda che mi faccio è: quanto del valore del tuo prodotto stai regalando per costruire il network che un giorno lo renderà indispensabile?

Ci vediamo nella prossima newsletter

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

Primo giorno con un nuovo cliente. Il founder mi accoglie in call, condivide lo schermo e mi mostra il repository. “Ecco, questo è il codice. Da dove vuoi partire?”

“Dal business.”

Non se l’aspettava. Mi aveva assunto come CTO e la prima cosa che gli chiedo è stata quella di raccontarmi come funziona l’azienda, chi sono i clienti, dove vogliono arrivare tra sei mesi. Roba che non c’entra niente con il codice.

Questa scena, con variazioni diverse, si ripete quasi ogni volta che entro in una nuova startup. Mi chiamano per un motivo e il vero lavoro da fare è un altro.

In questo numero di Senza Filtri voglio raccontarti cosa succede davvero nei miei primi 90 giorni quando entro in una startup e perché è molto diverso da quello che la maggior parte dei founder si immagina.

Giorni 0-30: non tocco il codice (quasi)

Una delle prime volte che sono entrato in una startup come Fractional CTO ho fatto esattamente quello che tutti si aspettano. Mi sono seduto, ho aperto il repository, ho letto il codice per giorni, ho analizzato l’architettura e ho preparato un bel documento con tutte le mie raccomandazioni tecniche. Potrebbe sembrare un lavoro impeccabile, peccato che stessi risolvendo i problemi sbagliati.

Non avevo capito dove voleva andare il business. Non avevo parlato con gli utenti, non avevo guardato i numeri, non avevo chiesto ai founder cosa li teneva svegli la notte al di là del codice. Avevo fatto il CTO da manuale e il risultato era un documento che non serviva a niente. Ho dovuto rifare tutto da capo, una rottura pazzesca.

Da quella volta ho cambiato completamente approccio.

Oggi quando entro in una startup la prima cosa che faccio è sedermi con i founder e fargli un botto di domande che non c’entrano niente con la tecnologia. Chi sono i vostri utenti, come li raggiungete, dove perdete le persone nel flusso, qual è il modello di business, dove volete essere tra sei mesi. Roba da business manager, non da CTO.

Poi guardo il prodotto, ma in ottica di prodotto: come è costruito, dove funziona, dove fa schifo, quali sono le frizioni che gli utenti sentono. E solo dopo tutto questo arrivo alla tecnologia. Lo stack, l’architettura, il team, come shippano.

Lo so che sembra controintuitivo per un CTO, ma la realtà è che senza capire il business qualsiasi decisione tecnica è campata in aria. Puoi avere l’architettura più elegante del mondo, ma se stai costruendo la cosa sbagliata non importa a nessuno.

Le urgenze che nessuno aveva visto

C’è un pattern che si ripete ogni volta: io e i founder parliamo in fase di discovery, quindi sappiamo sempre quali sono gli obiettivi quando arrivo, anche se tra quelli concordati e la realtà c’è quasi sempre uno scarto; perché entri, inizi a guardare le cose da vicino e alla fine trovi un botto di urgenze che non erano state preventivate.

A volte manca qualcuno che abbia una vera direzione di prodotto, un mindset di product management. In quei casi coinvolgo persone della mia rete con competenze verticali, perché è una cosa che posso fare io ma che preferisco delegare a chi la fa meglio di me.

Altre volte ci sono cose da fare prima di quelle che avevamo pianificato, cose che i founder non vedevano perché erano troppo dentro al day-to-day per accorgersene.

La startup che ti raccontavo all’inizio è l’esempio perfetto; mi avevano chiamato per velocizzare lo sviluppo, avevano un team piccolo, il prodotto cresceva e sentivano di star andando troppo lenti. Quindi il mio ruolo è stato: iniziare a fare domande, capire il business, parlare col team e osservare il prodotto.

Mi sono reso conto che non avevano ancora validato quello che stavano costruendo: stavano mettendo feature su feature senza aver capito quello che serviva davvero ai loro utenti.

Gli ho suggerito di non investire sullo sviluppo tradizionale ma di usare strumenti di AI per ricostruire un MVP leggero e iterare direttamente con i clienti. Zero intermediari tra chi parla con gli utenti e chi modifica il prodotto. Ne ho parlato anche nella newsletter su come l’AI ha ribaltato il mio lavoro: quando uno strumento ti permette di fare in quattro giorni quello che prima prendeva quattro mesi, il collo di bottiglia si sposta.

Non era quello che si aspettavano dal CTO, ma era quello che serviva.

Il mio lavoro nei primi 30 giorni alla fine è tutto qui: capire quali sono le vere urgenze e avere il coraggio di dire “questa cosa che avevamo pianificato può aspettare, facciamo prima quest’altra”. Non è sempre facile da far digerire, ma è per questo che mi pagano.

Giorni 30-60: adesso si fa

Passati i primi 30 giorni il contesto è chiaro. So dove siamo, so dove dobbiamo andare, so quali sono i problemi veri. E adesso bisogna iniziare a portare risultati, perché le analisi vanno bene ma a un certo punto servono le cose fatte.

Quello che faccio è prendere i problemi che ho identificato e li trasformo in un piano di lavoro concreto, qualcosa che in genere dura due settimane. In questa fase servono quick win, low hanging fruit che dimostrino al team e ai founder che le cose stanno andando nella direzione giusta. Ecco perché i primi sprint sono i più importanti, perché danno ritorno a ciò che ci sarà dopo.

In parallelo metto a terra una metodologia di lavoro, un flusso che permetta a tutti di sapere cosa fare, come farlo e quando è fatto. Sprint, priorità chiare, ownership definita. È roba che sembra banale ma che nella maggior parte delle startup early stage semplicemente non esiste. Quello che succede quando la introduci è che le persone smettono di rincorrersi e iniziano a lavorare nella stessa direzione. Prima ognuno aveva la sua idea di cosa fosse urgente, adesso c’è una lista condivisa e si va avanti insieme.

Ma c’è un prerequisito senza il quale niente di tutto questo funziona: la trasparenza.

La mia capacità di essere efficace dipende dalla fiducia e dalla trasparenza dei founder. Ho bisogno di sapere dove si vuole arrivare, quanta runway c’è, qual è il burn rate, se ci sono problemi nel team che non emergono nelle riunioni. Se hai 18 mesi di runway possiamo ragionare con calma. Se ne hai 6, ogni decisione ha un peso diverso e io ho bisogno di saperlo per non pianificare come se il tempo fosse infinito.

Giorni 60-90: far fare

Se i primi 30 giorni sono “capire” e i secondi sono “fare”, gli ultimi 30 sono “far fare”. Il mio ruolo qui cambia, passo da quello che fa le cose a quello che mette gli altri nelle condizioni di farle. Si tratta di qualcosa che ho provato sulla mia pelle: in una delle prime esperienze come leader è andato tutto bene finché c’ero io, però appena ho ridotto il mio coinvolgimento, il team ha iniziato a rallentare. Erano bravi, ma ogni decisione passava ancora da me, col risultato che avevo costruito un sistema che dipendeva dalla mia presenza. E quando me ne sono andato… beh, si è visto.

Da lì ho capito che il mio lavoro non è risolvere i problemi. È mettere le persone nelle condizioni di risolverli da sole.

Quindi in questa fase si inizia a ragionare in ottica di team: quali sono i gap di competenze, se serve assumere qualcuno, e se sì chi e per fare cosa. Come ridistribuiamo le responsabilità con le persone che ci sono. I processi che abbiamo messo a terra nei 30-60 adesso devono girare in autonomia.

Con i primi risultati in mano si costruisce una roadmap a 3-6 mesi che sia realistica, basata su quello che abbiamo imparato nei primi 60 giorni. Si definiscono le metriche per capire se stiamo andando nella direzione giusta, e non parlo solo di KPI tecnici ma anche di prodotto e di business, perché se il team tech non sa come il suo lavoro impatta sul business sta lavorando al buio.

E la relazione con i founder cambia. Nei primi 30 giorni erano update operativi, “ho guardato questo, ho trovato quello”. Adesso sono conversazioni strategiche su dove siamo, dove possiamo andare e cosa serve per arrivarci. Il segnale che le cose stanno funzionando è quando il founder smette di chiederti “cosa facciamo?” e inizia a dirti “ho pensato che potremmo fare così, che ne dici?”.

Io sono un Fractional CTO, non sono lì per sempre. Se quando me ne vado il team non è autonomo, ho fallito.

La cosa che dico sempre ai founder

C’è una cosa che ripeto a ogni founder prima di iniziare a lavorare insieme: trattami come un co-founder, non come un consulente esterno.

È come gli avvocati: per creare una buona strategia difensiva devono conoscere i fatti. Tutti i fatti, anche quelli scomodi e se mi nascondi che hai solo tre mesi di runway, io pianifico come se ne avessi dodici. Se non mi dici che nel team c’è qualcuno che sta per andarsene, io costruisco piani che si reggono su una persona che tra un mese non ci sarà più.

Ogni startup è diversa. I tempi cambiano, le priorità cambiano, le persone cambiano. Ma il percorso di fondo è sempre lo stesso: prima capisci, poi fai, poi fai fare. E la cosa che li accomuna tutti è che il vero lavoro non è quasi mai quello che il founder si aspetta.

Se stai pensando di prendere un CTO per la tua startup, chiediti se sei pronto a condividere tutto. Se sei pronto a sentirti dire che la priorità non è quella che pensavi.

Perché è da lì che parte tutto.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Io me la ricordo eccome. Avevo chiesto il permesso a mamma e papà (cavolo se ne è passato di tempo…) e non sapevo nemmeno cosa fosse “un indirizzo mail”.

Per la mia generazione, l’indirizzo @hotmail.com era il primo passaporto per internet. Lo mettevi ovunque: nelle chat, nei forum, nei profili MSN. Era tuo, non di tuo padre, non della scuola, non del provider internet.

Tuo soltanto.

E la cosa assurda è che quel prodotto, che per noi era semplicemente “la mail”, non doveva nemmeno esistere. Non lo sapevo? Siediti, che adesso te lo racconto.

Prima di Hotmail: la mail era una prigione

Per capire quanto Hotmail fosse rivoluzionario, bisogna capire com’era la posta elettronica nel 1996.

La tua email era legata al tuo Internet Service Provider. Se avevi AOL, il tuo indirizzo era @aol.com. Se avevi CompuServe, era @compuserve.com. Cambiavi provider? Perdevi la mail. Cambiavi lavoro? Perdevi la mail. Andavi in vacanza? Non potevi leggere la mail.

Per accedere alla posta serviva un software specifico, tipo Eudora o Pine, configurato su un singolo computer. Dovevi sapere cos’era un server POP3, inserire porte, configurare parametri che il 99% delle persone non capiva.

La mail era un servizio accessorio legato a un contratto, niente di più.

Due ingegneri, un firewall e un’idea

Sabeer Bhatia e Jack Smith si erano conosciuti lavorando in Apple, per poi finire insieme in un’azienda chiamata Firepower Systems.

Avevano un problema banale: volevano comunicare privatamente durante il lavoro per scambiarsi idee sulla startup che sognavano di fondare. Ma il firewall aziendale bloccava l’accesso alle email personali.

Bloccava la posta, non bloccava il web.

L’intuizione fu immediata: se l’email fosse stata accessibile da un browser, come una qualsiasi pagina web, il firewall non l’avrebbe fermata. Niente software da installare, niente configurazioni. Apri il browser, fai login, leggi la posta.

Da qualsiasi computer, in qualsiasi posto del mondo.

Oggi ci sembra ovvio, ma nel 1996 era fantascienza.

Venti rifiuti e 250 dollari in tasca

Bhatia era arrivato negli Stati Uniti dall’India a 19 anni con 250 dollari e una borsa di studio per il Caltech. Quel background gli aveva dato una cosa che in Silicon Valley vale più di qualsiasi MBA: la caparbietà di chi non ha alternative.

Per non farsi copiare l’idea, i due fondarono una società fittizia chiamata JavaSoft (che nome eh...) e iniziarono a fare il giro dei VC su Sand Hill Road.

Venti rifiuti. Uno dopo l’altro.

I VC non capivano il modello: “Come fai soldi se il prodotto è gratis?” alcuni dubitavano che avrebbero mai raggiunto 50.000 utenti.

Al ventunesimo tentativo, Tim Draper di Draper Fisher Jurvetson disse sì. Investì 300.000 dollari per il 15% della società, valutandola 2 milioni (pazzo? visionario? giudicalo tu).

Il nome lo scelsero con un trucco: HoTMaiL, con le maiuscole su H-T-M-L, per sottolineare che era un prodotto costruito sul web.

Lo lanciarono il 4 luglio del 1996, lo stesso giorno dell’indipendenza americana. Il simbolismo era decisamente intenzionale: indipendenza dagli ISP, dal computer fisico e dai provider.

“P.S.: I love you”

Hotmail cresceva, ma non abbastanza velocemente. In una riunione, Tim Draper chiese ai fondatori come pensavano di fare marketing.

Bhatia rispose: cartelloni sulla Highway 101 e pubblicità in TV.

Draper fu diretto: con quei soldi avrebbero potuto comprare “circa un nanosecondo di TV e un francobollo su un cartellone per un giorno.”

Ispirato da un case study di Harvard sulle vendite Tupperware, dove i clienti diventano la forza vendita, Draper propose qualcosa di diverso: inserire un messaggio automatico in fondo a ogni email spedita dagli utenti di Hotmail.

Il testo che suggerì: “P.S.: I love you. Get your free email at Hotmail.”

I fondatori dissero no, categoricamente. Per loro era spam, una violazione della privacy dell’utente.

Draper insistette e la discussione si accese. Alla fine arrivarono a un compromesso: il messaggio sarebbe stato inserito, ma senza il “P.S.: I love you”. Solo una riga: “Get your free email at Hotmail”, con un link cliccabile.

Draper, a distanza di anni, scherza ancora: “Se avessero tenuto l’I love you, il mondo sarebbe un posto più pacifico.”

La curva che nessuno aveva mai visto

Quella riga cambiò tutto.

Non era un programma di referral dove dovevi scegliere di consigliare il prodotto. Era integrata nel prodotto stesso: ogni email che mandavi era pubblicità gratuita, recapitata a qualcuno che ti conosceva e si fidava di te.

Cliccavi il link, ti registravi in trenta secondi e poi iniziavi a mandare mail. Tutte con la stessa riga in fondo.

I numeri:

Prima ora di lancio: 100 iscritti.

Primo mese: 20.000 utenti.

Settembre 1996 (tre mesi): 100.000 utenti.

Gennaio 1997 (sei mesi): 1 milione di utenti.

Cinque settimane dopo: 2 milioni.

Dicembre 1997 (diciotto mesi): 12 milioni di utenti.

Oltre l’80% delle iscrizioni arrivava da quella riga in fondo alle email. Il costo di acquisizione per utente era di circa 4 centesimi di dollaro.

Nel frattempo, il competitor Juno spendeva oltre 20 milioni di dollari in pubblicità tradizionale, cartelloni, TV, stampa, e raggiungeva 2 milioni di utenti. Juno spendeva 5-10 dollari per ogni utente acquisito. Hotmail, 4 centesimi.

Ogni volta che vedo una startup bruciare budget in ads sperando che i numeri salgano, mi torna in mente questo confronto. Non c’è partita.

100.000 utenti indiani da una singola email

La storia più assurda della crescita di Hotmail riguarda l’India.

Bhatia mandò una mail ad un amico in India, invitandolo a provare il servizio. Tre settimane dopo Hotmail aveva 10.000 utenti indiani senza aver speso un centesimo in marketing locale, ma anche senza sapere cosa stesse succedendo.

Il dettaglio che rende questa storia surreale: nel 1996, in tutta l’India c’erano probabilmente meno di 100.000 computer connessi a internet. Gli utenti accedevano da internet café, laboratori universitari, uffici condivisi. Ogni persona che si iscriveva diventava un punto di propagazione per tutti quelli intorno.

Hotmail divenne il leader di mercato in India e in Svezia senza averlo pianificato. Come disse Draper: “Hotmail è il più grande provider email in Svezia e India nonostante non abbiano mai fatto marketing di nessun tipo in quei paesi.”

Il prodotto si vendeva da solo, letteralmente.

Il “janitor” impazzito e il 25% delle inbox cancellate

Crescere così velocemente, nel 1997, senza il cloud computing di oggi, era un incubo operativo. E ogni tanto l’incubo diventava realtà.

Hotmail aveva un processo automatizzato, soprannominato internamente “the janitor” (il custode), che durante la notte svuotava le cartelle Cestino degli utenti per recuperare spazio sui dischi.

Una notte, un bug fece impazzire il janitor. Invece di svuotare solo il cestino, iniziò a generare cloni di se stesso che cancellarono la Posta in Arrivo degli utenti. Quando gli ingegneri riuscirono a fermarlo, il danno era fatto: il 25% dell’intera base utenti aveva la casella completamente vuota.

Bhatia chiese al COO quanto tempo servisse per ripristinare i backup.

Il problema è che non c’erano backup. I costi dei nastri magnetici erano diventati insostenibili con la crescita esplosiva degli utenti, e l’azienda aveva smesso di farli un mese prima.

Le email di milioni di persone erano perse per sempre.

Con la stampa che bussava alla porta e migliaia di utenti furiosi, Hotmail scelse la trasparenza totale. Spiegarono esattamente cosa era successo, si scusarono, e offrirono upgrade gratuiti a vita a tutti gli utenti colpiti.

Da CTO, questa parte mi fa venire i brividi. L’idea di non avere backup è il tipo di scelta che fai quando stai crescendo talmente in fretta che non riesci nemmeno a tenere in piedi l’infrastruttura, figurati pianificare il disaster recovery.

Il servizio sopravvisse, sorprendentemente direi, ma non c’erano alternative valide in giro. Perciò le caselle vuote si riempirono di nuove mail in pochissimi giorni.

In sostanza: a volte il miglior piano B è non avere concorrenti.

Ma riguardiamo i numeri un attimo

Ricapitoliamo il viaggio finanziario:

Investimento iniziale DFJ: 300.000 dollari, valutazione 2 milioni.

Otto mesi dopo: valutazione salita a 20 milioni.

Yahoo offre 40 milioni. No grazie.

Microsoft offre 160 milioni. No grazie.

Microsoft sale a 350 milioni. Ancora no.

Bhatia chiese 400 milioni a Microsoft e Bill Gates lo fece volare a Redmond. La trattativa non fu delle più rilassate, con i manager di Microsoft che urlavano e abbandonavano la stanza mentre i VC di Bhatia dicevano di accettare qualsiasi cifra sopra i 200 milioni.

Bhatia tenne duro. Sapeva che i suoi 12 milioni di utenti e l’effetto rete erano l’asset vero. Il codice lo poteva riscrivere chiunque, quella base utenti no.

Il 31 dicembre 1997, Microsoft annunciò l’acquisizione per circa 400 milioni di dollari. Gates lo definì “il miglior acquisto che abbia mai fatto.”

Da 300.000 dollari a 400 milioni in diciotto mesi. Un ritorno di oltre 1.300 volte per DFJ.

L’imbarazzo di Microsoft: FreeBSD sotto il cofano

E qui la storia diventa comica.

L’architettura originale di Hotmail girava su FreeBSD con Apache per il front-end e Sun Solaris per il back-end. Sistemi UNIX, open source, leggeri ed efficienti. I server front-end erano descritti da un admin come “schede madri da 200 dollari appoggiate su un pezzo di cartone.”

Microsoft comprò il più grande servizio web del mondo e scoprì che girava sul sistema operativo del nemico.

La cultura interna di Microsoft imponeva il “dogfooding”: ogni prodotto doveva usare le tecnologie Microsoft. Quindi l’ordine fu chiaro: migrare tutto su Windows.

Il primo tentativo, su Windows NT, fu un disastro. Gli ingegneri scoprirono che servivano circa 20 macchine Windows per sostituire ogni singolo server FreeBSD, ciascuna costando dieci volte tanto e gli admin UNIX minacciarono di licenziarsi sul posto.

La migrazione a Windows 2000 andò poco meglio. L’immagine di sistema pesava 900MB contro i pochi megabyte di FreeBSD, rendendo il deployment lentissimo. Le operazioni che su UNIX erano automatizzate con script erano “essenzialmente impossibili da scriptare” su Windows. Il bilanciamento del carico con strumenti Microsoft sarebbe costato 15 milioni di dollari, contro 6 milioni con la soluzione esistente.

Ed eccolo il colpo di scena finale: per far funzionare i processi automatizzati su Windows, gli ingegneri Microsoft dovettero installare un pacchetto chiamato “Services for UNIX” e per poter usare cron, lo scheduler di UNIX. Lo strumento del nemico, installato sul proprio sistema operativo, per far funzionare il proprio prodotto di punta.

Ogni volta che vedo un’azienda forzare una scelta tecnologica per ragioni politiche invece che tecniche, mi torna in mente questa storia. Il dogfooding ha senso quando il tuo prodotto è pronto. Quando non lo è, stai solo sabotando il tuo team.

Nel 2001 Microsoft dichiarò al Wall Street Journal che FreeBSD era stato completamente eliminato. Pochi giorni dopo, uno sviluppatore FreeBSD verificò e dimostrò il contrario. Microsoft dovette ritrattare.

I server front-end di Hotmail girarono su FreeBSD per almeno tre anni dopo l’acquisizione. La migrazione completa richiese quasi un decennio.

Da must-have a barzelletta

Per un’intera generazione, creare un account Hotmail era il primo atto di cittadinanza digitale. In India, in America Latina, nel mondo arabo, Hotmail era sinonimo di email.

Poi le cose cambiarono.

La registrazione senza frizioni, che aveva fatto il successo del prodotto, divenne la sua maledizione. Spammer, bot e criminali crearono milioni di account fake. I filtri antispam erano inadeguati. Un indirizzo @hotmail.com su un curriculum passò da segnale di modernità a segnale di allarme. Studi dimostrarono che il 70% dei recruiter percepiva i candidati con email Hotmail come meno professionali.

Il colpo di grazia arrivò il 1 aprile 2004.

Google lanciò Gmail con 1 Gigabyte di spazio gratuito, Hotmail ne offriva 2 Megabyte. Cinquecento volte meno. L’industria intera pensò fosse uno scherzo d’aprile.

Non lo era.

Microsoft reagì tardi: portò lo spazio a 250MB, poi tentò vari rebranding (Windows Live Hotmail, poi Outlook.com). Ma il danno era fatto. Nel 2012 annunciò la chiusura del brand, migrando 400 milioni di account su Outlook.com.

Fine di un’era.

Il DNA di Hotmail è ovunque

La firma virale di Hotmail non ha costruito solo un’azienda, ha creato un’intera categoria di strategia di crescita.

“Sent from my iPhone” di Apple è il discendente diretto. Una firma predefinita su 2.2 miliardi di iPhone venduti, miliardi di impressioni gratuite senza spendere un euro.

Non offre nessuna utilità tecnica, ma ogni email diventa una piccola pubblicità.

I watermark di TikTok sono la stessa logica applicata ai video. Ogni clip scaricata porta il logo TikTok su Instagram, YouTube e WhatsApp. Il contenuto stesso diventa il veicolo pubblicitario, sulle piattaforme dei competitor.

Superhuman, il client email premium da 30 dollari al mese, aggiunge “Sent via Superhuman” con un link di referral personale. Il 30% del traffico al loro sito arriva da quelle firme. Hanno raggiunto 100 milioni di dollari di fatturato annuo in gran parte grazie a questo loop.

Mailchimp col badge in fondo alle email gratuite, Calendly coi link che espongono il tool a ogni destinatario, Dropbox col programma referral che aumentò le iscrizioni del 60%.

Tutti figli di quella riga in fondo alle email di Hotmail.

La lezione che mi porto a casa

Hotmail ha dimostrato una cosa che vale ancora oggi: il canale di marketing più potente è quello che non sembra marketing.

Un messaggio che arrivava da una persona di cui ti fidavi e inserito in una conversazione privata, era più potente di un qualunque banner o spot. Il link all’interno ti portava a registrarti in trenta secondi e tu ti fidavi.

Due ingegneri bloccati da un firewall hanno inventato la webmail, un investitore testardo ha insistito per una riga di testo, e quella riga ha costruito il primo impero virale della storia di internet.

La domanda che mi faccio ogni volta che lavoro su un prodotto è questa: quale touchpoint sottovalutato potrebbe diventare il canale di crescita più forte?

Ogni fattura inviata, ogni notifica, ogni report esportato, ogni link condiviso. Se non ci pensi, stai lasciando sul tavolo il tuo viral loop.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Qualche settimana fa mi ha scritto una startup (lo so che sei curioso/a, ma si dice il peccato, non il peccatore). Il co-founder tecnico aveva costruito e validato tutto, i primi clienti paganti c’erano già. Poi, a un certo punto, il founder se n’è andato.

Quello che ha lasciato era un software che funzionava: gli utenti lo usavano e il business girava. Sotto il cofano, però, c’era un problema grosso. Il software non poteva evolvere. E non per colpa della tecnologia in sé, ma per come era stata scelta.

Mi sono ritrovato a pensare a quante volte mi capita di entrare in progetti dove il problema non è il codice, il team o altro, ma la scelta tecnologica fatta all’inizio senza farsi le domande giuste. Purtroppo è una roba che vedo in continuazione.

Quando lo stack diventa un muro

La prima cosa che faccio quando entro in un progetto è guardare sotto il cofano. E quello che ho trovato qui mi ha dato subito il quadro della situazione.

Utenti, transazioni, relazioni tra persone, dati che si collegano tra loro in continuazione. Il tipo di prodotto dove tutto dipende da tutto.

Il database che avevano sotto? MongoDB. Che è un ottimo strumento, ma per un tipo di lavoro diverso. Qui serviva qualcosa che gestisse le relazioni tra i dati in modo naturale e MongoDB non è pensato per quello.

Non voglio aprire il dibattito su MongoDB ovviamente, ma quando me ne sono accorto ho capito perché il team voleva cambiarlo. Ogni volta che dovevano costruire qualcosa che toccava le connessioni tra utenti, era una lotta. Workaround su workaround, soluzioni fragili, tempi di sviluppo che esplodevano. Il team non era scarso, però lo strumento che avevano sotto gli remava contro.

E qui il punto è che il costo di una scelta così non lo vedi subito. Lo vedi dopo mesi, quando ti accorgi che una feature che avrebbe dovuto prendere due settimane ne prende sei. Quando il team è frustrato e non capisce perché tutto è così faticoso. Quando un competitor che è partito dopo di te ti supera perché riesce a iterare più veloce. Il costo non è solo tecnico: sono mesi persi, opportunità che sfumano, e soldi bruciati in sviluppo che non doveva essere così complicato.

Mi è successo anche a me, anni fa, di trovarmi in una situazione simile su un progetto mio. Avevo scelto una tecnologia perché mi piaceva, perché volevo impararla, e dopo qualche mese mi sono ritrovato a combattere contro lo strumento invece che a costruire il prodotto. È una sensazione che riconosco al volo quando la vedo in altri.

La prima cosa che stiamo facendo insieme è costruire una strategia di migrazione verso PostgreSQL. Non perché sia “migliore” in assoluto, ma perché per quello che il loro prodotto deve fare è lo strumento giusto.

La trappola del “migliore”

Quando un founder deve scegliere la tecnologia per il suo prodotto, la domanda che si fa quasi sempre è: “Qual è la tecnologia migliore?”

Sembra ragionevole, eppure è la domanda sbagliata.

Non esiste la tecnologia migliore in assoluto, esiste quella più adatta al contesto in cui ti trovi. Sembrerà una differenza sottile, ma ti assicuro che non lo è. Questo cambia completamente il modo in cui affronti la scelta finale.

Quando cerchi “la migliore”, finisci per scegliere in base alla moda del momento, al post che hai letto su X, al consiglio dell’amico developer, o alla tecnologia che “tutti stanno usando”. Nessuna di queste è una buona ragione per prendere una decisione che condizionerà il tuo prodotto per anni.

Quando invece parti dal contesto, ti fermi a capire cosa ti serve davvero. Che tipo di prodotto stai costruendo? Come si comportano i tuoi dati? Come crescerà il prodotto nei prossimi dodici mesi? Quante persone ci lavoreranno sopra?

È come un artigiano che sceglie l’attrezzo in base a quello che deve costruire. Non prende il martello più costoso perché è il “migliore”: prende quello che gli serve per il lavoro che ha davanti.

Anche io all’inizio della carriera ho fatto questo errore (ma tipo 100 volte almeno). Sceglievo le tecnologie che mi piacevano, quelle che volevo imparare, quelle che erano “cool” in quel momento. Poi ti ritrovi con un progetto costruito su uno stack che conosci solo tu e che il prossimo developer dovrà smontare per capirci qualcosa. E lì capisci che la scelta non è mai solo tua: è una scelta che condiziona tutti quelli che verranno dopo.

Nel caso della startup che ti ho raccontato il founder aveva fatto una scelta senza chiedersi dove il prodotto sarebbe dovuto andare. E quindi, quando il prodotto è cresciuto nella direzione naturale, lo stack non ha retto.

Cosa guardo davvero quando devo scegliere

Quando entro in un progetto e devo valutare o scegliere uno stack, seguo una logica che nel tempo si è consolidata. Non è una formula magica e si adatta caso per caso, ma ci sono delle variabili che peso sempre.

Il contesto di prodotto e di business

Questa è sempre la prima cosa. Che tipo di prodotto stai costruendo? Per chi? Come interagiscono i dati al suo interno?

Se stai costruendo un marketplace dove gli utenti hanno relazioni tra loro, hai bisogno di una tecnologia che gestisca quelle relazioni in modo naturale. Se stai costruendo un sistema che riceve milioni di eventi al secondo e deve solo registrarli, le tue esigenze sono completamente diverse.

La tecnologia segue il problema. Mai il contrario.

Sembra ovvio, eppure lo vedo succedere in continuazione: startup che scelgono il database perché “è quello che va adesso” senza mai chiedersi se è quello giusto per i dati che devono gestire. È come comprare un furgone quando ti serviva una bicicletta. O viceversa.

Chi trovi sul mercato

Questo è un fattore che un botto di persone sottovalutano. Puoi scegliere la tecnologia più elegante del mondo, ma se poi non riesci a trovare persone che la conoscono, hai un problema serio.

Non mi sto riferendo solo alle assunzioni a tempo pieno. Parlo anche di freelancer, consulenti, community online dove chiedere aiuto quando sei bloccato alle tre di notte, magari prima di un lancio. Parlo di documentazione fatta bene, di tutorial aggiornati, di risorse per formare il team quando arriva qualcuno nuovo.

Scegliere una tecnologia di nicchia quando sei una startup con budget limitato e devi muoverti veloce è un rischio che nella maggior parte dei casi non vale la pena correre. Lo so, fa meno figo dire “usiamo Go con questo framework che conoscono in dodici nel mondo”. Ma quando il tuo unico developer se ne va e devi trovare qualcuno che ci metta le mani, capisci perché “noioso e diffuso” batte “figo e di nicchia” nove volte su dieci.

La longevità

Questa tecnologia sarà ancora supportata tra tre anni? Chi c’è dietro? È un progetto open source con una community attiva e un’azienda che lo sostiene, o è il side project di qualcuno che potrebbe abbandonarlo da un giorno all’altro?

Non devi per forza scegliere qualcosa che durerà vent’anni. Ma devi almeno evitare di ritrovarti tra due anni con uno stack che nessuno mantiene più e una migrazione forzata nel momento peggiore. Tipo quando stai per chiudere un round. O quando hai appena assunto tre persone. O quando il cliente più grande ti chiede una feature urgente.

La migrazione forzata è una delle robe più dolorose che esistano nel mondo tech. Se puoi evitarla con una scelta più ragionata all’inizio, fallo.

Il fattore economico e il tempo

Quanto budget hai realmente? Quanto tempo ti separa dal prossimo round, dal prossimo lancio, dal prossimo obiettivo di business?

Ti faccio un esempio concreto: se devi mettere in piedi l’infrastruttura del tuo prodotto e non hai né il budget né il tempo per trovare un DevOps che ti gestisca tutto su AWS, andare su una Platform as a Service come Railway o Render non è una scelta pigra. È una scelta intelligente.

Stai delegando una complessità che in questo momento non puoi permetterti di gestire internamente, e questo ti libera tempo e risorse per concentrarti su quello che conta davvero: il prodotto. Quando crescerai e avrai le risorse per farlo, potrai sempre valutare se portare l’infrastruttura in-house.

Il fattore che nessuno sta considerando

C’è una variabile relativamente nuova che secondo me pochissime persone stanno mettendo sul piatto. Ed è una di quelle che nei prossimi anni farà sempre più differenza.

Quanto materiale ha l’AI su quella tecnologia?

L’AI ormai è diventata un collaboratore reale nello sviluppo di un software; non si tratta più di un giocattolo, ma di uno strumento che uso ogni giorno. Bisogna ricordarsi, però, che l’AI funziona bene su tecnologie sulle quali è stata allenata con tanto materiale: documentazione, codice open source, tutorial, discussioni su StackOverflow ed esempi reali di implementazione.

Se scegli una tecnologia di nicchia, con poca documentazione e poca community, l’AI avrà poco materiale su cui basarsi per aiutarti. E questo si traduce in qualcosa di molto concreto: il tuo team sarà più lento nel risolvere problemi, farà più errori che avrebbe potuto evitare, e dovrà investire più tempo su cose che con una tecnologia più diffusa l’AI avrebbe gestito in pochi secondi.

Ci penso spesso, perché è un circolo che si autoalimenta. Più una tecnologia è diffusa, più materiale c’è, più l’AI è brava ad aiutarti, più il tuo team è produttivo, più la tecnologia diventa attraente. E viceversa: meno una tecnologia è diffusa, meno l’AI ti aiuta, più sei lento, meno conviene sceglierla.

Attenzione, non ti dico che non devi scegliere una tecnologia solo perché l’AI la conosce bene, il punto è che oggi ha senso mettere questo fattore nella valutazione finale. È uno di quei ragionamenti che tra qualche anno ti sembreranno anche ovvi, ma che adesso pochi stanno facendo.

La scelta sbagliata non è la fine del mondo

Questa è la parte che volevo aggiungere, perché rischia di passare il messaggio sbagliato.

Non tutte le scelte tecnologiche sbagliate sono fatali. Ho visto startup sopravvivere e crescere con stack discutibili. Ho visto prodotti di successo costruiti su fondamenta traballanti che sono state sistemate nel tempo, pezzo dopo pezzo, senza mai fermare il business.

La startup di cui ti ho parlato all’inizio ne è la dimostrazione: hanno validato il prodotto, hanno trovato clienti paganti, il business funziona. Lo stack non era quello giusto, ma non li ha uccisi. Li ha rallentati.

Quando arrivo in un progetto dove le scelte sono già state fatte, il mio lavoro non è giudicare chi le ha fatte. Sarebbe inutile e pure un po’ da stronzi. Il mio lavoro è capire se quelle scelte reggono per dove il business vuole andare. Se reggono le rafforzo e se non reggono costruisco una strategia per migrare senza fermare tutto.

E questa è la parte che mi piace di più del mio lavoro, tra l’altro. Non è scegliere la tecnologia perfetta il primo giorno. È navigare la complessità di scelte già fatte, vincoli reali, budget limitati e obiettivi ambiziosi. È trovare il percorso migliore con le carte che hai in mano.

Perché alla fine la tecnologia è uno strumento. E come ogni strumento, il suo valore non dipende da quanto è sofisticato o alla moda. Dipende da quanto ti permette di fare quello che devi fare, con le risorse che hai, nel tempo che hai.

Il tuo stack tecnologico è stato scelto partendo dal business o da una preferenza tecnica?

Rispondi a questa mail, sono curioso di sapere com’è andata nel tuo caso.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternato a qualche deep dive sui business che mi incuriosiscono.

Ho una confessione da fare.

Avevo una streak seria su Duolingo. Non vi dico di quanto perché mi vergogno, ma ogni mattina, prima ancora del caffè, aprivo l’app e provavo a fare la lezione di spagnolo. Non sono diventato bravo, anzi se mi mettessi a parlare spagnolo probabilmente farei ridere i polli. Però quell’app ha qualcosa di malefico: ti crea una dipendenza che nemmeno i social riescono a dare.

Quel maledetto gufo ti manda notifiche passive-aggressive se salti un giorno, le streak ti fanno sentire in colpa, le leghe ti fanno competere con gli sconosciuti. Sembra Candy Crush mascherato da una scuola di lingue.

E posso dirti la verità? Funziona. Non impari davvero lo spagnolo (e su questo ci arriviamo), ma 100 milioni di persone al mese aprono quell’app.

Non è una newsletter sulla gamification, la storia che voglio raccontarti è un’altra.

Duolingo nel 2024 ha licenziato parte dei contractor e li ha sostituiti con l’AI, ma la cosa più sorprendente non è questa, è che il titolo in borsa non è sceso.

Anzi.

Ed è qui che la cosa diventa interessante per chi, come me, costruisce prodotti.

L’uomo che ha fatto lavorare gratis il mondo intero (due volte)

Prima di parlare di AI, devo raccontarti chi c’è dietro, perché la storia di Luis von Ahn è una di quelle che ti fanno pensare.

Luis è guatemalteco (non sapevo si dicesse così). Cresciuto in un paese dove l’educazione di qualità è un privilegio, non un diritto. Questo dettaglio diventerà importante tra poco.

Nel 2007, da professore alla Carnegie Mellon, inventa reCAPTCHA. Sai quando devi cliccare su “non sono un robot” e ti fa selezionare le immagini con i semafori? (che sbaglio sempre tra l’altro) Ecco, quello.

C’era un trucco geniale che mentre tu dimostravi di non essere un bot, stavi anche digitalizzando libri per Google. Gratis. Senza saperlo.

200 milioni di persone al giorno lavoravano gratuitamente per digitalizzare l’archivio del New York Times e milioni di libri. Google compra reCAPTCHA nel 2009.

Luis aveva trovato un pattern: prendi un’attività che le persone fanno comunque e crea valore enorme sopra.

E poi lo rifece.

L’idea di Duolingo nasce dalla stessa logica. In origine, gli utenti avrebbero imparato le lingue e contemporaneamente tradotto il web. Learning come sottoprodotto del lavoro utile.

Quel modello specifico non ha funzionato a lungo. Ma l’intuizione di base, rendere l’educazione linguistica gratuita e accessibile, quella sì.

Nel 2011 nasce Duolingo. Nel 2021 fa l’IPO. Oggi vale circa 12 miliardi di dollari.

Tutto partendo da un senso di colpa: Luis si sentiva in colpa perché reCAPTCHA sfruttava il lavoro gratuito delle persone. Voleva creare qualcosa che desse indietro.

“Il mio paese non può permettersi Rosetta Stone a 500 dollari. Dovevo trovare un altro modo.”

Va che numeri

Ok, la parte che vi piace:

• 100+ milioni di utenti attivi al mese

• 37+ milioni di utenti attivi al giorno

• Circa 1 miliardo di dollari di fatturato annuo [dato 2025]

• Valutazione: circa 12 miliardi di dollari

• Team: circa 800 dipendenti

• Lingue disponibili: 40+

• Il 95% degli utenti usa il piano gratuito

Per dare un contesto: Rosetta Stone al suo picco valeva circa 1 miliardo. Duolingo vale 12 volte tanto, con un prodotto che è gratis per quasi tutti.

Ma il numero che mi ha fatto pensare è un altro: Duolingo ha un fatturato per dipendente di circa 900.000 dollari. E per un’azienda di educazione è roba seria.

Il momento che ha cambiato tutto

E arriviamo al punto.

A gennaio 2024, Duolingo taglia circa il 10% dei contractor. Non i dipendenti full-time, i contractor. Quelli che creavano contenuti, traducevano lezioni, scrivevano esercizi.

Il motivo? L’AI fa lo stesso lavoro, ma più veloce e a costo (quasi) zero.

Non l’hanno detto con queste parole esatte, ovviamente. Il comunicato parlava di “evoluzione dei processi” e “nuove priorità”. Ma la sostanza era chiara.

Qualche mese prima avevano lanciato Duolingo Max, il piano premium che usa GPT-4 per due funzionalità:

Explain My Answer: quando sbagli una risposta, l’AI ti spiega perché in modo conversazionale. Non il solito messaggio pre-scritto, ma una spiegazione personalizzata che capisce il tuo errore specifico.

Roleplay: conversazioni simulate con personaggi AI. Tipo ordinare al ristorante in francese o chiedere indicazioni in giapponese. Interazioni che prima richiedevano un insegnante umano o, nel caso di Duolingo, decine di content writer che scrivessero centinaia di scenari.

Poi è arrivata la Video Call, dove parli direttamente con un personaggio AI in tempo reale. Pratica di conversazione senza l’ansia sociale di parlare con un umano.

Il CEO Luis von Ahn l’ha detto chiaramente: l’AI sta gradualmente sostituendo il lavoro dei contractor nella creazione di contenuti. Per carità, non tutto, non domani, ma ormai la direzione è quella.

[Piccola interruzione] Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

Cosa ha funzionato (e cosa no)

Cerchiamo di essere onesti intellettualmente (almeno noi dai…)

Cosa ha funzionato:

I costi di produzione dei contenuti sono scesi. Creare una nuova lezione o un nuovo esercizio che prima richiedeva ore di lavoro umano ora richiede minuti di revisione. L’AI genera, l’umano controlla e affina. Il processo è invertito.

La personalizzazione è migliorata. L’algoritmo di Duolingo (che si chiama Birdbrain.. geniale…) usa il machine learning per adattare la difficoltà a ogni utente. Con l’AI generativa, anche le spiegazioni e le conversazioni diventano personalizzate.

La velocità di espansione è aumentata. Aggiungere una nuova lingua o un nuovo tipo di esercizio è diventato significativamente più veloce.

Cosa è più complicato:

La qualità non è uniforme. Chi usa Duolingo Max nota che a volte le spiegazioni dell’AI sono generiche o poco precise per lingue meno comuni. Il giapponese non è l’inglese, e GPT-4 lo sa bene.

Il dibattito “ma funziona davvero?” resta aperto. Duolingo è sempre stato criticato per il fatto che la gamification funziona meglio nel tenerti incollato all’app che nell’insegnarti davvero una lingua. L’AI migliora il prodotto, ma non risolve questo problema di fondo. Infine, ma non da meno, c’è la questione etica. Diverse persone hanno perso il lavoro, contractor che creavano contenuti da anni sono stati sostituiti.

Non è una nota a piè di pagina, è una conseguenza reale.

La mia opinione (da CTO)

Ora parlo da chi vive questo tema ogni giorno con le startup che seguo.

L’AI adoption non è un’opzione e non è una moda: è una realtà che sta cambiando il modo in cui si costruiscono i prodotti e chi la ignora oggi, sarà in svantaggio domani.

Ma, e questo “ma” è importante, l’approccio deve essere cauto.

Ho visto startup buttarsi sull’AI come se fosse la soluzione a tutto. “Mettiamoci l’AI!” senza sapere cosa, dove e perché. Tipo le aziende che nel 2018 volevano “mettere la blockchain” ovunque.

Duolingo ha fatto una cosa diversa. Non ha semplicemente sostituito tutto con l’AI, ha guardato il processo, identificato dove l’AI poteva fare un lavoro uguale o migliore a costo inferiore e hanno iniziato da lì.

Content creation ripetitiva? L’AI la fa bene. Spiegazioni personalizzate? L’AI la fa meglio di un messaggio pre-scritto. Conversazioni simulate? L’AI è perfetta.

Strategia di prodotto? No. Design dell’esperienza utente? No. Decisioni su cosa costruire? Assolutamente no.

La lezione non è “sostituisci le persone con l’AI”. La lezione è “capisci dove l’AI ti dà un vantaggio reale e usala lì.”

Io con i miei clienti faccio esattamente questo. Partiamo dalle attività, non dalla tecnologia. Quali task sono ripetitivi? Quali richiedono poca creatività ma molto tempo? Quali processi hanno un output prevedibile?

Quelli sono i candidati. Il resto, strategia, relazioni, decisioni, resta umano.

Cosa possono fare le startup (in pratica)

Nella pratica se sei un founder o un CTO di una startup, come applichi quello che ha fatto Duolingo?

Primo: mappa i processi, non le feature. Non chiederti “dove posso mettere l’AI nel mio prodotto?” Chiediti “quali attività del mio team sono ripetitive, prevedibili e ad alto volume?” Duolingo non ha messo l’AI a caso. Ha sostituito content creation ripetitiva, migliaia di esercizi che seguono pattern simili.

Secondo: parti dal testing, non dal replacement. Non licenziare nessuno domani. Fai un test. Prendi un’attività specifica, falla fare all’AI per un mese, confronta qualità e costi. Se funziona, scala. Se no, hai imparato qualcosa senza danni (non fare come Klarna)

Terzo: l’umano diventa il quality controller. Il modello che funziona non è “AI al posto delle persone” ma “AI che produce, persona che controlla”. L’AI genera il primo 80%, l’umano affina il restante 20%. Il risultato è spesso migliore e sempre più veloce.

Quarto: non tutto è automatizzabile. E va bene così. Le attività che richiedono giudizio, empatia, creatività vera, comprensione del contesto. Quelle restano umane. Duolingo non ha sostituito i suoi product manager o i designer con l’AI. Ha sostituito chi scriveva la variante numero 347 dello stesso tipo di esercizio.

Ti racconto una cosa che ho visto con un mio cliente: avevano un team di tre persone che passava l’80% del tempo a scrivere documentazione tecnica. Roba super ripetitiva. Quindi abbiamo testato l’AI su quel processo e il risultato è stato che le tre persone ora dedicano il 60% del loro tempo a cose più importanti come parlare con gli utenti, migliorare il prodotto e pensare. La documentazione la rivede una persona sola. Non abbiamo licenziato nessuno, abbiamo liberato tempo.

Il parallelo con Linear (e con tutti gli altri)

Se ci pensi, Duolingo sta facendo con l’AI quello che Linear ha fatto con il prodotto: fare di più con meno.

Linear ha 52 milioni di fatturato con 57 persone. Duolingo sta andando nella stessa direzione: aumentare l’output riducendo le risorse necessarie.

Linear ha scelto di essere piccola, è un principio di Design, Duolingo invece non vuole essere piccola. Cerca di capire come riallocare le persone e i soldi risparmiati con l’AI vanno in nuove feature, nuovi mercati e nuovi prodotti.

Entrambi gli approcci sono validi. Ma la domanda per te è: se l’AI ti libera risorse, dove le metti?

Puoi fare come Duolingo: reinvestirle in crescita.

Puoi fare come me con i miei clienti: reinvestirle in qualità.

Ma una cosa è certa: fingere che l’AI non esista non è un’opzione. Non per le startup, non per le aziende e soprattutto, non per i professionisti.

La domanda scomoda

Se un’azienda da 12 miliardi di dollari può sostituire parte del lavoro umano con l’AI e ottenere risultati uguali o migliori, cosa significa per il resto del mercato?

Non ho una risposta definitiva. Ma ho un’opinione.

L’AI non sostituirà chi fa lavoro di qualità, ma chi fa lavori ripetitivi che sembrano di qualità e credimi, c’è una differenza enorme.

Il content writer che scrive la variante numero 347 di un esercizio di grammatica? Sostituibile. Il content strategist che decide quali esercizi creare e perché? No.

Il developer che scrive boilerplate code? Sempre più sostituibile. Il developer che progetta l’architettura e prende decisioni di trade-off? No.

Il traduttore che traduce frasi standard? Sostituibile. Il traduttore letterario che cattura sfumature culturali? No.

Il pattern è chiaro: l’AI sostituisce l’esecuzione ripetitiva, non il giudizio (almeno per ora eh…)

E la domanda che dovresti farti è questa: nel tuo lavoro, quanto tempo passi a eseguire e quanto a decidere?

Perché se la risposta è “80% esecuzione”, hai un problema. O meglio, hai un’opportunità: usare l’AI per ribaltare quel rapporto.

Duolingo l’ha fatto. Il gufo verde è ancora lì, ti manda ancora notifiche passive-aggressive, ti fa ancora sentire in colpa se salti un giorno.

Ma dietro le quinte, il modo in cui crea quei contenuti è cambiato per sempre.

La domanda per te è semplice: cosa stai aspettando per fare lo stesso?

E no, non parlo di licenziare nessuno. Parlo di essere onesto su dove il tuo tempo (e quello del tuo team) sta andando davvero. E se l’AI può liberarne una parte, usarla.

Perché il futuro non è “umani contro AI”. Il futuro è “umani con AI contro umani senza AI”.

E io so da che parte voglio stare.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

P.S. Costruiamo insieme Senza Filtri

Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.

L’altro giorno ero in call con un potenziale cliente. Startup interessante, un team piccolo e prodotto in forte crescita. A un certo punto, mi fa LA domanda: “Ok Christian, ma qual è la tua tariffa oraria?”

“Non lavoro a ore.”

Rimane in silenzio, lo vedo spiazzato. Palesemente non se l’aspettava.

A quel punto gli spiego come lavoro, cosa offro e come possiamo strutturare la collaborazione. Alla fine della call mi dice: “Ah okay, ha molto più senso così”.

Oggi mi viene naturale rispondere così, ma c’è voluto del tempo per arrivare a questo punto e il percorso non è stato solo un “chiedere di più”, ma cambiare il modo in cui lavoro, in cui mi posiziono e i clienti che scelgo.

Se sei un freelance e stai ancora vendendo ore, non ti giudico. Ci sono passato anch’io, in un certo senso.

Però qui voglio raccontarti cosa è cambiato per me, magari può aiutarti a fare lo stesso percorso con qualche sbattimento in meno.

Il problema non è quanto chiedi. È cosa stai vendendo.

La tariffa oraria è il punto di partenza naturale per qualsiasi freelance. Ed è giusto che sia così.

È semplice: guardi il mercato, guardi la tua esperienza, metti un numero. Il cliente capisce subito quanto costi. Stimi le ore, le moltiplichi per la tariffa, e hai il preventivo. Pulito, lineare, easy.

Il problema è che quando vendi ore, attiri persone che comprano ore.

E chi compra ore cerca manodopera. Cerca qualcuno che esegua, che stia lì X ore a fare Y cose. Non ragiona per obiettivi, non ragiona per risultati, ma per tempo dedicato.

“Quante ore ci metti?”

“Possiamo fare un paio d’ore in meno?”

“Ma se ci metti meno ore, mi fai un prezzo più basso?”

Questa dinamica è pericolosa, perché sposta l’attenzione dal valore che porti al tempo che impieghi. E il tempo è una commodity: c’è sempre qualcuno che costa meno di te e che può dedicare lo stesso numero di ore.

Facciamo un esempio estremo per rendere l’idea: immagina che in un’ora di consulenza io riesca a sbloccare un problema che stava frenando il lancio del prodotto di un cliente. Quel blocco gli stava costando settimane di ritardo e decine di migliaia di euro in opportunità perse.

Quell’ora vale il mio prezzo orario? O vale molto di più?

Il valore non sta nel tempo, sta nel risultato.

Non si tratta di guadagnare di più o di meno, è un approccio lavorativo completamente diverso: chi lavora per obiettivi pianifica tutto in modo diverso, comunica in modo diverso e, infine, lavora in modo diverso.

Per me è stato un cambio di mentalità rispetto al tipo di cliente che volevo cercare sul mercato.

Non ho alzato il prezzo. Ho cambiato tutto il resto.

Qui sta il punto che molti sbagliano: pensano che passare dal vendere ore al vendere valore sia semplicemente chiedere di più.

Invece è cambiare cosa vendi, come lo presenti e a chi lo vendi.

Ti racconto cosa ho fatto io quest’anno che ho deciso di riposizionarmi.

Ho cambiato il sito. Ho smesso di usare la parola “MVP” come bandiera. Per anni il mio posizionamento era legato alla fase iniziale delle startup: ti aiuto a costruire l’MVP, a validare l’idea e a lanciare. Poi mi sono reso conto che quel tipo di servizio, soprattutto oggi con l’intelligenza artificiale, sta diventando sempre meno legato alla mia esperienza, anche qualcun altro può farlo bene. Io posso dare molto più valore nella fase successiva: quando hai raccolto, quando devi scalare, quando il prodotto deve diventare un business.

Ho cambiato i contenuti. Su LinkedIn, nella newsletter, nei confronti con i clienti: parlo molto meno della parte iniziale e molto più di quella post-raccolta. Non perché la fase iniziale non sia importante, ma perché non è più dove il mio valore è al massimo.

Ho iniziato a dire no. Ci sono clienti che ancora oggi mi contattano per la primissima fase. Con tutta onestà, o li giro a qualcuno della mia rete che è più adatto, o gli dico di ricontattarmi nel momento giusto. Non è facile dire no ai soldi, soprattutto all’inizio. Ma se accetti tutto, non ti stai posizionando, stai solo riempendo il tuo calendario.

Il posizionamento non è una dichiarazione su LinkedIn. È una serie di scelte concrete su cosa fai, cosa non fai e per chi lavori.

Come presento il mio valore oggi

Oggi ogni proposta che mando ha una struttura chiara.

Il cliente vede: X euro al mese, per Y mesi. Un retainer mensile fisso.

Dentro ci sono tre cose:

1. I servizi: cosa faccio concretamente, quali attività sono incluse e con che modalità di ingaggio.

2. Gli obiettivi: quali problemi andiamo a risolvere insieme, quali risultati vogliamo raggiungere nel periodo di collaborazione.

3. I deliverable: cosa consegno, cosa il cliente può aspettarsi di avere alla fine.

In questo modo il cliente compra un percorso verso un risultato, non il mio tempo.

La conversazione cambia: non parliamo più di “quante ore”, ma di “cosa risolviamo”, e non si negozia il tempo, ma lo scope.

E c’è un altro vantaggio enorme che non avevo previsto: il retainer mensile permette al cliente di avere chiarezza totale. Sa esattamente quanto spende, per quanto tempo e cosa ottiene. Niente sorprese, niente fatture che lievitano, niente discussioni a fine mese su quante ore ho fatto.

La semplicità per il cliente è un valore in sé.

Il cliente giusto vale più del cliente che paga di più

Questa è una cosa che ho capito solo con l’esperienza e che avrei voluto capire molto prima.

Io seleziono i miei clienti tanto quanto loro selezionano me.

Non scelgo in base a quanto pagano, ma in base al valore di ritorno che mi danno. E quel valore non sono solo i soldi.

È il portfolio. Lavorare con un’azienda interessante ti permette di mostrare risultati concreti ai futuri clienti. Un case study forte vale più di mille parole sul tuo sito.

È il network. Se il cliente ha una rete importante e le cose vanno bene, parlerà di te. E non c’è marketing migliore di un cliente soddisfatto che ti referenzia spontaneamente. Il 60/70% del mio business oggi arriva da referral. Non dalla pubblicità o dal content marketing. Il passaparola delle persone che hanno lavorato bene con me e sono state bene è uno strumento potentissimo.

È la crescita professionale. Ci sono progetti che ti insegnano cose nuove, ti espongono a sfide che non avevi affrontato, ti fanno crescere come professionista. Questo ha un valore economico enorme, anche se non compare in fattura.

E poi ci sono clienti che magari ti pagano anche bene, ma ti mangiano tempo, energia e spazio mentale sproporzionato rispetto al ritorno. Clienti “one shot” che vanno bene, per carità, ma che non ti lasciano nient’altro.

Devi imparare a ragionare come se stessi per prepararti a fare una maratona, non uno sprint. Il ritorno è sul lungo periodo, più che su quello breve.

Guadagnare subito è facile. Costruire un business solido nel tempo richiede investire nelle relazioni, non solo nei ricavi.

Il primo passo concreto (per chi vuole iniziare)

Se oggi vendi a ore e vuoi iniziare a spostarti verso il valore, ecco quello che ti consiglio di fare. Non è teoria, è quello che avrei detto al me stesso di qualche anno fa.

Definisci i tuoi servizi. Prima ancora di parlare con il prossimo cliente, siediti e scrivi nero su bianco: quali problemi risolvo? Che risultati porto? Non pensare in termini di “faccio X ore di sviluppo” o “faccio Y ore di consulenza”. Pensa a cosa cambia per il cliente dopo che hai lavorato con lui.

Dagli un valore economico. Non basato sulle ore, basato sull’impatto. Se il tuo intervento permette al cliente di risparmiare tre mesi di sviluppo, quanto vale quel tempo per lui? Se lo aiuti a evitare un errore che gli costerebbe decine di migliaia di euro, quanto vale quella consulenza?

Presentali così al prossimo cliente. Non devi cambiare tutto dall’oggi al domani. Quando arriva il prossimo potenziale cliente, prova a dire: “Guarda, sto spostando il mio modello di business a un modello a progetto. Per me è importante definire bene gli obiettivi che andiamo a risolvere, i problemi che ti vado a risolvere e il ritorno che hai.”

In quel momento stai parlando di valore, non di tempo.

E qui arriva l’errore più grande che vedo fare a tanti freelance che provano a fare questo switch: alzano il prezzo senza aver cambiato nient’altro.

Chiedono di più per lo stesso servizio, presentato nello stesso modo, allo stesso tipo di clienti. Non funziona così, ciccio.

Prima di tutto identifica i problemi che vai a risolvere, sii specifico, perché il risultato va saputo comunicare, non basta parlare dell’attività.

Se non sai spiegare perché il tuo lavoro vale quello che chiedi, non è un problema di prezzo. È un problema di posizionamento.

Non è coraggio. È chiarezza.

Se c’è una cosa che questo percorso mi ha insegnato è che alzare il proprio valore non è una questione di coraggio nel chiedere di più.

È una questione di chiarezza.

Chiarezza su cosa offri. Chiarezza su per chi lavori. Chiarezza su quali problemi risolvi e che risultati porti.

Quando hai questa chiarezza, il prezzo diventa una conseguenza naturale. Non devi più giustificarlo. Non devi più sentirti a disagio quando lo dici. Non devi più negoziare al ribasso.

Perché non stai vendendo il tuo tempo, stai vendendo la tua competenza, la tua esperienza e il cambiamento che generi nel business del cliente.

E quello ha un valore che non si misura in ore.

Tu stai vendendo il tuo tempo o il tuo valore?

Rispondi a questa mail, sono curioso di sapere a che punto sei del percorso.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Qualche settimana fa un mio cliente mi scrive un messaggio che potrei riassumere cosi:

“Abbiamo speso 40.000 dollari per un top developer americano. Quattro mesi di lavoro su un MVP. Centinaia di interviste fatte. Il prodotto dovrebbe essere perfetto. Eppure stiamo girando a vuoto.”

Il problema non era il developer, lui era bravo, forse anche troppo. La piattaforma invece era diventata troppo complessa per una fase early stage; troppe automazioni, troppi percorsi di sviluppo, troppa distanza tra chi parla con gli utenti e chi scrive il codice.

Una cosa che vedo succedere spesso è questa: i developer forti in fase super early tendono a portarti fuori strada perché costruiscono l’architettura perfetta per un prodotto che tu non hai ancora validato. Così gli ho suggerito una cosa che fino a poco tempo fa non avrei mai detto a un cliente.

“Ricostruisci tutto con Lovable, da zero. Fallo tu, ma senza developer”.

Michele, product manager, ha ricostruito in quattro giorni quello che era stato sviluppato in quattro mesi.

Quattro giorni. Da solo. Senza scrivere una riga di codice.

Non sarà l’infrastruttura che li porterà a un milione di utenti, ma per la fase in cui sono è perfetto: velocità, controllo, e soprattutto chi parla con gli utenti è la stessa persona che modifica il prodotto. Zero intermediari.

Mentre guardavo il loro nuovo setup funzionare, mi sono fermato a pensare.

Io sono un Fractional CTO: il mio mestiere ruota attorno alla tecnologia, al codice, alle decisioni tecniche. E ho appena consigliato a un cliente di eliminare il developer e fare da solo.

Se tutti possono programmare, quanto vale saperlo fare?

Benvenuti nell’era del vibe coding

Forse hai già sentito questo termine, forse no. Te lo spiego in trenta secondi.

“Vibe coding” è un’espressione coniata da Andrej Karpathy, cofondatore di OpenAI, a febbraio 2025. Significa costruire software “seguendo il vibe”, a sensazione: descrivi quello che vuoi in linguaggio naturale, un’AI lo costruisce per te. Niente sintassi, niente debug manuale, niente anni di studio per capire la differenza tra un framework e l’altro.

Collins Dictionary l’ha eletta parola dell’anno 2025 e non è un caso.

I numeri danno la dimensione del fenomeno. Lovable, uno degli strumenti più popolari in questo spazio, è passato da zero a 200 milioni di dollari di ricavi annuali in 12 mesi con soli 100 dipendenti.

Bolt.new, Cursor, v0, Replit: il mercato degli strumenti per costruire software senza saper programmare è esploso. Le stime parlano di un settore da quasi 3 miliardi di dollari oggi, 325 miliardi entro il 2040.

Ma il punto non sono i numeri. Il punto è cosa significano.

Fino a ieri, solo l’1% della popolazione mondiale sapeva programmare. Il software, che governa praticamente ogni aspetto della nostra vita, era costruito da una casta ristretta di persone con competenze specifiche e anni di formazione.

Oggi quella barriera si sta sgretolando. Un founder può costruire il suo MVP in un weekend. Un marketing manager può crearsi il tool interno che gli serviva senza aprire un ticket al team tech. Uno studente di economia può tirare su un’app con database, autenticazione e pagamenti in un pomeriggio.

Il 99% della popolazione che non sapeva programmare sta entrando nel gioco.

E per chi come me ha costruito la propria carriera su competenze tecniche, questa non è una notizia che si può ignorare.

Cosa perde valore

Devo essere onesto adesso, perché questa parte sarà scomoda.

Se costruire software diventa accessibile a tutti, il valore di “saper costruire software” scende. Si tratta di matematica, non è opinione. Quando una competenza si diffonde, il suo prezzo di mercato cala.

Non sto dicendo che i developer spariranno domani. Sto dicendo che un certo tipo di developer è a rischio.

Il developer che “posa mattoni”. Quello che riceve le specifiche, le implementa e consegna. Quello che è fortissimo nell’esecuzione, ma non si chiede (quasi) mai se quello che sta costruendo ha senso.

Il mio cliente aveva esattamente questo problema. Un developer eccellente dal punto di vista tecnico. Ma nessuno nel team stava rispondendo alla domanda fondamentale: stiamo costruendo la cosa giusta?

Quattro mesi di architettura impeccabile su un prodotto che non aveva ancora trovato il suo mercato. Il come era perfetto. Il cosa e il perché erano completamente fuori fuoco.

E non è un caso isolato, lo vedo continuamente nel mio lavoro. Startup che bruciano mesi e budget su feature che nessuno ha chiesto. Team tecnici che costruiscono soluzioni eleganti a problemi che non esistono. Developer che ottimizzano performance su prodotti che non hanno ancora un utente pagante.

Quando l’esecuzione tecnica era il collo di bottiglia, aveva senso investire tutto lì. Ma se un founder può ricostruire il tuo lavoro di quattro mesi in quattro giorni con un AI builder, il collo di bottiglia si è spostato.

E si è spostato dal “chi sa costruire” a “chi sa cosa costruire” secondo me.

Cosa guadagna valore

Se il codice diventa una commodity, cosa resta?

Resta tutto quello che l’AI non sa fare. E la lista è più lunga di quanto pensi.

Capire il problema vero.

Come ho scritto nella newsletter su WinMX: il vero problema non è mai quello ovvio.

Il cliente che vuole “un sito più veloce” in realtà vuole meno ansia nel processo di checkout.

La startup che cerca “più features” in realtà ha bisogno di capire chi sia il suo utente.

Il founder che chiede “più investimenti” in realtà deve sistemare il product-market-fit.

Lovable può costruirti un’app in un pomeriggio. Ma non può dirti se quell’app risolve un problema reale. Non puo sedersi davanti a un utente e capire che il vero blocco non è tecnologico, ma emotivo.

Non può leggere tra le righe di un feedback e intuire dove sta la vera opportunità.

Sapere cosa NON costruire.

Questa è la skill più sottovalutata in assoluto. Ogni feature che non aggiungi è una feature che non può rompersi, che non va mantenuta, che non complica l’esperienza. Ogni progetto che non inizi è tempo risparmiato per quello che conta davvero.

Il mio cliente ha dovuto buttare via quattro mesi di lavoro perché nessuno aveva avuto il coraggio di dire “fermiamoci, stiamo costruendo troppo”. Avevano automatizzato cose che non serviva automatizzare. Avevano generalizzato quando dovevano specializzare. Avevano costruito per scalare quando dovevano costruire per validare.

La decisione più importante che hanno preso? Smettere di automatizzare.

Mettere una facciata che parla di AI, ma dietro fare il lavoro a mano. Validare prima, automatizzare dopo e concentrarsi su un’unica industry invece di inseguire tutti.

Sembra un passo indietro. È il passo avanti più intelligente che potessero fare.

Tradurre tra due mondi.

Ne ho parlato nella newsletter su come comunico ai non-techy del business: la comunicazione è LA competenza. Puoi avere la soluzione tecnica migliore del mondo, ma se non sai spiegare perché conta al CEO, al commerciale, all’investitore, il tuo impatto resta confinato alla tua tastiera.

Con il vibe coding, questa competenza diventa ancora più critica. Perché ora hai più persone non tecniche che costruiscono cose tecniche, e qualcuno deve fare da ponte. Qualcuno deve dire “questa soluzione funziona oggi ma non scalera tra sei mesi”.

Qualcuno deve tradurre “abbiamo un problema di performance” in “stiamo perdendo il 20% dei clienti al checkout”.

Il gusto di prodotto.

Saper guardare qualcosa e sentire se funziona o no. Non con una metrica, non con un A/B test, ma con quell’intuizione che viene da anni di esperienza nel costruire cose e osservare come le persone le usano.

L’AI può generare dieci versioni di un’interfaccia, ma non sa quale delle dieci farà sentire l’utente a casa.

La riflessione che dovresti fare

Per costruire Lovable, che promette di rendere inutile saper programmare, servono i migliori ingegneri al mondo.

Cento persone che generano 2 milioni di dollari in ricavi ciascuna. Non stiamo parlando di persone qualsiasi, ma tra i migliori cervelli nel mondo dell’AI e dell’ingegneria del software sul pianeta.

Per rendere “inutile” programmare serve concentrare più talento di programmazione in un unico posto di quanto la maggior parte delle aziende tech abbia mai fatto.

Il valore non scompare: si sposta.

Si sposta da “saper scrivere codice” a “saper pensare a cosa il codice deve fare”. Da “eseguire” a “decidere”. Da “costruire” a “orchestrare”.

Il programmatore del futuro non è un muratore che posa mattoni, è un direttore d’orchestra. Sa benissimo quali strumenti usare, quando farli entrare e come farli suonare assieme. Ma, soprattutto, sa riconoscere quando la musica non funziona anche se ogni singolo strumento sta suonando le note giuste.

Il cerchio si chiude

Torniamo al mio cliente e al suo MVP ricostruito in quattro giorni.

Non ha eliminato il bisogno di competenza tecnica, ha eliminato il collo di bottiglia.

Prima: un developer da 40.000 dollari che costruiva l’architettura perfetta per un prodotto non validato.

Dopo: il founder che parla con gli utenti, torna alla scrivania, e modifica il prodotto in tempo reale. Nessun intermediario. Nessun ticket. Nessuna call di allineamento.

Non è che il developer servisse di meno, ma serviva dopo. Prima ci voleva qualcuno che capisse cosa costruire e cosa no, applicando quella competenza che nessun AI builder può replicare.

Guardando la mia carriera, mi rendo conto che il mio valore non è mai stato nel codice che sapevo scrivere, ma è stato nelle domande che sapevo fare. “Ma il vero problema qui qual è?” “Siamo sicuri che questa feature serva?” “Cosa succede se non costruiamo niente e testiamo prima a mano?”

Il codice sta diventando una commodity. La visione no.

E forse, paradossalmente, proprio nel momento in cui tutti possono programmare, chi sa davvero cosa vale la pena costruire diventa più prezioso che mai.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Devo essere onesto: la prima volta che mi hanno mostrato ChatGPT non ci credevo neanche io.

E non perché fossi uno di quelli scettici stile “ah sì, l’intelligenza artificiale, una roba da film”, anzi. Nel 2015-16 lavoravo in una startup di Milano che si chiamava iGenius (oggi Domyn), che faceva proprio quello: intelligenza artificiale. Quindi c’ero dentro, la vedevo tutti i giorni.

E per questo ero scettico.

Sapevo quanto fosse complicato far funzionare quella roba bene. Sapevo quanta distanza c’era tra la demo figa e il prodotto vero. Sapevo che tra “sembra intelligente” e “è davvero utile” c’era un canyon.

Poi, a fine 2022, uno dei miei migliori amici mi dice: “Fra, prova questa cosa nuova. ChatGPT.”

Lo apro. Gli do un pezzo di codice, gli descrivo cosa mi serve.

In 30 secondi mi restituisce qualcosa di funzionante.

Non perfetto, eh. C’erano un paio di cose da sistemare. Ma la struttura era lì, la logica era giusta. E io che avevo visto la materia da vicino, che sapevo quanto fosse stato difficile arrivare anche solo a risultati mediocri pochi anni prima, sono rimasto incantato.

Però allo stesso tempo pensavo: “Vabbè, carino come giochino.”

Avere un background in quel mondo mi ha reso più difficile accettare il salto che era stato fatto. Ero così abituato ai limiti della tecnologia che non riuscivo a credere che quei limiti fossero stati superati davvero.

L’ho usato un paio di altre volte quella settimana, per cose piccole: riscrivermi una mail, farmi suggerire un nome per una variabile, roba così. Poi l’ho chiuso e sono tornato a lavorare come sempre.

Il vero cambiamento non è stato immediato. È stato lento, progressivo, e soprattutto non me ne sono accorto finché non mi sono girato indietro.

Quando ho capito che non era un giocattolo

Il momento “click” è arrivato qualche mese dopo, su un progetto reale.

Dovevo fare una due diligence tecnica per un cliente. Analizzare il codebase, capire lo stato dell’architettura, identificare i debiti tecnici, scrivere un report con raccomandazioni.

Di solito questo processo mi prendeva una settimana piena: leggere il codice, prendere appunti, strutturare il documento e infine revisionare.

Quella volta ho provato qualcosa di diverso. Ho iniziato a usare l’AI come sparring partner: gli passavo pezzi di codice e gli chiedevo di analizzarli, gli descrivevo l’architettura e gli chiedevo di trovare i punti deboli, gli facevo generare la prima bozza del report partendo dai miei appunti.

Ho finito in tre giorni. Non in una settimana eh, in. tre. giorni.

Non è che il report fosse peggiore, tra l’altro. Anzi, era uguale e forse in alcune parti anche più strutturato, perché l’AI mi aveva costretto ad essere più preciso nel descrivere i miei problemi.

In quel momento ho capito che non stavo usando un giocattolo. Stavo usando un collaboratore. Uno strano, che non dorme, non si lamenta e ogni tanto dice caz*ate con una sicurezza disarmante, ma un collaboratore.

Pure Karpathy, co-founder di OpenAI, a ottobre definiva i coding agent “slop”. Due mesi dopo ha scritto di non essersi mai sentito così indietro come programmatore. Se anche lui ha fatto quel percorso, vuol dire che è normale partire scettici.

La differenza la fa cosa fai dopo.

Il ribaltamento

Nella mia newsletter di fine anno ho scritto che l’AI è diventata il mio collaboratore silenzioso. Ma non avevo raccontato cosa significa concretamente.

Te lo dico adesso.

Un anno fa il mio lavoro era diviso così: 80% fare, 20% pensare. Scrivevo specifiche, facevo review, preparavo documentazione, costruivo prototipi. Il tempo per ragionare sulla strategia era quello che avanzava, se avanzava.

Oggi si è ribaltato. Passo l’80% del tempo a pensare e il 20% a fare.

Non perché lavoro meno, ma perché il “fare” è diventato più veloce.

Faccio un esempio concreto. Prima, quando un founder mi chiedeva “Ha senso questa architettura?”, io dovevo: analizzare il codice, disegnare un’alternativa, scrivere un documento con pro e contro, preparare una presentazione. Ci volevano giorni.

Oggi scrivo specifiche dettagliate, le passo all’AI, ottengo una prima bozza in un’ora, la revisiono come farei con un junior, correggo le cose che non tornano e consegno. Il tempo che risparmio lo investo in quello che conta davvero: capire se quel founder sta costruendo la cosa giusta, non solo se la sta costruendo bene.

Questo cambiamento non è solo mio. DHH, il creatore di Ruby on Rails, quest’estate diceva a Lex Fridman che non avrebbe mai lasciato scrivere codice all’AI. Oggi ammette che quella resistenza non era ideologica, i modelli semplicemente non erano ancora pronti. Il CTO di Vercel durante le vacanze ha costruito due progetti open source e ha raccontato che Claude si comporta come un senior engineer: gli dici cosa fare e lo fa.

Il punto non è se l’AI cambierà il nostro lavoro perché l’ha già cambiato.

La vera domanda è se te ne sei accorto.

Il dilemma che nessuno racconta

Questa è la parte che mi ha fatto riflettere di più, ma non vedo mai raccontarla da nessuno. Faccio il Fractional CTO e una parte importante del mio lavoro è aiutare i founder a costruire team tecnici: decidere chi assumere, quando e per fare cosa.

A un certo punto, qualche mese fa, stavo per consigliare a un cliente di assumere uno sviluppatore junior per gestire una serie di task operativi: integrazioni, fix minori, documentazione tecnica.

Poi mi sono fermato.

Mi sono chiesto: “Ma prima di spendere 35-40 mila euro l’anno per questa persona, ha senso capire quanto di questo lavoro possiamo efficientare con gli strumenti che abbiamo?”

Ho fatto un test. Per due settimane ho provato a gestire quei task con l’AI, affiancata da me come developer senior.

Risultato: il 60-70% di quel lavoro si faceva in metà del tempo. Non tutto, ma abbastanza da ripensare completamente la priorità di quell’assunzione.

Attenzione: non sto dicendo che gli umani non servono. Sarebbe una minchiata.

Sto dicendo che prima di assumere, oggi, c’è un passaggio in più che non esisteva due anni fa: capire dove gli strumenti possono efficientare e dove serve davvero il capitale umano.

Perché se assumi una persona per fare cose che un tool fa meglio e più velocemente, stai bruciando soldi. Ma se assumi una persona per fare cose che richiedono giudizio, relazione, contesto, creatività, stai facendo l’investimento giusto.

Il problema è che la linea tra le due cose si sta spostando. Velocemente. E se non la tieni d’occhio, rischi di trovarti con un team costruito per un mondo che non esiste più.

Ne ho parlato anche quando ho scritto delle nostre cicatrici digitali: costruiamo partendo dalle nostre esperienze passate, e quelle esperienze possono diventare i nostri limiti. Anche nel modo in cui pensiamo ai team.

Il lato oscuro della forza

Nella newsletter di fine anno ho scritto una frase che mi è rimasta in testa: “Quello che mi preoccupa per il 2026 è non sapere come evolverà l’intelligenza artificiale. Non quanto velocemente cambierà le cose, ma quanto tempo avrò per adattarmi.”

Ci penso spesso.

Non so se il modello Fractional CTO esisterà nella stessa forma tra tre anni. Non so se le competenze che oggi mi rendono utile saranno le stesse che serviranno domani. Non so se sto imparando abbastanza velocemente.

Quello che so è che chi si ferma è fottuto.

Quando ho scritto di WinRAR, la lezione era che a volte la cosa più intelligente è non cambiare. Restare fermi, fare bene una cosa sola, lasciare che il tempo costruisca fiducia. Quando ho scritto di Craigslist, il messaggio era lo stesso: non tutta l’innovazione è necessaria.

Ma qui è diverso.

WinRAR poteva permettersi di non cambiare perché il suo prodotto era già “commoditizzato”. Comprimi un file, decomprimi un file. Fine. Il lavoro di un CTO non è una commodity, almeno non ancora, ma gli strumenti che usa stanno cambiando sotto i piedi. E se non ti muovi con loro, il terreno ti frana sotto.

Non è panico. È consapevolezza.

Come ho scritto quando ho raccontato come resto aggiornato: ho imparato che “essere aggiornati” e “essere preparati” sono due cose diverse. Essere aggiornati significa sapere cosa succede. Essere preparati significa saper agire quando serve.

Con l’AI, non basta sapere che esiste. Devi sapere come ragiona, dove fallisce, come dargli il contesto giusto. E devi farlo ogni giorno, perché quello che funzionava il mese scorso potrebbe non funzionare più oggi.

Cosa sto facendo concretamente

Niente proclami, niente “i 5 step per usare l’AI”. Solo quello che faccio io, che funziona per me.

Scrivo specifiche più dettagliate di prima. Prima di far partire qualsiasi cosa, scrivo esattamente cosa voglio, come lo voglio, quali sono i vincoli. Più il contesto è preciso, migliore è l’output. È come dare un brief a un freelancer: se gli dici “fammi un sito”, ti torna qualcosa di random. Se gli dici esattamente cosa serve, perché e per chi, il risultato cambia completamente.

Faccio review come se stessi seguendo un junior. L’AI produce codice, documentazione, analisi. Ma non mi fido ciecamente. Revisiono tutto, cerco gli errori, verifico la logica. Il pensiero critico sull’output è la competenza più importante che ho sviluppato.

Uso l’AI come sparring partner per le decisioni. Prima di proporre un’architettura a un cliente, la discuto con l’AI. Non perché abbia ragione, ma perché mi costringe a spiegare il mio ragionamento. E quando devi spiegare qualcosa, trovi i buchi (tipo rubber duck programming)

Ho costruito i miei stessi tool con l’AI. Il sito, la dashboard analytics, le automazioni. Non per risparmiare soldi, ma perché avere strumenti costruiti sulle mie esigenze mi rende più efficace.

E soprattutto, ho smesso di avere paura di non sapere tutto. Come ho scritto nella newsletter sullo studio: non memorizzo più nozioni, ma affino la capacità di trovarle quando servono. Con l’AI questo è ancora più vero.

Il mio mestiere sta cambiando

Non so dove saremo tra due anni. Non so se scriverò ancora codice o se il mio lavoro sarà al 100% strategia, visione e traduzione tra tech e business. Non so se i team saranno più piccoli o semplicemente diversi.

Quello che so è che il mio mestiere sta cambiando. E io ho scelto di cambiare con lui.

Non per hype e non perché “lo fanno tutti”. Ma perché quando uno strumento ti permette di fare in tre giorni quello che prima ti prendeva una settimana, non puoi far finta di niente.

La domanda che lascio a te è semplice: nel tuo lavoro, quanto tempo passi a fare cose che uno strumento potrebbe fare per te? E quel tempo che libereresti, su cosa lo investiresti?

Rispondi a questa mail, sono curioso di sapere come stai vivendo questo cambiamento.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Ero solo un ragazzino quando ho iniziato a giocare online (vabbè, a dire la verità io e l’online siamo nati quasi assieme).

Adoravo la sensazione di accendere il PC, aprire TeamSpeak e sentire le voci dei miei amici che mi aspettavano.

“Ooooh, ma ti muovi?! Sei pronto??” ”A te stiamo aspettando, sbrigati!!” Se hai vissuto quell’epoca, sai di cosa parlo. Condividere quei momenti, ridere delle cazzate mentre qualcuno moriva in modo stupido o insultarsi dopo un errore clamoroso faceva parte di un rituale.

TeamSpeak comunque non era per tutti: dovevi trovare un server, configurarlo a parte e poi sperare pure che l’audio non gracchiasse troppo. Ma bastava per quel periodo (anche perché la connessione era quel che era). Poi, a un certo punto, qualcuno ha mandato un link nel gruppo.

”Raga proviamo questo?”

Non ricordo chi fosse e nemmeno il giorno esatto, ma ricordo la sensazione.

Discord non era solo “parlare mentre giochi”, era qualcosa di diverso. C’erano i canali, c’erano i ruoli, c’era una struttura. Non era solo più una chiamata vocale con gli amici, era un posto dove accadevano cose.

Due tool, due filosofie completamente diverse.

E sai qual è la cosa assurda? Discord non doveva nemmeno esistere.

Il problema che nessuno risolveva (bene)

Nel 2015, se volevi parlare con gli amici mentre giocavi, le opzioni erano queste:

Skype dominava la comunicazione casual, ma non era pensato per il gaming. Pesante, mangiava un botto di risorse e crashava durante le partite. A quei tempi non me ne fregava ovviamente ma ho scoperto che esponeva il tuo indirizzo IP. I ragazzini più stronzi potevano farti un attacco DDoS e buttarti offline nel bel mezzo di un raid su WoW.

TeamSpeak era tecnicamente eccellente. Latenza bassissima, audio pulito. Ma richiedeva di affittare o mantenere un server. Setup complesso, port forwarding, configurazioni che il gamer casual non avrebbe mai fatto.

Entrambi funzionavano “abbastanza bene”.

Ma “abbastanza bene” non è mai abbastanza quando qualcuno arriva con qualcosa che funziona davvero.

Il videogioco non è andato

Jason Citron nel 2012 aveva già fatto i soldi.

Tre anni prima aveva venduto OpenFeint, una piattaforma social per giochi mobile, a FREE per 104 milioni di dollari.

Aveva solo 26 anni (beato lui), avrebbe pure potuto ritirarsi, ma invece fece quello che fanno i veri builder: ricominciò da capo.

Fondò Hammer & Chisel con un’ambizione precisa: creare il primo MOBA serio per tablet.

Lo chiamò Fates Forever, un League of Legends ma per iPad.

Era fatto bene, i critici lo lodarono, Apple gli diede anche l’Editor’s Choice.

Ma, c’è un ma: nessuno lo giocava.

Il mercato era troppo limitato (solo ai possessori di iPad), la competizione feroce e la retention pessima lo schiacciarono, oltretutto Vainglory era appena uscito. Citron e il suo team avevano costruito qualcosa di tecnicamente eccellente per carità, ma non interessava a nessuno.

Non so, ti suona familiare?

La feature che nessuno aveva chiesto

Dentro Fates Forever il team aveva costruito una chat vocale per permettere ai giocatori di coordinarsi durante le partite.

Era una feature secondaria. Infrastruttura. Roba che doveva funzionare e basta.

Solo che funzionava davvero tanto bene, talmente tanto bene che la gente iniziò a usarla parlare invece che per giocare.

Citron se ne accorse. Gli utenti erano più interessati a connettersi tra loro, a formare amicizie, a stare insieme, che a eseguire la meccanica del gioco.

Il gioco stava fallendo.

Ma quella chat no.

Il pivot che non ti aspetti

Ci sono due modi di raccontare un pivot.

Il primo è quello glorificato: “Fail fast, pivot, succeed.” Sembra facile, quasi figo.

Il secondo è quello vero. Ed è quello che Citron racconta:

“Pivoting feels like fucking up, honestly. La gente ne parla in modo glorificato, come se fallire velocemente e poi pivotare fosse normale. La realtà è che è emotivamente devastante. Hai appena speso mesi a versare il tuo cuore in qualcosa e non sta funzionando. E poi devi realizzarlo e ripensare tutto.”

Citron quindi prese la decisione più difficile.

Decise di uccidere Fates Forever riducendo il team da 18 persone a un manipolo di ingegneri. E puntò tutto sulla chat vocale che nessuno gli aveva chiesto di costruire.

Uno dei suoi ingegneri si dimise il giorno dopo, via post-it.

Metà del team pensava fosse la decisione più stupida di sempre. “TeamSpeak funziona benissimo, questo non funzionerà mai.”

Nel maggio 2015 lanciò Discord.

Venti utenti e il dubbio di mollare tutto

Discord uscì… e non successe niente. Per settimane e settimane praticamente non lo usò nessuno. Venti persone al giorno massimo, amici obbligati a testarlo. Il team allora provò il marketing tradizionale. Niente. Cercò influencer. Ancora poco e niente.

Citron considerò di arrendersi. Ma poi decidero di fare qualcosa di completamente diverso. Un amico condivise un post su un subreddit di Final Fantasy XIV. Non era un pitch, né una pubblicità, ma una domanda genuina:

“Ehi, stiamo costruendo uno strumento di comunicazione. Credi che possa risolvere un problema per te?”

Il tono non era da vendita, ma da curiosità.

Il post generò cinquanta utenti il primo giorno, cento il secondo. Poi il numero iniziò a crescere. Il team replicò: World of Warcraft, Diablo, StarCraft. Ovunque tutti i gamer si riunissero, loro andavano lì. E non per vendere, ma per ascoltare.

Otto mesi dopo: 3 milioni di utenti.

Un anno dopo: 25 milioni.

Perché funzionava (la versione semplice)

Discord non era tecnicamente superiore a tutto.

TeamSpeak aveva latenza più bassa. Skype aveva più utenti.

Ma Discord aveva trovato il compromesso perfetto:

Server centralizzati invece di peer-to-peer. Cerco di non usare troppo serpentese, promesso. In pratica il tuo IP resta nascosto. Niente più burloni che ti buttano offline perché li hai battuti (forse io ero uno di quelli…)

Latenza ottimizzata per il parlato. 50-100 millisecondi sono impercettibili per la voce umana. Non serviva la perfezione tecnica di TeamSpeak, serviva “abbastanza buono” a scala.

Onboarding in un click. Ricevi un link, clicchi, metti un username, sei dentro. Per un gamer tra una partita e l’altra, con 40 secondi di countdown, questa semplicità non era un nice-to-have. Era tutto.

Il vantaggio tecnico non era la tecnologia in sé. Era aver capito esattamente cosa serviva al target e aver costruito solo quello.

Va che numeri adesso

Oggi Discord ha:

• 200+ milioni di utenti attivi mensili

• 15 miliardi di valutazione

• 725 milioni di dollari di fatturato annuo

• 4 miliardi di minuti di conversazione vocale ogni giorno

Tutto partito da una feature secondaria di un gioco che nessuno voleva giocare.

Un’offerta che (non) puoi rifiutare

Nel 2021 Microsoft bussò alla porta e presentò un’offerta: 12 miliardi di dollari per acquisire Discord.

Per dare un contesto: Microsoft aveva comprato Skype per 8.5 miliardi. Stava offrendo il 40% in più per un’azienda che fatturava una frazione.

Discord disse no.

“Abbiamo deliberatamente perseguito un modello di business che non dipende dalla monetizzazione dei dati dei nostri utenti,” spiegò il co-fondatore Stan Vishnevskiy.

Volevano l’IPO. Credevano che Discord potesse diventare più grande da indipendente di quanto sarebbe mai diventato dentro Microsoft.

È facile dire “segui la tua visione” quando non hai 12 miliardi sul tavolo.

È molto più difficile farlo quando ce li hai davvero.

Non è la prima volta che lo vediamo

E qui la storia diventa ancora più interessante.

Perché Discord non è l’unico caso.

Slack nacque da Glitch, un gioco multiplayer online che fallì dopo 4 anni di sviluppo e 17.5 milioni investiti. Il sistema di chat interna che il team usava per coordinarsi divenne il prodotto. Salesforce lo comprò per 27.7 miliardi.

Instagram nacque da Burbn, un’app di check-in che nessuno usava. Kevin Systrom notò che gli utenti erano interessati solo alla feature di condivisione foto. Tolse tutto il resto. Facebook la comprò per 1 miliardo, con 13 dipendenti.

Twitter nacque da Odeo, una piattaforma di podcasting resa obsoleta quando Apple annunciò che iTunes avrebbe supportato i podcast nativamente. Durante un hackathon interno, Jack Dorsey propose l’idea degli “status update”. Il resto è storia.

Quattro aziende. Quattro prodotti falliti. Quattro pivot su feature secondarie.

Decine di miliardi di valore creato.

Il pattern è chiaro: il vero prodotto era nascosto dentro quello sbagliato.

L’arte di riconoscere cosa stai davvero costruendo

La lezione di Discord non è “fallisci veloce e poi pivota”.

È qualcosa di più sottile e più difficile.

È avere l’umiltà di vedere che gli utenti stanno usando il tuo prodotto in modo diverso da come l’avevi pensato.

Citron voleva costruire un gioco, gli utenti volevano parlare tra loro.

Systrom voleva costruire un’app di check-in. Gli utenti volevano condividere foto.

Butterfield voleva costruire un mondo virtuale. Il suo team voleva una chat migliore.

In tutti i casi, il founder aveva una visione. E in tutti i casi, la realtà gli ha mostrato qualcosa di diverso.

La differenza tra chi crea miliardi e chi fallisce non è l’idea iniziale. È la capacità di vedere cosa sta realmente succedendo e il coraggio di seguirlo.

Non è facile.

Significa ammettere che avevi torto. Significa uccidere il progetto in cui hai versato anni della tua vita. Significa guardare in faccia il tuo team e dire: “Cambiamo tutto.”

Ma a volte, dentro il prodotto sbagliato, c’è quello giusto che aspetta di essere riconosciuto.

La domanda che ti lascio

Se stai costruendo qualcosa, fermati un secondo.

Guarda come le persone lo usano davvero. Non come vorresti che lo usassero. Come lo usano.

C’è una feature che genera più engagement del previsto? C’è un comportamento che non avevi anticipato? C’è qualcosa che i tuoi utenti fanno che ti sorprende?

Forse quella è la risposta.

La prossima volta che guardi i dati del tuo prodotto, chiediti:

“Quale feature del mio prodotto è segretamente il vero prodotto?”

Dopotutto… potrebbe valere 15 miliardi.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Da quando ho iniziato a costruire prodotti ho iniziato anche a studiare e ad osservare come li facevano gli altri.

Aprivo app di aziende con budget enormi, team di centinaia di sviluppatori e risorse praticamente infinite. Spesso, quello che vedevo, era uno schivo. Pensavo: “ma com’è possibile che siano così tremendi con tutti quei soldi investiti?”

Poi mi capita di vedere prodotti di startup che con due lire e team di cinque persone mettono in piedi un prodotto di qualità. E non è un caso isolato.

Ho iniziato a osservare con più attenzione e a cercare di capire cosa distingue un prodotto fatto bene da uno fatto male. Soprattutto perché ad alcuni escono bene e ad altri male (nonostante i budget differenti).

Sai cosa? La risposta non è così ovvia.

Non è un questione di soldi e nemmeno una questione di competenze tecniche.

È qualcos’altro.

Il problema non è mai uno solo

Quando un prodotto fa schifo, la tentazione è cercare un colpevole: il budget, il team, la tecnologia e il tempo.

Ma la realtà è più complessa… Ci sono diversi fattori che uccidono la qualità e spesso agiscono insieme.

La qualità non è mai una priorità

Hai mai sentito qualcuno entrare in riunione e dire “facciamo un prodotto di merda”?

Direi di no (o almeno spero).

Ma nessuno dice nemmeno “la qualità viene prima di tutto, anche se costa di più, anche se ci vuole più tempo”. La qualità resta sottintesa, data per scontata. E quando arriva la pressione, è la prima cosa che salta. Perché non era mai stata davvero una priorità.

La distanza tra chi decide e chi costruisce

Più un’organizzazione cresce, più si creano passaggi intermedi. Il designer propone qualcosa, il PM lo filtra, il manager lo annacqua per farlo passare e infine lo sviluppatore implementa ciò che resta.

Ogni passaggio crea distanza tra l’idea originale e il risultato finale, ergo il risultato finale non è più di nessuno, è il compromesso tra i compromessi.

Tutti responsabili, nessuno responsabile.

Tutti sono responsabili dell’esperienza utente, nessuno lo è davvero. Le decisioni diventano scollegate. Ogni pezzo del prodotto funziona per conto suo, ma l’insieme non ha senso. Manca qualcuno che guardi il tutto e dica “questa cosa non funziona”.

Metriche sbagliate guidano i risultati sbagliati.

Se il successo si misura in numero di feature rilasciate, otterrai tante feature fatte male. Se misuri la velocity, otterrai velocità senza direzione. Se misuri i ticket chiusi, otterrai ticket chiusi di fretta. I KPI guidano i comportamenti. E se i KPI non includono la qualità, la qualità sparisce.

La paura di dire no.

Ogni stakeholder ha la sua richiesta: il commerciale vuole quella feature in modo da chiudere il cliente, il marketing poi vuole quel banner e il CEO ha visto una cosa dal competitor che vuole implementare.

Nessuno ha il coraggio o l’autorità di dire di no, quindi il prodotto diventa un accumulo che somiglia più ad un albero di Natale dove ognuno ha appeso una sua pallina. E alla fine non si capisce più cosa dovrebbe essere o cosa dovrebbe fare.

L’urgenza sovrasta la cura.

L’urgenza di rilasciare sovrasta la cura per quello che rilasci. Prima lo facciamo funzionare, poi lo miglioriamo. Ma il “poi” non arriva mai, perché c’è sempre qualcos’altro di urgente.

Le scorciatoie si accumulano.

Ogni scorciatoia sembra innocua nel momento in cui la prendi, “tanto lo sistemiamo dopo”, “per ora va bene così”, “è un workaround temporaneo”.

Tutte frasi che portano a scorciatoie, scorciatoie che si sommano, che diventano debito tecnico, e che rende ogni miglioramento più costoso, più rischioso. E arrivi al punto in cui migliorare diventa più difficile che rifare. Ma indovina? rifare non si può, quindi si rattoppa, e il rattoppo genera altro debito.

Questi fattori non si escludono a vicenda. Si sommano. Si amplificano. E il risultato è quel comportamento che è alla luce del sole: aziende con risorse enormi che producono esperienze mediocri.

Le startup hanno un vantaggio, ma non è scontato

Team piccolissimi, decisioni veloci. Chi decide è spesso chi costruisce, non ci sono dieci layer tra visione ed esecuzione.

Ma questo non significa che le startup facciano qualità di default.

Significa solo che hanno meno ostacoli strutturali. Meno burocrazia da attraversare. Meno compromessi obbligati.

Ma la qualità resta una scelta: un investimento consapevole, e anche una startup con tre persone può fare un prodotto di merda se non ci investe, se non la mette come priorità, se cede alla tentazione di “fare veloce” invece che “fare bene”.

Il vantaggio delle startup non è che fanno qualità per natura. È che possono scegliere di farla senza dover prima smontare una struttura che la impedisce.

E questa scelta, secondo me, non è mai un errore.

Cosa significa qualità per me

Quando prendo in mano un prodotto per la prima volta, la mia testa fa automaticamente una checklist (tipo lo scanner).

La prima cosa che guardo è la prima impressione visiva e di interazione. È curato? C’è attenzione ai dettagli? Le cose sono dove me le aspetto? I margini sono consistenti? I colori hanno senso? Sembra che qualcuno ci abbia pensato o sembra buttato lì?

Poi c’è la performance percepita. Non i millisecondi reali, non sto con il cronometro. Parlo di come si sente l’esperienza. Mi sembra veloce o mi sembra di aspettare? Le transizioni sono fluide o a scatti? Quando faccio un’azione, la risposta è immediata o c’è quel micro-ritardo che ti fa dubitare se il click sia andato a buon fine?

Guardo la coerenza. Sembra fatto da un team con una visione condivisa o da quindici team che non si sono mai parlati? I pattern si ripetono o ogni schermata sembra un’app diversa? I bottoni funzionano allo stesso modo ovunque?

Guardo la gestione degli errori (o degli imprevisti). Cosa succede quando qualcosa va storto? C’è un messaggio d’errore che mi spiega cosa è successo e cosa posso fare? O l’app crasha e basta? Gli stati vuoti sono gestiti? Se non ci sono dati, cosa vedo?

E per ultimo ma non per importanza, il copy. Mi parlano come una persona o come un robot dell’ufficio legale? I messaggi sono chiari? Capisco cosa devo fare? O devo interpretare gergo tecnico e frasi contorte?

Queste cose le noti nei primi trenta secondi. E ti dicono già quasi tutto su quanto chi ha costruito quel prodotto ci teneva davvero.

Chi lo fa bene secondo me

Ci sono prodotti che quando li uso penso: qui qualcuno ci ha messo cura. Ti faccio un paio di esempi:

• Pinterest è ossessionato dalla performance percepita, il caricamento infinito non lo senti mai e le immagini appaiono di continuo e progressivamente. Non c’è mai un momento in cui guardi qualcosa e ti chiedi se l’app si è bloccata. Tutto scorre, è una di quelle cose che non noti finché non trovi un’app che non lo fa.

• Claude e ChatGPT hanno reso naturale qualcosa di tecnicamente complesso. Lo streaming della risposta che ti tiene ingaggiato. La sensazione di conversazione. Dietro c’è una complessità enorme, ma tu non la vedi. Vedi solo qualcosa che funziona.

• PostHog è product analytics fatto da gente di prodotto. L’interfaccia non ti fa sentire stupido. La documentazione rispetta la tua intelligenza. È open source ma con una UX da SaaS premium. Ogni volta che lo uso penso: questi capiscono cosa serve a chi lo usa.

• Revolut ha fatto sembrare le banche tradizionali dei dinosauri. Ogni interazione è fluida. Le notifiche sono utili (non spam). Il cambio valuta in tempo reale sembra magia. Hanno preso un’industria ingessata e hanno dimostrato che si poteva fare diversamente.

Nessuna di queste aziende aveva budget illimitati all’inizio eppure hanno scelto la qualità come differenziatore. E hanno continuato a sceglierla anche quando potevano permettersi di non farlo.

Metà budget, doppia soddisfazione

Ho avuto un’esperienza diretta su questo tema poco tempo fa.

Un cliente mi ha chiesto di rifare un SaaS che aveva fatto sviluppare da altri. Il budget che avevano speso la prima volta era più del doppio di quello che avevo io a disposizione. Team più grande, più tempo, più risorse.

Il risultato? Un prodotto che non funzionava. Lento. Incoerente. Pieno di bug. E la home page, giuro che non sto esagerando, aveva un’immagine di sfondo. Un SaaS B2B. Con un’immagine di sfondo sulla home. Come fosse un sito vetrina del 2008.

L’abbiamo rifatto con metà del budget. Il cliente era molto più contento.

Non perché siamo più bravi. Non perché abbiamo qualche tecnologia segreta. Ma perché le priorità erano diverse. L’ownership era chiara. Chi decideva era vicino a chi costruiva. Non c’erano dieci passaggi tra “questa cosa dovrebbe funzionare così” e “ok, facciamola funzionare così”.

La differenza non erano i soldi. Era come quei soldi venivano spesi.

Come costruisco qualità (e come la proteggo)

Negli anni ho sviluppato un approccio che ha due parti. La prima è come costruisco qualità. La seconda è come evito di perderla quando le cose crescono.

Come costruisco.

Parto sempre dall’esperienza utente, non dalle feature. La domanda non è “cosa deve fare questo prodotto” ma “cosa deve provare chi lo usa”. È una differenza sottile eh, ma cambia tutto.

Non negozio mai sulle basi. Performance, gestione errori, coerenza visiva. Queste cose non sono optional, non sono “nice to have”, non sono “le facciamo nella prossima release”. Sono il minimo. Se non ci sono, il prodotto non è finito.

Faccio scelte esplicite su cosa non fare. Ogni feature che non aggiungi è una feature che non può rompersi, che non richiede manutenzione, che non complica l’esperienza. Dire no è parte del lavoro.

Testo con persone vere il prima possibile. Non per validare che funziona tecnicamente, ma per vedere dove si inceppano, cosa non capiscono, dove perdono tempo.

Come la proteggo.

Questa è la parte più difficile. Perché la qualità tende a degradare naturalmente quando le cose crescono. Più persone, più comunicazione, più compromessi.

La chiave è l’ownership chiara. Ogni pezzo del prodotto deve avere un responsabile. Non un team. Una persona. Qualcuno che si sveglia la mattina pensando “questa cosa è mia, e deve funzionare bene”.

Team piccoli con responsabilità end-to-end funzionano meglio di team grandi con responsabilità frammentate. Meglio tre persone che fanno tutto che dieci persone dove ognuno fa un pezzetto e nessuno vede l’insieme.

Chi decide deve sporcarsi le mani. Il momento in cui chi prende le decisioni smette di usare il prodotto, di vedere il codice, di parlare con gli utenti, è il momento in cui la qualità inizia a scendere.

Meno layer significa meno diluzione e ogni passaggio tra la visione e l’esecuzione è un’opportunità per perdere qualcosa. Riduci i passaggi.

Serve il coraggio di dire di no: dire di no a feature che non servono, a stakeholder che vogliono aggiungere cose, a scorciatoie che creano debito. Siamo d’accordo, dire di no è scomodo, ma spesso è anche l’unico modo per proteggere ciò che conta.

La qualità non si mantiene per caso. Si mantiene con strutture che la proteggono attivamente.

Oggi abbiamo un nuovo alleato

L’intelligenza artificiale sta liberando tempo. Attività che prima richiedevano ore ora ne richiedono minuti. Codice che prima scrivevi riga per riga ora lo generi e lo raffini. Documentazione, test, debug, tutto sta accelerando.

La domanda è: quel tempo dove lo mettiamo?

Possiamo usarlo per fare di più. Più feature, più prodotti, più clienti, più tutto.

Oppure possiamo usarlo per fare meglio: più cura, più attenzione, più qualità.

Investire sulla qualità non è mai stato così accessibile perché abbiamo gli strumenti che ci permettono di dedicare più tempo alle cose che contano: l’esperienza e i dettagli (quelli importanti).

La scelta è nostra.

E la prossima volta che apri un’app che fa schifo, chiediti: stanno facendo schifo perché non sanno fare meglio, o perché hanno scelto di non investire sulla qualità?

Perché alla fine, è sempre una scelta.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Diciamoci la verità, ogni volta che apri Jira non sei contento. L’ultima volta che l’ho utilizzato mi son trovato a dover passare diverso tempo nel configurarlo e nel renderlo “fit” per il caso d’uso.

Apro Jira, creo il progetto e via al delirio.

Quale template vuoi? Scrum o Kanban? Vuoi le epiche? Come vuoi chiamare gli stati? Vuoi i subtask? I componenti? Le versioni? I campi personalizzati?

Sono passati 40 minuti e non ho ancora creato un singolo task.

Mi torna in mente la prima volta che ho aperto Linear, qualche anno fa. Era per un’altra startup, ero quasi un early adopter. Ricordo che cercavo di fare una cosa specifica su Jira, non mi ricordo nemmeno più quale e ci stavo perdendo la testa. Poi qualcuno mi dice “prova Linear”.

Lo apro. Creo il workspace. In 5 minuti sto già lavorando.

Nessuna domanda esistenziale. Nessuna configurazione infinita. Nessun “prima devi settare gli scheme”. Solo un tool che funziona come ti aspetti che funzioni.

In quel momento ho capito una cosa che mi porto dietro ancora oggi: la differenza tra un prodotto costruito per chi lo compra e un prodotto costruito per chi lo usa.

Il cimitero dei task manager

Se c’è un settore dove le startup vanno a morire, è il project management.

Ci sono già Jira, Asana, Monday, Trello, ClickUp, Notion, e altri 3217361 tool che escono ogni settimana su Product Hunt. Il mercato sembra saturo da almeno dieci anni.

Qual è la strategia di tutti questo tool? Aggiungere feature: mille integrazioni, più automazioni, più dashboard e più report.

Linear ha fatto l’opposto: ha tolto.

Niente campi di personalizzazione infiniti, niente workflow builder complessi e mille opzioni di configurazione. Niente “puoi fare tutto quello che vuoi”.

Ti propone un modo di lavorare, quello giusto e pensato su di te.

E mentre tutti cercavano di essere “la piattaforma all-in-one per tutti”, Linear ha scelto di essere lo strumento perfetto per qualcuno.

Ecco che arriva il risultato: un unicorno da 1.25 miliardi di dollari in un mercato che tutti davano per finito.

Va che numeri va…

52 milioni di dollari di fatturato ricorrente ogni anno. Nel 2024 erano in cinquantasette persone. Linear, in un mondo dove le startup bruciano circa il 30-40% in advertising e growth hacking, ha speso solo 35.000 dollari in sei anni.

In. Sei. Anni.

E con questa strategia, mentre tutti bruciavano soldi per crescere, loro cominciavano a generare cassa (profittevoli dal 2021)

Altra cosa incredibile è che churn rate sotto il 5% annuale, una volta che un team entra in Linear, non ne esce più.

E il fatturato per ciascun dipendente? Quasi un milione di dollari a testa, la media SaaS è di 200-300k.

Che dire… complimentoni.

La differenza: costruire per chi usa, non per chi compra

Jira non è costruito per gli sviluppatori, ma per chi lo compra.

Pensaci. Chi decide di adottare Jira in un’azienda? Il management. Il procurement. I team lead che devono “tracciare il lavoro” e “generare report per gli stakeholder”.

È perfetto per loro: dashboard infinite, metriche su ogni cosa, una customizzazione totale perfetta per adattarsi a qualsiasi processo aziendale. In pratica il sogno di chi deve giustificare il budget e fare powerpoint.

Però poi chi lo deve usare ogni giorno, lo vede come un incubo: sviluppatori, design, product manager… insomma, quelli che effettivamente fanno il lavoro pratico.

Una volta lessi un commento su HackerNews che mi fece ridere (ma anche riflettere): “Le aziende scelgono Jira per soddisfare manager e consulenti, non sviluppatori. Il tool diventa il simbolo del ‘fare Agile’ invece di essere agile”.

Linear ha ribaltato questa logica.

Dal loro manifesto, il Linear Method:

“Software project management tools should build with the end users — the creators — in mind. Keeping individuals productive is more important than generating perfect reports.”

Tradotto: fottetevene dei report perfetti e fate lavorare bene le persone.

Karri Saarinen, il CEO, lo dice chiaramente: “La mia filosofia di design è sempre stata che devi progettare qualcosa per qualcuno. È quasi impossibile progettare qualcosa di davvero buono per tutti.”

Linear ha scelto il suo “qualcuno”: i builder. Gli IC. Quelli che scrivono codice, progettano interfacce, costruiscono prodotti.

E ha detto a tutti gli altri: “Non siamo per voi. E va bene così.”

Il paradosso del “No” (e perché la gente ama Linear)

Jori Lallo, co-founder di Linear, disse:

“Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.”

Jira ti dà infinite possibilità di configurazione: campi custom, stati custom, workflow custom, permessi custom… tutto custom. Quella che sembra una feature, però, diventa una trappola.

Però, se ogni team configura Jira a modo suo, dal momento che ogni progetto e ogni persona ha le sue regole e interpretazioni, come gestisci la collaborazione se nessuno sta parlando la stessa lingua?

Quando prendi un mobile da IKEA trovi almeno le istruzioni, non c’è scritto “costruisciti il mobile da solo e auguri”. Anche perché quante volte rimarresti con le viti in mano? (a me capita spesso, ma vabbè) IKEA invece ti dà il libretto, le istruzioni sono precise e se segui i passaggi il risultato è garantito.

Così Linear ha fatto la scelta opposta a Jira: ha deciso che doveva esserci un metodo, un solo modo di fare le cose, uno “giusto”. Forte magari, però hanno ragione loro almeno per ora.

Linear dice sistematicamente no alle feature request. Non perché non possano implementarle. Perché sanno che ogni feature aggiunta è complessità aggiunta. E la complessità uccide la produttività.

E sai qual è il risultato?

I team che usano Linear ne parlano con entusiasmo, quasi come se fosse un culto. “Devi provarlo,” “non posso più tornare indietro,” “è l’unico tool che mi fa venire voglia di gestire i task.”

Vogliamo parlare invece dei team che usano Jira? Quando gli chiedi cosa ne pensano hanno solo una risposta: “fa schifo”.

C’è una metrica che, secondo me, è un vantaggio competitivo ed è sottovalutata, ovvero il piacere quotidiano di usare uno strumento.

Le sensazioni sono importati perché creano fedeltà: per quanto possa, per esempio, una Fiat Punto fare le stesse cose di una Mercedes, la sensazione sarà completamente diversa e inciderà sulla scelta futura di quale macchina usare, o anche sulla voglia che si ha di guidare.

Il feeling crea fedeltà, crea crescita organica senza spendere un euro in marketing.

Il metodo Linear: non vendono un tool, vendono un metodo

Facci caso, loro non vendono un task manager ma vendono un modo di costruire prodotti.

Il tool è solo il veicolo. La vera proposta di valore è il loro metodo, un insieme di principi che hanno codificato e reso pubblici.

Alcuni esempi:

“Write issues, not user stories.” Scrivi task in linguaggio semplice. Niente format rigidi tipo “As a user, I want to...” che nessuno legge davvero, descrivi cosa va fatto, in modo chiaro.

“Build with users.” Non salvare ogni feature request per sempre. Le cose importanti torneranno a galla. Quelle a bassa priorità non verranno mai fatte comunque. Un backlog più snello significa pianificazione più veloce.

“Say no to busy work.” Gli strumenti devono lavorare per te, non il contrario. Se passi più tempo a gestire il tool che a fare il lavoro vero, c’è un problema.

“Generate momentum.” L’obiettivo non è finire lo sprint. È mantenere un ritmo sano e costante. Meglio consegnare poco ma continuamente che strafare e poi crollare.

Linear ha capito che il problema del project management non è tracciare i task. È costruire prodotti.

E per costruire prodotti serve focus, non feature.

La domanda che dovresti farti

È inevitabile, strumenti come questi fanno riflettere chi come me crea prodotti.

Quante volte aggiungiamo feature perché “il competitor ce l’ha”? Quante volte complichiamo l’interfaccia perché “il cliente enterprise lo richiede”? Quante volte costruiamo per chi firma il contratto invece che per chi usa il software ogni giorno?

Linear ha dimostrato che esiste un mercato enorme di persone disposte a pagare di più per avere meno.

Ma quel “meno” deve significare più velocità, più focus, più rispetto per il tempo dell’utente.

La domanda che mi porto a casa è: stai costruendo per chi compra o per chi usa?

Perché nel breve termine, costruire per chi compra ti fa chiudere i contratti. Ma nel lungo termine, costruire per chi usa ti fa tenere i clienti.

Linear non aveva bisogno di un team sales, il prodotto si vendeva da solo e gli utenti diventavano per primi gli ambasciatori.

Però ora chiediti: quante feature del tuo prodotto esistono per impressionare chi firma il contratto, invece di aiutare chi lavora ogni giorno?

La risposta a questa domanda potrebbe valere 52 milioni di dollari.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

L’altro giorno stavo rinnovando il mio sito e volevo aggiungere una seconda lingua e i case study. Per farlo, il buon Webflow, un tool da 182 euro annui, mi chiedeva altri 18 dollari al mese.

In totale 200 euro in più all’anno per qualcosa che, tecnicamente, è solo una cartella di file duplicati con un testo diverso.

Stavo per cedere, alla fine mi serviva, poi arriva una mail:

Allora mi sono chiesto: ma quanto ci metto a farmi il sito da zero con l’AI?

4 ore dopo avevo un sito custom in Astro, hostato gratis su Vercel, con tutte le lingue che volevo e i case study in markdown.

E lì è partita la spirale.

La lista della spesa che non volevo più pagare

Una volta capito che potevo costruirmi il sito, ho iniziato a guardare gli altri abbonamenti con occhi diversi.

Webflow: 362 euro l’anno.

Shield (analytics LinkedIn): 166 euro l’anno per vedere quattro grafici che potevo farmi da solo.

Zapier: 260 euro l’anno per automazioni che n8n fa self-hosted a 10 dollari al mese.

Totale: oltre 788 euro l’anno. Non sono cifre che ti cambiano la vita, sia chiaro, ma sono soldi che pagavo per funzionalità che usavo al 20%.

Il problema non era il prezzo. Era che stavo pagando per software pensati per tutti, quando a me serviva qualcosa di specifico.

4 ore e un sito nuovo

Ho aperto Claude Code, ho descritto quello che volevo e ho iniziato a costruire.

Il sito in Astro è stato il progetto più lineare. Template base, markdown file come CMS e deploy su Vercel. Zero costi di hosting, performance migliori di Webflow, controllo totale sul codice.

Ma la vera soddisfazione è stata Shield.

Shield ti mostra le analytics dei tuoi contenuti LinkedIn: impression, engagement, crescita followers. Tutto utile, ma è lento e poco funzionale.

Lo usavo una volta a settimana per confrontare il periodo passato con quello corrente e per fare ragionamenti sulla settimana successiva. Il problema principale, però, era che non mi permetteva di confrontare velocemente i dati e che l’interfaccia non rispondeva come desideravo.

Quindi mi sono costruito il mio sistema:

1. Un’estensione browser che fa scraping dei miei dati analitici direttamente da LinkedIn

2. Un server locale che salva questi dati

3. Una dashboard che mostra esattamente quello che mi serve

Gira tutto in locale. Niente cloud, niente abbonamenti, niente limiti. E la dashboard fa esattamente quello che voglio io, non quello che ha deciso qualcun altro.

L’ho chiamato Scudo. Ovviamente, direi.

Il fenomeno che sta crescendo

Non sono l’unico a fare questa cosa.

Su Reddit un utente ha documentato come è passato da 1.200 dollari al mese di abbonamenti SaaS a 50 dollari in costi server. Ha sostituito il suo tool di email marketing con AWS SES, ha costruito il suo workspace AI invece di pagare ChatGPT Plus e Claude Pro, ha creato un unico strumento per la creazione contenuti invece di pagare Canva, generatori di immagini ed editor video separati.

Un ragazzo ha raccontato su LinkedIn come ha ricostruito uno dei tool SaaS core della sua azienda in 11 ore durante un weekend. Risparmio annuale: 72.000 dollari. E l’applicazione personalizzata non era solo più economica, ma era anche migliore perché costruita esattamente sulle loro esigenze.

I numeri di mercato confermano il trend. La spesa media SaaS per dipendente è salita a 4.830 dollari nel 2025, in aumento del 22% rispetto all’anno precedente. Ma il 42% delle organizzazioni ha ridotto la spesa SaaS per pressioni di budget. E McKinsey rileva che solo il 25% delle licenze SaaS acquistate viene effettivamente utilizzato in modo consistente.

Stiamo pagando per software che usiamo poco, con feature che non ci servono, a prezzi che aumentano ogni anno.

Quando ha senso costruire (e quando no)

Non tutto va costruito da zero. Io continuo a pagare Notion e Cal.com senza pensarci due volte.

Come decido cosa pagare? Ho un processo che uso anche con i clienti quando devono scegliere se comprare un SaaS o costruire internamente. Si divide in tre parti: prima i criteri bloccanti, poi i numeri, infine i fattori qualitativi che i numeri non catturano.

Parte 1: I criteri bloccanti

Alcune domande hanno risposta binaria. Se la risposta è sì, compra e non pensarci più.

Il tool gestisce pagamenti, dati sanitari o informazioni sensibili? Compra. La sicurezza e la compliance richiedono competenze e aggiornamenti continui che non puoi garantire da solo.

Hai bisogno di integrazioni con altri sistemi che usi quotidianamente? Compra. Ricostruire le API di Notion che si collegano a Slack, Calendar e altri 50 tool richiederebbe mesi.

Il tool è correlato al tuo core business e un’ora di downtime ti costa più dell’abbonamento annuale? Compra.

Se nessuno di questi criteri si applica, vai avanti.

Parte 2: Il calcolo del break-even

Prendi tre numeri:

1. Ore stimate per costruire un MVP funzionante

2. Ore stimate di manutenzione annuale (bug fix, aggiornamenti, piccole modifiche)

3. Il tuo costo orario reale (non quello che fatturi, quello che il tuo tempo vale per te)

La formula: (ore_build + ore_manutenzione_anno1) × costo_orario = costo_costruzione.

Se il costo di costruzione è inferiore a 2 anni di abbonamento, costruire ha senso economico.

Facciamo un esempio concreto con Shield: 4 ore di build + 2 ore stimate di manutenzione primo anno = 6 ore. Se valutiamo il mio tempo 120 euro/ora (è un esempio, fai il bravo/a) fanno 720 euro. Shield costa 166 euro/anno. Break-even in 4.3 anni. Numeri alla mano, non conviene.

Ma i numeri non raccontano tutto.

Parte 3: I fattori qualitativi

Il calcolo del break-even assume che il SaaS e la soluzione custom abbiano lo stesso valore. Spesso non è così.

Shield non mi permetteva di confrontare settimana su settimana.

Ogni volta che aprivo la dashboard perdevo 10 minuti a esportare dati e metterli in un foglio Excel. Sono 40 minuti al mese, 8 ore all’anno. A 120 euro/ora, 960 euro di tempo buttato. Aggiungi questo al calcolo e il break-even scende sotto l’anno.

Poi c’è la frustrazione. Ogni volta che un tool non fa quello che ti serve, perdi concentrazione. Ti arrabbi. Cerchi workaround. Questo costo non compare in nessun foglio Excel, ma esiste.

E infine c’è quello che io chiamo il “costo dell’attesa”: quanto tempo passi a sperare che il SaaS aggiunga quella feature che ti serve? Con Webflow ho aspettato due anni che il multi-lingua diventasse accessibile. Due anni di workaround e compromessi.

La sintesi

Quando valuto se costruire o comprare, seguo questa sequenza:

1. Criteri bloccanti? Se sì, compra.

2. Break-even sotto i 2 anni? Se no, probabilmente compra.

3. Ci sono fattori qualitativi che cambiano l’equazione? Feature mancanti che ti costano tempo ogni settimana? Frustrazione ricorrente? Se sì, riconsidera i numeri.

Cal.com passa tutti e tre i test dalla parte del “compra”: non ho bisogni specifici, il break-even sarebbe lunghissimo, non mi frustra mai.

Shield falliva su tutti e tre: nessun criterio bloccante, break-even accettabile considerando il tempo perso, frustrazione alta.

Costruire si è rivelata la scelta giusta.

Il vero cambiamento

Parliamoci chiaro, l’AI non ha reso obsoleti i SaaS, ma ha stimolato ancora di più il “make vs buy”.

Prima, costruirsi un tool interno richiedeva settimane di sviluppo, competenze specifiche, manutenzione continua. Il costo era quasi sempre superiore all’abbonamento.

Oggi, con con i vari agent, un developer può costruire in ore quello che prima richiedeva giorni. E anche chi non è developer può arrivare a risultati funzionanti per casi d’uso semplici.

Ma attenzione: questo funziona per tool interni e casi d’uso specifici. Il codice generato dall’ AI può essere buggato, insicuro e difficile da scalare. Va bene per una dashboard personale. Non va bene per un sistema di pagamenti ad esempio.

Klarna ha provato a sostituire Salesforce e Workday con soluzioni AI interne. I risultati iniziali sembravano fantastici: 40 milioni di dollari di risparmio annuale, tempi di risoluzione ticket ridotti da 11 a 2 minuti. Poi sono emersi i problemi e il CEO si è dichiarato “tremendamente imbarazzato”, al punto da fare marcia indietro.

L’AI è matura per sostituire tool semplici e specifici. Non è matura per sostituire sistemi enterprise complessi.

Quello che mi porto a casa

Dopo questa esperienza, ho cambiato il modo in cui guardo gli abbonamenti.

Prima rinnovavo tutto in automatico. Ora mi chiedo: questo tool fa qualcosa che non potrei farmi da solo in meno tempo di quanto costa l’abbonamento?

Questa esperienza ha cambiato il mio modo di guardare gli abbonamenti. Se prima rinnovavo tutto in automatico, ora mi domando: questo tool da qualcosa che non potrei farmi da solo e, proporzionalmente, in meno tempo di quanto costa l’abbonamento?

Per Shield, la risposta era no. 4 ore di lavoro per risparmiare 166 euro l’anno e avere un tool migliore. Il break-even è in meno di 1 anno e da lì in poi è tutto guadagno.

Per Notion, la risposta è sì. Costruirmi un’alternativa richiederebbe settimane, e il risultato sarebbe peggiore.

Il punto non è eliminare tutti i SaaS. È smettere di pagare per software che non usi come dovresti, solo perché “si è sempre fatto così”.

Quando un solo developer può costruire in un weekend quello che prima richiedeva un team, l’equazione economica cambia. E chi non se ne accorge continua a pagare per feature che non usa, in tool pensati per tutti tranne che per lui.

Il mio sito nuovo è online. La dashboard analytics funziona. E ho 788 euro in più all’anno da spendere in cose che contano davvero.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Nel momento dell’anno dei vari Spotify Wrapped ho deciso di raccontare tutto il mio 2025.

In questo articolo ti voglio mostrare tutto il mio 2025 facendolo come mi riesce meglio: con i numeri. Ti dirò cosa è andato bene, cosa è andato male e cosa mi aspetto dal 2026 (tipo letterina di babbo natale, ma senza regali).

Ti anticipo già che nessuna call mi ha cambiato la vita, nessun cliente mi ha fatto saltare dalla sedia e nessun post virale ha svoltato tutto.

Eppure, guardando i numeri che ho davanti, realizzo che questo è stato l’anno più importante della mia vita. Sia dal punto di vista professionale che privato.

Il 2025 è stato il mio primo anno completo da solo come SRL, diciamo il mio primo bilancio vero dopo quasi quattro anni di lavoro indipendente. Ah e nel frattempo è nata pure la mia prima figlia.

“Gli occhi chico, non mentono mai” — diceva Tony Montana. Ecco, io invece dico sempre: “I numeri chico, non mentono mai”.

E a me questi numeri piacciono.

I numeri del mio business

Va che curiosone/a che sei. Vabbè non mi dilungo anche perché so che è quello che vuoi sapere.

Clienti: 12 clienti attivi nel 2025. Di questi, 5 nuovi e 7 rinnovi. Un tasso di retention che mi fa capire che qualcosa sta funzionando nel modo in cui lavoro.

Discovery call: 48 in totale durante l’anno. Di queste, 3 si sono trasformate in clienti completamente inbound. 25 non sono andate avanti. 13 non erano in target.

Da dove arrivano: Il mio business oggi gira per un 70% da referral e un 30% da inbound. I referral non li traccio perché arrivano in modo organico, ma sono la spina dorsale di tutto. L’inbound arriva principalmente da LinkedIn.

Ore lavorate: 1520 ore fatturate in tutto l’anno. Mi sono preso diversi momenti di pausa, soprattutto dopo la nascita di mia figlia.

Margine: 22% netto, dopo tasse, costi dei collaboratori e il mio stipendio. Il margine è già al netto di quello che mi pago ogni mese.

ROI del marketing: Investo 4 ore a settimana sui contenuti, con il supporto di Veronica e Marco che mi danno una mano nella gestione. I costi di marketing li avrei coperti con un solo nuovo cliente inbound. Quest’anno ne ho chiusi 3. Il conto torna.

Ah, pensavi ti dicessi quanto ho fatturato?

I contenuti: il secondo lavoro che mi piace di più

In questi giorni chissà quante volte avrai letto che essere presenti è fondamentale e magari chi lo scrive allega anche risultati flexati manco fosse Fabrizio Corona. Io però voglio approcciare alla cosa in maniera diversa, altrimenti rischierei di sminuire ciò che per me, nel mio caso specifico, è in tutti i sensi un secondo lavoro.

Quattro ore a settimana. Ogni settimana. Per un anno intero. Senza mai una pausa.

Totale: 208 ore. 26 giorni lavorativi.

Questo è quanto ho lavorato sui contenuti quest’anno. Questo è il tipo di investimento, non di costo, che c’è dietro ai numeri che leggi qui sotto. E non l’ho fatto da solo: Veronica e Marco (angeli custodi ormai) mi hanno supportato nella gestione e senza di loro sarebbe stato difficile mantenere questa costanza.

A questo aggiungo le interviste e i workshop che ho fatto durante l’anno. Uno in particolare: con Factanza Academy, dove ho raccontato come uso l’intelligenza artificiale per creare contenuti. Uscire dalla mia bolla e parlare a pubblici differenti è stato parte dell’investimento.

Ora arriva la ciccia.

LinkedIn:

• Follower: da 9.327 a 11.728 (superata la soglia dei 10k → ho fatto anche un video per questo)

• Post pubblicati: 190

• Impression totali: 2.8 milioni (+100% rispetto al 2024)

• Engagement: 0.9%

• Commenti: 4.100

• Reaction: 18.400

• Repost: 285

• Visitatori del mio profilo: 10988

Per dare un contesto a questi numeri: se avessi voluto comprare 2.8 milioni di impression su LinkedIn con advertising, a un CPM medio di 35 euro, avrei speso circa 100.000 euro. Le ho ottenute con 208 ore di lavoro e zero budget pubblicitario. Non per dire che la pubblicità non serva, ma per far capire il valore reale di quello che molti liquidano come “fare un post”.

Newsletter:

Progetto più figo di quest’anno secondo me. Ho ritrovato una voglia di condividere che avevo perso grazie alla newsletter. Su questo ci farò un articolo e se non non l’hai ancora fatto… iscriviti.

• Articoli pubblicati: 18

• Iscritti: 262

La cosa che ho imparato è che i contenuti che funzionano non sono quelli dove insegno qualcosa. Sono quelli dove racconto come io faccio le cose. Nessuna lezione, nessun “dovresti fare così”. Solo la mia esperienza, raccontata per quello che è.

I contenuti che hanno funzionato di meno sono stati quelli più tecnici, dove davo valore oggettivo, ma non parlavo delle difficoltà che incontra chi mi legge. Erano troppo distanti dal problema reale.

Un’altra cosa che ho notato: se ti lamenti sui social, l’attenzione arriva. Ma attenzione e valore sono due cose diverse. Io preferisco avere meno attenzione e più valore.

Non tutto è andato rose e fiori

Quest’anno ho perso due clienti.

Non per mancanza di lavoro, non per problemi di budget. Li ho persi perché ho sbagliato io.

L’idea era semplice: delegare di più per prendere più clienti. Avevo collaboratori esperti, persone con cui avevo già lavorato e di cui mi fidavo. In un caso ho delegato la parte tecnica, nell’altro la parte di prodotto e design.

Il piano sembrava solido: io seguo la relazione col cliente, loro eseguono. Ogni tanto controllo che tutto stia andando nella direzione giusta.

Il problema è che “ogni tanto” non basta.

Mi sono accorto troppo tardi che le aspettative si erano disallineate. Il cliente si aspettava una cosa, il progetto stava andando da un’altra parte. Quando me ne sono reso conto, ho provato a correggere il tiro, ma era troppo tardi.

La fiducia, una volta persa, è difficile da riconquistare.

La lezione che mi sono portato a casa è che puoi delegare l’execution, ma non la relazione e il controllo strategico, perché la mia presenza per il cliente non è un optional ed è importante. Alla fine è il prodotto stesso.

Non si trattava di controllare i miei collaboratori, mi fido ciecamente di loro. Si trattava di mantenere l’allineamento sui requisiti, di essere presente quando le aspettative iniziano a divergere e di accorgemene prima che sia troppo tardi.

Quindi, dopo questa esperienza ho ripensato il mio modo di lavorare: cerco di essere più presente nelle fasi di interfaccia col cliente, e uso l’intelligenza artificiale per essere più operativo e coinvolto nelle diverse fasi di progetto, andando a recuperare il tempo di cui ho bisogno. Non per fare di più, ma per farlo meglio.

Le relazioni e il personal brand

Quest’anno ho fatto 30 networking call.

Nessuna di queste ha portato un cliente diretto. Zero.

Ma non è quello il punto.

Il ROI sul networking non si misura in deal chiusi. Si misura in riconoscibilità, in fiducia costruita, in opportunità che arriveranno tra sei mesi o un anno.

Quello che sta succedendo è che le persone iniziano ad associare “Fractional CTO” al mio nome. Quando qualcuno ha bisogno di questa figura, pensa a me. Non perché ho fatto pubblicità, ma perché mi hanno visto, mi hanno parlato, sanno chi sono.

Le networking call alimentano il referral anche quando non portano business immediato. Ogni conversazione è un seme. Alcuni germogliano subito, altri ci mettono tempo.

Continuo a farle, non ho tanto spazio nel calendario, ma le voglio fare. Perché mi piace essere d’aiuto alle persone che mi scrivono e perché non sempre è necessario fare qualcosa per ricevere altro in cambio.

Come è cambiato tutto con lei 💖

Da quando è nata mia figlia, le mie scelte di business sono cambiate.

Non in modo drammatico, alla fine non ho rivoluzionato niente. Ho dovuto, però, incastrare la mia vita in modo diverso.

Prima se c’era una cosa da fare nel weekend la facevo, adesso mi impongo di non lavorare. prima staccavo quando finivo il lavoro, adesso stacco perché… devo staccare.

La disciplina che ho costruito negli anni mi sta permettendo di ritagliarmi spazio per lei. Il mio lavoro e la mia vita sono diventati una cosa sola da gestire insieme, non due mondi separati che si rubano tempo a vicenda.

Prima la mia vita girava intorno al lavoro. Adesso c’è equilibrio.

E questa è probabilmente la cosa di cui sono più orgoglioso di tutto il 2025.

Il collaboratore svizzero

C’è un’altra cosa che ha cambiato il mio 2025: l’intelligenza artificiale.

Non come hype, non perché è diventata una buzzword, ma perché è uno strumento di lavoro quotidiano.

L’AI è diventata il mio collaboratore silenzioso. Mi accompagna nello sviluppo, nella strategia, nel brainstorming, nella creazione di contenuti.

(Non sostituisce niente, ma amplifica tutto).

Il boost non è stato solo sulla produttività, ma sulla qualità. Riesco a fare cose che prima non avrei avuto tempo di fare bene.

Lavorare senza intelligenza artificiale oggi sarebbe fare un passo indietro. Non è più un optional, è parte del mio modo di operare.

Se vuoi sapere come uso l’AI nel mio lavoro quotidiano, scrivimi. Sto pensando di creare contenuti dedicati a questo tema.

Ma intanto lunga vita a Claude.

Il mercato e cosa mi spaventa

Nel 2025 ho visto il mercato del Fractional CTO crescere.

Tante persone mi hanno scritto per capire come entrare in questo mondo. Le startup cominciano a capire cosa fa un Fractional e perché ha senso. Anche gli investitori hanno cambiato prospettiva: avere figure Fractional in una startup non è più visto come un segnale negativo, ma come una scelta intelligente.

Quello che mi preoccupa per il 2026 è non sapere come evolverà l’intelligenza artificiale. Non quanto velocemente cambierà le cose, ma quanto tempo avrò per adattarmi.

Quello che mi entusiasma è che l’AI potrebbe rendere il modello Fractional ancora più percorribile. Se un singolo professionista può fare di più e meglio grazie a questi strumenti, il valore che porta aumenta (e non di poco)

Il 2026: meno, ma meglio

L’anno prossimo ho deciso di fare dei cambiamenti.

Cosa smetterò di fare:

Non accetterò più founder che vogliono costruire un MVP da zero senza aver validato niente. Prima devono testare l’idea con gli strumenti che esistono già. Poi, dopo aver raccolto un finanziamento anche minimo, possiamo lavorare insieme.

Ho cambiato target: mi concentro su startup che hanno già dei finanziamenti e possono investire seriamente sul prodotto, la tecnologia e il team.

Smetterò di delegare le cose sbagliate. La lezione dei due clienti persi è chiara.

Cosa farò diversamente:

Selezione più mirata dei clienti, così da ridurre i costi e aumentare i margini. Il fatturato potrebbe scendere, ma la proporzione dovrà rimanere la stessa.

L’obiettivo? porre il focus sulla qualità e non sulla quantità. Voglio lavorare meglio, non di più.

Il nuovo progetto:

Nel 2026 lancio il mio canale YouTube.

Questa è la prima volta che ne parlo pubblicamente.

Mi sono reso conto che creare contenuti è il mio secondo lavoro, ma è quello che mi piace di più fare. Condividere le mie esperienze è quello che mi dà la maggiore soddisfazione. Voglio avvicinarmi ancora di più alle persone e farlo tramite video è il passo successivo.

(Se vuoi iscriverti per non perderti il primo video questo è il link)

L’obiettivo per il 2026:

Ripetermi. Quest’anno è stato ottimo e l’obiettivo è fare altrettanto bene migliorando sulla qualità.

Il filo conduttore

Se dovessi riassumere il 2025 in una parola, sarebbe questa: costanza.

Non c’è stato un momento di svolta. Non c’è stato un colpo di fortuna. C’è stata disciplina e la capacità di continuare a fare le cose che funzionavano anche quando non vedevo risultati immediati.

Dopo quasi quattro anni di lavoro indipendente, posso dire che il sacrificio ha avuto senso.

Ho un’azienda che funziona. Ho una figlia bellissima. Ho un equilibrio che prima non avevo.

Scusa se è poco.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Sicuramente ne avrai sentito parlare qualche tempo fa: Canva ha reso Affinity completamente gratuito.

Se non sai cos’è Affinity te lo dico in breve: si tratta di una suite di software professionale che compete direttamente con Adobe, prendendo in considerazione Photoshop, Illustrator e InDesign. Canva l’ha acquistata nel marzo del 2024 per circa 380 milioni di dollari e a maggio 2025 ha deciso di regalarla al mondo.

Un milione di download in quattro giorni. L’equivalente di riempire Wembley undici volte.

La mossa mi è sembrata così aggressiva (e forse anche folle) che ho voluto indagare meglio.

Ho iniziato a scavare nella storia di Canva, nel suo modello di business, nella sua guerra silenziosa contro Adobe.

E come al solito, ho scoperto cose che non mi aspettavo.

Due mondi che non si parlavano

Adobe domina il design professionale da 35 anni.

Photoshop è uscito nel 1990 e in poco tempo è diventato un verbo. Per dire, “Photoshoppare” è entrato nel dizionario. Se sei un designer hai sicuramente usato almeno una volta Illustrator, InDesign o Premiere. Strumento essenziali per i creativi professionisti.

Il modello era chiaro: software potentissimo, curva di apprendimento ripida, prezzi da professionisti. La Creative Suite costava oltre 2.500 dollari. Oggi Creative Cloud costa circa 780 euro l’anno.

Per trent’anni nessuno ha messo in discussione questo modello.

Poi è arrivata Melanie, una ventenne australiana che non era né designer, né ingegnere.

La ragazza di Perth

Melanie Perkins aveva 19 anni quando ha avuto l’intuizione.

Stava studiando all’Università di Western Australia, arrotondando insegnando Photoshop e InDesign agli altri studenti. Ogni semestre vedeva la stessa scena: gente che passava mesi a capire dove fossero i bottoni delle varie funzioni.

Quindi non per imparare a progettare, ma per orientarsi nell’interfaccia.

“Gli studenti impiegavano un intero semestre solo per imparare dove fossero i pulsanti in programmi come Photoshop.”

Melanie non era dentro al settore. Non aveva passato anni a normalizzare quella complessità. Guardava da fuori e vedeva l’assurdo.

Nel 2007, insieme al fidanzato Cliff Obrecht, fondò Fusion Books nel salotto della madre: una piattaforma per creare annuari scolastici con un’interfaccia drag-and-drop. Con 50.000 dollari presi dai classici friends&family, costruirono la più grande azienda di annuari d’Australia.

Per lei questo ha validato che il design poteva essere semplificato.

Ma Melanie voleva andare oltre gli annuari. “Ci aveva visto lungo” direi oggi. Voleva una piattaforma universale di design facile per tutti.

Tre anni di porte in faccia

Quando nel 2010 iniziò a cercare investitori, la risposta fu sempre la stessa.

No.

“Non investiamo in cofondatori che sono anche partner romantici”.

“Non facciamo deal all’estero”.

“L’Australia non ha un ecosistema startup” (come in Italia, giusto?)

“Non riuscirai mai a battere Adobe”.

Oltre 100 rifiuti in tre anni.

Il problema era il pitch. Melanie entrava nelle stanze e parlava di “piattaforma che integra industrie precedentemente separate”. Tecnico, astratto, freddo. Nessuna connessione emotiva.

Poi cambiò approccio; smise di parlare della soluzione e iniziò a raccontare i problemi che vedeva ogni giorno. Gli studenti frustrati, le ore perse, la sensazione di esclusione che provava chiunque non fosse già un designer di mestiere.

La svolta arrivò quando incontrò Bill Tai, un venture capitalist californiano che organizzava retreat esclusivi alle Hawaii dove si faceva kitesurfing e networking. Se non sapevi stare sulla tavola, non entravi nel giro.

Melanie non sapeva fare kitesurfing.

Così imparò. Spese quasi metà del budget aziendale per voli e alloggio, mesi per imparare uno sport che definisce “peculiare e pericoloso”. La sua valutazione del rischio? “Rischio: danni seri. Ricompensa: fondare l’azienda.”

A quel retreat incontrò gli investitori che le avrebbero cambiato la vita. Nel 2012, con un seed round da 3 milioni di dollari e Cameron Adams come terzo cofondatore, nacque Canva.

Lei non aveva mai mollato. Aveva visto qualcosa che gli altri non vedevano.

Permettimi di uscire dalle righe. Cazzo, complimenti davvero Melanie.

Il paradosso che vale 42 miliardi

La cosa che mi ha fatto riflettere di più su questa storia è questa: Canva non ha mai cercato di battere Adobe.

Non ha costruito un Photoshop migliore. Non ha cercato di convincere i designer professionisti a cambiare strumento.

Ha fatto qualcosa di completamente diverso.

Ha costruito uno strumento per chi non è designer e non vuole diventarlo.

Il social media manager che prima usava PowerPoint (male) o il piccolo imprenditore che pagava un freelancer per ogni grafica. L’insegnante che creava materiali didattici con WordArt o l’HR che doveva preparare una presentazione per il nuovo assunto.

Avevamo di fronte milioni di persone che avevano bisogno di comunicare visivamente, ma che non avrebbero mai aperto Photoshop per mancanza o di competenze, o di tempo per imparare. E Adobe non li vedeva, o meglio: non li voleva.

Il loro modello era costruito sui professionisti. Abbonamenti costosi. Curve di apprendimento di mesi. Software che richiedono macchine potenti.

Canva ha preso quel mercato ignorato e ci ha costruito un impero.

I numeri oggi: 240 milioni di utenti mensili. 3,5 miliardi di dollari di fatturato annuo. 28 milioni di abbonati paganti. Valutazione di 42 miliardi di dollari. Profittevole da otto anni consecutivi.

E la parte più assurda? Il 90% degli utenti non paga un euro.

Come funziona dare via tutto gratis

Il modello freemium di Canva è spinto all’estremo.

Il piano gratuito include: 250.000 template, un milione di foto e grafiche stock, editor drag-and-drop completo, 5GB di storage, uso commerciale dei contenuti, in sostanza un utente può creare grafiche e design professionali senza sborsare un centesimo in più, a meno che non voglia un piano Premium.

E quel 10% che paga? Paga per la collaborazione di team, per il brand kit aziendale, per le funzionalità enterprise.

Ma il vero meccanismo è un altro.

Quei 220 milioni di utenti free non sono un costo. Sono il marketing.

Ogni design creato e condiviso sui social è pubblicità gratuita. Ogni collega a cui mostri “guarda cosa ho fatto in dieci minuti” è un potenziale nuovo utente. Ogni azienda in cui un dipendente inizia a usare Canva per i suoi progetti personali è un potenziale contratto enterprise.

Il 95% delle Fortune 500 oggi usa Canva. Non perché qualcuno abbia fatto una vendita enterprise tradizionale, ma perché qualcuno in quell’azienda l’ha portato dentro dal basso.

Melanie Perkins lo spiega così: “Rendiamo intenzionalmente il nostro prodotto gratuito estremamente generoso. È fondamentale sia per il marketing sia per la nostra mission. La gente può amare il prodotto, condividerlo con amici e colleghi, promuoverlo sui social. E quella viralità alimenta la nostra crescita.”

E ora puntano anche al restante 1%

Torniamo alla notizia che ha fatto partire questa mia ricerca.

Canva ha passato dieci anni a conquistare il 99% del mondo che non era designer. Ora punta anche al restante 1%.

Affinity gratuito è l’attacco diretto ad Adobe sul suo stesso terreno. Software professionale, strumenti da studio, precisione al pixel. Zero euro.

Cameron Adams, cofondatore e Chief Product Officer di Canva, lo dice chiaramente: “Non è più professionisti da una parte e non professionisti dall’altra. È tutto un unico ecosistema creativo che lavora insieme.”

La strategia è cambiata. Prima era: creiamo un mercato nuovo dove Adobe non può seguirci. Ora è: e se prendessimo anche il loro mercato, rendendo gratis quello che loro fanno pagare 70 dollari al mese?

Un milione di download in quattro giorni suggerisce che la risposta potrebbe essere sì.

Cosa mi porto a casa questa volta

Questa storia mi ha fatto ripensare a come guardo la competizione.

Il leader non vede chi sta escludendo.

Adobe per trent’anni ha costruito strumenti sempre più potenti per utenti sempre più esperti. Ogni nuova feature era pensata per il designer che chiedeva di più. Ma ogni nuova feature era anche una barriera in più per chi non era designer.

Canva ha guardato quella barriera e ha visto un’opportunità.

Good enough batte perfetto.

Il design “abbastanza buono” creato in dieci minuti da un non-designer su Canva genera più valore di quello perfetto che non verrà mai fatto perché il budget per il grafico non c’è.

La soluzione mediocre che esiste batte quella eccellente che resta nella testa del founder (forse il vibe coding è anche questo?)

Il mercato più grande è spesso quello che nessuno serve.

I designer professionisti sono qualche milione. Le persone che hanno bisogno di comunicare visivamente sono un miliardo.

Il concorrente di Canva nel 2013 non era Adobe. Era PowerPoint usato male, Word con le clipart, il nipote del titolare che “sa usare il computer”, oppure semplicemente niente.

La domanda da farsi

Invece di chiederti come battere il leader del tuo mercato, prova a chiederti: chi sta ignorando?

Canva non ha mai cercato di convincere i designer professionisti a lasciare Adobe. Ha cercato i milioni di persone che avevano bisogno di comunicare visivamente ma non avrebbero mai aperto Photoshop.

Il mercato più grande è spesso quello che nessuno sta servendo.

E se stai costruendo qualcosa, chiediti: stai costruendo per chi può permettersi la perfezione, o per chi ha bisogno di qualcosa che funzioni adesso?

Melanie Perkins non ha costruito Photoshop migliore. Ha risposto a una domanda diversa: e se il design non richiedesse essere designer?

La risposta valeva 42 miliardi di dollari.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

C’è un momento nella carriera di ogni tecnico in cui capisce una cosa scomoda: saper programmare e saper comunicare sono due competenze completamente diverse.

E peggio ancora, diventare più bravo nella prima rischia di renderti più debole nella seconda.

Più approfondisci il tech, più il tuo vocabolario si specializza. Più ti circondi di persone che parlano la tua stessa lingua, più dimentichi che quella lingua è incomprensibile per chiunque altro.

E quando arrivi al punto in cui devi guidare, convincere, proporre... scopri che tutto quello studio non ti ha preparato a questa parte del lavoro.

La specializzazione può essere una trappola comunicativa.

Il paradosso è che più diventi esperto, più diventi incomprensibile per chi non lo è.

La proposta giusta con le parole sbagliate

Anni fa ho proposto una soluzione tecnica che avrebbe dato flessibilità al prodotto e ridotto i costi, di conseguenza anche accelerato lo sviluppo di nuove funzionalità. Era la scelta giusta, oggettivamente (e non ti azzardare a dire il contrario 😀), ma quando l’ho presentata al management parlando di architettura, flessibilità dell’implementazione e vantaggi tecnici c’è stato un momento che mi ha fatto riglettere.

“Non vediamo il ritorno sul business,” è stato detto.

Così, sbattuto in faccia bellamente.

Sei mesi dopo, quella stessa soluzione è stata implementata e ha funzionato esattamente come avevo previsto.

Il problema? Non era la proposta, ma come l’avevo comunicata.

Avevo parlato in una lingua che solo io capivo e mi ero incazzato (di brutto pure) perché “loro non capivano”… Ma il problema non erano loro. Ero io.

Vivere in due mondi che non si parlano

Quando diventi tech leader, ti rendi conto di vivere in due mondi che non comunicano.

Con i tuoi colleghi più tecnici parli di motivazioni tecniche e usi un vocabolario: parlate la stessa lingua, capite gli stessi riferimenti, condividete lo stesso modo di pensare.

Con il management, parli di motivazioni di business, ritorno sull’investimento, rischio e opportunità, perché loro parlano un’altra lingua, hanno altri riferimenti, pensano in modo diverso.

E tu? Tu stai nel mezzo. E devi switchare continuamente.

Il problema è che per anni non ti sei reso conto che stavi switchando. Pensavi di parlare italiano con tutti, ma stavi parlando due dialetti diversi senza saperlo.

C’è una cosa che Dale Carnegie dice nel suo libro “Come trattare gli altri e farseli amici“ che mi è rimasta impressa: la comunicazione non è quello che dici ma è quello che l’altro capisce.

E tu puoi controllare solo la prima parte. Quello che esce dalla tua bocca e non quello che la persona comprende.

Questo significa che se l’altro non capisce, non è colpa sua. È tua. Perché non hai usato la lingua giusta.

Anche Chris Voss in “Never Split the Difference“ dice una cosa forte: l’empatia tattica non è essere gentili, è capire esattamente come pensa l’altra persona per comunicare nel modo più efficace.

Non è manipolazione (… forse), è rispetto.

E Marshall Rosenberg in “Nonviolent Communication“ va ancora più a fondo: la comunicazione efficace parte dall’osservare senza giudicare, dal capire i bisogni dell’altro prima di esprimere i propri.

Sembrano concetti ovvi, ma nella pratica li dimentichiamo costantemente.

Come tradurre (senza tradire)

Oggi, prima di una riunione importante con persone non tecniche, faccio una cosa semplice: mi chiedo “cosa conta per questa persona?“

Non mi concentro su cosa sia tecnicamente giusto, o su cosa vorrei dire io… Ma mi focalizzo su ciò che conta per loro.

Se parlo con il CEO conta il fatturato, i costi, il rischio. Se parlo con il commerciale conta quanto è facile vendere, quanto tempo serve per implementare, come si differenzia dalla concorrenza. E così via…

E solo dopo aver capito cosa conta per loro, scelgo come raccontare la mia soluzione.

Facciamo un esempio concreto:

Devo proporre di scalare l’infrastruttura. Con un altro tech, dico: “Dobbiamo implementare scaling orizzontale e distribuire il carico su più istanze“.

Al business dico: “Possiamo ridurre i costi del 30% e gestire il triplo degli utenti senza riscrivere tutto. Significa che quando arriverà il picco di traffico non crasha tutto, e risparmiamo quando il carico è minimo“.

Poi, e questo è importante, aggiungo: “Questo approccio si chiama scaling orizzontale, se vuoi approfondire te lo spiego“.

Visto che non conoscono le parole tecniche, le traduco. E faccio education mentre comunico.

Ma prima metto il valore, poi il nome tecnico (mai il contrario).

La differenza? Con il primo approccio, vieni percepito come qualcuno che vuole fare il figo con paroloni, o peggio ancora una supercazzola. Con il secondo, vieni percepito come qualcuno che risolve problemi.

Perché è così difficile (e cosa c’è davvero sotto)

Perché è così difficile per noi tech comunicare con il business?

La risposta è più profonda di “usiamo linguaggi diversi”.

Il punto è che viviamo in bolle. Piccole bolle specializzate dove per diventare davvero bravi devi studiare TANTO. Devi approfondire, devi specializzarti, devi immergerti completamente in quel mondo.

E quando sei immerso, il linguaggio di quel mondo diventa il tuo linguaggio naturale. Inizi a pensare in quel linguaggio e le tue assunzioni diventano le assunzioni di quel mondo.

E poi esci dalla bolla per parlare con qualcuno che vive in un’altra bolla. Che ha studiato tanto quanto te, ma in un’area completamente diversa. Che ha le sue assunzioni, il suo linguaggio, il suo modo di pensare.

E cosa facciamo? Parliamo nella nostra lingua e ci stupiamo che l’altro non capisca. O peggio ancora, pensiamo che sia “ignorante” sulla nostra materia.

Ma non è ignoranza, è specializzazione.

Il commerciale non è ignorante sulla tech. Ha solo studiato come vendere, come negoziazione e psicologia del cliente. Ha competenze profondissime che io non ho.

Il CFO non è ignorante sulla tech. Ha studiato finanza, analisi del rischio e allocazione del capitale. Competenze che io non ho.

Non è che loro non capiscono la tech. È che semplicemente non parliamo la stessa lingua.

Prima ancora di poter comunicare, devi comprendere quali sono le dinamiche dell’area dell’altro, tutto questo per capire cosa conta per loro (non per diventare esperto in quella materia).

E questo richiede investimento, tempo e studio… Non puoi farlo dall’oggi al domani.

Ma è quello che ti rende davvero senior:

Non solo le tue competenze tecniche, ma la capacità di far passare quelle competenze tecniche traducendole in valore per chi non è tech.

Perché alla fine, la tecnologia più bella del mondo non serve a niente se non riesci a convincere nessuno a farla (o usarla, ma è un altro discorso questo).

Che cosa ho imparato davvero

Guardando indietro, quella proposta bocciata anni fa mi ha insegnato più di mille proposte accettate.

Mi ha insegnato che l’empatia è mettersi letteralmente nei panni dell’altro PRIMA di parlare. È chiederti “se fossi il CEO con i suoi problemi, cosa vorrei sapere?” (e smetterla di pensare a “cosa voglio dire io?”)

Mi ha insegnato che la comunicazione è LA competenza da avere SEMPRE. Puoi essere il miglior architetto del mondo, ma se non sai spiegare perché quella architettura conta, il tuo impatto è limitato alla tua tastiera. Mi ha insegnato che più diventi esperto, più rischi di diventare incomprensibile, perché l’expertise ti chiude nella tua bolla. Quindi devi fare uno sforzo attivo e costante per uscirne e parlare col resto del mondo.

E soprattutto che quando qualcuno non capisce, il problema non è mai l’altro. Il problema sei tu che non hai trovato il modo giusto di spiegare.

Severo ma giusto.

Se il problema sei tu, significa che puoi risolverlo. Significa che hai controllo. Significa che puoi migliorare.

E questo vale non solo nella comunicazione tech-business: vale in ogni tipo di comunicazione. che sia con i clienti, con il team o con la famiglia.

La lingua giusta per la persona giusta al momento giusto. Non esiste altro modo.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Nel 2025, se vuoi lanciare un prodotto tech, ti dicono che DEVI avere: L’AI integrata, un’app mobile, la personalizzazione utente, un team di growth, un design da urlo (non quello dei Gemelli Diversi), la dark mode (ovvio) e altre 100 cose…

Mi sono chiesto allora, ma ci sono prodotti che stampano soldi e non hanno niente di tutto questo? Sì, e uno di questi lo conosciamo tutti: Craigslist.

Sito identico dal 1996 e nessun tipo di innovazione da 25 anni.

Craigslist ha fatto ricavi per 302 milioni di dollari nel 2024.

Non male per un sito che sembra progettato dalla copisteria sotto casa con l’insegna in Comic Sans, vero?

C’è di più però: la società ha circa 50 dipendenti. Cinquanta, sì hai letto bene.

Facendo due conti, significa circa 6 milioni di dollari di ricavi per dipendente.

Zero spesa in marketing. Mai. In 30 anni.

Zero team di vendita (i pagamenti sono automatizzati).

115 milioni di visite mensili servite da 50 persone con tecnologia del 1995.

AI, algoritmi di raccomandazione e personalizzazione? ZERO.

Visti questi numeri potevo non approfondire? E allora andiamo!

Come una email list è diventata un monopolio

Primavera 1995, San Francisco.

Craig Newmark, 43 anni, programmatore IBM appena trasferito per lavorare in Charles Schwab, si sente isolato.

Vede persone aiutarsi su community online primitive (WELL, MindVox, Usenet) e decide di fare la sua parte: crea una mailing list per segnalare eventi interessanti della Bay Area a 10-12 amici.

Concerti, saloni digitali, incontri per sviluppatori… Lo scopo nobile è quello di: “coltivare un po’ di community.”

A metà 1995 la lista ha 240 indirizzi email, troppi per averli tutti in cc.

Serve qualcosa di diverso.

Nel 1996 nasce il sito web. Nel 1999 incorpora come società.

Serve un nome. Lui vuole chiamarla “sf-events” (letterale, da nerd), ma gli amici insistono: la gente già la chiama “Craigslist.”

Il nome personale lo imbarazza, ma diventa il brand.

Gli utenti iniziano spontaneamente a postare annunci di lavoro, appartamenti, oggetti in vendita. Craig non aveva pianificato niente di tutto questo.

Nel 2000 assume Jim Buckmaster come CTO e lo promuove CEO dopo un anno.

Perché? Il motivo è semplice, basta leggere le parole di Craig: “Facevo schifo come manager.” Buckmaster guida ancora l’azienda 25 anni dopo.

Nel 1997 qualcuno propone a Craig di mettere banner pubblicitari sul sito.

La sua risposta oggi sarebbe da matti: “Rallentano il sito e mi sembrano stupidi. Niente pubblicità.”

È la decisione più importante della storia di Craigslist, scegliere di NON monetizzare (per il momento).

Nel 2004 infatti iniziano a far pagare annunci di lavoro a New York e Los Angeles (25-75 dollari) ma solo dopo aver consultato gli utenti e determinato che ridurrebbe lo spam.

Ma perché ha funzionato così tanto?

Quando il “brutto” generava fiducia

Questo è il paradosso che sembra esserci e che mi ha fatto guardare la cosa da un’altra prospettiva. Ma davvero nel mondo digitale, brutto è uguale ad autentico che a sua volta è uguale ad affidabile?

Sembra una ca***ta, vero? Eppure molte volte può essere vero:

Siti ben disegnati = establishment = non fidati.

Siti mal disegnati = autentici = fidati.

Il modello mentale è “buon design = informazione mainstream = da non fidarsi.”

Strano vero? Forse oggi non è più così, ma ai tempi lo era.

Quando un sito non appariva eccessivamente commerciale o rifinito, le persone tendevano a fidarsene di più, sembra che stessero cercando meno di manipolare o vendere aggressivamente.

È l’effetto underdog: design meno sofisticato appare come “uno di noi”, il negozio sotto casa vs la catena corporativa.

Gli utenti sospettano: soldi spesi per design elegante = inclusi nel markup.

La performance contava (e conta tutt’ora)

Con pochi kb per pagina, Craigslist si carica istantaneamente su qualsiasi connessione.

Funziona su computer obsoleti, browser vecchi, smartphone economici.

È accessibile a tutti i livelli. La ricercatrice Jessa Lingel lo descrive come parte del “poor people’s internet.”

Le persone di colore e povere possono cercare housing e lavoro senza discriminazione basata sull’aspetto (a differenza di Airbnb dove gli host vedono foto).

In sostanza: l’anonimato protegge dai bias.

La coerenza di 25 anni.

Mentre Facebook ridisegna ogni 6 mesi costringendo utenti a reimparare l’interfaccia, Craigslist non è mai cambiato:

• Zero relearning cost.

• Muscle memory advantage.

• Fiducia attraverso stabilità.

E questo ci fa capire che, in un’era di cambiamento costante, forse la cosa più radicale che un sito può fare è restare uguale.

Il paragone con oggi

Voglio fare un paragone con le “regole” (se così le vogliamo chiamare) di oggi. Quelle regole che vengono imposte per fare startup. Facciamo il confronto diretto (regola per regola).

REGOLA 1: “Devi innovare costantemente”

Loro dicono: Ship fast, iterate, move fast and break things.

Craigslist dice: Se non è rotto, non aggiustarlo.

Design identico da 25 anni. Zero feature nuove “che contano”. L’unica “innovazione” è stata l’app mobile nel 2019, dopo 24 anni di esistenza.

Quando finalmente l’hanno lanciata, l’hanno descritta come “estremamente semplice, niente fronzoli.”

È diventata la decima app più scaricata nella categoria Shopping in 24 ore.

Risultato? Gli utenti in questo modo sanno sempre cosa aspettarsi, nessuna delusione.

REGOLA 2: “Devi integrare l’AI”

Loro dicono: AI per raccomandazioni, Machine learning per personalizzazione e Algoritmi per ottimizzare engagement.

Craigslist dice: Zero AI, zero algoritmi e zero personalizzazione.

Le ricerche sono letterali, non algoritmiche. I risultati sono cronologici, non ordinati da engagement.

Tutti vedono le stesse cose…

Non ci sono feed curati. Non ci sono raccomandazioni “per te”.

È l’anti-network effect: l’assenza di algoritmi crea fiducia.

Nessuna filter bubble, nessuna manipolazione e soprattutto nessun “ti mostriamo prima gli annunci che pagano.”

REGOLA 3: “Devi scalare il team”

Loro dicono: Hire fast, team per ogni funzione, poi concentrati su sales, marketing, growth, data science, customer success...

Craigslist dice: 50 dipendenti (da 30 anni).

Niente marketing department (zero spesa pubblicitaria in 30 anni).

Niente sales team (pagamenti automatizzati).

Niente customer service center (Craig rispondeva personalmente alle email fino al 2016).

Niente management bloat (organizzazione piatta).

Jim Buckmaster, CEO, lo dice chiaramente: “No meetings, ever.”

Risultato? In uno dei picchi più alti, si stima facessero 14 milioni di dollari per dipendente. (per avere un benchmark: Apple fa 2.1 mln e Google 1.8 milioni).

REGOLA 4: “Devi monetizzare aggressivamente”

Silicon Valley dice: Freemium, subscription, ads ovunque, data monetization, premium features, dark pattern per upgradare...

Craigslist dice: Facciamo pagare solo per annunci di lavoro in 39 città americane (10-75 dollari), annunci immobiliari commerciali in alcune città (5 dollari), veicoli da dealer (5 dollari).

Tutto il resto è gratis: vendita oggetti personali, housing wanted, community post, forum di discussione.

Peter Zollman, analista dell’AIM Group, ha stimato che se Craigslist fosse gestita come un’azienda pienamente commerciale potrebbe generare da 5 a 10 volte i ricavi attuali.

Scelgono di non farlo.

Craig lo racconta così: “VC e banker mi dicevano: ‘Craig, fai come tutti: monetizza ogni cosa, e arriveranno miliardi’. Ma il mio compasso morale era stato formato alla scuola domenicale: tratta le persone come vorresti essere trattato e sappi quando è abbastanza”.

Craig ha rifiutato miliardi di dollari in potenziali guadagni.

“Non mi disturba perché ho imparato che nessuno ha davvero bisogno di un miliardo di dollari.”

Risultato? 80% margine di profitto.

REGOLA 5: “Devi rimuovere ogni attrito”

Silicon Valley dice: One-click purchase, payment integrato, verifica istantanea, chat in-app e smooth experience.

Craigslist dice: Frizione intenzionale.

Niente payment integrato (forza transazioni cash locali che costruiscono community).

Niente rating/recensioni (preserva privacy).

Niente auto-refresh (previene manipolazione engagement).

Devi mandare email. Devi metterti d’accordo. Devi incontrare la persona.

Così la frizione diventa la feature principale del prodotto.

Mentre i competitor rimuovono ogni attrito per aumentare engagement, Craigslist mantiene frizioni intenzionali che costruiscono fiducia.

Oggi come se la cava?

C’è però una verità…

Craigslist sta morendo. Lentamente, ma sta morendo.

I ricavi sono crollati del 70% in 6 anni, qui vi lascio le stime:

• 2018: 1.035 miliardi

• 2021: 660 milioni

• 2024: 302 milioni

Perché?

La generazione Z non sa nemmeno cosa sia Craigslist (per loro è roba da boomer).

I competitor hanno un buon mercato: Facebook Marketplace (ecosistema che la gente usa già ogni giorno).

App come OfferUp e Mercari stanno divorando il mercato mobile.

Ma comunque oggi sono 302 milioni con 50 persone.

Anche in declino, Craigslist rimane più efficiente di quasi ogni tech company al mondo.

Non ha debiti. Non ha investitori da accontentare. Può sopravvivere indefinitamente anche a una frazione del traffico attuale.

È allo stesso tempo morente e imbattibile.

Quello che ho imparato

Studiando Craigslist, ho capito alcune cose che mi hanno fatto cambiare prospettiva.

Quando l’innovazione è il nemico

La prima lezione è la più controversa: a volte innovare è la cosa peggiore che puoi fare.

Ogni feature che non aggiungi è una feature che non può rompersi. Ogni redesign che eviti è un redesign che non farà incazzare gli utenti.

Mentre i competitor spendevano milioni in nuove funzionalità, Craigslist rimaneva immobile e vinceva.

La domanda da farsi non è “come posso innovare?” ma “questa innovazione risolve un problema reale o è solo innovazione per il gusto di innovare?”

Perché nel 90% dei casi, la risposta è la seconda.

Trust through consistency

In un’era di redesign trimestrali, Craigslist non ha mai cambiato.

Questa consistenza è diventata il suo brand, il suo moat e la sua arma segreta.

Altri esempi di questo approccio:

• Hacker News: design arancione minimale, testo puro. Eppure aziende del valore combinato di 400+ miliardi di dollari (Stripe, Dropbox, Airbnb) attribuiscono feedback fondamentali ad HN.

• Old Reddit: molti degli utenti attivi preferisce ancora Old Reddit. Quando hanno provato a modernizzare, gli utenti si sono ribellati.

• Berkshire Hathaway website: link in testo puro su sfondo bianco, sembra HTML 1990. Valore azienda: circa 1 trilione di dollari.

Il pattern è chiaro: coerenza × tempo = fiducia compounding.

Monopolio attraverso semplicità

Il vero monopolio non viene dalla complessità, ma dalla semplicità radicale.

Craigslist ha creato una posizione dominante rendendo impossibile per i competitor giustificare investimenti massicci in “features migliori” quando gli utenti vogliono solo postare un ca*** di annuncio.

Chiunque può costruire Craigslist in 2 settimane, ma nessuno può replicare 25 anni di fiducia.

È il paradosso del minimalista: i competitor possono competere solo aggiungendo feature, che distrugge il vantaggio semplicità.

Sapere quando è abbastanza

Questa è forse la lezione più radicale e ignorata nel mondo tech.

Craig Newmark ha rifiutato miliardi di dollari perché “nessuno ha davvero bisogno di un miliardo di dollari.”

Ha incorporato questa filosofia nel DNA dell’azienda dal 1999.

Nel mondo delle exit da unicorno, degli SPAC, delle SPV, questo sembra folle.

Ma Craig è un miliardario che vive secondo i suoi valori, fa customer service per hobby, e ha dato via la maggior parte della sua ricchezza in filantropia.

La domanda che dovremmo farci: stiamo crescendo perché serve, o perché “è quello che si fa”?

La frizione può essere una feature

Ultimo punto, ma importante.

Non tutta la frizione è cattiva, a volte aggiungerla è la cosa più intelligente che puoi fare.

Devi mandare email. Devi metterti d’accordo. Devi incontrare la persona faccia a faccia.

Questa frizione costruisce fiducia.

Perché quando devi fare uno sforzo, ci pensi due volte. Quando devi incontrare qualcuno, sei più onesto.

Le startup di oggi ottimizzano per rimuovere ogni attrito, Craigslist fa l’opposto.

E funziona.

Una provocazione finale

Craigslist mi ha insegnato una cosa fondamentale: forse stiamo complicando tutto quello che funzionerebbe meglio lasciato semplice.

Viviamo in un’era di overengineering.

Craigslist avrebbe potuto stare al passo ma non l’ha voluto fare… Eppure ha generato più valore (sia economico che sociale) di migliaia di startup con tutte le feature immaginabili.

Il messaggio di Craigslist è sovversivo: maybe you’re doing too much.

Forse il tuo prodotto non ha bisogno di quella feature.

Forse la tua azienda non ha bisogno di 500 dipendenti.

Forse la semplicità non è un compromesso, è la strategia.

La domanda provocatoria per te: cosa stai complicando che funzionerebbe meglio lasciato semplice?

Quali “innovazioni” stai inseguendo per mentalità da gregge piuttosto che necessità reale?

Il paradosso di Craigslist non è che sia sopravvissuto.

È che tutti gli altri abbiano reso la sopravvivenza così complicata.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

L’altro giorno cazzeggiando su instagram mi sono imbattuto in un video dove un ragazzo elencava tutte le cose che chi è nato dopo il 2000 non capirà mai.

Aspettare ore per scaricare un film, perdere un episodio in TV e non poterlo mai più rivedere.

Stampare le mappe prima di partire e pregare di non sbagliare strada perché “quella benzina costa.”

Mentre ascoltavo, sorridevo e pensavo (da vero anziano): “bei tempi”.

Ma purtroppo da “anziano” questo genere di cose si portano dietro dei retro pensieri…

Io costruisco prodotti digitali. E costruisco partendo da quelle esperienze.

Quelle attese infinite, quella scarsità, quella necessità di scegliere con cura perché non potevi permetterti errori.

Così mi sono chiesto: e se quelle esperienze passate, che per me sono state formative, fossero oggi i miei limiti più grandi?

Ho conosciuto un mondo che oggi non esiste più (e questo è un problema)

Se una cosa valeva, potevi aspettare. Nel mondo in cui sono cresciuto la pazienza è una virtù e l’anticipazione rende le cose più preziose.

Ricordo ancora la soddisfazione di svegliarmi la mattina e vedere l’avanzamento della barra dei download, ore passate ad aspettare per un motivo.

Oggi, 3 secondi di caricamento sono un’eternità, un form di registrazione con più di 2 campi è troppo e se una cosa non funziona immediatamente, viene abbandonata.

Ho imparato a valutare prima di scegliere.

Quando sceglievo un film lo facevo con attenzione: non potevo cambiare idea a metà e sprecare tempo ad aspettare, quindi leggevo le recensioni, guardavo i trailer più volte e pesavo le opzioni.

Oggi però non vogliamo scegliere, vogliamo che sia il prodotto a farlo per te. “Show me the best, subito.” Zero decisioni, zero problemi.

Ho imparato che la complessità significa controllo.

Passavo ore a configurare software. Più opzioni c’erano, meglio era. Ogni setting, ogni personalizzazione era potere nelle mie mani.

Oggi quella complessità ci spaventa perché non si vogliono mille opzioni, ma qualcosa che funzioni subito senza dover capire come.

Ho imparato che capire come funziona fa parte dell’esperienza.

Quando installavo un programma come prima cosa leggevo il manuale, poi magari cercavo le FAQ e se qualcosa ancora non era chiaro andavo sul forum di supporto. Era normale, faceva parte del processo per imparare a usare uno strumento.

Oggi se serve leggere più di tre righe, l’app è già chiusa o anche disinstallata. Non è immediato? Ottimo, non ne vale la pena. Però non esiste un bene o un male, un migliore o un peggiore.

Stiamo costruendo per contesti diversi, con aspettative diverse, plasmate da esperienze e ritmi diversi. Il problema, però, è quando non me ne accorgo.

Quando penso che le “best practices” siano universali e in realtà sono solo quello che hanno funzionato per la mia generazione.

Quando costruisco un prodotto e mi stupisco che “gli utenti non capiscono” e non mi chiedo: forse il problema è che sto costruendo considerando solo me stesso e la mia esperienza?

Il bias non è solo generazionale

Ma la cosa che mi spaventa di più è che questo non riguarda solo le generazioni più giovani.

Se costruisco per un target più anziano, ho lo stesso identico problema.

Loro hanno imparato a diffidare del digitale, a voler stampare tutto, a cercare conferma umana prima di cliccare su “conferma.”

Hanno imparato che “se è gratis, c’è la fregatura”, che “meglio chiamare che mandare un messaggio” e che “il computer è complicato, meglio chiedere aiuto”.

E io? Io do per scontato che “tutti sappiano usare un’app” o che “basta un tooltip per spiegare.”

Insomma, “se è intuitivo per me, lo è per tutti”, no?

Costruisco prodotti dove “basta fare login con Google” e non mi rendo conto che per alcuni quella frase genera ansia. “Dove vanno i miei dati? Cosa vede Google? È sicuro?”

Non è capire (o non capire) i giovani o i vecchi. Il punto è che io costruisco partendo da ME. E questo è un problema.

I prodotti cambiano perché le persone cambiano

Sei anni fa costruivo prodotti diversi da quelli che costruisco oggi.

Non perché sono diventato più bravo (anche un po’ quello dai…) ma perché le aspettative sono cambiate.

Funzionalità che avevano “senso” nel 2018, oggi sono superflue. Interfacce che erano “intuitive” allora, oggi sono troppo complicate.

Le persone non usano i prodotti allo stesso modo: le loro esperienze formative sono diverse e lo sono anche le loro aspettative.

E tra 6 anni? Cosa costruirò? Per chi? Con quali assunzioni?

Se non mi interrogo su questo oggi, rischio di diventare irrilevante domani. Rischio di essere di professionista che continua a costruire per un mondo che non esiste più.

Cosa sto facendo per evitare di restare indietro

Non ho la risposta. Ma ho capito che il primo passo è riconoscere il problema. Non posso eliminare i miei bias, sono parte di me e sono frutto delle mie esperienze, ma posso essere consapevole che esistono.

Mi chiedo sempre: “Sto costruendo per me o per loro?”

Quando progetto una feature, mi fermo e penso: “Questo risolve un problema vero o sto solo costruendo come MI ASPETTO che funzioni?”

Se la risposta è la seconda, devo fare un passo indietro.

Devo chiedermi: chi userà questo prodotto? Quali sono le loro esperienze? Cosa si aspettano?

Non cosa MI ASPETTO io. Cosa si aspettano LORO.

Cerco contaminazione

Parlo con utenti di generazioni diverse, ma non perché voglio sentirmi dire “sì, hai ragione”, ma per capire come ragionano.

Quindi chiedo sempre: “tu come useresti questo? Cosa ti aspetti che succeda quando clicchi qui?”

E ascolto, davvero eh. Senza pensare “eh vabbè ma non ha capito”, perché se non ha capito il problema non è suo. È mio.

Osservo senza giudicare

Quando vedo un prodotto che “non ha senso per me,” invece di pensare “è fatto male,” mi chiedo: “Per chi ha senso? Perché?”

Non devo capirlo. Non devo usarlo.

Devo capire chi lo usa e perché funziona per loro.

Perché se funziona per loro e io non lo capisco, significa che sto guardando con i miei filtri e con i miei bias.

E quei filtri potrebbero essere il mio limite.

Non è solo tech, è cultura

Il rischio più grande non è non conoscere l’ultima tecnologia. È pensare che il nostro modo di vedere i prodotti sia l’unico modo. Perché i prodotti non sono solo codice, interfacce, funzionalità. Sono esperienze plasmate dal contesto culturale di chi li usa.

Chi è cresciuto aspettando i download ha imparato la pazienza. Chi è cresciuto con tutto on-demand ha imparato l’immediatezza.

Chi ha dovuto stampare le mappe si fida del controllo. Chi ha sempre avuto Google Maps si fida dell’algoritmo.

Chi ha perso dati importanti per un crash ha imparato a salvare tutto. Chi ha tutto nel cloud non sa nemmeno cosa significa “salvare.”

E io? Io devo costruire per tutti loro. Non solo per me.

Comunque, quello che voglio dire non è di cancellare le proprie esperienze.

Sono preziose, perché ci hanno insegnato tanto.

Ma bisogna essere consapevoli che quelle esperienze sono filtri, e se non li riconosco, diventano limiti.

La domanda che mi faccio sempre più spesso è questa:

“Sto costruendo prodotti per il mondo che ho conosciuto o per il mondo che esiste oggi?”

Perché il mondo che ho conosciuto io non esiste più.

E quello che esiste oggi cambierà di nuovo domani.

E se non cambio io, resto indietro.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Qualche newsletter fa ti ho raccontato di Clubhouse: 4 miliardi di valutazione, zero fatturato, morta quando il mondo ha riaperto.

La lezione era chiara: avevano trovato il product-market fit perfetto... per un mondo che non sarebbe durato.

Ma poi mi sono chiesto: quante idee geniali sono morte solo perché sono arrivate troppo presto?

Quanti prodotti hanno fallito non perché fossero sbagliati, ma perché il mondo non era pronto?

Mi è venuto in mente un software che tutti abbiamo odiato. Uno che voleva fare nel 1997 quello che oggi consideriamo normale, anzi, indispensabile.

Sto parlando di Clippy.

Il responsabile del computer di classe

Avevo 9 anni ed ero il “responsabile del computer di classe“. (Sì, già all’epoca sapevo che avrei fatto questo nella vita. Che fortunello vero? Ma torniamo a noi).

Il PC era uno di quei cassoni beige con Windows 98, e ogni volta che aprivamo Word per scrivere qualcosa, appariva lui:

Clippy.

Si presentava come assistente, ma per me e i miei compagni era solo un gioco. Una specie di Tamagotchi rotto che appariva quando meno te lo aspettavi. Lo facevamo trasformare in bicicletta, lo trascinavamo per tutto lo schermo, cliccavamo su di lui per vedere cosa faceva.

“Sembra che tu stia scrivendo una lettera. Vuoi aiuto?”

No Clippy, stiamo scrivendo “CULO CULO CULO” per vedere quante volte entra in una pagina. Ma grazie lo stesso.

Lo trattavamo male, come si trattano male le cose che non si capiscono…

Per noi però non funzionava mai abbastanza bene: voleva aiutarci a fare cose che non stavamo effettivamente facendo, era come avere un compagno di classe che alza sempre la mano per rispondere alla domanda sbagliata.

Non potevo saperlo all’epoca, ma stavo guardando il futuro.

Solo che era arrivato con 25 anni di anticipo.

Perché Clippy doveva esistere (e perché tutti lo odiavano)

Per capire Clippy bisogna tornare al 1995.

Microsoft aveva un problema: Office era potente, ma complicato (era nuovo d’altronde). Le aziende spendevano fortune in formazione e nel mentre gli utenti usavano forse il 10% delle funzionalità.

Allora pensarono a una soluzione. Proprio lui.

Un assistente virtuale che ti guidasse nell’utilizzo di Office. L’idea veniva da ricerche di Stanford che dicevano che trattiamo i computer come persone. Quindi perché non dargli letteralmente una personalità?

Prima provarono con Microsoft Bob, un intero sistema operativo con assistenti animati. Flop gigantesco.

Ma non si arresero. così presero il concept e lo integrarono in Office.

I numeri di Office furono incredibili:

• 20 milioni di licenze vendute in un anno

• 60.000 copie al giorno

• Clippy finì su centinaia di milioni di computer

Il team aveva testato 250 personaggi diversi e Clippy vinse perché nei focus group risultava “il più affidabile e coinvolgente“.

Purtroppo anche lui non andò benissimo.

Time Magazine lo mise tra le “50 peggiori invenzioni di sempre” e Smithsonian Magazine lo definì “uno dei peggiori errori di design software negli annali dell’informatica”.

Il nome in codice interno era “TFC”, ufficialmente “The Friendly Character”.

In realtà, come ammise il manager Steven Sinofsky, stava per “The Fucking Clown”.

Clippy era Copilot, solo che non lo sapevamo

Ecco il paradosso che mi fa impazzire.

Clippy voleva fare ESATTAMENTE quello che fanno oggi ChatGPT, Claude e Copilot:

• Capire cosa stai scrivendo

• Suggerirti come migliorarlo

• Aiutarti con la formattazione

• Rispondere alle tue domande

• Essere il tuo assistente personale

E quindi cosa non è andato? Te lo dico io:

Tecnologia: Clippy aveva algoritmi degli anni ‘90 che riconoscevano pattern basilari. Gli LLM di oggi hanno miliardi di parametri e capiscono davvero il linguaggio.

Interfaccia: Clippy appariva senza essere chiamato (push). ChatGPT aspetta che tu lo cerchi (pull). Se ci pensi, è la differenza tra un venditore porta a porta e un negozio.

Contesto culturale: Nel 1997 la gente stava ancora imparando a usare il mouse. L’idea di “parlare” con il computer era fantascienza. Oggi chiediamo a Siri che tempo fa mentre ci laviamo i denti (per dirne una).

Il timing non è solo “quando”

La vera lezione di Clippy non è che fosse una cattiva idea.

È che nel tech, il timing non riguarda solo il QUANDO, ma anche il COME e il CON COSA.

La vera lezione di Clippy alla fine è solo una: non era una cattiva idea, ma nel Tech il timing non è solo il QUANDO, ma è anche il COME e CON COSA.

Il QUANDO conta: Nel 1997 il mondo non era pronto per un assistente digitale. Non c’era la banda larga, i computer erano lenti e la gente ancora stampava le email.

Il COME è fondamentale: L’esecuzione può uccidere anche l’idea migliore. Clippy non aspettava mai un tuo input, ti interrompeva sempre, pensava di conoscerti e non faceva domande per capire il tuo contesto.

Il CON COSA fa la differenza: Puoi avere la visione giusta, ma gli strumenti sbagliati. È come provare a costruire Tesla nel 1950, l’idea dell’auto elettrica c’era già… ma le batterie facevano schifo.

Microsoft aveva capito che serviva un assistente.

Aveva capito che il software era troppo complesso. Aveva pure capito che serviva un’interfaccia più umana.

Ma era il 1997, non il 2025.

E a volte, avere ragione troppo presto è peggio che avere torto.

Dal funeral party alla rivincita postuma

Nel 2001, Microsoft decide che è ora di dire addio a Clippy. Ma invece di farlo sparire in silenzio, organizzano un vero e proprio spettacolo.

Nel 2001 Microsoft decide che è ora di dire addio a Clippy, però invece di farlo sparire in silenzio organizza un vero e proprio spettacolo.

Al lancio di Office XP a New York, un attore vestito da Clippy irrompe sul palco. Implora, piagnucola, chiede di riavere il lavoro e due uomini lo trascinano via con un magnete gigante.

Nel mentre, sul sito Microsoft appare un gioco in Flash: puoi finalmente “uccidere” Clippy sparandogli graffette.

Infine, producono video con Clippy doppiato da Gilbert Gottfried, disoccupato e depresso.

Microsoft ha letteralmente speso soldi per prendere per il culo il proprio prodotto.

Nel 2019 Clippy diventa sticker su Teams. Nel 2021, un tweet di Microsoft che promette di riportarlo come emoji ottiene 170.000 like (ne chiedevano 20.000).

E nell’agosto 2025 Louis Rossmann, YouTuber con 2,3 milioni di follower, lancia una protesta contro le Big Tech che sfruttano i nostri dati. Il simbolo? Clippy.

“Rappresenta un’epoca in cui le aziende volevano solo aiutarti, senza monetizzare i tuoi dati“

Il video fa 3,5 milioni di views e migliaia cambiano avatar mettendo Clippy.

La graffetta più odiata della storia diventa simbolo di privacy e resistenza.

Il cerchio si chiude

Quel bambino di 9 anni che trascinava Clippy per lo schermo oggi usa ChatGPT tutti i giorni.

La differenza è che ora so esattamente cosa sta succedendo, so cosa do in cambio e so cosa ricevo.

Ma ogni tanto, quando ChatGPT mi riscrive una mail o Copilot mi suggerisce come completare una funzione, penso a quella graffetta.

Aveva capito tutto: l’assistente personale, l’aiuto contestuale e l’intelligenza artificiale al servizio dell’utente.

Era solo arrivata con la tecnologia sbagliata, nel momento sbagliato, con l’approccio sbagliato.

Ma l’idea era giusta.

Tanto giusta che oggi vale miliardi… Solo che ora si chiama ChatGPT, Claude, Copilot. E nessuno ride più.

Anzi, paghiamo 20 euro al mese per avere quello che Clippy voleva darci gratis.

Il progresso a volte è solo questione di aspettare che il mondo sia pronto per le tue idee.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri

Il suo CV era perfetto, tecnicamente.

Aveva anni di esperienza, il colloquio tecnico era andato benissimo e aveva risposto senza esitazione.

Ci diciamo: “Finalmente l’abbiamo trovato”. Poi firma il contratto, inizia e le prime settimane sembrano andare molto bene.

Tecnicamente era forte, nessun dubbio. A un certo punto, però, iniziano ad arrivare i segnali.

Comincia a rispondere male in chat, a saltare le riunioni dicendo “non m’interessa l’argomento”, e infine a criticare il lavoro dei colleghi.

La situazione peggiora nel tempo, non risponde più male solo ad alcune persone, ma a tutti.

È maleducato, geloso del suo lavoro e si sente superiore. Ogni suggerimento sembra un attacco personale.

Il team inizia a cambiare: le persone evitano di lavorare con lui, le pull request si fermano in attesa di un cenno, perché nessuno vuole affrontare la sua reazione. In ultimo, l’atmosfera si fa pesante. Troppo.

E noi? Noi temporeggiamo.

“Magari si ambienta.”

“Dai, è solo stressato per il nuovo lavoro.”

“Però tecnicamente è bravo, non possiamo perdere uno così.”

Così abbiamo fatto passare il periodo di prova, e quando finalmente abbiamo capito che non potevamo più andare avanti così, mandarlo a casa è diventato complicato (e costoso).

Ma non solo economicamente eh, il danno vero era ciò che aveva fatto al team. Persone che prima lavoravano bene assieme, avevano perso fiducia. L’ambiente era diventato tossico.

Quando se n’è andato, il giorno dopo in ufficio c’era un’altra aria.

In quel momento ho realizzato una cosa: saper scegliere le persone giuste è il 50% del lavoro di ogni founder, di ogni tech leader e di chiunque debba costruire un team.

E indovina? Io, fino a quel momento, lo stavo facendo male.

Come sbagliavo (e forse lo stai facendo anche tu)

Prima di quella esperienza, il mio modo di fare hiring era semplice: guardavo le competenze tecniche.

Il CV arrivava già pre-scremato dall’HR, io facevo il colloquio tecnico e se sapeva fare quello che serviva, andava bene.

“Conosce React? Check.”

“Ha esperienza con i microservizi? Check.”

“Sa scrivere codice pulito? Check.”

Ottimo.

Assunto.

Pensavo che le skill tecniche fossero tutto. Se sai fare, il resto si sistema.

E invece no, non si sistema un bel niente.

Perché puoi essere il developer più bravo del mondo, ma se nessuno vuole lavorare con te, crei più danno che vantaggio.

E io ci ho messo anni a capirlo.

Come sono cambiato

Dopo quel disastro, ho iniziato a ragionare diversamente.

Mi sono chiesto: cosa sto cercando davvero quando assumo qualcuno?

La risposta non era più “qualcuno che sa fare X tecnologia.”

La risposta era: qualcuno che ha risolto problemi. E voglio capire quali, come e con chi.

La tecnologia è diventata un mezzo, non il fine.

Quello che contava davvero era:

• Che problemi hai affrontato nella tua carriera?

• Come li hai risolti?

• Con chi hai lavorato?

• In che ambienti?

Ho iniziato a guardare le persone, non solo i CV. E ho iniziato a chiedermi: questa è una persona su cui vale la pena investire?

Anche se non è perfetta tecnicamente. Anche se le manca qualche skill. Ma è una persona con cui si può lavorare? Che può crescere? Che vuole crescere?

Perché a volte è meglio assumere qualcuno meno skillato ma con cui puoi costruire, piuttosto che il “senior perfetto” che poi distrugge il team.

Come funziona oggi

Oggi faccio l’hiring in due modi diversi: quando cerco collaboratori diretti per i miei progetti e quando seguo il processo di assunzione per le startup che seguo come Fractional CTO.

In entrambi i casi, la filosofia è la stessa, ma il processo cambia.

Premessa importante

Qualche mese fa ho fatto un post su LinkedIn cercando collaboratori.

Mi sono arrivate 300 candidature.

Quando ho visto il numero, per un secondo ho pensato: “Mo sono cazzi….” (senza filtri, no?)

Ho pensato di automatizzare tutto o usare qualche tool di screening… ma non me la sono sentita.

Così ho fatto una cosa probabilmente poco scalabile ma che per me aveva senso: le ho lette tutte.

Una per una.

Ci ho messo settimane. Ho avvisato subito tutti che ci avrei messo tempo, che avrei risposto a tutti (anche con un no).

E l’ho fatto: tutti i 300, anche quelli che non andavano bene, hanno ricevuto un feedback.

Perché nell’hiring è anche chi viene assunto che sceglie, non è solo una strada a senso unico.

E questa cosa vale sia per me, sia quando lavoro con i founder delle startup.

Spesso mi capita di vedere aziende che trattano i candidati come numeri: nessun feedback e processi che durano mesi senza comunicazioni.

E poi si lamentano che non trovano persone.

Il punto è che il talento oggi sceglie.

E sceglie chi li rispetta già dal processo di selezione.

Come faccio la prima scrematura

Oggi, la prima cosa che guardo non è il CV. È il profilo LinkedIn.

Per me è diventato il vero biglietto da visita. Più del CV.

Cosa guardo:

• Come è scritto. La scelta delle parole. Se le tecnologie sono menzionate con senso o buttate lì a caso.

• Le esperienze. Non i titoli, ma quello che è stato fatto. I problemi risolti. I risultati.

• Come si presenta. Non il design fighetto, ma la capacità di comunicare chi è e cosa sa fare.

• Come si relaziona sui social (sì, ti osservo quando commenti e cosa commenti).

Se il profilo LinkedIn non mi convince, difficilmente vado avanti.

Se invece mi convince, parto con il processo.

I colloqui: come cambiano in base al contesto

Quando assumo collaboratori diretti, faccio due colloqui:

Primo colloquio: conoscitivo

Qui non parlo quasi di tecnologia. Parlo di esperienze, di contesto e di team.

Voglio capire:

• In che ambienti hai lavorato

• Che problemi hai affrontato

• Come li hai risolti

• Con chi hai collaborato

E soprattutto voglio capire: sei una persona o sei una macchina?

Perché il CV lo sanno scrivere tutti… ma la persona, quella la vedi solo dal vivo.

Secondo colloquio: tecnico

Se passa il primo step, andiamo sul concreto. Test teorici e pratici: live coding, architetture e problem solving.

Ma anche qui, non mi interessa solo se “sai fare”, mi interessa “come pensi”.

Quando invece seguo il processo per le startup che seguo come Fractional CTO, il processo è più strutturato e coinvolge tre step:

Primo step: HR/Comportamentale

Qui lavoro con il team HR (o lo faccio io se non c’è) per valutare le soft skills, la motivazione, il fit culturale. Questo permette di scremare subito chi non è allineato con i valori dell’azienda.

Secondo step: Tecnico

Qui entro io. Valuto le competenze, faccio test pratici, verifico che sappia pensare e risolvere problemi.

Terzo step: Decisionale

L’ultima call è con i founder, i tech leader o comunque chi poi lavorerà direttamente con quella persona. Perché alla fine, devono essere loro a dire: “Sì, voglio questa persona nel mio team.”

Il mio ruolo è portare davanti ai founder solo candidati che hanno già passato i primi due filtri. Non gli faccio perdere tempo con persone che non vanno bene.

Le red flags che non ignoro più

Durante i colloqui, ci sono cose che ormai mi fanno scattare l’allarme immediatamente.

1. Parla sempre di “noi” e mai di “io”

“Noi abbiamo fatto questo progetto.”

“Noi abbiamo risolto questo problema.”

Ok, ma tu cosa hai fatto? Qual è stato il tuo contributo specifico?

Se dopo tre domande continui a dirmi “noi”, vuol dire che probabilmente quel problema non l’hai risolto tu. E se non l’hai risolto tu, non hai quell’esperienza.

2. Risponde con “nella mia azienda facciamo così”

Gli chiedo: “Come affronteresti questo problema?”

Mi risponde: “Beh, nella mia azienda attuale facciamo così“

Io non ti sto chiedendo cosa fa la tua azienda. Ti sto chiedendo cosa faresti TU.

Se non sai pensare in autonomia, è un problema.

3. Non fa domande

Se la risposta è “No, tutto chiaro,” è una red flag gigante.

Come fai a non avere curiosità? Come fai a non voler sapere niente sul progetto, sul team, sugli strumenti, sulle sfide?

L’entusiasmo si vede anche da questo. E se non c’è entusiasmo, non c’è voglia di lavorare insieme.

4. È maleducato o arrogante

Questa ormai la intercetto subito dal tono di voce, dal modo di rispondere o da come parla degli ex colleghi o dell’azienda precedente.

Se durante un colloquio, dove teoricamente uno si presenta al meglio, già emergono segnali di maleducazione o arroganza, immagina quando sarà dentro al team.

La domanda finale che mi faccio (e faccio fare) sempre

Alla fine di ogni colloquio, mi fermo e mi chiedo una cosa sola:

“È una persona con cui vorrei lavorare?”

Vorrei passare 8 ore al giorno a collaborare con questa persona?

Vorrei che facesse parte del team?

Se la risposta è no, non importa quanto sia bravo… Non va bene.

E quando lavoro con i founder, gli insegno a farsi la stessa domanda.

Perché loro saranno quelli che ci lavoreranno ogni giorno. E se io sono convinto ma loro non lo sono, allora non è la persona giusta.

Dai sempre un feedback (anche quando è un no)

Una cosa che ho imparato è che il feedback è fondamentale. Sempre.

Sia quando dico sì, sia quando dico no.

Quando do un feedback negativo, cerco di essere chiaro ma rispettoso:

“Guarda, secondo me ad oggi non sei la persona giusta per questo tipo di attività. Stiamo cercando qualcuno con più esperienza in X. Probabilmente non è il momento giusto.”

E quando possibile, cerco anche di dare spunti su come migliorare.

Il 99,9% delle persone la prende bene. Non bene bene, ovvio. Nessuno è felice di un no, ma lo apprezzano.

Perché è meglio un no chiaro che essere ghostati.

E c’è un’altra cosa che faccio, che molti non si aspettano: chiedo feedback anche a loro.

“Come ti sei trovato con il colloquio? C’è qualcosa che avresti cambiato?”

Perché l’hiring è una strada a doppio senso. E se voglio migliorare, devo ascoltare anche dall’altra parte.

Questa cosa la insegno anche ai founder con cui lavoro.

All’inizio mi guardano straniti: “Ma perché devo chiedere feedback a chi non assumo?“

Semplice: perché quel candidato scartato oggi potrebbe essere quello giusto domani. O potrebbe parlare bene (o male) di te nel suo network.

E soprattutto, perché ti dice dove puoi migliorare il tuo processo.

Cosa ho imparato davvero

Dopo anni di colloqui, la lezione più importante è questa:

Per me, vince sempre la persona con cui vuoi lavorare davvero.

Puoi essere tecnicamente bravo quanto vuoi, ma se crei più danno che vantaggio, non servi a niente.

E al contrario, puoi essere meno skillato di altri, ma se sei una persona su cui si può investire, su cui si può contare, con cui si può costruire, allora vali molto di più.

Perché le competenze si imparano. Il modo di essere, molto meno.

E soprattutto, ho capito che saper mandare a casa è importante quanto saper assumere.

Se sbagli un’assunzione (e succede), la cosa peggiore che puoi fare è temporeggiare, perché no, le cose non si sistemano da sole.

Il danno si accumula, deteriore il team, il progetto e l’ambiente. E quando finalmente ti decidi ad agire… è già troppo tardi.

Questa è una delle cose più difficili da far capire ai founder, perché hanno paura di ammettere l’errore, di apparire incapaci.

Ma la verità è che tenere la persona sbagliata costa molto di più che mandarla a casa.

La domanda che ti lascio

La prossima volta che fai un colloquio, chiediti:

Sto cercando qualcuno che “sa fare” o sto cercando qualcuno con cui voglio lavorare?

Non tutto si vede sulla carta…

E non tutto si risolve con le competenze tecniche.

A volte la differenza tra un team che funziona e uno che implode è solo questa: aver scelto le persone giuste.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri