Il consiglio standard per un founder early-stage suona familiare: costruisci in fretta la prima versione del prodotto, lancia, itera con i clienti. Ash Maurya, autore di Running Lean e creatore del Lean Canvas, sostiene che questo approccio era valido dieci anni fa e oggi non funziona più. Il motivo non è ideologico, è strutturale: il costo di costruire prodotti è ai minimi storici, quindi i clienti hanno molte più alternative per lo stesso job. Davanti a un MVP a metà, non si trasformano in early adopter pazienti, ti lasciano e passano al concorrente. Senza feedback diretto, il founder resta a tirare a indovinare quale feature aggiungere — quella che Maurya chiama la modalità "spaghetti contro il muro".
La premessa originaria dell'MVP era ragionevole: meglio rilasciare qualcosa di imperfetto subito che spendere mesi su un prodotto che nessuno vuole. Maurya non contesta la logica, contesta il contesto in cui si applica. Quando le barriere d'ingresso erano alte e le scelte poche, un alpha grezzo era accettabile per il cliente. Oggi i prodotti competono in mercati saturi e la finestra di attenzione è strettissima. Un MVP che non eroga valore al primo colpo viene scartato senza appello, e tu rimani con metriche che ti dicono solo cosa sapevi già — nessuno sta comprando — senza dirti il perché.
L'inversione di Maurya è semplice nel principio e impegnativa nell'esecuzione. La sequenza non è build-demo-sell ma demo-sell-build. La demo non è un prototipo deluxe né una landing page generica: è il proxy del prodotto, lo standing per qualcosa che ancora non esiste. Se chi guarda la demo è disposto a comprarla — pre-ordine, deposito, pilot — allora vale la pena costruire. Maurya ricorda che ogni campagna di crowdfunding di successo è demo-sell-build all'opera, e che nelle vendite B2B complesse la demo gioca un ruolo centrale ben prima del pilot. Confezionare la demo in un'offerta esplicita permette di testare in un colpo solo le tre assunzioni più rischiose del business model: la value proposition (stai risolvendo un problema abbastanza grosso?), la soluzione (il tuo approccio convince?), il pricing (quanto sono disposti a pagare?).
C'è però un avvertimento. Anche partire dalla demo, da soli, non basta. La maggior parte delle prime demo cade piatta perché il founder sta ancora tirando a indovinare cosa vogliono i clienti. Si finisce nella offer trap: una landing page con metriche che dicono che nessuno converte, ma non spiegano perché. Si testa l'headline, poi il copy, poi il prezzo, e le settimane diventano mesi. La via d'uscita non sono demo migliori, ma customer discovery conversation più profonde. Maurya è netto su volumi e obiettivo: non servono 600 survey né 100 interviste, ne bastano 20-30 fatte bene. L'obiettivo non è pitchare la soluzione, è capire il problema del cliente e le sue cause radice meglio di quanto lo capisca lui stesso. Funziona perché il cliente è troppo occupato a spegnere incendi per studiare i propri problemi — è la stessa ragione per cui esistono terapeuti e coach.
Quando il founder unisce due "superpoteri" — sa progettare la soluzione giusta perché il problema è chiaro, e sa pitchare in modo che il cliente lo riconosca come esperto — il risultato non è una demo qualsiasi ma una mafia offer. Maurya ha coniato il termine ispirandosi a Il Padrino: un'offerta che il cliente non può rifiutare, non per pressione commerciale ma perché la soluzione combacia esattamente con il problema sentito. È qui che si decide il gioco. Se non riesci a far comprare l'offerta, non hai il diritto di costruire l'MVP. Se invece l'offerta vende, non solo sai cosa costruire: passi dal "spero che lo comprino" al "so che lo compreranno", e moltiplichi le probabilità di successo. La domanda finale — quanti clienti servono per dichiarare validato l'offer — Maurya la rimanda al traction roadmap, parte del business model design che tratta in altri contenuti.
**Key takeaways**: - L'MVP nasce in un'epoca con barriere d'ingresso alte: oggi i clienti hanno troppe alternative e ti abbandonano davanti a un prodotto a metà invece di darti feedback - Il metodo è demo-sell-build, non build-demo-sell: i clienti non comprano un prodotto funzionante, comprano una promessa di qualcosa di meglio - Una demo ben confezionata in offerta testa i tre rischi più grossi del business model: value proposition, soluzione, pricing - Servono 20-30 customer discovery interview per capire il problema meglio di quanto lo capiscano i clienti stessi (non 600 sondaggi, non 100 interviste) - L'output finale non è una demo qualsiasi, ma una mafia offer: un'offerta che il cliente non può rifiutare perché la soluzione calza esattamente sul problema **FAQ**: - Q: Quindi l'MVP è morto? A: No, ma è spostato più avanti nel processo. Maurya non dice di non costruire mai un MVP, dice di non partire dall'MVP. Prima vengono customer discovery, demo e sell. L'MVP arriva quando hai già clienti che hanno detto sì all'offerta. - Q: Cosa intende Ash Maurya per 'demo'? A: Non un prototipo funzionante, ma un proxy del prodotto: una landing page con offerta esplicita, un pitch deck, un pre-order, una crowdfunding campaign, un mockup mostrato in conversazione vendita. Tutto ciò che permette al cliente di dire sì o no senza che tu abbia ancora costruito il prodotto. - Q: Bastano davvero 20-30 interview di customer discovery? A: Maurya sostiene di sì, a patto che siano interview ben strutturate per estrarre cause radice del problema, non per pitchare la soluzione. Più interviste non aiutano se sono fatte male; meno bastano se sono profonde. - Q: Cos'è la mafia offer? A: Termine coniato da Maurya ispirandosi al Padrino. È un'offerta che il cliente non può rifiutare perché la soluzione risolve il suo problema in modo esatto. La differenza con un'offerta normale è che il cliente ti riconosce come esperto del suo problema prima ancora di valutare la soluzione. - Q: Questo metodo funziona anche per prodotti B2B complessi? A: Maurya sostiene di sì, anzi sostiene che funziona ancora meglio. Più la vendita è complessa, più la demo gioca un ruolo decisivo prima del pilot. La differenza è che la demo B2B è una conversazione strutturata o un proof of concept, non una landing page con bottone pre-order. ### Solo founder, exit 80M$ in 6 mesi: Base44 | Maor Shlomo URL: https://startupmentors.it/video/base44-maor-shlomo-lennys YouTube: https://youtu.be/L9KvV_UOs3A Channel: Lenny's Podcast · 92 min · mvp-build Personas: founder, builder **Perché vale**: Maor racconta come ha portato Base44 da zero a 80M$ di exit in sei mesi, solo founder, senza raccogliere un euro. Stack, growth via build in public, lezioni su activation e acquisition: il manuale per competere con Lovable, Bolt, Replit. **Riassunto**:Maor Shlomo aveva appena chiuso sette anni come CEO di Explorium, una startup B2B enterprise nello spazio dati su cui aveva raccolto 130 milioni di dollari. Dopo l'attacco del 7 ottobre 2023 era andato in riserva quasi un anno. Quando è tornato voleva una sola cosa: smettere di gestire team di vendita, HR e investitori, e tornare a scrivere codice.
Base44 nasce da due trigger concreti. La fidanzata di Maor, un'artista, aveva bisogno di un sito per catturare lead e i tool no-code esistenti erano una sofferenza tra drag and drop, layout mobile rotti e gestione dati impossibile. In parallelo, da volontario per i Tzofim (gli Scout israeliani, decine di migliaia di persone), si scontrava con il fatto che ogni piccolo software interno veniva quotato un milione di dollari dalle agenzie. Maor sapeva che gli LLM potevano scrivere quel codice: mancava solo l'infrastruttura giusta sotto.
L'inizio è anti-hype: niente VC, niente category leadership, solo "costruisco una cosa che mi serve e che mi diverte". Sul volo di ritorno da un viaggio in Asia dice alla fidanzata: "se arriviamo a 1,5 milioni di ARR entro fine 2025 ci compriamo una bella macchina". Ci arriva in quattro settimane.
Maor è rimasto da solo per quasi tutta la vita di Base44. Il primo hire, un product person tuttofare di nome Yoav, è entrato un mese e mezzo prima dell'acquisition. Prima ancora, "team" significava letteralmente Maor che gestiva flotte di LLM che scrivevano codice al posto suo: nei tre mesi precedenti l'exit non ha scritto una sola riga di HTML o JavaScript.
Il bootstrap, ammette, non è per tutti. Per un B2B enterprise serve un sales team, e senza fundraising è impossibile. Per un prodotto B2C virale è invece il setup migliore: zero pressione da investitori, default alive dal giorno uno, decisioni rapide. La parte brutale è la prioritizzazione: ogni mattina la lotta interna tra "voglio lavorare al prodotto" e "devo lavorare al marketing perché il bottleneck è lì". E poi i momenti in cui sei solo a gestire il fuoco, come la sera del matrimonio del fratello quando un amico lo chiama per dirgli "qualcuno ha hackerato Base44, è uno scam crypto". Due ore con il laptop in bagno per scoprire che era un falso allarme: il modello aveva usato il pacchetto Node.js cryptography, l'utente non tecnico aveva visto la parola e si era spaventato.
L'ADHD severo, dice Maor, è una superpotenza solo se proteggi il deep work. Per questo usa RescueTime per bloccare Twitter e LinkedIn nelle ore di build, e ha vibe-coded dentro Base44 stesso il proprio tool di content production: scrive un'idea grezza, l'app la trasforma in post LinkedIn nel suo tono, poi in thread Twitter, mantenendo coerenza con i post precedenti salvati come reference.
Base44 gira su Render.com (infrastruttura cloud sopra AWS, gestione semplificata di web app, processi e scaling). Il database è MongoDB perché gli schemi cambiano in continuazione: gli LLM non sempre capiscono cosa vuole l'utente e mutano la struttura dati ad ogni iterazione, e uno schema flessibile è meno fragile.
Il backend è in Python. Maor sa che è una scelta divisiva, ma in produzione regge anche tentativi di DDoS. Il frontend è in JSX, non TypeScript: la sua tesi controintuitiva è che i modelli scrivono codice migliore in plain JavaScript, senza il rumore dei tipi. La regola più importante per il code repository: tutto in un singolo monorepo, frontend e backend vicini, perché l'AI deve poter leggere il contesto pieno in un colpo solo.
Il pezzo più interessante è il routing multi-modello. Base44 non usa un solo LLM: smista la richiesta in base al tipo di task. Claude 4 per il prompt iniziale e il design UI, dove eccelle. Gemini per problemi algoritmici complessi o quando Claude resta intrappolato in un bug loop. Modelli più piccoli e veloci (Gemini Flash, o4-mini) per le patch chirurgiche dentro un file esistente. La filosofia generale: fai in modo che l'LLM scriva il meno codice possibile. Più boilerplate generi da zero, più punti dove sbagliare e più token da tenere in context per le iterazioni successive. Per questo Base44 espone SDK e endpoint pensati per essere consumati da modelli, non da umani.
La playbook di growth di Maor è un manuale per builder con budget zero.
I primi tre utenti sono amici stretti, due dei quali disoccupati al momento giusto. Maor li fa sedere al tavolo ogni due giorni, li guarda usare Base44, prende le richieste rotte e le sistema in tempo reale. Niente survey, niente call asincrone: presenza fisica, observability brutale.
La regola che si dà: non investo niente in marketing finché non vedo che gli utenti condividono il prodotto spontaneamente. Quando gli amici cominciano a portare amici, e l'undicesimo utente è un perfetto sconosciuto, scatta il momento di alzare l'asticella. Il primo lancio Product Hunt è un mezzo flop: 15 nuovi utenti. Maor non lo legge come fallimento ma come strumento per arrivare ai prossimi 30. Il secondo lancio rompe l'algoritmo di Product Hunt, che lo segnala come bot per l'eccesso di voti reali (delta di 500 voti dal secondo classificato): primo prodotto del giorno, della settimana, del mese.
Paid e influencer non hanno funzionato: 2.000 dollari a un influencer non hanno portato nulla, qualche migliaio in ads idem. Quello che ha acceso la growth è il build in public su LinkedIn. Maor pubblica il bello, il brutto e il cattivo: numeri di profit, charts, bug embarrassing, scelte tecniche. L'audience naturale era già allineata (builder, founder, technical operator), e l'angolo "solo founder bootstrappato che combatte contro Lovable e Bolt" funzionava come narrativa underdog. Twitter, dice senza mezzi termini, è stato uno spreco di tempo: tutto il ROI è arrivato da LinkedIn, e una volta visto il segnale ha raddoppiato e triplicato lì invece di disperdersi.
Il secondo growth loop è venuto dal programma di referral inverso: chi pubblicava un post sui social raccontando cosa stava costruendo su Base44 riceveva crediti extra. All'inizio la verifica era manuale via email, poi automatizzata. Aggiunto a questo, l'hackathon 4Good: 3.000 team registrati, prize iniziale di 5.000 dollari pagato di tasca propria con i profit del prodotto, poi sponsor di livello (Amazon, Google, MongoDB, Deloitte) che hanno aperto le proprie sedi in tutto il mondo per ospitare i team.
All'inizio Base44, prima di generare l'app, mostrava all'utente uno user flow generato dal modello. Una specie di mini-PRD che diceva "ho capito che vuoi una task management app con questi step, confermi?". Era la cosa "giusta" da fare: forzava l'allineamento, riduceva i misunderstanding, produceva app migliori.
Maor l'ha tolta. Le conversion al momento aha erano troppo basse. La sua tesi: in un prodotto B2C il momento magico non è "il modello mi ha capito bene", è "cazzo, ha capito davvero, e l'app è già qui". Ogni step intermedio diluisce quella sorpresa. L'attention span è basso, il time-to-aha-moment va compresso a un paio di minuti, e il prezzo da pagare in qualità del prodotto generato è accettabile, perché il polish lo fai dopo, una volta che l'utente è già dentro.
Wix si è fatta avanti dopo che parte della community di Base44 aveva iniziato a scrivere su LinkedIn "Wix dovrebbe comprare Base44 prima che sia troppo tardi". Stesso ecosistema israeliano, customer base sovrapposta (utenti che costruivano siti su Base44), DNA simile. La frase di apertura di Avishai, CEO di Wix, è stata: "tutti dicono che dovremmo comprarvi, magari almeno parliamo".
Maor sottolinea due cose. Prima, la chemistry conta tantissimo quando il buyer sta acquisendo un team piccolo o un solo founder: stanno comprando una persona, non un'organizzazione, e quella persona deve essere una con cui hanno voglia di lavorare per anni. Seconda, la posizione negoziale migliore è essere genuinamente ok anche se il deal salta: come negli appuntamenti, non puoi mostrare troppo interesse. Base44 era profittevole (vicino a 200K di profit a maggio), poteva continuare da sola, e questo cambiava il framing della conversazione.
La struttura del deal è 80 milioni iniziali più un earnout significativo legato alla performance dentro Wix. Per Maor è il setup ideale: continua a presentarsi al lavoro ogni mattina perché ha skin in the game personale, non è uno che ha venduto e vuole sparire.
La firma è arrivata di giovedì notte, con la deadline che il team si era imposto. I lawyer alle 2 del mattino chiedevano un altro giro di revisioni di forma. Maor ha detto "andiamo a dormire e firmiamo domattina". Alle 4 del mattino è scoppiata la guerra con l'Iran. La mattina dopo, sotto allarmi e missili, hanno firmato comunque.
Chiusura di Maor: passa almeno metà del tuo tempo nelle cose in cui sei un genio e che ti energizzano. Non il 100%, perché ogni lavoro ha le sue parti noiose. Ma il 50% è la soglia minima per restare carichi a lungo termine. È quello che differenzia un founder talentuoso che brucia in due anni da uno che continua a costruire per dieci.
Sul "è il momento giusto per costruire" Maor è netto: stiamo entrando in un'epoca più grande della rivoluzione di internet. Costruire quello che vuoi non è mai stato così facile. Se va bene cambia la vita, se va male ti resta poco rimpianto. Il rischio asimmetrico è dalla tua parte.
**Key takeaways**: - $1M di ARR in tre settimane bootstrappato: il vantaggio strutturale del solo founder è che non devi scalare team, devi scalare velocity. Maor ha gestito Base44 da solo per oltre quattro mesi, prima hire (un product person tuttofare) solo a un mese e mezzo dall'acquisition. - Build in public su LinkedIn è stato l'unico canale di growth che ha funzionato: paid e influencer ($2.000 spesi) hanno reso zero, mentre condividere onestamente metriche, bug e processi ha portato i primi 1.000 utenti e poi migliaia al giorno. - Stack opinionato per LLM coding: Render.com per infrastruttura, MongoDB (schemi flessibili), Python backend, JSX invece di TypeScript, monorepo unico per dare contesto pieno all'AI. Routing multi-modello: Claude 4 per UI e prompt iniziali, Gemini per algoritmi complessi e bug loops, modelli più piccoli (Flash, o4-mini) per patch chirurgiche. - L'activation triplica rimuovendo feature 'utili': Maor ha tagliato lo step di preview user flow prima della generazione app perché allungava il time-to-aha-moment. La regola: in B2C l'attention span è bassissimo, devi arrivare al 'cazzo, ha capito davvero quello che volevo' in due o tre minuti. - Acquisition Wix da 80 milioni firmata alle 4 del mattino mentre scoppiava la guerra con l'Iran. Earnout strutturato per allineare incentivi: la parte rilevante della compensation arriva solo se Base44 cresce dentro Wix. Maor: 'la posizione migliore per negoziare è essere genuinamente ok anche con il path opposto'. **FAQ**: - Q: Si può davvero costruire una startup AI da solo founder e fare un exit da 80 milioni? A: Sì, ma con vincoli precisi. Maor Shlomo ha bootstrappato Base44 in sei mesi senza raccogliere capitali, restando solo founder per oltre quattro mesi prima del primo hire. Il setup funziona per prodotti B2C virali con potenziale di word-of-mouth, non per B2B enterprise dove serve un sales team. Il prerequisito è essere già un builder esperto: Maor era stato sette anni CEO di una startup precedente (Explorium, 130M$ raccolti) e non ha scritto una riga di HTML o JavaScript negli ultimi tre mesi perché gestiva flotte di LLM al posto suo. - Q: Quale stack tecnico ha usato Maor Shlomo per costruire Base44 con LLM? A: Render.com per l'infrastruttura cloud, MongoDB come database (schema flessibili adatti a vibe coding), Python per il backend, JSX invece di TypeScript per il frontend (tesi: i modelli scrivono codice migliore in plain JavaScript). Tutto in un singolo monorepo per dare contesto completo all'AI. Il routing multi-modello smista le richieste: Claude 4 per UI e prompt iniziali, Gemini per problemi algoritmici complessi e bug loops, modelli più piccoli e veloci (Gemini Flash, o4-mini) per patch chirurgiche dentro file esistenti. Filosofia: l'LLM deve scrivere il meno codice possibile, perché ogni token in più è un punto in cui può sbagliare. - Q: Come ha fatto Base44 a crescere fino a 400.000 utenti senza budget marketing? A: Tre leve principali. Primo: build in public su LinkedIn con totale onestà su numeri, bug e scelte tecniche, sfruttando l'angolo underdog del solo founder bootstrappato contro Lovable e Bolt. Twitter non ha funzionato, paid e influencer (2.000$ spesi) zero risultati. Secondo: programma di referral inverso: chi postava sui social cosa stava costruendo su Base44 riceveva crediti extra. Terzo: hackathon 4Good con 3.000 team partecipanti, prize iniziale di 5.000$ pagato dai profit, poi sponsor di livello (Amazon, Google, MongoDB, Deloitte). La regola: non investire in marketing prima di vedere che gli utenti condividono il prodotto spontaneamente. - Q: Cos'è la lezione sull'activation che ha triplicato le conversioni di Base44? A: All'inizio Base44, prima di generare l'app, mostrava all'utente uno user flow generato dal modello come mini-PRD per confermare la comprensione. Era la scelta 'corretta': riduceva i misunderstanding e produceva app migliori. Maor l'ha tolta perché abbassava le conversion al momento aha. La sua tesi: in B2C il momento magico non è 'il modello mi ha capito bene', è 'cazzo, ha capito davvero, e l'app è già qui'. Ogni step intermedio diluisce quella sorpresa. Il time-to-aha-moment va compresso a due o tre minuti, e il polish del prodotto si fa dopo, una volta che l'utente è dentro. - Q: Come si negozia un'acquisition da solo founder? A: Maor ha individuato due principi. Primo, la chemistry conta tantissimo quando il buyer sta acquisendo un team piccolo: non stanno comprando un'organizzazione, stanno comprando una persona con cui dovranno lavorare per anni. Devi essere uno con cui hanno voglia di stare. Secondo, la posizione negoziale migliore è essere genuinamente ok anche se il deal salta: come negli appuntamenti, non puoi mostrare troppo interesse. Base44 era profittevole e poteva continuare da sola, e questo cambiava il framing. Sulla struttura: 80 milioni iniziali più un earnout significativo legato alla performance dentro Wix, per allineare gli incentivi e mantenere skin in the game. ### Bending Spoons: come Ferrari l'ha portata a 2,5 miliardi URL: https://startupmentors.it/video/bending-spoons-luca-ferrari-chapeau YouTube: https://youtu.be/bfTO6dqhE0I Channel: Chapeau · 26 min · case-study Personas: founder, investor **Perché vale**: Se vuoi capire come si costruisce una scaleup tech globale partendo dall'Italia, qui Luca Ferrari spiega senza filtri il modello Bending Spoons: acquisire prodotti con PMF e farli decollare invece di partire da zero. **Riassunto**:Luca Ferrari, co-founder e CEO di Bending Spoons, racconta a Chapeau come una società fondata di notte mentre lui lavorava 80 ore a settimana da McKinsey sia diventata la scaleup tech più grande d'Italia, con una valutazione di 2,5 miliardi di euro, ricavi attesi oltre i 600 milioni e acquisizioni come Evernote, Remini e StreamYard. È una conversazione utile per chi vuole capire come funziona davvero il passaggio da founder a operatore di una holding tecnologica globale, senza scorciatoie e senza l'estetica da pitch.
Ferrari parte raccontando la prima avventura imprenditoriale, Evertale, finanziata con uno schema semplice: tre amici cercano lavoro, chi trova quello più pagato finanzia gli altri due, che lavorano al prototipo. Lui finisce a McKinsey Copenhagen, prima 80 ore alla settimana, poi anche 100 quando il progetto si fa più intenso, mentre dedica altre 30 ore a Evertale. Dorme 4-5 ore a notte, non beve caffè, e quando lascia McKinsey è in una forma fisica così compromessa che non riesce a correre cento metri con i suoi soci.
Evertale fallisce, ma quel fallimento diventa il dato di partenza per Bending Spoons. Osservando founder bravi che falliscono e founder mediocri che riescono, Ferrari arriva a una tesi controintuitiva: nella fase 0-a-1, cioè trovare il product-market fit, la fortuna pesa molto più delle competenze. Le abilità che servono per portare un'azienda da 1 a 10 sono diverse, più legate a esecuzione, tecnologia, design e growth. Bending Spoons sceglie di concentrarsi su questa seconda fase: invece di cercare il PMF, lo compra da chi l'ha già trovato e investe tutto sull'amplificazione.
Quando il conduttore gli chiede di definire l'azienda, Ferrari la descrive come un incrocio tra Google e Blackstone. Da un lato un'anima finanziaria di allocazione di capitali, sofisticata e basata sui dati; dall'altro un'anima operativa di builder che mettono le mani nel codice e nel prodotto. Una combinazione che lui stesso definisce inusuale.
La differenza chiave rispetto a un fondo di private equity è la profondità dell'intervento. Un PE tipico cambia il management, taglia un po' di costi, vende un asset e tiene tre-cinque anni in portafoglio. Bending Spoons quando acquisisce un prodotto lo riscrive da capo. Il caso Remini è il più chiaro: comprata tre anni fa con cinque milioni di utenti attivi mensili e quattro milioni di dollari di ricavi annui, oggi ha 90 milioni di utenti attivi mensili e ricavi vicini ai 150 milioni di dollari. Del prodotto originale è rimasto poco o nulla. Tutto il software è stato riscritto, tutte le funzionalità sono nuove tranne quella embrionale, i modelli di machine learning sono nuovi, la monetizzazione, il marketing e il design sono cambiati. Hanno pagato 40 milioni di dollari, prezzo alto, ma hanno comprato velocità e certezza di risultato. Lo stesso schema si applica a Evernote, prodotto ventennale entrato in fase legacy che ora viene rivisto completamente.
Acquisire una tech company americana da una società italiana non è scontato. Ferrari spiega che la credibilità è una costante, un percorso che si accumula nel tempo. I processi di vendita sono privati, l'azienda venditrice contatta venti o trenta possibili acquirenti, ed essere nella lista è già un risultato.
Il caso Evernote è emblematico: Bending Spoons non era inizialmente nella lista degli invitati al processo, non per cattiveria ma perché non li conoscevano. Sono entrati per vie traverse, hanno fatto un'offerta e dalla reazione sorpresa hanno capito che la loro era probabilmente la più alta. La controparte ha chiesto screenshot del conto in banca per verificare che i soldi ci fossero davvero, una richiesta che a Google non sarebbe stata fatta. La fiducia si costruisce un'acquisizione alla volta.
Ferrari conferma che Bending Spoons ha sempre dato poca equity agli investitori e molta ai dipendenti, internamente chiamati spooners. Il primo round in equity vero, inteso come aumento di capitale, è arrivato solo nel 2023, da 50 milioni, seguito da 150 milioni a inizio 2024 e 155 milioni due mesi prima dell'intervista. Prima c'erano stati round per lo più di secondario, dove i fondi compravano azioni esistenti senza diluire troppo la cap table.
Il risultato è che alcune decine di spooners su circa 400 sono diventati milionari, non tramite IPO ma vendendo quote ai nuovi investitori durante i round secondari. È un modello di liquidità intermedia che permette ai dipendenti di monetizzare senza che l'azienda debba quotarsi, e che Ferrari oggi non ha in programma di cambiare con un'IPO immediata.
Ferrari non nasconde i fallimenti interni. Il più plateale è PlayOn, un tentativo di costruire il Netflix dei giochi mobile: un abbonamento mensile per accedere a un catalogo ampio di giochi indie. L'ipotesi era che gli utenti volessero giocare a tanti giochi brevi e di qualità, pagando uno-dieci dollari al mese. La realtà ha smentito tutto: anche su mobile le persone tendono a giocare allo stesso titolo per molto tempo, e la quota di domanda si concentra su pochi grandi brand non licenziabili. Hanno bruciato molti milioni nel giro di un anno. Anche abbassando il prezzo a un dollaro al mese non funzionava. Il punto, sottolinea Ferrari, è che predire cosa funziona è molto difficile a priori: a posteriori si trova sempre una spiegazione razionale, ma quel processo non aiuta nella decisione iniziale.
Sulla domanda finale ai founder italiani che vogliono provarci, Ferrari è asciutto: la prima cosa da fare è farlo. La maggior parte non lo fa e quando gli chiedi perché tira fuori le tasse, senza essersi mai informata davvero. Per lui è un peccato culturale: si perdono opportunità di occupazione, di innovazione e di elevare la cultura imprenditoriale italiana, che resta indietro proprio perché pochi giovani provano cose nuove e i più bravi spesso vanno via. Il messaggio finale è diretto: avete poco da perdere, le grandi aziende assumeranno comunque tra tre anni, anzi probabilmente più volentieri se avete dimostrato qualcosa.
**Key takeaways**: - Bending Spoons non si comporta come una startup classica: compra software con PMF e ne riscrive prodotto, ML, monetizzazione e marketing per accelerare la fase 1-a-10. - Andare da 0 a 1 e da 1 a 10 richiede competenze diverse: il primo step è dominato dalla fortuna, il secondo dall'esecuzione disciplinata su tecnologia, design e growth. - Il caso Remini: acquisita per 40 milioni di dollari con 5 milioni di utenti attivi mensili, oggi conta 90 milioni di utenti e ricavi vicini ai 150 milioni di dollari. - L'azienda ha sempre dato poca equity agli investitori e molta agli spooners: alcuni dipendenti sono diventati milionari tramite vendite secondarie nei round recenti. - Il consiglio di Ferrari ai founder italiani è asciutto: smettere di nascondersi dietro le tasse, informarsi davvero e iniziare, perché il costo opportunità di non provarci è più alto di quello che sembra. **FAQ**: - Q: Cosa fa Bending Spoons e perché è diversa da una startup classica? A: Bending Spoons è una scaleup tech italiana che acquisisce software già con product-market fit e ne riscrive prodotto, machine learning, monetizzazione e marketing per accelerarne la crescita. Si posiziona come ibrido tra una holding finanziaria sofisticata e un builder operativo, distinguendosi dai fondi di private equity per la profondità dell'intervento tecnologico. - Q: Quanto vale Bending Spoons e che ricavi fa? A: Al momento dell'intervista Bending Spoons era valutata 2,5 miliardi di euro, con ricavi 2024 attesi oltre i 600 milioni. La società è cresciuta principalmente per acquisizioni mirate, non per round di venture capital di entità rilevante: il primo aumento di capitale vero è arrivato nel 2023, seguito da round da 150 e 155 milioni nei mesi successivi. - Q: Quali sono le acquisizioni più importanti di Bending Spoons? A: Le tre acquisizioni più visibili sono Remini, app di photo enhancement comprata per 40 milioni di dollari e cresciuta da 5 a 90 milioni di utenti attivi mensili; Evernote, software di produttività con storia ventennale entrato in fase legacy; e StreamYard, piattaforma di streaming chiusa il giorno stesso dell'intervista. - Q: Perché Luca Ferrari sostiene che andare da 0 a 1 dipenda dalla fortuna? A: Osservando founder dedicati e brillanti che falliscono e founder mediocri che riescono, Ferrari ha concluso che il product-market fit dipende molto dalla fortuna. Le competenze che servono per andare da 0 a 1 sono diverse da quelle per scalare da 1 a 10, fase in cui pesano di più tecnologia, design, growth e disciplina di esecuzione, terreno su cui Bending Spoons ha scelto di concentrarsi. - Q: Come hanno fatto i dipendenti di Bending Spoons a diventare milionari senza un'IPO? A: Bending Spoons ha sempre concesso poca equity agli investitori e molta ai dipendenti, internamente chiamati spooners. Nei round recenti, principalmente di tipo secondario, alcune decine di spooners su circa 400 hanno venduto parte delle proprie azioni ai nuovi investitori, monetizzando in milioni di euro senza che l'azienda dovesse quotarsi in Borsa. ### Biggest Mistakes First-Time Founders Make - Michael Seibel URL: https://startupmentors.it/video/biggest-mistakes-first-time-founders-yc YouTube: https://youtu.be/D56QeyyQMLI Channel: Y Combinator · 7 min · founder-skills Personas: founder **Perché vale**: Sette minuti di Michael Seibel su YC: gli errori che vede ripetere ai first-time founder nel primo anno di azienda. Riconoscili nel tuo team prima che diventino fatali. **Riassunto**:Michael Seibel guida YC dopo aver fondato Justin.tv e visto da dentro la trasformazione in Twitch. In questo intervento condensa in sette minuti gli errori più frequenti dei first-time founder nel primo anno di azienda. Non sono errori fatali presi singolarmente, ma sommati spiegano perché tante startup chiudono prima ancora di trovare il proprio mercato.
Il primo errore è silenzioso e si manifesta dopo qualche mese. Molti founder scelgono un problema perché pensano possa crescere in fretta, perché sembra cool, perché qualcuno potrebbe volerlo. Non perché a loro interessi davvero. Funziona finché tutto va liscio. Quando arrivano i primi sei mesi duri, la motivazione si esaurisce e il founder smette di lavorarci.
La maggior parte delle startup che falliscono, dice Seibel, non muore per ragioni di mercato. Muore perché i founder perdono la voglia di continuare. Sono partiti senza una connessione profonda con il problema, senza essere disposti a dedicargli cinque o più anni della propria vita. La regola operativa è brutale ma utile: prima di scrivere una riga di codice, chiediti se ti vedi su questa cosa per cinque anni anche se va male.
Lo stesso vale per il secondo errore: aiutare utenti verso cui non hai vero interesse. Seibel racconta la storia di Justin.tv. All'inizio l'idea era democratizzare il live video, una missione astratta. La squadra si entusiasmava per il concetto, non per le persone che usavano davvero la piattaforma. Solo quando Emmett Shear ha rifocalizzato l'azienda sui gamer, comunità che lui amava e capiva, è nata Twitch. Il pivot non è stato tecnologico, è stato una riconnessione umana con gli utenti.
Il terzo errore è la scelta del co-founder. Le startup sono talmente dure che avere una relazione preesistente con chi ti accompagna non è un vezzo, è una rete di sicurezza. Amici, colleghi, compagni di un progetto di studio: serve una storia condivisa che ti dica come reggete insieme la pressione e come lavorate quando le cose si rompono. Trovare un co-founder ieri sera a un evento di networking è un punto di partenza pessimo.
Il quarto errore è la conseguenza diretta del terzo: la mancanza di conversazioni trasparenti tra co-founder. Ci sono temi ricorrenti che generano tensione in quasi tutti i team: il mio socio sta lavorando duro come me, abbiamo lo stesso obiettivo, chi fa engineering, chi fa prodotto, chi parla con i clienti. Spesso i founder evitano il discorso perché temono il conflitto. Il risentimento si accumula, e quando finalmente la conversazione arriva, è già una lite. Una conversazione organizzata, fatta in tempo, prima che il malumore diventi crisi, è una delle abitudini più protettive che si possa costruire.
Il quinto errore è aspettare troppo per lanciare. Launch è diventata una parola carica: i founder se la immaginano come un evento mediatico, con la stampa, i blog, l'hype. Per paura di non essere pronti, rimandano. Seibel fa notare che nessuno ricorda il giorno in cui Snapchat, Instagram, WhatsApp o Uber sono partiti. Il lancio è un evento significativo solo per chi lo vive da dentro. Per i clienti è irrilevante.
La regola è mettere il prodotto in mano alle persone il prima possibile. Finché non lo fai, non puoi validare se risolve un problema. Meglio un prodotto più ruvido in mano ai clienti questo mese che un prodotto perfetto fra sei mesi. Le eccezioni esistono in mercati molto regolati come banking o lending, dove il via libera deve arrivare prima dei clienti. Per la maggior parte delle startup consumer e B2B che YC vede, costruire un MVP e lanciarlo in meno di un mese è fattibile.
Una volta lanciato, il sesto errore arriva subito: non misurare. Non sapere cosa fanno gli utenti quando arrivano, dove cliccano, dove abbandonano. Costruire prodotto senza analytics significa volare al buio. Strettamente collegato c'è un settimo punto: non avere idea di dove arriveranno i primi utenti. Trovare i primi cento o mille è un problema di crescita. Trovare i primi cinque non lo è: dovrebbero arrivare dalla tua rete, da persone che già conosci con quel problema, da una community che già frequenti. Se non sai da dove tirarli fuori, è un segnale che hai scelto un problema lontano dalla tua vita.
L'errore finale è di prioritizzazione. Seibel lo chiama "sizzle over steak": confondere lo scintillio con la sostanza. Press, conference, investor da incontrare, hiring di figure senior, eventi: sono attività che fanno sentire founder, ma non sono il lavoro vero. Il lavoro vero è spingere prodotto, metterlo nelle mani degli utenti, ascoltare cosa funziona e cosa no, iterare.
Quando una startup passa più tempo a comportarsi da startup che a fare il lavoro di una startup, diventa un cargo cult. Sembra una vera azienda, ne ha tutte le forme esteriori, ma non sta facendo le uniche cose che contano davvero. Seibel chiude con un caveat onesto: per ognuno di questi errori esistono startup che li hanno commessi tutti e hanno avuto successo lo stesso. Sono eccezioni. Se vuoi alzare la probabilità che la tua azienda funzioni, riducile al minimo.
**Key takeaways**: - Scegliere un problema che non ti interessa davvero è la prima causa di mortalità: la maggior parte delle startup che falliscono perdono la motivazione, non il mercato. - Costruire per utenti che non ami è un blocco silenzioso: Justin.tv è diventata Twitch solo quando Emmett Shear ha rifocalizzato l'azienda sui gamer, persone che amava davvero. - Co-founder che non conosci bene = roulette russa: serve una storia condivisa (amici, colleghi, compagni di studi) per sapere se reggete insieme i momenti duri. - Lanciare presto vale più del lancio perfetto: nessuno ricorda il giorno in cui Snapchat o Instagram sono usciti, e tu non puoi validare nulla finché il prodotto non è davanti ai clienti. - I primi 5 utenti devono uscire dalla tua rete o da un canale già identificato; se non sai da dove arrivano, probabilmente hai scelto un problema che non vivi. - Press, conference, investor e hiring sono sizzle: il vero lavoro della startup è mettere il prodotto in mano ai clienti e iterare. Tutto il resto è cargo cult. **FAQ**: - Q: Perché Michael Seibel insiste sul lavorare su un problema che ami davvero? A: Perché la maggior parte delle startup che falliscono non muore per ragioni di mercato, ma per esaurimento della motivazione del founder. Se hai scelto il problema solo perché sembra cool o perché pensi che possa crescere in fretta, dopo qualche mese duro smetti di lavorarci. Serve una connessione profonda, abbastanza forte da reggere cinque o più anni di lavoro anche quando va male. - Q: Si può fondare una startup con un co-founder appena conosciuto? A: Tecnicamente sì, ma è un punto di partenza fragile. Seibel raccomanda una relazione preesistente: un amico, un collega, un compagno di un progetto universitario. Le startup sono talmente dure che avere una storia condivisa ti dice come reggete insieme la pressione. Senza quella base è molto più probabile che la prima crisi si trasformi in rottura. - Q: Quanto presto dovrei lanciare la mia startup secondo YC? A: Il prima possibile. Per la maggior parte delle startup consumer e B2B, costruire un MVP e lanciarlo in meno di un mese è fattibile. Finché il prodotto non è davanti ai clienti non puoi validare nulla. Le eccezioni sono mercati molto regolati come banking o lending. In tutti gli altri casi, meglio un prodotto più ruvido in mano ai clienti oggi che un prodotto perfetto fra sei mesi. - Q: Da dove arrivano i primi utenti di una startup? A: I primi cinque dovrebbero arrivare dalla tua rete o da un canale che hai già identificato. Seibel fa notare che se ti chiedi dove trovarli, probabilmente hai scelto un problema che nessuno intorno a te vive. Trovare i primi cento o mille utenti è una sfida di crescita; trovare i primi cinque è una verifica del fatto che hai scelto un problema reale e vicino alla tua vita. - Q: Cosa intende Seibel quando parla di cargo cult startup? A: Una startup che si comporta da startup senza fare il lavoro di una startup. Press, conference, investor da incontrare, hiring di figure senior sono attività che fanno sentire founder ma non sono il lavoro vero. Il lavoro vero è spingere prodotto, metterlo nelle mani degli utenti e iterare. Quando le attività di scintillio prendono priorità su prodotto e clienti, sei in pieno cargo cult. ### Perché le Startup Hanno Successo: i 5 Fattori (Bill Gross) URL: https://startupmentors.it/video/bill-gross-ted-startups-succeed YouTube: https://youtu.be/bNpx7gpSqbY Channel: TED · 7 min · strategia-business-plan Personas: founder, operator **Perché vale**: Se ti sei mai chiesto perché alcune startup esplodono e altre no, Bill Gross ha la risposta basata sui dati: il timing pesa il 42% del successo, più di idea, team e funding insieme. TED talk evergreen, 6,8M views, sui 5 fattori che predicono davvero il successo. **Riassunto**:Bill Gross fonda startup dal 1996, quando ha avviato Idealab e creato oltre 100 aziende — alcune diventate unicorni miliardari, altre crollate dopo pochi anni di vita. Per capire perché alcune startup esplodono e altre falliscono, ha provato un approccio sistematico: un ranking quantitativo di 200 aziende su cinque fattori chiave. Il risultato lo ha sorpreso e ribalta il modo in cui la maggior parte dei founder pensa al successo di una startup.
Gross ha valutato ogni azienda — 100 di Idealab e 100 di altri investitori — su cinque dimensioni che secondo l'esperienza comune determinano l'esito di una startup. La prima è l'idea, intesa come differenziabilità e unicità del concetto. La seconda è il team e l'execution, ovvero la capacità di adattamento operativo: come dice Mike Tyson, "tutti hanno un piano finché non vengono colpiti in faccia dal cliente". La terza è il business model, cioè un percorso chiaro per generare ricavi. La quarta è il funding, quantità e qualità dei capitali raccolti. La quinta è il timing, che misura se il mondo è davvero pronto per quell'idea o se la startup arriva troppo presto o troppo tardi.
L'aspettativa iniziale di Gross era che l'idea fosse tutto. Aveva chiamato la sua azienda "Idealab" proprio per celebrare il momento "aha!" del concetto. Negli anni ha cambiato idea più volte: forse il team conta di più, poi il business model, poi il funding. Solo l'analisi quantitativa ha rivelato il vincitore inaspettato.
Il fattore numero uno è risultato essere il timing, che pesa il 42% della differenza tra successo e fallimento delle startup analizzate. Più di tutti gli altri quattro fattori messi insieme.
Il ranking completo posiziona il timing al primo posto con il 42% del peso totale, seguito da team ed execution al secondo posto, dall'idea (per differenziabilità e unicità) al terzo, dal business model al quarto e dal funding al quinto.
Perché business model e funding finiscono in fondo alla classifica? Perché un modello di ricavo si può costruire dopo: YouTube non ne aveva uno all'inizio. E il funding arriva facilmente quando la startup ha già trazione, anche partendo con poca cassa.
Airbnb è stato rifiutato da molti investitori intelligenti, convinti che nessuno avrebbe mai affittato la propria casa a uno sconosciuto. Ma il lancio del prodotto ha coinciso con il picco della recessione 2008-2009: la gente aveva un bisogno urgente di reddito extra, e quel contesto economico ha abbattuto la barriera psicologica che bloccava il modello di business.
Uber aveva un'idea solida, un business model eccellente e un'execution forte. Ma il vero acceleratore è stato il timing dal lato dell'offerta. I conducenti cercavano lavoro flessibile, e la piattaforma è arrivata nel momento giusto per saturare la supply senza dover fare campagne di reclutamento aggressive.
Tra le startup di Idealab, Citysearch è esploso quando le aziende avevano bisogno di pagine web e nessuno sapeva come crearle. GoTo.com — lanciata da Gross stesso al TED 1998 — è arrivata quando le aziende cercavano modi cost-effective per acquisire traffico online, prima che Google AdWords dominasse il mercato. In entrambi i casi l'idea era forte, ma il timing pesava di più.
L'esempio più chirurgico viene da una sconfitta personale di Gross. Z.com era un'azienda di intrattenimento online: capitali raccolti, business model definito, persino talent di Hollywood firmato. Ma nel 1999-2000 la penetrazione di banda larga in USA era ancora marginale, e guardare video online richiedeva di installare codec specifici nel browser. Troppi attriti per l'utente medio. L'azienda è fallita nel 2003.
Due anni dopo, Adobe Flash ha risolto definitivamente il problema dei codec, e la banda larga ha superato il 50% di penetrazione in America. YouTube è stato lanciato esattamente in quel momento: stessa idea di fondo di Z.com, ma con un timing perfetto. Non aveva nemmeno un business model definito all'inizio, eppure è esploso.
La differenza tra Z.com e YouTube non è stata l'idea, né il team, né il funding. È stato il timing.
L'idea conta, ma meno di quanto pensa la maggior parte dei founder. Il caso Z.com / YouTube dimostra che la stessa idea, eseguita in due momenti diversi del mercato, può produrre risultati diametralmente opposti. Vale per ogni vertical: AI agent oggi sì, AI agent nel 2018 no — e non perché la tecnologia non esistesse, ma perché il mercato non era pronto.
Misurare il timing onestamente è la disciplina più difficile. Il modo migliore per valutarlo è chiedersi se i clienti sono davvero pronti, oggi, per il prodotto che stiamo costruendo. Non se saranno pronti tra due anni. Non se "dovrebbero" essere pronti. Se i segnali del mercato dicono no, vale la pena ascoltare invece di rimanere innamorati dell'idea.
Capitali ed execution si possono recuperare nel tempo; il timing no. Se il mercato non è pronto, nessun capitale può salvare l'azienda.
La domanda che ogni founder dovrebbe porsi prima di partire è semplice: cosa è cambiato nel mondo che oggi rende possibile quest'idea, e perché non era possibile cinque anni fa? Se non c'è una risposta solida, probabilmente è troppo presto.
**Key takeaways**: - Il timing pesa il 42% sul successo: più di team, idea e funding messi insieme. - Team ed execution arrivano secondi; l'idea è solo terza. - Airbnb e Uber sono esplosi anche grazie al timing perfetto: recessione 2008 e supply di driver pronti. - Z.com è fallita nel 2000 per banda larga insufficiente; YouTube ha avuto successo nel 2005 con la stessa idea. - Per misurare il timing onestamente: chiediti se i clienti sono davvero pronti, oggi, per il tuo prodotto. **FAQ**: - Q: Qual è il fattore più importante per il successo di una startup secondo Bill Gross? A: Il timing, con il 42% di peso sulla differenza tra successo e fallimento. Pesa più di team, idea, business model e funding messi insieme. È il dato più sorprendente dell'analisi su 200 startup di Idealab e altri investitori. - Q: In che ordine si classificano i 5 fattori di successo di una startup? A: Il ranking di Gross posiziona il timing al primo posto con il 42% del peso, seguito da team ed execution al secondo, dall'idea (differenziabilità e unicità) al terzo, dal business model al quarto e dal funding al quinto. Idea e funding pesano meno di quanto la maggior parte dei founder pensa. - Q: Perché Airbnb e Uber sono esplosi grazie al timing? A: Airbnb è stato lanciato durante la recessione 2008-2009: la gente aveva un bisogno urgente di reddito extra e questo ha abbattuto la diffidenza nell'affittare casa a sconosciuti. Uber ha avuto un timing perfetto dal lato offerta: i conducenti cercavano lavoro flessibile ed erano subito disponibili a registrarsi sulla piattaforma. - Q: Cosa è successo a Z.com e perché YouTube ha avuto successo con la stessa idea? A: Z.com è fallita nel 2003 perché lanciata nel 1999-2000, quando la banda larga in USA era ancora marginale e guardare video online richiedeva di installare codec specifici nel browser. YouTube è stato lanciato due anni dopo, quando la banda larga aveva superato il 50% di penetrazione e Adobe Flash aveva risolto il problema dei codec. Stessa idea, timing diverso, esiti opposti. - Q: Come misurare il timing in modo onesto prima di lanciare una startup? A: Chiediti se i clienti sono davvero pronti oggi per il tuo prodotto, non se saranno pronti in due anni. Una domanda guida: cosa è cambiato nel mondo che rende possibile quest'idea oggi e non cinque anni fa? Se non hai una risposta solida, probabilmente sei troppo presto sul mercato. ### Brian Chesky: Founder Mode e l'Arte di Assumere in Startup URL: https://startupmentors.it/video/brian-chesky-founder-mode-hiring YouTube: https://youtu.be/aFOGlNL39xs Channel: The Art of Hiring · 46 min · operations Personas: founder, operator **Perché vale**: Il CEO di Airbnb racconta la genesi del founder mode: cosa è andato storto seguendo il manuale 'assumi grandi persone e fidati', perché ha riscritto l'organizzazione durante il COVID, e come oggi chiude i top candidate. Quarantasei minuti di operating wisdom raro. **Riassunto**:Quando Brian Chesky ha tenuto la presentazione che ha generato il post di Paul Graham sul "founder mode", non sapeva sarebbe diventata virale. La aveva accettata all'ultimo minuto, doveva durare 20 minuti e finire entro le nove di sera per non far attendere i drink agli altri partecipanti. Ha parlato per due ore. Il pubblico erano i founder di company unicorn-esque, oltre cento aziende. La sensazione condivisa, dice Chesky, era una specie di terapia di gruppo: "Non sono pazzo, anche gli altri vivono questo".
Questa intervista del canale The Art of Hiring (con Keith Rabois come intervistatore) approfondisce in 46 minuti la genesi del concetto, il modo in cui Chesky ha riscritto Airbnb durante la crisi del COVID, e il sistema operativo concreto con cui oggi gestisce people e prodotto. Una delle conversazioni più dense sull'operare di un CEO product-driven al livello pubblico.
Il punto di partenza di Chesky è una correzione brutale del manuale tradizionale. La frase classica — "assumi persone grandi e dai loro spazio di operare" — non è sbagliata in assoluto, ma applicata senza disciplina distrugge l'azienda. Lo racconta con un esempio concreto vissuto in Airbnb tra il 2014 e il 2019.
La struttura era matriciale, con team che potevano creare team, sub-team, sub-sub-team senza limiti. La marketing aveva un team graphics centrale che serviva 5 team interni. Quando i team da servire sono diventati 20, il graphics team è diventato un collo di bottiglia con file d'attesa di mesi. La risposta naturale: ogni team richiede il proprio graphics team. In poco tempo l'azienda passa da 5 team graphics a 10 team graphics. Lo stesso pattern si ripete su tecnologia, prodotto, dati. Risultato: 10 divisioni che vanno in 10 direzioni con tecnologie diverse e general manager che si moltiplicano come babushka — general manager che creano mini general manager che creano mini-mini general manager.
Chesky descrive il punto finale così: meeting su meeting, metric e priorità strategiche come unico collante, nessuna roadmap di prodotto coerente, time horizon diversi tra team, complacency. Il CEO si trova separato dal proprio prodotto, che era il core asset originale. Nel 2019, dieci anni dentro la company, era soul-crushing. Tre cose lo hanno salvato: l'incontro con Jony Ive e Hiroki Asai (creative director di Apple), l'IPO imminente come deadline forzato di pulizia, e poi il COVID — 80% del business perso in 8 settimane, occasione per ricostruire da zero.
Il primo cambio è strutturale: da organizzazione divisionale a organizzazione funzionale. Engineering, design, product marketing, sales, riportano direttamente al CEO. Niente più general manager con sotto-organizzazioni autonome. L'idea filosofica è di Steve Jobs: il team come Navy SEALs, non come Navy. Pochi, lean, elite, expert. Non un team di "battalion mid-level".
La regola che Chesky ripete spesso è la matematica del talento: un B player assume tre C player, perché un solo C player non basta a coprire il ruolo. La persona meno capace della media non può scegliere persone più capaci della media: non riconosce la differenza. Il risultato: tre persone meno capaci che vanno in tre direzioni diverse e creano altre meeting per coordinarsi. La cura è alzare la soglia di assunzione anche se questo significa stare a corto di persone.
Secondo cambio: rimozione dei manager non-expert. Per Chesky un manager che non sa fare il lavoro del team che gestisce è come un generale di cavalleria che non sa cavalcare. Solo expert manager che gestiscono il lavoro, non solo le persone. Ha imparato questa filosofia da Jony Ive, che era al 90% manager del lavoro e al 10% manager delle persone — non aveva career conversation tutto il giorno.
Terzo cambio: creazione della funzione product marketing, copiata esplicitamente da Apple. Il product manager classico viene unito all'outbound marketing in un unico ruolo. Le funzioni di program management vengono separate. Risultato: meno overhead, più storytelling integrato nello sviluppo prodotto.
Quarto cambio: design riporta direttamente al CEO, non al product. È la sua opinione più controversa. In nove company su dieci, sostiene Chesky, head of design dovrebbe riportare direttamente al CEO. Solo se la company è puramente tech con un CEO tech-appointed (Apple non lo era) ha senso un'altra struttura.
Il founder mode in pratica ruota attorno a tre meccanismi.
Review della work: Chesky rivede personalmente ogni cosa che spedisce. Cadenze: settimanale, bisettimanale, mensile, ogni 2 mesi, trimestrale, in base al peso strategico. Non rivede contabilità o sistemi interni invisibili al cliente, ma rivede tutto ciò che il cliente vede. La leggenda è che Steve Jobs passasse 35 ore alla settimana in meeting con un singolo executive di Apple, perché tutto quello che Steve faceva era review della work. Chesky ha capito che CEO involvement è un paradosso: meno il CEO è coinvolto, più il progetto degenera; più il progetto degenera, più si attribuisce la dysfunction alla leadership; più si attribuisce la dysfunction al CEO, più il CEO si tira indietro. Il ciclo si rompe solo essendo presenti dall'inizio: presence, non absence.
Launch come deadline: Airbnb non rilascia software in continuous deployment, fa product release coordinati come fa Apple con l'hardware. La ragione è di nuovo Steve Jobs: i mattoni sparsi a terra non producono effetto, i mattoni impilati creano una torre che la gente nota. La launch è insieme deadline interna che forza coordinamento e momento di marketing per il mercato. Per far lavorare le persone con intensità, dice Chesky, non serve check del badge in ufficio o pressione sulle nights/weekend: serve una deadline ambiziosa e check settimanali sui progressi.
Deep dive funzionali: ogni 1-2 anni, una funzione dell'azienda viene radiografata da Chesky con un audit di 2-4 settimane. Niente firing automatico, l'obiettivo è creare un ambiente sicuro per la honesty interna. Solo dopo il deep dive si ridisegna il gruppo per renderlo più efficiente.
Sull'hiring esterno Chesky propone un'inversione completa del flusso classico. La gente parte dai curriculum e dai brand: "questa persona ha lavorato a Google". Sbagliato. Bisogna partire dai risultati.
Step 1: identificare i prodotti che si ammirano. Step 2: scoprire chi davvero li ha costruiti (è un'indagine — i marketer che dicono di aver inventato "Just Do It" sono moltissimi, chi davvero l'ha fatto è uno solo). Step 3: contattare quelle persone.
Sulle interview Chesky è netto: per quanto si possa diventare bravi a interviewing, l'executive ha mediamente più esperienza nel raccontarsi di quanta ne abbia il founder nel decifrare. È un asimmetric game in cui sei una cintura bianca contro una cintura nera. La difesa è prioritizzare le reference sopra le interview. Andreessen Horowitz consigliava 8 ore di reference per ogni hire executive. Sembra esagerato, ma il principio regge: dedica tanto tempo alle reference quanto ne dedichi alle interview.
Tre tecniche concrete sulle reference. Primo: sono off-the-record, dichiarate esplicitamente all'inizio della call per ottenere onestà. Secondo: chiedi specifici concreti — "perché era così bravo?", "cosa ha fatto?", "cosa devo aspettarmi di rischioso assumendolo?". La domanda sul lato debole è obbligatoria: se non riescono a darti niente, non sono attendibili. Terzo: chiedi al referee chi è la persona migliore con cui ha lavorato, separatamente dalla persona di cui stai parlando. Se non nomina la persona oggetto dell'interview, non era tra i migliori.
Inoltre Chesky è co-hire manager dei direct report dei suoi direct report — i VP. Vede ogni candidato VP, non perché non si fidi dei suoi C-level, ma perché se i suoi direct possono assumere senza il suo input, allora non stanno mirando abbastanza in alto. La regola interna: "se puoi assumere senza di me, non sono abbastanza buoni". Ha intervistato personalmente i primi 400 dipendenti di Airbnb e dice che il suo unico rimpianto è non aver fatto i primi mille.
La parte sul closing dei top candidate è la più contro-intuitiva del video. Quattro tattiche concrete.
Prima: alla fine del processo, prova a dissuadere il candidato dal lavoro. È reverse psychology consapevole, citando il famoso annuncio di lavoro di Ernest Shackleton del 1914: "Cercasi uomini per missione pericolosa. Salari piccoli, freddo amaro, lunghi mesi di completa oscurità, pericolo costante, ritorno sicuro improbabile, onore e riconoscimento in caso di successo". Il principio: i grandi candidati vogliono sfide reali, non country club. Vendere la rosy picture attira mediocri, raccontare la realtà dura attira i migliori.
Seconda: dedica FaceTime al candidato. Quando Andreessen ha chiuso Chesky come investor, non ha dato il pitch migliore: lo ha chiamato e cercato più degli altri. Ha mandato Pierre Omidyar (founder di eBay) a chiamarlo, poi ha mandato Mark Zuckerberg. Le persone che il candidato ammira sono leve di chiusura potenti.
Terza: racconta al candidato la visione che hai per lui, non solo per la company. "Il mio lavoro è vedere potenziale in te che tu non vedi in te stesso, e dirti che non basta — non perché non vali, ma perché credo in qualcosa di più grande". Pre-vendi l'interview panel: parla con i tuoi membri del team prima della call con il candidato, perché spesso pannelli mal coordinati sabotano inconsapevolmente il closing.
Quarta: paga over the mean i veri high performer. Chesky è esplicito sul fatto che i sistemi HR standard tendono a sotto-pagare i top e sovra-pagare i medi. Inverte il pattern.
Una sezione finale, importante per founder che hanno chiuso fundraising recente. Chesky è severo sui board member junior: tendono al risk-averse, raramente coprono i founder quando le cose vanno male, mancano di autorità morale per difenderli verso i partner senior. La maggior parte dei board member secondo Chesky sono "zero o 0,1": non costruiscono la company, e qualcuno la distrugge attivamente (cita il quasi-disastro OpenAI come esempio).
Quando un board member dà advice sbagliato e non puoi dire "non hai mai gestito un'azienda" (che è vero ma offensivo), il consiglio operativo è portarlo nei dettagli. Il pattern recognition errato del VC viene da leggere la realtà a un livello di astrazione troppo alto. Camminare il board member attraverso i dettagli concreti del problema fa lo stesso lavoro: nell'80% dei casi il VC si tira indietro perché la sua iniziale convinzione era superficiale, nel 20% rimane convinto e a quel punto il founder deve scegliere se ascoltare o no. Ma la regola finale resta: l'outcome è del founder, non del VC. Anche se ascolti il VC e va male, sarà colpa tua.
Nota: l'intervista è stata registrata sul canale The Art of Hiring (Keith Rabois come host). Per il framework operativo dell'hiring early-stage applicato al primo team, vedi Hiring Playbook YC (stessa categoria, order 1).
**Key takeaways**: - Il consiglio 'hire great people and trust them' applicato senza disciplina distrugge l'azienda: i divisional org diventano 100 babushka di general manager che vanno in 100 direzioni. - Founder mode = presence, non absence. Chesky rivede personalmente ogni cosa che spedisce, su cadenze settimanali/bisettimanali/mensili. - Sull'hiring: parti dai risultati e vai a ritroso fino alle persone, non dai brand sul curriculum. Le reference valgono più dell'interview. - B player assume C player in gruppi di tre, perché 1 incompetente non basta a coprire un ruolo. Una persona meno capace di te non può scegliere chi è più capace. - Closing dei top candidate: prova a dissuaderli dal lavoro nel finale (reverse psychology Shackleton-style) e fai chiamare investor o founder che il candidato ammira. **FAQ**: - Q: Cos'è il founder mode secondo Brian Chesky? A: Il founder mode è un modello operativo basato sulla presenza del CEO nei dettagli, non sulla delega ad executive con autonomia totale. Si articola in tre meccanismi: review settimanale di tutto ciò che la company spedisce al cliente, launch coordinati come deadline interne, deep dive funzionali ogni 1-2 anni. È l'opposto del manuale 'hire great people and trust them' applicato senza disciplina. - Q: Perché secondo Chesky un B player assume tre C player? A: Perché una persona meno capace della media non può scegliere persone più capaci della media: non riconosce la differenza. E un singolo C player non basta a coprire il ruolo che il B player avrebbe dovuto fare, quindi ne servono tre. Il risultato è tre persone meno capaci che vanno in tre direzioni diverse e creano meeting per coordinarsi. La cura è alzare la soglia di assunzione anche se rimane il team a corto. - Q: Come ha riscritto Airbnb durante il COVID? A: Quattro cambiamenti strutturali: passaggio da divisional a functional org (engineering, design, product marketing, sales riportano al CEO), rimozione dei manager non-expert (solo manager che sanno fare il lavoro del team), creazione della funzione product marketing copiata da Apple, head of design che riporta direttamente al CEO invece che al product. La crisi è stata l'occasione per applicare un design organizzativo che Chesky aveva in mente da prima dell'IPO ma non poteva implementare. - Q: Perché le reference valgono più delle interview secondo Chesky? A: Perché gli executive hanno mediamente più esperienza nel raccontarsi di quanta il founder ne abbia nel decifrare. È un asimmetric game in cui chi assume è cintura bianca contro cintura nera. Le reference, fatte off-the-record con domande specifiche su risultati concreti e lati deboli, danno informazioni che l'interview non fornisce. Andreessen Horowitz consigliava 8 ore di reference per ogni hire executive. - Q: Come si chiude un top candidato secondo Chesky? A: Quattro tattiche: prima, prova a dissuaderlo nel finale (reverse psychology Shackleton-style — racconta la realtà dura, non vendere il country club). Seconda, dedica FaceTime e chiamate dirette. Terza, fai chiamare investor o founder che il candidato ammira (Andreessen ha chiuso Chesky chiamando Pierre Omidyar e Mark Zuckerberg). Quarta, paga sopra la media i veri high performer — i sistemi HR standard tendono a sotto-pagarli. ### From Idea to $650M Exit: Lessons in Building AI Startups URL: https://startupmentors.it/video/casetext-jake-heller-650m-exit-yc YouTube: https://youtu.be/l0h3nAW13ao Channel: Y Combinator · 39 min · case-study Personas: founder, investor **Perché vale**: Jake Heller racconta come Casetext ha portato CoCounsel a 650 milioni di dollari di exit con Thomson Reuters: scelta del problema, eval rigorose e pricing sul valore reale per i clienti. **Riassunto**:Jake Heller ha fondato Casetext nel 2013 dopo un breve passaggio in un grande studio legale. Coder dall'infanzia, avvocato per scelta, ha visto da dentro quanto fosse arretrato il modo in cui gli avvocati lavoravano. Per dieci anni Casetext ha costruito tool legali basati su NLP e machine learning, raggiungendo circa 20 milioni di dollari di revenue e cento dipendenti. Nell'estate 2022, grazie all'expertise sviluppata sui large language model, ha ottenuto accesso pre-launch a GPT-4: ha fermato tutto il resto e in pochi mesi ha lanciato CoCounsel, il primo AI assistant per avvocati. Due anni dopo, Thomson Reuters ha acquisito Casetext per 650 milioni di dollari cash.
In questo talk a Y Combinator, Heller distilla quello che ha imparato in tre blocchi: come scegliere l'idea, come costruire il prodotto, come venderlo. Il filo conduttore è uno: nell'era AI le regole del gioco sono cambiate, ma molti founder continuano a giocare con le vecchie.
Il vecchio mantra YC "make something people want" si è sempre scontrato con la difficoltà di capire cosa vogliano davvero. Heller propone una scorciatoia: guarda cosa la gente sta già pagando qualcun altro per fare. Customer support, paralegali, financial advisor, personal trainer, executive assistant. Quel denaro che oggi va a stipendi è il tuo vero mercato indirizzabile.
Da qui tre categorie di prodotto:
Il punto economico è radicale. Un SaaS tradizionale vende seat a 20 dollari al mese. Un prodotto AI che fa il lavoro di un professionista può chiedere 5.000, 10.000, 20.000 dollari al mese. Il TAM si moltiplica per cento o mille rispetto al modello seat-based.
Heller respinge l'accusa di distopia. Sostituire o assistere certi lavori libera capacità per cose che oggi non immaginiamo, come l'elettricità ha reso obsoleto il mestiere di lamp lighter. E democratizza l'accesso: oltre l'85% delle persone a basso reddito non accede a servizi legali perché costano troppo. Un avvocato AI cento volte più veloce e dieci volte più economico cambia chi può dire di sì ai clienti.
Il primo passo non è scrivere codice. È avere domain expertise. Da Casetext il 30-40% del team era composto da avvocati, anche tra i coder. Se non hai expertise diretta, vai sotto copertura nel settore o trova un co-founder che ce l'abbia. Senza questo, costruisci alla cieca.
La domanda chiave: come farebbe il migliore professionista del settore questo task se avesse tempo e risorse illimitate, mille AI che lavorano in parallelo? Heller racconta come hanno costruito una versione di deep research per il legal due anni e mezzo prima che il termine entrasse nel mainstream. Hanno chiesto a un avvocato top come avrebbe affrontato una research question: chiarire la richiesta, fare un piano, lanciare decine di ricerche, leggere centinaia di risultati, scartare l'irrilevante, prendere note, sintetizzare in un saggio, verificare le citazioni. Otto step concreti.
Ogni step diventa o un prompt o codice deterministico. Se puoi farlo senza prompt, fallo: i token sono lenti e costosi. Se il workflow è sempre uguale (sei step fissi ogni volta), costruisci una pipeline lineare con Python puro. Niente LangChain, niente over-engineering. Solo quando il flusso varia davvero in base al contesto entri nel territorio agentic, che è molto più difficile da garantire.
Qui la maggior parte delle startup AI fallisce. È facile costruire una demo al 60-70% di accuratezza, raccogliere capitale dai VC, firmare i primi pilot. È difficilissimo farla funzionare in produzione.
Le eval partono dalla stessa domanda: cosa significa "fatto bene" secondo l'esperto? Per ogni microtask costruisci test con risposta oggettivamente valutabile (true/false, score 0-7). Heller usa promptfoo come framework. Parti da una dozzina di test, arriva a 50, poi 100, e itera il prompt finché passa tutto. Tieni un hold-out set per evitare di overfittare le eval.
La sua regola pratica: due settimane di lavoro ossessivo su un singolo prompt. Dal 60% iniziale si passa al 97%, e il 3% rimanente è judgment call che farebbe sbagliare anche un umano. Pre-produzione: 100 test per prompt, 100 test per il task complessivo. Se passi 99 su 100, sei pronto per la beta.
In beta i clienti ti forniranno test reali (e spesso assurdi). Ogni nuovo modello che esce va testato contro le eval esistenti. Niente di statico: pull request sui prompt ogni giorno. Una singola parola può spostare un punto percentuale, e in finance, medicina o legal quel punto vale moltissimo.
Heller è categorico: chi fa solo questi due passaggi - capire come lavorano i professionisti e costruire eval rigorose - è già al 90% della strada per battere il 95% delle startup AI in giro.
Heller smonta una narrazione VC diffusa: che a partire da Series A/B il prodotto conti meno del go-to-market. La sua esperienza dice il contrario. Per dieci anni Casetext ha avuto un prodotto mediocre e venditori normali. Quando è uscito CoCounsel, i venditori sono diventati order taker, il word of mouth ha fatto il lavoro, la stampa è arrivata da sola. Il prodotto eccellente è la migliore strategia di marketing.
Detto questo, tre consigli operativi.
Pricing sul valore, non sul SaaS standard. Le aziende più interessanti oggi vendono un servizio completo (revisione contratti, accounting AI) a 500 dollari per contratto contro i 1.000 di uno studio legale. Step-up estremo dai 20 dollari/mese del SaaS classico. Però ascolta il cliente su come vuole pagare: Casetext pensava al per-usage, ma gli avvocati hanno chiesto 6.000 dollari per seat all'anno per avere budget prevedibile. Glielo hanno dato.
Trust gap. Le grandi aziende vogliono provare l'AI ma hanno paura. Funzionano i confronti head-to-head: tieni il tuo studio legale e usa il nostro tool in parallelo, poi confronta velocità, qualità, accuratezza. Pilot strutturati. Studi di validazione. Il tuo lavoro è costruire fiducia.
La vendita non finisce con il contratto. Heller, ora angel investor, vede troppe startup AI con "10 milioni di ARR" che a guardarli da vicino sono pilot non convertiti. Pilot recurring revenue, non ARR. Avverte di una mass extinction event in arrivo quando questi pilot non si trasformeranno in contratti reali. La soluzione: forward deployed engineer, onboarding curato, training, customer success. Il prodotto non è solo i pixel sullo schermo, è tutto l'ecosistema umano intorno.
Il messaggio di chiusura per chi sta scegliendo cosa costruire: vai sul problema più grande che pensi di poter risolvere con la tecnologia che hai. Heller riconosce che concentrarsi sul legal aveva senso per lui ma era anche un limite (gli avvocati spendono in software solo una piccola frazione del loro fatturato). Con CoCounsel ha capito la differenza tra fare cambiamenti incrementali a poche persone e cambiare davvero la vita a molti. Non torna indietro.
E sulla difensibilità contro il rischio "GPT wrapper": basta costruire davvero. Quando lo fai scopri quante integrazioni servono, quanti check, quanto fine-tuning sui prompt, quanti modelli da orchestrare. Due anni di lavoro vero non si replicano leggendo un blog post.
**Key takeaways**: - Scegli un problema dove qualcuno paga già qualcun altro per farlo: il TAM diventa il salario aggregato dei professionisti, non il prezzo del seat SaaS - Decomponi il workflow come farebbe il miglior professionista del settore, poi trasforma ogni step in un prompt o in codice deterministico - Le eval sono il vero lavoro: punta a 97-99% di accuratezza su 100+ test per prompt prima di andare in beta - Prezza sul valore generato, non sul costo: Casetext ha venduto a 6.000 dollari per seat all'anno quando i clienti hanno chiesto budget prevedibile - Il pilot revenue non è ARR: molte startup AI rischiano una mass extinction event quando i pilot non convertono in contratti reali **FAQ**: - Q: Come ha fatto Casetext a ottenere accesso pre-launch a GPT-4? A: Heller racconta che il team aveva un AI researcher (Javeed) che lavorava sui modelli linguistici fin dai tempi del paper BERT e di 'Attention Is All You Need', circa sette anni prima dell'exit. Questa expertise profonda sui language model ha portato OpenAI a includere Casetext tra le aziende con accesso pre-launch a GPT-4 nell'estate 2022, quando l'azienda aveva già 20 milioni di dollari di revenue e cento dipendenti. - Q: Quale strategia di pricing ha adottato CoCounsel e perché? A: Casetext ha venduto CoCounsel a circa 6.000 dollari per seat all'anno (500 dollari al mese per avvocato), molto sopra i 20 dollari/mese del SaaS tradizionale. Inizialmente pensavano a un modello per-usage, ma hanno chiesto direttamente ai clienti come preferivano pagare e gli avvocati hanno indicato il modello per-seat per avere budget prevedibile durante l'anno. La lezione di Heller: prezza in base al valore che generi (sostituisci ore di lavoro pagate molto di più), ma ascolta il cliente sulla forma del pricing. - Q: Cosa intende Heller per 'mass extinction event' delle startup AI? A: Heller, da angel investor post-exit, osserva molte startup AI che dichiarano ARR alti (per esempio 10 milioni di dollari) ma sotto la superficie sono in larga parte pilot pagati da grandi aziende che non si convertono in contratti reali. Lo definisce 'pilot recurring revenue', non ARR. Prevede che molte di queste startup falliranno quando i pilot non si trasformeranno in revenue ricorrenti veri. La difesa: investire in onboarding strutturato, forward deployed engineer e customer success per assicurarsi che il prodotto venga davvero adottato. - Q: Quante eval servono prima di mandare in beta un prodotto AI? A: La regola pratica di Heller: almeno 100 test per ogni prompt e 100 test per il task complessivo, con un tasso di successo del 99% prima della beta. Mille test sono dieci volte meglio se riesci a farli. Usa framework come promptfoo per automatizzare l'esecuzione. Mantieni un hold-out set per evitare di ottimizzare il prompt sui test che vedi. In produzione, ogni reclamo cliente diventa una nuova eval e ogni nuovo modello rilasciato va ritestato contro l'intera suite. - Q: Come si difende un prodotto AI dal rischio di essere un 'GPT wrapper'? A: La risposta di Heller è pragmatica: 'just build it'. Quando costruisci davvero un prodotto AI verticale scopri quanto lavoro serve oltre al modello base: integrazioni dati, check di qualità, prompt fine-tuned per casi specifici, scelta del modello giusto per ogni task, workflow domain-specific. Dopo due anni di sviluppo continuo hai accumulato un livello di sofisticazione che nessun nuovo entrante può replicare velocemente. La domain expertise applicata sistematicamente diventa il moat. ### Claude Code: 36 lezioni dopo 6 mesi di uso quotidiano URL: https://startupmentors.it/video/claude-code-6-months-lessons-avthar YouTube: https://youtu.be/rfDvkSkelhg Channel: AI with Avthar · 26 min · mvp-build Personas: founder, builder **Perché vale**: Sei mesi di pratica condensati in 36 tecniche operative: dal file Claude.md al planning mode, dai sub-agent ai git work tree per far girare più istanze in parallelo. Smetti di trattare Claude Code come ChatGPT con il tasto save. **Riassunto**:Avthar Sewrathan racconta sei mesi vissuti dentro Claude Code da power user, organizzando 36 tecniche in tre livelli: foundations, workflow intermedi, tecniche avanzate. Il punto di partenza è una confessione utile: per i primi mesi usava Claude Code come "ChatGPT con il tasto save", prompt vaghi e zero struttura. La svolta è arrivata trattandolo come uno strumento di engineering, non come un autocomplete potenziato. Per chi sta costruendo un MVP da solo o in team piccolo, le lezioni che seguono valgono settimane di tentativi a vuoto.
L'installazione standard è sul laptop con un comando dal sito Anthropic, ma Avthar segnala anche due opzioni meno banali: installazione su server remoto (AWS, DigitalOcean, Hetzner) per progetti backend, e uso dentro IDE come VS Code, Cursor o Windsurf se non sei a tuo agio nel terminale. Da iOS si può controllare il tutto con Termius. Tra i comandi base, la to-do list automatica, il bash mode dentro la sessione, l'auto accept con shift+tab, lo switch modello con /model, l'escape per interrompere quando vedi che sta sbagliando direzione.
Ma il vero acceleratore è il file Claude.md. Pensalo come la memoria del progetto: viene aggiunto al contesto a ogni task. Dentro ci stanno le convenzioni git (creare branch, mai push diretto su main, commit regolari), l'overview architetturale, i comandi di build, le preferenze su test, debugging, analytics e documentazione. Una volta scritto, Claude Code segue queste regole in automatico. Pro tip di Avthar: non scriverlo a mano, chiedi a Claude stesso di generarlo e poi di aggiornarlo man mano che il progetto evolve. Stessa logica per il debugging: screenshot in input quando ci sono bug di UI, generazione automatica dei test (puntando a end-to-end, non a test specifici dell'implementazione), e test driven development chiedendo a Claude prima i test e poi l'implementazione.
Il salto di qualità arriva con il planning mode. Premi tab+shift fino al "plan only mode" e Claude restituisce un piano scritto prima di toccare il codice. Avthar lo usa per decisioni architetturali e bug complessi. Combinato con l'opus plan mode, il modello più potente ragiona sul piano e Sonnet, più economico, esegue. I "think keyword" controllano quanto budget di ragionamento allocare: think, think hard, ultra think. Inseriti nel prompt, dicono al modello di fermarsi a riflettere prima di agire.
Claude Code non è solo per scrivere codice. Il web search e il web fetch lo rendono utile per ricerche tecniche (come usare l'API di Stripe) o report di scouting (qual è il miglior auth provider con componenti di login pronti). Legge anche PDF: Avthar gli passa report di Deep Research di ChatGPT come input alla fase di research interna. Stessa logica per generare PRD, guide di UX, documentazione API e decision doc, sfruttando il contesto reale del codebase invece di partire da zero come farebbe ChatGPT. L'integrazione con GitHub Actions (/install gh actions) chiude il cerchio: tagghi Claude Code in issue e pull request e lui lavora su GitHub senza passare dalla tua macchina, recensendo anche le PR in entrata.
La parte più difficile da accettare è la mentalità giusta. Avthar la formula così: pensa come un product manager. Significa due cose. La prima è dare a Claude tutto il contesto rilevante e i constraint giusti. La seconda, più scomoda per chi viene dall'engineering tradizionale, è lasciar andare la rilettura riga per riga. Verifichi a un livello di astrazione più alto: l'esperienza utente è quella che volevi, i test passano, l'app si comporta come previsto. Non devi capire ogni riga generata. È un cambio di postura simile al passaggio da ingegnere senior a manager di un team tecnico.
Il livello master si apre con il parallelismo. I sub-agent paralleli esplorano più soluzioni a uno stesso problema in parallelo, e tu (o Claude stesso) scegli la migliore: utile per architettura di feature complesse o bug ostici. Ma il vero unlock sono i git work tree. Crei una cartella .trees nel repo, lanci git worktree add per ogni feature da sviluppare, apri una sessione terminale per ogni work tree e dentro fai partire un'istanza separata di Claude Code. Risultato: più feature sviluppate in parallelo sullo stesso codebase senza conflitti, history git pulita, alla fine chiedi a Claude di fare il merge e risolvere i conflitti rimasti. Una settimana di lavoro in poche ore.
I custom slash command sono scorciatoie per i prompt che ripeti spesso. Crei una cartella commands/ dentro .claude/ nel working directory, aggiungi un file markdown con il nome del comando (es. changelog.md), specifichi descrizione, tool permessi (di solito bash, read, write) e il prompt vero e proprio. Possono essere project-specific o personal (validi per tutti i progetti). I sub-agent custom sono assistenti specializzati con prompt e permessi dedicati: UX design, API design, security review, esecuzione test, database administration. Si creano con /agents, una procedura guidata che genera il file markdown con tipo, descrizione d'uso, tool e system prompt. Una volta esistenti, Claude Code li delega in automatico ai task pertinenti, oppure li invochi tu nel prompt ("usa il database admin agent per validare queste query").
L'ultimo tassello è MCP, Model Context Protocol. Estende Claude Code verso tool esterni: i server MCP per database (MongoDB, Postgres, Supabase) per lavoro diretto sui dati, Playwright MCP per far "vedere" a Claude la UI dell'app durante test e debugging, Figma MCP per andare da design a codice. È un ecosistema in crescita, che vale la pena monitorare se stai costruendo prodotti dove Claude Code deve interagire con sistemi terzi.
Non c'è una versione gratuita. Il piano Pro a 20 dollari al mese serve per familiarizzare. Quando sei serio sul build, il Max 5x a 100 dollari o il Max 20x a 200 dollari diventano sostenibili: rate limit cinque o 20 volte superiori al Pro. Avthar usa il Max 20x e lo consiglia a chi vive nel tool. L'API Anthropic diretta resta opzione percorribile solo se l'azienda paga il consumo. Da fine agosto sono entrati in vigore rate limit settimanali aggiuntivi sul piano Max: vale la pena tenere d'occhio l'impatto reale, ma per ora il rapporto valore/prezzo regge.
**Key takeaways**: - Il file Claude.md è la memoria del progetto: workflow git, architettura, regole di test e analytics applicate automaticamente a ogni task. - Planning mode + Opus per pianificare, Sonnet per scrivere il codice: qualità migliore e consumo token sotto controllo. - Git work tree + più istanze di Claude Code in parallelo permettono di chiudere una settimana di feature in poche ore senza conflitti. - Custom slash command e sub-agent specializzati (UX, security review, database, test) trasformano i prompt ripetitivi in scorciatoie riusabili. - Mentalità da product manager: smetti di rileggere ogni riga, verifica gli output a un livello di astrazione più alto (esperienza, test, comportamento dell'app). **FAQ**: - Q: Devo essere uno sviluppatore esperto per usare Claude Code in modo efficace? A: No. Avthar parte dall'esperienza di chi insegna AI coding anche a chi non ha background tecnico. Le foundations (installazione, comandi base, file Claude.md) sono accessibili. Quello che cambia tutto è la mentalità da product manager: dare contesto, definire constraint, verificare gli output a un livello di astrazione più alto invece che riga per riga. - Q: Cos'è esattamente il file Claude.md e perché è considerato la differenza più grande? A: È un file markdown nella root del progetto che viene aggiunto automaticamente al contesto di ogni sessione. Contiene workflow git, overview architetturale, comandi di build, regole su test, analytics e documentazione. Una volta scritto, Claude Code rispetta queste regole senza che tu debba ripeterle a ogni prompt: crea branch, fa commit regolari, mantiene lo stile del progetto. Si genera chiedendolo a Claude stesso e si aggiorna man mano che emergono nuove preferenze. - Q: Come funzionano i git work tree con più istanze di Claude Code? A: Crei una cartella nascosta nel repo (es. `.trees`), poi con `git worktree add` generi un work tree per ogni feature da sviluppare in parallelo. Apri una sessione terminale per ogni work tree e dentro fai partire un'istanza di Claude Code. Ogni istanza lavora isolata, niente conflitti. Alla fine chiedi a Claude di fare il merge dei work tree e risolvere i conflitti residui. Permette di chiudere più feature contemporaneamente sullo stesso codebase. - Q: Quando ha senso usare il planning mode invece di andare diretto al codice? A: Sempre che il task non sia banale. Decisioni architetturali, bug complessi, feature nuove: il planning mode (tab+shift fino a 'plan only mode') costringe Claude a produrre un piano scritto prima di toccare il codice. Combinato con `opus plan mode` usi Opus per pianificare e Sonnet per implementare, ottimizzando qualità e consumo token. Per task ripetitivi o piccole correzioni, puoi saltarlo. - Q: Quale piano Claude conviene a chi sta costruendo un MVP da solo? A: Il Pro a 20 dollari al mese va bene per iniziare e capire il tool. Quando lo usi seriamente ogni giorno, il Max 5x a 100 dollari è il punto di equilibrio per la maggior parte dei founder solitari. Il Max 20x a 200 dollari ha senso se Claude Code è il tuo tool principale e sviluppi feature in parallelo con più istanze. L'API diretta è troppo cara per uso individuale. ### Come trasformare Claude Code nel tuo AI engineering team URL: https://startupmentors.it/video/claude-code-ai-engineering-team-yc YouTube: https://youtu.be/wkv2ifxPpF8 Channel: Y Combinator · 22 min · ai-stack Personas: founder, builder **Perché vale**: Gary Tan, presidente di Y Combinator, mostra come orchestrare Claude Code come un team di engineering: ruoli, processo, review. Workshop pratico costruendo una tax app, con il framework GStack che ha superato 70.000 stelle su GitHub in poche settimane. **Riassunto**:Gary Tan, presidente di Y Combinator, parte da una tesi netta che ribalta il dibattito tipico sulle capacità degli agent: i modelli sono già abbastanza intelligenti per fare lavoro straordinario su qualsiasi codebase. Quello che manca è il contorno. Senza configurazione l'agent vaga, non conosce i tuoi dati, tira a indovinare, e a quella scala il guessing produce codice plausibile che si rompe in silenzio. Tan ha le credenziali per dirlo: ha studiato computer systems engineering a Stanford, è stato dipendente numero 10 a Palantir come engineer, designer e product manager insieme, ha co-fondato Posterous (poi venduta a Twitter), e ha scritto la prima versione di Bookface, la piattaforma interna di YC. Negli ultimi due mesi ha scritto più codice di quanto ne avesse scritto nel 2013, l'ultima volta in cui aveva lavorato come engineer a tempo pieno.
La sua tesi è che siamo entrati in una nuova era del software, l'agent era, e che il modo per far funzionare gli agent è lo stesso con cui hanno sempre funzionato i team umani: ruoli, processo, review. La soluzione, secondo Tan, è quindi invertire la logica del prodotto: harness leggero, skill ricche. Lo scaffolding deve essere sottile, le competenze devono essere profonde.
Per dimostrarlo ha costruito GStack, un repo open-source che in tre settimane ha superato Ruby on Rails per numero di stelle e oggi sfiora le 70.000. GStack non è un wrapper attorno a Claude Code: è un set di skill che trasformano Claude Code in un team di specialisti, ognuno con un ruolo definito. Office hours, plan CEO review, design shotgun, review, ship. Sono 28 comandi che riproducono il modo in cui un team umano lavora davvero. Tan racconta che molti utenti gli scrivono di passare l'80-90% del tempo in soli tre comandi: office hours, plan CEO review e auto plan.
Lo skill che Tan considera il cuore di GStack è office hours, la versione distillata delle migliaia di ore che i sedici partner di YC hanno passato con i founder. Lo definisce una versione al 10% della loro intensità reale, ma sufficiente a fare la differenza prima ancora di incontrare un partner umano. Prima di toccare codice, l'agent fa sei domande di framing. La più importante è quella che secondo Tan determina tutto il resto: qual è la prova più forte che qualcuno voglia davvero questo prodotto?
Nel workshop Tan costruisce in diretta una tax app che recupera i moduli 1099 dalla Gmail e dai portali bancari. L'office hours non si limita a raccogliere requirement: spinge indietro sul perché il problema non è già risolto da TurboTax o H&R Block, fa notare che Plaid si collega già alle banche, mette in dubbio il modello di business. Quando Tan ammette che il problema gli costa solo fastidio e qualche email seccata del commercialista, l'agent lo riformula in una direzione più ambiziosa: un wedge verso il marketplace dei commercialisti, dove invece di addebitare due-cinque dollari l'anno per l'aggregazione documenti puoi prendere una percentuale sulla transazione fiscale, potenzialmente dieci volte tanto.
Il risultato è che invece di partire da una specifica grezza si arriva a tre approcci alternativi (A, B, C) con effort e risk stimati per ognuno: una versione minimal con solo Gmail OAuth e checklist, una full-stack con automation browser e marketplace CPA, una flip del go-to-market che parte dai commercialisti. Tan sceglie un mix tra B e C, propone di usare la browser automation per evitare del tutto Google OAuth e procede. Lo definisce non un workflow on rails ma una conversazione con il modello, e ammette che una volta su tre arriva alla fine di office hours e si rende conto che l'idea non sta in piedi. Anche questo è un risultato.
Una volta definito il piano, parte una multi-step adversarial review automatica. Il documento di design viene messo alla prova in più round: l'agent identifica problemi concreti (failure handling mancante, sezione privacy assente, handoff 2FA senza soluzione proposta) e prova a riempirli da solo. Quello che non riesce a coprire viene lasciato come issue residue da decidere a mano. Nel demo il design doc passa da 6/10 a 8/10 con sedici issue auto-corrette in due round, e tre questioni residue messe da parte per dopo. È review automatica al servizio del founder, non al posto suo.
Poi entra in scena design shotgun, uno skill che Tan definisce tra i suoi preferiti. Invece di disegnare un'unica UI, l'agent delega a Codex la generazione di tre varianti visive con image gen, e in circa sessanta secondi torna con tre direzioni alternative: command center, friendly progress, split view. Tan le valuta in diretta, le commenta una per una (la versione command center è perfetta per un Linux hacker, ma per utenti normali serve un approccio più accessibile), sceglie la B con il card-based layout e procede. L'opzione di rigenerare passando feedback in linguaggio naturale è sempre lì, ma il punto è generare options per scegliere, non chiedere all'agent di indovinare la migliore in un colpo solo.
Su come orchestrare tutto questo, Tan offre una metafora che è quasi una checklist mentale: di default Claude Code lavora con Claude (Tan parla di Opus come del CEO con ADHD, brillante ma dispersivo), e quando il problema si fa duro si chiama in causa Codex come CTO che chiude le code path complesse. È una divisione del lavoro tra modelli che ricalca la divisione del lavoro tra ruoli umani.
Il punto di arrivo non è una sessione che fila liscia: è un sistema di lavoro a sessioni parallele. Tan lavora con Conductor aprendo dieci-quindici Claude Code in contemporanea, ognuna su un worktree separato. Ogni nuova idea, bug report o segnalazione su X diventa un nuovo work item: click sul pulsante più in Conductor, nuovo worktree, run di office hours, CEO review, end review, adversarial review, e via. Una sessione fa office hours su una nuova idea, due gestiscono le PR open-source della community per fare triage in arrivo (Tan ha più di 400 PR aperte in attesa di review), le altre sviluppano feature in parallelo su branch indipendenti che convergono su main quasi simultaneamente.
Su questo aspetto Tan è esplicito sui rischi. Cita i supply chain attack come una delle cose che lo preoccupano di più nell'AI coding del 2026, e dice di essere paranoico al riguardo. La sua difesa è proprio GStack: la review automatica funziona da filtro su tutto quello che entra dal community prima di toccare main. La paranoia non è opzionale, è parte del processo.
Il QA, che Tan definisce la parte meno divertente del software development, è automatizzato dagli skill /qa e /browse. Tan racconta di avere wrappato Playwright a livello CLI dopo che il Claude in Chrome MCP si era rivelato ingestibile per via del context bloat e della latenza: ogni azione richiedeva due-tre secondi quando funzionava, e spesso non funzionava per niente. Adesso ogni agent può aprire un browser headed o headless, fare screenshot, click, fill di form, download di media, fino a regression test completi e fix di bug CSS o JavaScript veri. C'è anche uno ship tool come ultimo controllo prima di fare merge su main. Tan dice che con questo setup chiude tra 10 e 50 PR al giorno, a seconda dei meeting in agenda.
Il messaggio operativo è semplice: non aspettare di trovare il prompt perfetto. Investi nello scaffolding. Definisci ruoli, processo, review come faresti per un team umano. Tan parla di un livello 8 ideale di software factory, un punto in cui il founder solo orchestra agent in pipeline completamente autonome. GStack, per sua stessa ammissione, ti porta al livello sette, non oltre. Ma il livello sette è già abbastanza per costruire in due mesi quello che a Posterous era costato due anni, dieci milioni di dollari e dieci engineer.
Per Tan questa è l'agent era e il barrier to building è collassato. Per chi legge questo da founder e da builder italiani, la lezione è che il salto di produttività non si gioca più sul prompt engineering raffinato ma sulla disciplina di processo che imponi all'agent. La domanda che resta in piedi è solo cosa costruire. GStack è disponibile su github.com/gritan/GStack se vuoi provarlo direttamente.
**Key takeaways**: - Il collo di bottiglia non è l'intelligenza del modello, ma lo scaffolding intorno: senza ruoli e processo l'agent vaga e produce codice plausibile che si rompe in silenzio. - GStack applica il pattern thin harness fat skills: harness leggero, skill specializzate (office hours, plan CEO review, design shotgun, review, ship) che riproducono i ruoli di un team. - Lo skill office hours forza sei domande di framing prima di scrivere codice: la più importante è qual è la prova più forte che qualcuno voglia davvero questo prodotto. - Adversarial review automatica: il piano viene messo alla prova in più round, si auto-corregge i problemi rilevati e si alza lo score prima di approvare. - Workflow a 10-15 sessioni Claude Code parallele tramite Conductor con worktree separati, una per ogni feature o bug, per chiudere fino a 50 PR al giorno. **FAQ**: - Q: Cos'è GStack e che rapporto ha con Claude Code? A: GStack è un repo open-source di Gary Tan che aggiunge a Claude Code un set di 28 skill, slash command e sub-agent che riproducono i ruoli di un team di engineering. Non sostituisce Claude Code: lo orchestra con office hours, plan CEO review, design shotgun, review e ship. È installabile da github.com/gritan/GStack. - Q: Serve essere developer per usare GStack? A: Tan lo presenta come strumento per founder e builder. Office hours è pensato proprio per chi parte da un'idea grezza: forza sei domande di framing prima di scrivere codice. Per usarlo serve familiarità con Claude Code, CLI e idealmente Conductor per orchestrare sessioni parallele. - Q: Come funziona l'adversarial review? A: Dopo che office hours produce un design doc, una skill dedicata mette il piano sotto stress in più round: identifica buchi (failure handling, privacy, edge case) e prova ad auto-correggerli. Il founder approva quando lo score sale a una soglia accettabile. Nel demo il doc passa da 6/10 a 8/10 in due round con sedici issue auto-fixate. - Q: Perché Tan parla di sessioni Claude Code parallele? A: Una volta che planning, design e coding sono delegati agli agent, il vero collo di bottiglia diventa la review umana. Tan tiene aperte 10-15 sessioni Claude Code in parallelo via Conductor, ognuna su un worktree separato, per chiudere fino a 50 PR al giorno. Ogni feature o bug è un work item indipendente che può procedere senza bloccare gli altri. - Q: Cosa sono /qa e /browse di GStack? A: Sono due skill che wrappano Playwright a livello CLI per dare a qualsiasi agent un browser headed o headless. L'agent può navigare, fare screenshot, click, riempire form, scaricare media e in prospettiva regression test completi. Tan li ha costruiti dopo aver giudicato il Claude in Chrome MCP ingestibile per context bloat e latenza. ### Claude Code in 30 minuti: la guida ufficiale Anthropic URL: https://startupmentors.it/video/claude-code-tutorial-beginners YouTube: https://youtu.be/6eBSHbLKuN0 Channel: Anthropic · 28 min · mvp-build Personas: founder, builder **Perché vale**: Boris Cherny, il creatore di Claude Code in Anthropic, mostra in 28 minuti come passare da prompt sparsi a workflow strutturato: codebase Q&A, CLAUDE.md, slash command, SDK e sessioni in parallelo. Tactical, zero teoria. **Riassunto**:Boris Cherny, member of technical staff in Anthropic e creatore di Claude Code, ha tenuto un workshop dal vivo di 28 minuti dedicato esclusivamente alla pratica: niente storia del prodotto, niente teoria sugli agent, solo prompt che funzionano e workflow da copiare. Per chi sta usando Claude Code in modo superficiale, è il salto più rapido da "interessante" a "questo cambia il mio mese".
Cherny apre chiarendo il posizionamento: Claude Code non completa righe di codice, costruisce feature intere, scrive funzioni e file completi, fixa bug end-to-end. È fully agentic e gira nel terminal, quindi funziona con qualunque IDE, anche su SSH remoto o dentro tmux. Non chiede di cambiare workflow. L'unico requisito di installazione è Node.js.
Prima cosa da fare dopo l'install: lanciare /terminal-setup (così shift+enter va a capo senza backslash), scegliere un tema con /theme, installare la GitHub app con /install-github-app per menzionare Claude in issue e pull request, e personalizzare gli allowed tool per non doverli approvare ogni volta. Su macOS, suggerisce di attivare la dictation di sistema: parlare i prompt al posto di scriverli si rivela più veloce ed esprime meglio l'intento.
Il consiglio numero uno per chi inizia, anche per onboardare un nuovo dev nel team: non far scrivere codice subito. Fai domande al codebase. Tipo "come si istanzia questa classe?", "dove viene usata questa funzione?", "perché questo metodo ha 15 argomenti chiamati così?". Claude Code non fa una text search, va più in profondità: legge gli usage, attraversa la git history, segue i link agli issue collegati nei commit, e ti restituisce una sintesi da wiki interna.
Il dato concreto: in Anthropic l'onboarding tecnico richiedeva 2-3 settimane, ora ne richiede 2-3 giorni. La differenza è quasi tutta qui. E nota una cosa importante per la privacy: nessuna indicizzazione remota, il codice non viene caricato da nessuna parte, non viene usato per addestrare modelli. Setup zero, no attesa, lo accendi e funziona.
Esempio di prompt che Cherny usa ogni lunedì mattina nello standup: "what did I ship this week". Claude Code conosce il suo username, scorre il git log, restituisce un report copiabile.
Solo dopo che ti senti a tuo agio con il Q&A, passa all'editing. Claude Code ha un set di tool piccolo e voluto: edit file, bash, search file. È il modello che decide come comporre la sequenza, non serve guidarlo a basso livello.
Il pattern critico per le feature non banali: chiedere un piano prima del codice. "Brainstorma, proponi un piano, fammelo approvare prima di scrivere". Non serve una plan mode, basta scriverlo nel prompt. Cherny mostra anche un'incantation che usa quotidianamente: "commit, push, PR". Claude legge la git history, deduce il formato dei commit del repo, crea il branch, push e apre la pull request.
Il salto di qualità arriva dando a Claude Code un loop di feedback: unit test che può eseguire, screenshot via Puppeteer, screenshot del simulatore iOS, e mock di una UI da replicare. Con un canale per verificare il proprio output, itera due-tre volte e arriva quasi sempre al risultato giusto. Senza loop di verifica si fida del primo tentativo, e qui sta la differenza tra "quasi giusto" e "production-ready".
Più contesto dai a Claude, migliori sono le decisioni. Lo strumento principale è il file CLAUDE.md nella root del progetto: viene letto automaticamente all'inizio di ogni sessione e iniettato nel primo turno utente. Mettici i comandi bash ricorrenti, gli MCP attivi, le decisioni architetturali, i file core, lo style guide. Va committato e condiviso col team. Tienilo corto: se diventa enorme consuma context window senza valore aggiunto.
Esiste anche CLAUDE.local.md per le tue preferenze personali (non da committare), CLAUDE.md in sottocartelle (caricati on-demand quando Claude lavora lì), ed enterprise policy globali per tutti i dipendenti di un'azienda. Stessa logica gerarchica per gli slash command (.claude/commands/ nel repo o nella home), per le permissions, e per il file .mcp.json che propaga gli MCP server al team.
Tip operativo per chi gestisce un team: shared project context. Scrivi una volta, condividi con tutti, e ottieni un effetto network: una persona migliora la config e ne beneficia tutto il team. Comando /memory per vedere quali file di memoria sono attivi nella sessione corrente; il cancelletto # davanti a una nota la salva direttamente in CLAUDE.md.
Sezione rapida di scorciatoie da terminal che pochi conoscono: shift+tab per entrare in auto-accept edits (i bash command continuano a chiedere approvazione, gli edit vengono accettati automaticamente, sempre annullabili), # per far ricordare qualcosa a Claude, ! per droppare in bash mode (output finisce nel context), escape per interrompere in qualunque momento senza corrompere la sessione, escape escape per saltare indietro nella history, ctrl+R per vedere l'output completo, claude --resume o --continue per riaprire una sessione.
Poi c'è l'SDK. Il flag -p trasforma Claude Code in una utility da riga di comando: gli passi un prompt, definisci gli allowed tool, scegli il formato di output (JSON o JSON streaming), e lo usi in CI, in pipeline, in incident response. Funziona come una utility Unix intelligente: piping in input ("git status | claude -p"), piping in output verso jq. Cherny lo descrive come "barely scratched the surface" — il pattern è ancora in scoperta, ma già oggi viene usato per leggere log da bucket GCP, fetchare dati da Sentry CLI, automatizzare label di issue su GitHub.
Ultimo livello, da power user: parallelismo. Mentre la maggior parte degli ingegneri lavora con una sessione attiva, chi spinge davvero sullo strumento usa più checkout dello stesso repo, sessioni SSH multiple, tunnel tmux verso istanze Claude Code remote, git worktrees per isolare il lavoro. Il dato di chiusura sulla cultura interna: circa l'80% dei dipendenti tecnici di Anthropic usa Claude Code ogni giorno, inclusi i ricercatori che lavorano su notebook.
Il Q&A finale aggiunge tre dettagli utili. La parte più tricky nello sviluppo è stata la safety dei comandi bash: la soluzione è static analysis per identificare i read-only, più un sistema di permission tiered con allow list e block list a più livelli. Claude Code è multimodal dall'inizio: drag-and-drop di un'immagine, file path, copy-paste, tutti modi validi per passargli un mock. E viene usato anche per machine learning e modeling, ricercatori inclusi, con il tool notebook per editare ed eseguire celle. La chiusura del workshop è un invito tattico: configura una volta, condividi con il team, ed estrai valore da questa configurazione per mesi. Per chi lo sta usando da poco, il primo investimento giusto è scrivere il CLAUDE.md del repo principale e committarlo.
Cristina Scocchia è una figura rara nel business italiano: amministratore delegato per tre volte, prima in L'Oréal Italia, poi in KIKO Milano e oggi in illycaffè. Una traiettoria iniziata in un paese di duemila abitanti vicino a Sanremo, con una famiglia normale, due insegnanti come genitori e nessun cognome che apre porte. In questa conversazione di oltre un'ora con Made IT Podcast racconta come si costruisce davvero una carriera ai vertici, senza filtri retorici e senza nascondere i sacrifici.
Il filo che tiene insieme tutta la storia è una frase del padre, ricevuta quando da adolescente si lamentava di non avere le possibilità dei compagni di liceo a Sanremo: non importa se ce la fai, importa il coraggio di provarci. Da lì nasce il tema centrale del libro che Scocchia ha pubblicato di recente, Il coraggio di provarci, e il principio che ripete più volte nel podcast: la disciplina è il ponte tra il sogno e la realtà.
Scocchia descrive un'infanzia ligure con scuola elementare, due alimentari, un'edicola. La frattura arriva con il liceo a Sanremo, dove conosce coetanei con risorse diverse, viaggi, lingue. Da lì la decisione di puntare alla Bocconi contro la tradizione familiare, che voleva l'università a Torino dalla zia con cui vivevano già i cugini. Costò mesi di silenzio col padre, una rottura ricomposta solo quando entrambi capirono che era il momento di girare pagina. La cifra di risparmi era sufficiente per due o tre anni di studi a Milano: il resto sarebbe stato responsabilità sua.
Il messaggio per chi parte da contesti senza capitale economico o sociale è chiaro: non puoi cambiare le condizioni di partenza, ma puoi smettere di lamentartene e usare quell'energia per correre. È lo stesso consiglio che ripete oggi a chi prova a costruire qualcosa di proprio.
L'incontro con P&G arriva per caso, durante un Career Day in Bocconi a cui Scocchia non voleva nemmeno andare. La selezione è dura, l'inglese inizialmente non basta, ma il test scritto va talmente bene che le viene data un'opportunità. Un patto col primo capo, Tony Belloni, ridefinisce tutto: la assumono come laureata pur non essendolo ancora, le pagano lo stipendio pieno, ma se non si laurea in tre anni senza prendere ferie deve dimettersi.
Per tre anni lavora dalle nove di mattina alle dieci di sera, studia dalle undici fino alle tre o le quattro del mattino, e il sabato fa volontariato in ambulanza con la Croce Rossa. Una volta finisce in ospedale per stanchezza, il medico sospetta salmonella, in realtà aveva solo bisogno di dormire due giorni. Non racconta questi anni con tono eroico: li descrive come la fame e la determinazione che sentiva di dover dimostrare, e come gratitudine verso una famiglia e un'azienda che le stavano dando un'opportunità reale.
L'episodio che cambia tutto è la presentazione del budget annuale all'amministratore delegato, dieci giorni prima del meeting il suo capo si licenzia, lei alza la mano, prepara discorso e Q&A in inglese a memoria, presenta. È il primo segnale di carriera. Seguono 16 anni nel gruppo, fra Italia e Ginevra, con un passaggio formativo importante: quattro anni a gestire Cookident, gli adesivi per dentiere. Un brand piccolo, in declino, con poco glamour. Ma è lì che scopre quello che le piace davvero: l'adrenalina del turn-around, il portare la nave fuori dalla tempesta.
La chiamata di L'Oréal Italia arriva proprio per quella reputazione di chi sa rilanciare business in difficoltà. La filiale italiana stava attraversando anni di crisi, Scocchia si costruisce una squadra e la riporta a crescere. Distingue però con onestà: amministratore delegato di una filiale è un ruolo pieno, ma non sei davvero il capo dell'azienda, sopra di te c'è un capo Europa e un CEO globale.
KIKO Milano è un altro film. Lì arriva come CEO mondiale di un retailer in crisi profonda. In due anni chiude il 14% dei negozi, 137 store nel mondo, gestisce un Chapter 11 negli Stati Uniti. Ricorda ancora il nome della prima persona a cui ha dovuto comunicare il licenziamento. Sono cose che non ti insegnano all'università. Il 14 febbraio 2020 annuncia in CDA la fine del turn-around. Tre settimane dopo arriva il paziente uno di Codogno.
Il momento più importante della sua carriera, lo dice esplicitamente, è la decisione presa in quei giorni: chiudere i negozi prima che fosse obbligatorio per legge, e poi chiudere anche l'e-commerce, unica fonte di fatturato rimasta, per quattro settimane. Il motivo: i fornitori che gestivano l'e-commerce erano nella bergamasca, dove l'esercito portava via le bare, e non avevano dispositivi di protezione individuale. In CDA non tutti erano d'accordo, lei mette sul tavolo le dimissioni. Il presidente Antonio Percassi le dà via libera con una frase che cita ancora: durante la tempesta il comandante della nave non si mette in discussione. Risultato: nessun licenziamento, integrazione fino al 70% dello stipendio anche in paesi senza cassa integrazione, l'anno dopo crescita e nuove assunzioni nella bergamasca.
Quando le si chiede come si gestisce concretamente il cambiamento dentro un'organizzazione che non lo vuole, Scocchia offre il framework più operativo del podcast. In ogni azienda ci sono sempre tre gruppi.
I nemici esistono indipendentemente da te, dalla tua visione o dal tuo carattere: persone che volevano il tuo posto, che preferivano un altro candidato, che non condividono la strategia. Non li puoi convertire, devi solo identificarli e disinnescare le mine prima di saltarci sopra. Gli ambasciatori sono il gruppo più numeroso, comprano il messaggio e lo trasmettono per cascata, ma sono fluidi: come nei cambi di governo il corpo diplomatico resta, oggi sostiene te, domani sostiene chi viene dopo. Sono utili ma non incondizionati.
I moschettieri sono il gruppo che fa la differenza in un turn-around. Non sono i sì-uomini: sono persone che ti chiudono la porta della stanza e ti dicono che non sono d'accordo, ma una volta uscite sostengono la decisione presa, sopra di te, sotto di te, alle tue spalle. Una parte la trovi dentro l'azienda, una parte la porti da fuori per contaminazione. È questa squadra ristretta che permette di reggere la pressione nei momenti duri.
Sul tema donne ai vertici Scocchia parte dai numeri: in Italia circa il 7% delle aziende ha una CEO donna, percentuale che scende sotto il 3% se si guardano solo le grandi aziende. Sono talmente poche che si conoscono fra loro. Le ragioni sono culturali prima ancora che strutturali: un ragazzino ambizioso è determinato, una ragazzina con la stessa frase è ambiziosetta. E secondo l'Istat l'80% del carico domestico in Italia ricade sulle donne, cinque o sei ore al giorno, l'equivalente di un altro mezzo lavoro.
Ma quando le si propongono soluzioni come la maternità paritaria obbligatoria, Scocchia tiene un punto controintuitivo: i grandi cambiamenti culturali non si impongono per legge. Servono pari diritti e pari doveri davvero condivisi, servizi pubblici che permettano a entrambi i genitori di realizzarsi, e un codice etico forte fra chi assume ruoli di responsabilità. Chi sceglie un uomo invece di una donna a parità di competenze per evitare il rischio maternità, semplicemente non merita la leadership che ha.
Il punto più netto arriva sulla cosiddetta leadership al femminile. Scocchia rifiuta la categoria. Non crede che le donne debbano avere uno stile diverso, più empatico o più collaborativo. La leadership dipende da carattere, esperienze, valori, non dal genere. Ha conosciuto uomini empatici e donne verticali, e viceversa. Quando si racconta che la leadership al femminile è più dolce, si crea uno stereotipo che poi si ritorce contro: una donna che non corrisponde a quel template viene letta come problema.
La parte più personale del podcast riguarda come ha tenuto insieme i due ruoli. La metafora che usa, che cita anche nel libro, è il giocoliere: tre palle in aria, ma non sono tutte allo stesso livello. Una è in mano e riceve energia, una è arrivata in alto e per un momento può stare ferma, una sta scendendo e va presa prima che cada. Le donne devono smettere di pretendere di essere perfette in tutti i ruoli contemporaneamente. Saper delegare senza sensi di colpa è una competenza, non una rinuncia.
Racconta di aver perso il primo passo del figlio mentre era in viaggio per lavoro a Fort Lauderdale. La madre l'ha chiamata in lacrime per scusarsi, lei si è sentita una madre da buttare via, poi ha avuto l'epifania: quando sarei tornata a casa, mio figlio avrebbe fatto un primo passo per me. Non sarà il primo passo in assoluto, ma sarà il primo passo che vedo io. È un esempio piccolo che racconta una postura mentale molto chiara: i sensi di colpa non recuperano niente, ti consumano e basta.
Le rinunce concrete che cita sono nette. Niente cene di networking, niente eventi mondani la sera quando è a Milano. Sa di aver perso opportunità di business e di carriera per questa scelta. Ha tagliato anche le amicizie larghe, riducendo a un cerchio ristretto di persone con cui passare tempo di qualità. Ha rinunciato agli hobby, ammette che la domanda più difficile che le possono fare oggi è quali sono i suoi hobby, perché non ha tempo per averne.
Per un founder o un operator che ascolta questa conversazione ci sono almeno tre messaggi che valgono indipendentemente dal contesto corporate in cui Scocchia li ha vissuti. Il primo riguarda il punto di partenza: lamentarsi delle condizioni iniziali è legittimo ma non operativo, l'unica strategia che funziona è investire l'energia nel correre. Il secondo riguarda la leadership come responsabilità: il momento in cui quella responsabilità si vede davvero è quando devi prendere decisioni che ti costano, non quando va tutto bene. Il terzo è la regola del giocoliere: smettere di pretendere il 100% in tutti i ruoli ogni giorno è una condizione per durare.
La chiusura del podcast è una battuta che Scocchia ripete alla sua squadra e che funziona bene anche fuori dal contesto FMCG: in salita si accelera, perché è l'unico modo per scollinare. È filosoficamente povera, lo dice lei stessa, ma operativamente vera. Per chi sta costruendo qualcosa di proprio, partendo da zero o quasi, è un buon promemoria.
**Key takeaways**: - Il punto di partenza non definisce dove puoi arrivare: serve disciplina come ponte tra sogno e risultato, non talento puro o fortuna. - La leadership non è potere, è responsabilità: durante la tempesta il comandante decide, anche quando significa chiudere l'unico canale di fatturato per proteggere persone e fornitori. - Per gestire un turn-around mappa subito le persone in tre gruppi (nemici, ambasciatori, moschettieri) e costruisci una squadra mista, fatta di talenti interni e contaminazione esterna. - Lo stile di leadership va alternato in base al contesto: empatia e partecipazione quando il mare è piatto, decisione asciutta quando la nave è in tempesta. - Coniugare CEO e maternità è disciplina militare, non superpotere: rinunci a networking, eventi, hobby, e impari che i sensi di colpa non recuperano nulla. **FAQ**: - Q: Chi è Cristina Scocchia e perché la sua storia è rilevante per chi fa impresa? A: Scocchia è una delle pochissime donne in Italia ad aver guidato tre grandi aziende come amministratore delegato: L'Oréal Italia, KIKO Milano e attualmente illycaffè. Ha costruito tutto partendo da un paese ligure di duemila abitanti, senza network familiari né capitali. La sua traiettoria è uno studio di caso su disciplina, gestione di turn-around e leadership in contesti difficili. - Q: Cosa intende Cristina Scocchia per leadership come responsabilità invece che potere? A: Significa che il ruolo di chi guida non è esercitare autorità ma assumersi il peso delle decisioni che proteggono persone e organizzazione. L'esempio più forte è la decisione presa in KIKO durante la pandemia di chiudere anche l'e-commerce, unica fonte di fatturato rimasta, per dare ai fornitori bergamaschi il tempo di ricevere dispositivi di protezione adeguati. - Q: Come si gestisce un turn-around quando metà dell'organizzazione non vuole cambiare? A: Il framework operativo proposto è mappare le persone in tre gruppi: nemici, ambasciatori, moschettieri. I nemici vanno identificati per disinnescarne le mine. Gli ambasciatori vanno coinvolti perché trasmettono il messaggio per cascata. I moschettieri sono la squadra ristretta su cui si regge il cambiamento, una parte interna e una portata da fuori per contaminazione. - Q: Esiste una leadership al femminile diversa da quella maschile secondo Scocchia? A: No, e considera lo stereotipo dannoso. La leadership dipende da carattere, valori ed esperienze, non dal genere. Promuovere l'idea che le donne abbiano uno stile più empatico crea un template che poi penalizza chi non vi corrisponde. Lo stile va alternato in base al contesto, partecipativo quando il mare è piatto, asciutto quando la nave è in tempesta. - Q: Come si concilia un ruolo da CEO con la maternità senza farsi distruggere dai sensi di colpa? A: La metafora che propone è il giocoliere: le palle non sono tutte al massimo nello stesso momento, ognuna riceve attenzione quando è il suo momento. Concretamente significa scegliere a cosa rinunciare in modo consapevole, networking serale ed eventi mondani nel suo caso, e accettare che i sensi di colpa non recuperano nulla. Delegare senza colpevolizzarsi è una competenza. ### Come Funzionano gli Agenti AI? - Strumenti e Strategie URL: https://startupmentors.it/video/datapizza-agenti-ai-strumenti YouTube: https://youtu.be/sNKAkklCN-c Channel: Datapizza · 27 min · ai-stack Personas: founder, builder **Perché vale**: Se costruisci un MVP con LLM e ti chiedi se ti serve davvero un agent o basta un workflow deterministico, qui trovi il framework mentale per decidere e gli esempi pratici di chi ci lavora ogni giorno. **Riassunto**:Quando un founder o un builder italiano si avvicina al mondo degli agent LLM, la prima difficoltà è semantica: la parola "agente" in italiano suona generica, ma deriva dall'inglese agency, ovvero libertà di azione e autonomia. Nel video di Datapizza, Luca e Raul partono proprio da qui per spiegare cos'è davvero un agent AI, come si progetta un sistema multi-agent e quando ha senso usarlo invece di un workflow tradizionale. Il taglio è pratico e operativo, con esempi presi da progetti reali e domande live dal pubblico che toccano i nodi concreti di chi sta sviluppando questi sistemi adesso.
Un agent LLM è un large language model a cui viene fornito un set di strumenti (tool) che può invocare per compiere azioni. L'esempio più semplice: ChatGPT puro non sa che tempo farà domani a Milano, perché la sua conoscenza interna è statica. Diventa un agent nel momento in cui gli si dà accesso a un tool che, dato un luogo e una data, restituisce le previsioni meteo. L'analogia con l'essere umano è precisa: una persona senza tool risponde solo con quello che ha studiato, una persona-agent può consultare una calcolatrice, cercare su internet o telefonare a qualcuno per arrivare alla risposta. La parte interessante è che un tool, dietro le quinte, è semplicemente una funzione Python con dei parametri. Quindi qualsiasi cosa scrivibile in codice diventa potenzialmente un tool: una chiamata API al meteo, un generatore di immagini come DALL-E, una query a un database, l'accesso al codice di un software aziendale interno. È proprio questa apertura che rende il paradigma agentico interessante per chi costruisce prodotti: se hai accesso al codice del software che la tua azienda usa per processi macchinosi, puoi avvolgerlo in una funzione Python e dare a un agent la capacità di automatizzare o semi-automatizzare quel processo.
Il salto concettuale arriva quando si capisce che un tool può essere un altro agent. A quel punto si possono costruire reti di agent che si chiamano a vicenda, ognuno specializzato in un sotto-task. Luca racconta l'emozione del momento in cui Raul gli ha mostrato per la prima volta agent che collaboravano da soli per risolvere un caso d'uso. Il punto operativo è chiaro: il singolo agent non è complicato da implementare, la difficoltà sta nell'architettura. Bisogna prendere il task principale, scomporlo nelle sue parti più elementari e assegnare ognuna a un agent specializzato. Raul porta un esempio concreto preso da un progetto in corso: un sistema che riceve via mail dei form da compilare (nello specifico, moduli di iscrizione a un workshop di cucina con regole non banali — sezioni obbligatorie, sezioni alternative, dati personali da incrociare). La rete è composta da tre agent in sequenza: un classificatore che capisce se il PDF allegato è davvero il modulo atteso, un ispettore che applica le regole di compilazione e identifica errori, e uno scrittore che genera la mail di risposta al cliente con i problemi rilevati. Una domanda dal pubblico chiede perché non risolvere tutto con una catena di chiamate API. La risposta è che a priori non sai cosa ti arriva nella mail: serve un livello che ragioni sulla richiesta e decida quale percorso attivare, cosa che un singolo prompt monolitico fa fatica a gestire bene per limiti di context window e di affidabilità.
I tool richiedono parametri strutturati per definizione: una funzione Python ha bisogno di sapere che il primo argomento è una data e il secondo una città. Quando dichiari un tool all'agent, gli passi anche le descrizioni dei parametri. Dietro le quinte, framework come quelli di OpenAI inseriscono queste descrizioni nel system message, e il modello è addestrato a capire quale tool usare e con quali parametri. La forza dell'agent emerge proprio nella conversione dell'input non strutturato in chiamata strutturata: se l'utente chiede "che tempo farà domani nel capoluogo lombardo", l'agent capisce che deve chiamare il tool meteo con città uguale a Milano. Se manca un parametro, lo chiede. Questa capacità di tradurre linguaggio naturale ambiguo in azioni precise è esattamente ciò che la programmazione deterministica con if/else o regex fatica a fare. Un esempio operativo: capire se in un form PDF una checkbox è stata spuntata. A livello programmatico è un incubo, perché le checkbox non fanno parte del testo estraibile e i PDF hanno formati eterogenei. Se poi il modulo è scannerizzato o fotografato male, non c'è proprio modo di leggerlo senza un sistema che ragioni come farebbe un occhio umano. Lì l'agent diventa la scelta naturale.
Una domanda dal pubblico tocca il tema RAG. Il limite del RAG tradizionale è che la ricerca per similarità tra query e chunk si basa su distanze tra vettori numerici, senza un livello di intelligenza che valuti davvero la rilevanza. Quando il caso d'uso è complesso, succede di non beccare mai il chunk giusto. La soluzione che sta emergendo nei progetti più articolati è il RAG agentico: agent che hanno in pancia pezzi di documenti critici e decidono attivamente cosa portare nel contesto del modello. Su un altro fronte, sul fine-tuning dei modelli di embedding, il messaggio è prudente. Sui modelli piccoli può aiutare, sui modelli grandi e generalisti ha senso solo se lavori in un dominio molto specifico e nessun modello pre-trained disponibile ti soddisfa. La parte difficile è costruire il dataset: servono migliaia, idealmente decine di migliaia di esempi, e anche se gli LLM moderni aiutano a generare dati sintetici, bisogna fare attenzione alla qualità.
Il pain point principale, secondo Raul, non è scrivere codice ma decidere dove serve davvero un agent. Le casistiche estreme sono semplici: workflow completamente deterministico (niente agent) o workflow completamente agentico con molto ragionamento freestyle. Le situazioni difficili stanno nel mezzo, dove parte del flusso è deterministica e parte richiede ragionamento. La regola pratica è chiara: se un problema si risolve con un if/else, usare un agent equivale a uccidere una formica con un bazooka. Un agent al 99% di accuracy va peggio di una regex al 100%. Ma quando devi capire se un testo parla di un certo argomento, o gestire input non strutturati, allora la programmazione deterministica non scala. Sul fronte tooling, il giudizio sui framework esistenti è duro ma onesto: librerie come CrewAI sono molto specializzate in una direzione, LangChain ha un livello di complessità non trascurabile, e nessuna delle opzioni è ancora completamente matura per ogni caso d'uso. Per questo Datapizza sta sviluppando un proprio framework interno. Un altro problema operativo è il parallelismo: quando alcuni agent vanno richiamati in sequenza e altri in parallelo per ridurre la latenza, bisogna scegliere tra threading, async e multiprocessing. La direzione che stanno prendendo è async, per i limiti noti del multithreading in Python. Sulla comunicazione tra agent ci sono diverse opzioni valide: function calling con parametri strutturati, scambio di messaggi, oppure una memoria condivisa implementata tramite un database esterno trasformato in tool accessibile a più agent.
Il messaggio finale per chi costruisce con gli agent oggi è coerente con l'esperienza di chi ci lavora ogni giorno: la documentazione strutturata su questi temi è scarsa, le tecnologie sono troppo nuove perché esistano percorsi formativi consolidati, e l'unica strada è l'autodidatta — leggere documentazione, seguire chi sperimenta su Twitter e LinkedIn, e soprattutto provare. La fase di brainstorming architetturale, fatta anche solo con un foglio e una penna per disegnare il flusso, sta diventando più importante della fase di scrittura del codice vero e proprio. Per un founder italiano che sta valutando se costruire il proprio prodotto attorno a un sistema multi-agent, questo è il segnale operativo principale: il vantaggio competitivo si gioca sulla capacità di scomporre bene il problema, non sulla padronanza del singolo framework.
**Key takeaways**: - Un agent LLM è un modello a cui dai un set di tool (funzioni Python, chiamate API, altri agent) per espandere quello che può fare oltre la sua conoscenza interna. - Il vero lavoro architetturale non è scrivere il singolo agent, ma scomporre il task principale in sotto-task e assegnare ognuno a un agent specializzato. - Un tool può essere qualsiasi cosa scrivibile in codice: una calcolatrice, una query SQL, un accesso a un software aziendale interno, persino un altro agent. - Gli agent brillano sugli input non strutturati (PDF scannerizzati, mail, form compilati male) dove la programmazione deterministica con if/else non basta. - Il pain point principale non è implementare l'agent, ma capire quando serve davvero rispetto a un workflow tradizionale o a una semplice catena di chiamate API. **FAQ**: - Q: Qual è la differenza tra un LLM puro e un agent LLM? A: Un LLM puro risponde solo sulla base della conoscenza interna acquisita in fase di training. Un agent LLM riceve in più un set di tool, ovvero funzioni esterne (API, query a database, altri agent) che può invocare per recuperare informazioni aggiornate o compiere azioni concrete. Il modello impara dalle descrizioni dei tool quale usare e con quali parametri. - Q: Quando ha senso usare un sistema multi-agent invece di una singola chiamata LLM? A: Conviene quando il task è complesso e l'input non è prevedibile a priori. Un singolo prompt monolitico fa fatica a verificare molte regole insieme per limiti di context window e affidabilità. Scomporre il problema in sotto-task assegnati ad agent specializzati produce risultati più stabili e debuggabili, soprattutto su workflow che combinano logica deterministica e ragionamento. - Q: Cosa può essere un tool per un agent? A: Qualsiasi cosa scrivibile in codice. Le opzioni più comuni sono funzioni Python, chiamate API esterne (meteo, ricerca web, generazione immagini), query SQL su database relazionali, ricerche per similarità su database vettoriali, accessi a software aziendali interni e perfino altri agent. La libertà sta nel fatto che il tool deve solo esporre parametri strutturati con descrizioni chiare. - Q: Quando NON conviene usare un agent? A: Quando il problema si risolve con regole deterministiche tipo if/else o con regex. In quei casi un agent introduce overhead di latenza e costi senza aggiungere valore, e tipicamente offre accuracy inferiore rispetto a una regola codificata. La domanda da farsi è se serve davvero ragionamento sul linguaggio naturale o sull'input non strutturato. - Q: Come comunicano tra loro gli agent in un sistema multi-agent? A: Le opzioni principali sono tre. Function calling con parametri strutturati, dove un agent chiama l'altro come fosse una funzione. Scambio di messaggi in linguaggio naturale, utile per coordinamento meno rigido. Memoria condivisa, di solito implementata come database esterno trasformato in tool accessibile a più agent. Le tre opzioni convivono nello stesso progetto a seconda del tipo di informazione da scambiare. ### Elena Verna (Lovable): perché i growth playbook crollano URL: https://startupmentors.it/video/elena-verna-growth-playbooks-lovable YouTube: https://youtu.be/Vc6ij1ilhwc Channel: Product School · 27 min · crescita-marketing Personas: operator, founder **Perché vale**: Elena Verna (advisor growth, ex Dropbox, oggi Lovable) smonta i canali di distribuzione su cui hai costruito il tuo growth team. SEO che cala dell'80-90%, social che chiudono il rubinetto, vibe coding che commoditizza intere categorie SaaS. Cosa resta che funziona davvero. **Riassunto**:Elena Verna ha guidato growth team per dieci anni, è passata da Dropbox a SVP Growth di Lovable e apre il talk con una provocazione che vale la pena registrare: ci sono milioni di prodotti incredibili che non hai mai sentito nominare, e ci sono prodotti orribili che fatturano miliardi. La differenza non è la qualità del prodotto, è la distribuzione. Se non pensi alla distribuzione mentre costruisci, muori di morte lenta. E la maggior parte dei team di prodotto, dice Verna, ci pensa troppo poco e troppo tardi.
La domanda operativa che si porta dietro tutti i giorni è una matrice di quattro punti: come acquisiamo i clienti, come li attiviamo, come li monetizziamo, come li tratteniamo. Le aziende che vincono sono quelle che rispondono a queste quattro domande in modo prevedibile, sostenibile e competitivamente difendibile. Tutto il resto è rumore.
Verna usa un termine che vale la pena rubare: chiama "funnel" la f-word del growth, una parola che le tocca pronunciare ma che preferisce evitare. Le aziende che crescono più velocemente non crescono per funnel, crescono per loop. Un loop è un flywheel che compone: c'è un input (per esempio un nuovo utente), che genera un'azione, che produce un output, che si reinveste come nuovo input. Esistono loop di marketing, di sales, di prodotto, ognuno con durata e potenza diverse, ma sono i loop di prodotto quelli che generano crescita prevedibile e difendibile.
Due esempi concreti dal suo percorso. Dropbox è cresciuto al primo miliardo di fatturato quasi senza spesa marketing grazie a un viral loop classico: dai storage in cambio di storage. Oggi il 60% dell'acquisition di Dropbox arriva da un product loop diverso ma sempre interno: nuovo utente carica contenuti, vuole condividerli, una percentuale dei destinatari si registra. Il 60% di acquisition costruita dagli utenti stessi, non dai team marketing o sales. Su Lovable, che ha solo dieci mesi, il loop dominante è ancora il word of mouth: il prodotto supera le aspettative nei primi due minuti, l'utente sente il bisogno di raccontarlo, una parte del network si registra. Non è sostenibile a lungo, ma è il modo migliore per innescare crescita all'inizio. La lezione operativa per chi fa growth e per i founder: investi i primi due minuti dell'esperienza come se fossero l'unica cosa che conta, perché lì si decide se il word of mouth si accende o si spegne.
Cinque anni fa il product-led growth è esploso per quattro motivi precisi. Primo, nel B2B gli utenti finali sono diventati buyer: non più checklist enterprise calate dall'alto su utenti che odiavano il prodotto, ma adozione bottom-up di strumenti consumer-like che risolvono davvero un problema. Secondo, il ciclo di vita dei canali si è accorciato brutalmente: una campagna marketing oggi dura una settimana, contro l'anno che durava una campagna Coca-Cola dieci anni fa. Terzo, i dati sono diventati accessibili dentro il prodotto, non solo via sales. Quarto, i ruoli si sono mescolati: il product manager deve avere un cappello marketing, il marketer deve essere mezzo PM, tutti devono saper leggere dati. Verna lo descrive come la cosa più bella successa al mestiere, ma anche la più stressante.
Poi è arrivato l'AI e ha riscritto la mappa. Non solo a livello di prodotto, dove ogni roadmap ha aggiunto features AI di cui nessun cliente aveva chiesto, ma soprattutto a livello di distribuzione. G2, azienda B2B che vive di reviews e che si era ottimizzata interamente sul SEO, ha visto l'acquisition crollare dell'80-90% da quando ChatGPT ha cambiato le abitudini di ricerca. La gente non googla più, chiede a un LLM. Il SEO come canale primario è in crisi profonda per chiunque ci aveva costruito sopra il go-to-market. I social non aiutano: gli algoritmi cambiano ogni giorno, e i network stanno strozzando gli outbound link perché il loro KPI di retention è l'intensità di utilizzo. Metti un link nel post, e l'algoritmo ti penalizza. Search difficile, social difficile, la torta dei canali tradizionali si sta restringendo.
Qui Verna apre il pezzo più scomodo del talk, quello che ogni founder dovrebbe stamparsi sopra il monitor. Su Lovable, e nel vibe coding in generale, sta succedendo una cosa che internamente chiamano "SaaS replacement": invece di pagare abbonamenti gonfi per software bloated, gli utenti si costruiscono il proprio tooling. Funzionalità che fino a ieri sembravano difendibili, firme digitali, form, generazione di landing page, scheduling, no-code tool, dashboard, tooling interno, oggi si ricostruiscono in un pomeriggio. La barriera della commoditizzazione si sta alzando di colpo.
Il consiglio operativo è brutale e diretto: vai su una piattaforma di vibe coding e prova a ricostruire la funzionalità core del tuo prodotto. Se ci riesci facilmente, devi preoccuparti seriamente, perché significa che da un giorno all'altro stai competendo non più con altre aziende ma con i tuoi stessi clienti che si stanno costruendo il tuo replacement. La matrice 2x2 che Verna usa: complessità della funzionalità (alta o bassa) per utilizzo (alto o basso). Se hai funzionalità complesse e ad alto utilizzo, sei in zona sicura. Se hai funzionalità complesse ma poco usate, devi alzare l'utilizzo. Se hai funzionalità semplici ad alto utilizzo, la tua product strategy ha un problema serio. Docusign sta minacciando azioni legali contro utenti che hanno replicato la firma elettronica con vibe coding: quando devi difendere il product-market fit per via legale, non è un buon segno.
Verna chiude con sette opzioni operative che vale la pena trattare come checklist. Prima leva, i product loop restano centrali: tratta il prodotto come canale marketing, considera il freemium come budget marketing e non come costo. Su Lovable oltre metà dei costi viene dal freemium, ma lo guardano come investimento in acquisition: meglio dare il prodotto agli utenti che pagare Google. Importante: con l'AI il freemium si è ribaltato, perché ogni interazione costa molto e i margini SaaS classici dell'80-90% sono crollati al 30% o meno. Il calcolo va rifatto.
Seconda leva, velocity di shipping come moat. Lovable, 60-70 persone, rilascia tier 1 ogni tre mesi (le big launch), tier 2 a cadenza settimanale, tier 3 ogni ora. Per arrivarci servono due cose: AI native employees, persone che usano AI in tutti gli ambiti del proprio lavoro e indossano più cappelli (engineer che lanciano marketing, per esempio), e zero gridlock cross-funzionale. Meno dipendenze interne, più agency e fiducia ai singoli per portare un progetto end-to-end.
Terza leva, i dati come moat. Memoria utente, dati strutturati, integrazioni nei sistemi del cliente: sono asset di retention e difendibilità. Il caso Salesforce-Slack-Glean è un esempio operativo da studiare: Salesforce ha capito quanto conta il dato Slack e ha tagliato l'accesso a Glean che ci costruiva sopra l'enterprise search. Senza dati Slack, l'enterprise search interna non funziona. Quarta leva, brand come funzione di prodotto. Lovable ha zero spesa branding e quasi zero marketing, ma il brand si sente perché lo costruiscono dentro l'esperienza prodotto. La domanda interna che si pongono per fixare qualsiasi cosa è "questa esperienza è lovable o unlovable?" Quinta leva, integrazioni e partnership. Strategia che richiede first mover advantage, perché chi arriva primo prende il canale. Verna cita l'app store di OpenAI uscito due giorni prima del talk come potenziale prossimo Google search per la distribuzione AI: vale la pena tenerlo d'occhio.
Sesta leva, founder e employee social. Anton, CEO di Lovable, dieci mesi fa aveva zero following su LinkedIn. Oggi i suoi post fanno 2.000+ reazioni e milioni di impression organiche. Verna invita esplicitamente a fare lo stesso: in Lovable tutti possono postare, in aziende grandi i team legali bloccano, ma chi può deve farlo perché umanizzare l'azienda è leverage organico gratuito. Settima leva, creator economy: gli influencer non sono più solo B2C. YouTube è enorme per B2B, TikTok e Instagram pure se la tua audience è lì. L'influencer marketing tecnico è un canale serio.
La sintesi finale che Verna lascia ai builder e operator italiani è una sola: non puoi più scaricare la distribuzione su marketing e sales. Devi farne una responsabilità di prodotto. È nel prodotto che costruisci il canale più difendibile, perché è l'unico che non può togliertelo Google, OpenAI o un cambio di algoritmo.
**Key takeaways**: - I funnel sono morti, vincono i loop. Acquisition, activation, monetization e retention vanno pensate come flywheel che si ricarica da solo, non come imbuto lineare. Su Dropbox il 60% dell'acquisition arriva da un product loop, non da marketing o sales. - Il search organico sta collassando: G2 ha perso l'80-90% del traffico SEO da quando ChatGPT ha cambiato le abitudini di ricerca. I social network strozzano gli outbound link per massimizzare retention. Affidarsi solo a marketing e sales per la distribuzione oggi non basta più. - Il vibe coding sta commoditizzando funzionalità che credevi difendibili: firme digitali, form, scheduling, dashboard, tooling interno. Se la funzione core del tuo prodotto si ricostruisce in un pomeriggio su Lovable o simili, non stai più competendo con altre aziende ma con i tuoi stessi clienti. - Il prodotto stesso diventa il tuo canale marketing più difendibile. Lovable spende oltre metà dei costi sul freemium e lo tratta come budget marketing, non come centro di costo: meglio dare il prodotto in mano agli utenti che pagare Google. - Cinque leve concrete oltre ai product loop: velocity di shipping (Lovable rilascia tier 2 a settimana, tier 3 ogni ora con 60-70 persone), dati come moat (Salesforce ha tagliato l'accesso Slack a Glean per difendere il suo), brand come funzione di prodotto e non di marketing, integrazioni e partnership (vedi app store OpenAI), founder e employee social organico. **FAQ**: - Q: Cosa intende Elena Verna quando dice che i funnel sono morti e contano solo i loop? A: Il funnel è il modello lineare classico (acquisition → activation → monetization → retention). Il loop è un flywheel che compone: l'output di un'azione utente diventa input per acquisirne di nuovi, senza ricominciare da zero ogni volta. Esempio Dropbox: utente carica contenuti, li condivide, una parte dei destinatari si registra, quei nuovi utenti ripetono il ciclo. Il 60% dell'acquisition di Dropbox arriva da questo product loop, non da spesa marketing. Per costruire un loop devi pensare al prodotto come canale di distribuzione, non come destinazione finale. - Q: Perché il SEO sta crollando per molte aziende B2B? A: Le abitudini di ricerca sono cambiate: gli utenti chiedono a ChatGPT, Claude o Perplexity invece di googlare. Verna porta il caso di G2, azienda B2B di reviews che si era ottimizzata interamente sul SEO: l'acquisition è scesa dell'80-90% da quando ChatGPT è esploso. Il problema non è solo G2, è strutturale. Chi aveva costruito il go-to-market sul search organico deve ricostruirsi una distribuzione fatta di product loop, brand, integrazioni e canali AI nativi (vedi app store OpenAI). - Q: Cosa significa che i clienti diventano competitor con il vibe coding? A: Con strumenti come Lovable o piattaforme di vibe coding simili, gli utenti si costruiscono da soli funzionalità che prima compravano via SaaS: form, firme digitali, scheduling, dashboard, tooling interno. Verna lo chiama internamente 'SaaS replacement use case'. Se la funzione core del tuo prodotto si ricostruisce in poche ore su una di queste piattaforme, non stai più competendo con altre aziende ma con i tuoi stessi clienti che ti stanno facendo replacement. Il consiglio operativo: prova a ricostruire il tuo prodotto in vibe coding. Se ci riesci facilmente, devi ripensare la product strategy. - Q: Come fa Lovable a rilasciare update tutti i giorni con 60-70 persone? A: Verna parla di due abilitatori. Primo, AI native employees: persone che usano AI trasversalmente nel proprio lavoro e indossano più ruoli (engineer che fanno marketing, marketer che fanno PM). Secondo, riduzione drastica delle dipendenze cross-funzionali: meno gridlock interno, più autonomia individuale, fiducia nel portare progetti end-to-end. Il rilascio è strutturato a tier: tier 1 (big launch) ogni tre mesi, tier 2 (update sostanziali) settimanali, tier 3 (update minori ma significativi) ogni ora. Velocity diventa il moat. - Q: Perché Lovable considera il freemium budget marketing e non costo? A: Su Lovable oltre metà dei costi totali deriva dall'utilizzo freemium. Invece di trattarlo come centro di costo da ottimizzare, lo guardano come marketing budget: meglio dare il prodotto in mano agli utenti che spendere quegli stessi soldi su Google Ads. C'è un caveat operativo importante che Verna sottolinea: con l'AI il freemium è più costoso che in passato perché ogni interazione consuma compute. I margini SaaS storici dell'80-90% sono scesi al 30% o meno, quindi il calcolo del freemium come canale acquisition va rifatto azienda per azienda. ### Reflections on a movement | Eric Ries (Lean Startup) URL: https://startupmentors.it/video/eric-ries-lean-startup-reflections YouTube: https://youtu.be/xzebbzIntFc Channel: Lenny's Podcast · 134 min · strategia-business-plan Personas: founder, operator **Perché vale**: Dopo dodici anni dal libro, Eric Ries ripensa il Lean Startup: cosa ha funzionato, cosa è stato frainteso, e come l'AI cambia le regole. Centotrentaquattro minuti distillati in un framework attuale per founder e operator che vogliono costruire aziende che durino. **Riassunto**:Eric Ries ha scritto The Lean Startup nel 2011. Oggi, dopo più di un decennio passato ad accompagnare founder e CEO di grandi aziende, racconta a Lenny Rachitsky un bilancio onesto: cosa ha funzionato, cosa è stato frainteso, e cosa rifarebbe. La conversazione di oltre due ore tocca MVP, pivot, salute mentale dei founder, l'arrivo dell'AI, governance e il senso profondo di costruire un'azienda. Non è un'apologia del proprio metodo: è un riesame, con la voglia esplicita di trattare le idee come ipotesi da rivedere, esattamente come insegna il libro.
Quando Ries iniziò a scrivere del Lean Startup, lo fece in anonimo. Pubblicare un blog era considerato suicidio professionale, e i primi tre blogger di startup gli scrissero personalmente perché vedevano un nuovo nome nei loro referrer. Lui veniva chiamato in azienda come dispensatore di "polverina magica": nelle riunioni gli urlavano contro, lo cacciavano, non credevano che IMVU shippasse cinquanta volte al giorno quando il resto del mondo rilasciava ogni mese.
Poi qualcosa è cambiato. La carica iniziale, da "religious revival" pronto alla guerra contro le vecchie metodologie, ha incontrato un campo di battaglia vuoto: nessuno difendeva davvero lo Stage-Gate. La vittoria è arrivata per assenza di avversari. I termini che Ries ha coniato o popolarizzato, come MVP, pivot, A/B test, vanity metrics e continuous deployment, sono diventati il vocabolario base del settore. E con la normalizzazione è arrivata anche la noia: i nuovi founder ascoltano le idee del libro e dicono "è ovvio". Ries ha imparato a riconoscere che quella è la vera vittoria. Non un parade, ma le storie silenziose di chi gli scrive per dire "il libro mi ha aiutato".
Il primo errore che Ries riconosce è il capitolo finale, quello sullo scaling del Lean Startup nelle grandi aziende. Non c'è niente di tecnicamente sbagliato, ma è scritto in modo "blithe", troppo passo-passo, "step one, step two". L'ha rimediato con un libro intero successivo, ma il senso di colpa rimane: ogni volta che fai sembrare facile l'imprenditoria, stai preparando qualcuno alla delusione.
Il secondo rimpianto è più profondo. Nell'introduzione del libro, Ries scrive che il Lean Startup darà ai founder gli strumenti per cambiare il mondo. Avrebbe voluto aggiungere "in meglio". Lo dava per scontato, era il valore con cui era cresciuto, ma il decennio successivo ha mostrato che non lo era affatto. Il meme di Anakin Skywalker ("I'm going to change the world for the better, right?") è diventato per lui la sintesi della tech industry: aziende che cambiano davvero il mondo dimenticando di chiedersi se in meglio.
Quasi ogni anno qualcuno scrive a Ries dicendo che andava usato un termine diverso da MVP. La sua risposta è sempre la stessa: proponi tu un termine migliore e lo userò. Il problema non è il nome, è la traduzione automatica che la gente fa: MVP = prodotto scarso, stripped down, che crasha. Sbagliato. MVP è semplicemente il modo più efficiente per ottenere la validazione di cui hai bisogno su un'ipotesi.
Ries lo dice esplicito: ha lavorato su jet engine, terapie oncologiche, robotica, e il Long-Term Stock Exchange ha richiesto dieci anni per essere costruito. Il suo MVP. La parola "minimum" non significa cheap, significa as little as necessary per testare quella specifica ipotesi su quello specifico cliente.
Quando un founder è bloccato sul "quanto deve essere grande il mio MVP", Ries dà un consiglio brutale: scrivi la lista delle feature che ti sembrano necessarie, tagliala a metà, taglia di nuovo a metà, e costruisci quello. Le persone sono sistematicamente sbagliate di uno o due ordini di grandezza su quanto lavoro serve. La curva è a U: se ti avvicini all'ottimo, va bene. Il problema vero è quasi sempre upstream: non hai chiarezza su cosa vuoi imparare. E spesso non vuoi ammettere di non saperlo.
La storia che racconta sugli avatar 3D di IMVU è esemplare. Non potevano permettersi l'inverse kinematics per far camminare gli avatar, quindi li tenevano fissi sulle sedie. I clienti si lamentavano di "claustrofobia". Un giorno, come hack, Ries cambia il rendering: clicchi sul punto e l'avatar teletrasporta, senza camminare. Brutto, sotto la qualità di IMVU. Lo shippano comunque. Niente succede. Anzi: nelle survey, gli utenti iniziano a dire che IMVU è "più avanzato dei Sims" perché "ti teletrasporti, non aspetti che il tizio cammini". Il bug era diventato feature. Senza il rilascio sotto-qualità, non l'avrebbero mai scoperto.
Il pivot nella definizione originale è cambio di strategia mantenendo fedeltà alla vision. Ma Ries oggi ammette qualcosa di più sottile: anche la vision evolve. I founder scoprono la vision attraverso il processo di costruzione, non la possiedono dall'inizio. Lo dimostra con una storia personale: anni dopo aver lasciato un'azienda, ritrova una lavagna originale di un meeting fondativo, e si accorge che molte delle idee scritte di suo pugno sono idee che ricorda di non aver mai sostenuto, attribuendole al co-founder. La memoria psicologica e l'evidenza fisica si contraddicono.
Per chi sta valutando un pivot, il framework operativo è semplice: se ti stai chiedendo se sia ora di pivotare, probabilmente sai già la risposta. Il product-market fit non lascia tempo per chiederselo. Una volta ammesso che non funziona, datti sei settimane (o sei giorni, o un weekend) di tempo fisso per testare con tutta la squadra una sola ipotesi nuova. Fai il giro del tavolo: "se potessi ricominciare oggi, su cosa lavoreresti?". Spesso scopri che tutti volevano dire la stessa cosa da mesi ma avevano paura di deludersi.
Una delle parti più dure dell'intervista è quando Ries dice che avere una startup che fallisce non è nemmeno tra le dieci cose peggiori che possono capitarti. Peggio è essere bloccati in un'azienda zombie che non muore ma che odi. Peggio è vendere un'azienda che diventa qualcosa di abominevole e di cui devi fingere di non essere stato parte. Conosceva personalmente Tony Hsieh e altri founder "di successo" finiti male.
Il sistema delle startup ha una cosa positiva paradossale: alla fine i soldi finiscono e devi dichiarare bancarotta. È una funzione, non un bug. Per chi è ancora dentro a un'azienda che non vola, il consiglio è secco: se potessi agitare una bacchetta magica e iniziare una nuova azienda oggi, sceglieresti questa? Se no, non c'è più la servitù della gleba. Chiudi, restituisci i soldi, fai un hard pivot. Ego identification con la propria azienda è la ricetta per la depressione.
Ries vede l'AI prima come tecnologia di management che come tecnologia di prodotto. È una tecnologia che gestisce intelligenze e altre intelligenze. Chi prova a costruire AI agent oggi ne tocca subito i limiti: l'agent riceve un task, spawna un sub-agent, che spawna un altro sub-agent in un regresso infinito di delega. Chi è stato middle manager riconosce il pattern al volo.
Ma il punto strategico è un altro: l'AI abbassa drasticamente il costo della sintesi. Una delle ragioni per cui le aziende hanno layer e layer di gerarchia è che riassumere centomila attività di centomila dipendenti per il CEO costa lavoro umano. Se l'AI fa quella sintesi a costo quasi zero, lo span of control individuale può crescere di un ordine di grandezza e l'organigramma collassa.
Sul rovescio della medaglia: ogni canale di comunicazione sta per essere saturato di email, pitch, prospect AI-generated. La risposta non è bandire, è AI-mediated marketplace: il tuo agent legge la posta con il tuo filtro di procurement e ti porta solo quello che combacia. È più equo della pubblicità, perché il tuo agente non si fa convincere dal tono brillante, valuta la sostanza.
Ries fa anche una mossa filosofica importante. Tutti chiedono "AI sarà utopia o distopia?" e ognuno ha la propria certezza. Ma nessuno conosce davvero la risposta: dipende da questioni empiriche aperte. Allora il framework giusto, lo stesso del Lean Startup applicato all'incertezza esistenziale, è scegliere azioni che abbiano senso etico in un'ampia varietà di scenari futuri. Più trasparenza, più capacità statale, più leader competenti, più aziende con valori espliciti: queste cose sono buone in ogni mondo possibile. Quindi falle.
La parte finale dell'intervista è la più radicale. Ries chiede a un ex-Googler: "qual è la probabilità che Google depositi il prossimo report trimestrale in tempo?". Risposta: cento per cento. "Qual è la probabilità che Google sia complice di qualcosa che gli faccia fare soldi al costo di una vita umana?". Risposta: "non lo farebbero apposta". La differenza tra il certo e il non certo rivela cosa l'azienda davvero sa fare e cosa no. Le aziende sono brave nelle cose che gli interessano. Quindi possiamo capire cosa interessa veramente a un'azienda guardando cosa è bravo a fare.
Per Ries, il punto chiave è che un singolo founder non può fare promesse a nome dell'organizzazione. È sostituibile. Le aziende sono superorganismi, non si possiedono, si nutrono. Se vuoi che l'azienda mantenga una promessa anche dopo che tu non ci sarai, devi codificarla nella struttura stessa: public benefit corp, foundation control, board mission pledge, LTSPV con LP pre-impegnati alla mission, founder preferred shares.
Il dato che lo ha sconvolto: aziende controllate da fondazioni come Hershey, modelli giapponesi tipo Toyota, fino al 20-25% delle public company in alcuni paesi europei (Danimarca in particolare) performano meglio dei competitor public standard. Il paper di ricerca esiste. La dottrina della shareholder primacy è sbagliata anche solo per massimizzare il ritorno azionario. Eppure a quasi nessun founder viene mai proposto questo modello. Il consiglio operativo di Ries: parla con il tuo avvocato adesso, non quando sei a diciotto mesi dall'IPO, perché è "sempre troppo presto finché non è troppo tardi".
Tra le idee che Ries ha provato a lanciare e che non hanno avuto il successo del pivot e dell'MVP c'è un concetto che sente ancora sottovalutato: gli engagement loop. I viral loop spiegano come un prodotto cresce. Gli engagement loop spiegano perché un cliente torna. Non è la stessa cosa della "stickiness" da gamification: è un modello rigoroso. Una persona torna sul tuo prodotto solo per tre ragioni possibili: una notifica sintetica che gli mandi tu, una notifica organica generata da un altro utente (lo storico esempio di PayPal "you've got money"), o un trigger interno legato al positioning, una situazione di vita che gli fa pensare al tuo prodotto. Sono solo tre, e sono tutte misurabili. Ries è ancora convinto che chi capisce la matematica degli engagement loop oggi abbia un vantaggio competitivo notevole, soprattutto in un mondo dove l'attenzione è il bene più scarso.
La forza di questa conversazione non è in un singolo trick. È nella postura: trattare il proprio metodo come ipotesi, accettare che la vision si scopra costruendo, riconoscere il fallimento prima che diventi zombie, e infine alzare lo sguardo dalla feature di prodotto al livello di governance, dove si decide davvero che tipo di soul avrà l'azienda che stai mettendo al mondo. Per i founder italiani che oggi si misurano con AI, capitale scarso e bandi, il sottotesto è chiaro: la disciplina del test rapido vale ancora, ma da sola non basta. Serve anche la struttura, dura e contrattuale, che protegga quello che dichiari di voler costruire. E serve, soprattutto, la lucidità di chiedersi non solo "come faccio crescere questa azienda" ma "è ancora questa l'azienda che voglio costruire". Ries lo dice senza retorica: la risposta a quella domanda, ripetuta ogni sei mesi, è il vero motore di una carriera da founder che dura.
**Key takeaways**: - L'MVP non è 'prodotto scarso e veloce': è il test più efficiente per validare l'ipotesi che ti serve. La qualità minima dipende dal cliente, non dal tuo gusto. Lista delle feature che credi necessarie, dimezzala due volte e parti da lì. - Il pivot è cambio di strategia con fedeltà alla vision, ma la vision stessa si scopre costruendo. Se ti stai chiedendo se sia ora di pivotare, probabilmente sai già la risposta: chi è dentro al product-market fit non ha tempo per chiederselo. - Lo zombie funding è peggio del fallimento: un'azienda che non muore ma che odi è una crisi di salute mentale silenziosa per migliaia di founder. Meglio chiudere e restituire i soldi che restare incastrati. - L'AI è una tecnologia di management, non solo di prodotto. Cambia lo span of control, abbassa il costo della sintesi gerarchica e satura ogni canale: serviranno marketplace AI-mediati e nuove regole di filtering. - Governance non è burocrazia: è il modo in cui codifichi nell'azienda promesse che resistano anche a un cambio di CEO o a un investitore predatorio. Le aziende foundation-controlled (Hershey, OpenAI, modello danese) batteno spesso i competitor public. **FAQ**: - Q: Cosa cambierebbe Eric Ries del libro Lean Startup oggi? A: Due cose. Il capitolo sullo scaling, scritto in modo troppo facile e step-by-step, che gli ha fatto poi scrivere un libro intero (The Startup Way) per spiegare la complessità reale. E l'introduzione, dove parla di founder che cambieranno il mondo: avrebbe voluto aggiungere 'in meglio'. Lo dava per scontato, ma il decennio successivo ha mostrato che non era affatto scontato. - Q: L'MVP è ancora rilevante con AI tool e standard di qualità più alti? A: Sì, ma va capito bene. MVP non significa prodotto scarso o veloce. Significa il test più efficiente per validare la specifica ipotesi che ti serve. La qualità minima è definita dal cliente, non da te. Anche in settori ad alta posta in gioco, come jet engine o data center, il costo di proporre qualcosa che il cliente rifiuta è basso: dice no e basta. Il vero spreco non è shippare presto qualcosa che il mercato non vuole: è shippare tardi qualcosa che il mercato non vuole, dopo aver investito anni di craft. - Q: Come applica build-measure-learn alle AI startup? A: Per Ries l'AI è prima una tecnologia di management, poi di prodotto. Cambia tre cose. Primo: alza enormemente la velocità di esperimentazione (vedi sales prospecting AI-generated su decine di migliaia di prospect). Secondo: abbassa il costo della sintesi gerarchica, quindi cambia lo span of control e l'organigramma. Terzo: in un mondo di canali saturi di output AI, vincono i marketplace AI-mediati dove il tuo agente filtra le proposte dei venditori in modo più equo della pubblicità. - Q: Qual è il vero significato di pivot, secondo la definizione originale? A: Cambio di strategia con fedeltà alla vision: un piede ancorato in quello che hai imparato, l'altro che si muove. Ma Ries oggi ammette che la vision stessa evolve, e i founder la scoprono costruendo. Tante storie pubbliche di pivot omettono che il founder ha cambiato idea anche sulla vision, non solo sulla tattica. Se è davvero shutdown completo senza alcun filo conduttore, non è un pivot, è un'azienda nuova. Ma è raro: di solito c'è un'intuizione critica del primo tentativo che si ritrova nel secondo. - Q: Cosa intende Eric Ries per spiritual holding company? A: Una struttura legale al centro dell'ecosistema aziendale che custodisce la mission e impedisce a un cambio di CEO o a un'acquisizione predatoria di tradire le promesse fondative. Esempi reali: l'Anthropic Long-Term Benefit Trust, la struttura nonprofit-con-subsidiary di OpenAI, le foundation-controlled company danesi e tedesche, Hershey controllata da una scuola. La ricerca mostra che queste aziende spesso superano in performance i competitor public standard, perché evitano lo short-termism imposto dai mercati pubblici. ### Come costruire un MVP nel modo giusto: Twitter e Uber URL: https://startupmentors.it/video/forrestknight-mvp-right-way YouTube: https://youtu.be/jpQJ8aOThNY Channel: ForrestKnight · 11 min · mvp-build Personas: founder, builder **Perché vale**: Hai un'idea che vuoi portare al mercato e stai per cadere nella trappola del 'taglia tutto, ship subito'. ForrestKnight smonta l'equivoco: un MVP non è un prodotto fatto male, è uno scope ridotto fatto bene. Utile se sei founder o builder solo. **Riassunto**:ForrestKnight apre il video con una premessa che ogni founder dovrebbe interiorizzare: l'MVP è uno strumento di validazione, non una scusa per spedire qualcosa di mediocre. Negli anni Duemila il concetto è stato abbracciato da product manager e developer per i motivi giusti, poi è degenerato in un alibi: "tagliamo tutto, tanto è solo l'MVP". Il risultato è una raccolta di prodotti che falliscono perché confondono scope ridotto con qualità ridotta.
La tesi del video è netta: lo scope si limita, la qualità no. Un MVP fatto bene mantiene codice pulito, design coerente, UX usabile e contenuti curati. Quello che cambia è il numero di problemi che risolvi e il numero di audience che servi. Uno e uno, all'inizio. Risolverli bene per quel singolo segmento è ciò che ti dà segnali validi quando metti il prodotto in mano agli utenti reali.
Se ti accontenti di "barely functional" perché tanto refattorizzi dopo, stai facendo due errori in uno: stai costruendo debito tecnico che ti rallenterà sul vero work, e stai contaminando i test con un'esperienza così rotta che non saprai mai se gli utenti rifiutano l'idea o l'esecuzione.
ForrestKnight elenca quattro caratteristiche che un MVP deve soddisfare per produrre dati utili. Una sola audience target ben definita. Un solo pain point centrale per quell'audience. Una UX che sia funzionale, comoda e riconoscibile. Un build veloce, da mettere in mano agli utenti in tempi brevi. Se anche una sola di queste manca, i risultati del test diventano biased: non stai più misurando se la tua ipotesi regge, stai misurando il rumore di un esperimento mal progettato.
Per scegliere cosa entra e cosa resta fuori, il framework è una sequenza di domande dal punto di vista dell'utente, non del developer. Chi è il tuo utente. Quali sono i suoi pain point. Quali tra questi hanno il rapporto sforzo-impatto migliore. Se l'utente è disposto a pagare per quella soluzione. Le risposte selezionano la feature di partenza in modo brutale ma onesto.
Un passaggio importante riguarda l'automazione. La tentazione di automatizzare tutto fin dall'inizio è forte, ma costruire automazione richiede tempo che in fase MVP non hai. ForrestKnight cita il suo esempio: invece di automatizzare l'invio quotidiano di una nuova domanda, la spediresti a mano ogni mattina. L'utente vede un servizio che funziona; tu validi l'ipotesi senza spendere due settimane su un cron job che potrebbe diventare inutile se l'idea non regge.
È la stessa logica del "do things that don't scale" di Paul Graham: simuli a mano ciò che un giorno sarà automatico, e automatizzi solo dopo aver visto che il valore esiste.
Gli esempi che chiudono il video sono utili da tenere a mente. Twitter è nato come progetto interno di Odeo con una sola funzione: postare status update via SMS. Niente web interface, niente timeline, niente DM. I dipendenti lo usavano così tanto che hanno deciso di estenderlo al pubblico. Uber, beta lanciata nel 2010, faceva una cosa sola: connetteva utenti a tassisti via iPhone, con pagamento in-app e una UI minimale. Tutto il resto, Uber Eats compreso, è arrivato dopo che il primo loop aveva traction.
La lezione per un builder italiano è semplice da enunciare e brutale da applicare: smetti di immaginare il prodotto finito, isola la singola feature che da sola risolve il problema centrale, e accetta che tutto il resto sia scope creep travestito da ambizione. Quella feature isolata è l'MVP. Il resto è una lista d'attesa che si sblocca solo se i numeri ti dicono che hai imboccato la strada giusta.
**Key takeaways**: - Un MVP non è un prodotto sciatto: è uno scope limitato con qualità di codice, design e UX intatte. - Servono quattro condizioni minime: un'audience precisa, un pain point chiaro, una UX usabile, un build veloce. Se ne manca una, i risultati del test sono distorti. - Per decidere quali feature includere parti dall'utente: chi è, qual è il dolore, quale soluzione ha più impatto col minor sforzo, e se è disposto a pagarla. - Le cose che non scalano vanno bene in fase MVP: meglio simulare l'automazione a mano che spendere settimane a costruirla prima di validare. - Twitter e Uber sono partiti con una sola feature core (status via SMS, connessione tassista-passeggero su iPhone). Hanno aggiunto il resto solo dopo aver visto traction. **FAQ**: - Q: Quanto deve durare la fase MVP prima di iniziare ad aggiungere feature? A: Non c'è una durata fissa. Il segnale per uscire dall'MVP è la traction misurabile sulla feature core: utenti che tornano, che pagano o che invitano altri. Se dopo settimane di esposizione i numeri non si muovono, il problema non è lo scope, è l'ipotesi sbagliata. - Q: Posso usare un no-code per il mio MVP o devo scrivere codice? A: Lo strumento conta meno della disciplina sullo scope. No-code, full-stack JS, framework backend tradizionali: tutto va bene se ti permette di shippare velocemente mantenendo un'esperienza pulita. Il rischio del codice è la tentazione di sovra-ingegnerizzare; il rischio del no-code è di restare bloccato quando devi customizzare. - Q: Cosa succede se la mia idea richiede per forza più di una feature per essere capita? A: Quasi sempre quella convinzione è sbagliata. Twitter sembrava avere senso solo con timeline, profili e follower; è partito con un campo per lo status via SMS. Sforzati di trovare la singola interazione che, isolata, dà valore. Se non la trovi, l'idea non è ancora abbastanza messa a fuoco. - Q: Come gestisco le richieste di feature degli early user senza far esplodere lo scope? A: Raccoglile tutte ma non implementarle subito. Prima di aggiungere qualunque cosa, chiediti: senza questa feature il prodotto risolve ancora il problema primario? Se sì, parcheggiala. Le richieste sono dati, non ordini di lavoro. - Q: L'MVP serve anche se ho già validato l'idea con interviste e survey? A: Sì, perché interviste e survey misurano intenzioni dichiarate, non comportamenti reali. Un MVP messo davvero in mano agli utenti è l'unico modo per vedere cosa fanno quando devono usare il prodotto, non cosa dicono che farebbero. ### iGenius: Startup Italiana da 1 MILIARDO vs OpenAI URL: https://startupmentors.it/video/igenius-uljan-sharka-chapeau YouTube: https://youtu.be/Zzhgys8dg8c Channel: Chapeau · 16 min · case-study Personas: founder, investor **Perché vale**: iGenius è uno dei pochi unicorni AI italiani: premoney da 1 miliardo, accordo NVIDIA per un supercomputer da 1 miliardo in Sud Italia, round da 650 milioni in apertura. Uljan Sharka racconta come ci è arrivato senza laurea, partito da barista albanese. **Riassunto**:Uljan Sharka cresce in Albania in un contesto sociale difficile, arriva in Italia adolescente, lavora come barista. Studia da autodidatta, entra in Apple, si trasferisce a San Francisco. Da lì assorbe la cultura della Silicon Valley ("fanno le cose in grande, pensano in grande, falliscono in grande") e nel 2016 fonda iGenius: software di analisi dati per aziende basato su AI. Senza laurea. A inizio 2025, dopo aver raccolto 70 milioni di euro complessivi, annuncia un accordo con NVIDIA per costruire uno dei supercomputer AI più grandi d'Europa in Sud Italia, finanziato da un round in apertura da 650 milioni di euro su valutazione di 1 miliardo. Questa intervista di Chapeau (16 minuti) è la versione integrale del founder che racconta come ci è arrivato.
La copertura giornalistica del 2024 sul round da 650 milioni di euro ha generato confusione. Sharka chiarisce: il ticket effettivamente chiuso a giugno 2024 è di 25 milioni, ma su una premoney da 1 miliardo di dollari. iGenius era già tecnicamente unicorno a quel punto. L'annuncio dei 650 milioni è la dichiarazione di intent della raccolta successiva, non una chiusura: c'erano già interessi e basi di confidenza per chiuderlo, ma il round non era closed quando i giornali lo hanno scritto come fatto.
Il distinguo premoney/postmoney è tecnicamente banale (premoney = valore prima del round; postmoney = dopo l'ingresso del cash) ma riflette un problema più generale dell'ecosistema italiano: poca dimestichezza con la comunicazione finanziaria delle scaleup. Sharka cita il caso parallelo di Mistral in Francia, che ha annunciato un round simile circa un anno prima di chiuderlo con la stessa confusione mediatica. Mistral oggi è a 6 miliardi di valutazione, dopo aver raccolto 645 milioni di euro.
La scelta di evitare i fondi VC istituzionali nelle prime fasi è deliberata. Sharka dice esplicitamente che "andare a parlare con i fondi americani era un tempo sprecato": esiste una discriminazione strutturale verso le deeptech europee in fase early, e su quella scala la conversazione con istituzionali era prematura. La rotta scelta è raccogliere capitali solo da privati nelle prime fasi, sapendo che gli investitori istituzionali sarebbero arrivati più avanti.
La giustificazione operativa è interessante: gli Angel investor sono persone vicine all'azienda, con la pazienza di ascoltare il founder anche quando il numero non è ancora pronto. Un investitore istituzionale, per come funziona la sua governance interna, non può permettersi quel livello di vicinanza. Sharka cita Bezos: i primi assegni di Amazon sono arrivati da family and friends, bussando porta a porta. La lezione che porta a casa è che l'imitazione cieca dei playbook americani su quale tipo di capitale prendere a quale stadio può essere controproducente per chi parte dall'Italia.
La parte più rilevante operativamente è l'accordo con NVIDIA. iGenius sta acquistando 6.000 chip Blackwell di ultima generazione (le GPU top di gamma di NVIDIA dedicate al training di modelli AI) per costruire un data center in Sud Italia. La timeline che Sharka indica è "entro l'estate". Sharka parla nel video di "115 exaflop" come capacità di calcolo: il giornalista di Chapeau in voice-off solleva l'obiezione che il supercomputer più potente al mondo (El Capitan in California) ne dichiara 1,7, quindi la cifra va presa con cautela. Il riferimento ufficiale all'altezza dell'intervista per l'Italia resta il Leonardo di Bologna, attualmente nono supercomputer più potente al mondo.
Il punto più strategico è la logica di finanziamento. Sharka spiega che l'asset supercomputer ha un valore intrinseco che garantisce da solo l'investimento: i fondi di backstop ci sono già, l'ordine NVIDIA è partito. La trattativa aperta non è "chiudiamo il round?" ma "chi controlla l'asset?". La preferenza dichiarata è mantenere il controllo italiano ed europeo. Solo se le istituzioni italiane non capiranno il valore di quell'asset (Sharka non è tenero su questo punto), iGenius si aprirà a investitori stranieri.
La tesi che Sharka chiude è politica oltre che tecnica. Le analisi citate: 9 delle 10 aziende più grandi del mondo sono tecnologiche, 6 su 10 sono americane, solo 3 europee. Da un lato gli Stati Uniti investono centinaia di miliardi in AI con un asse pubblico-privato; dall'altro la Cina ha appena dimostrato di poter competere con i migliori modelli investendo (apparentemente) "solo 6 miliardi" - il riferimento è al modello cinese che ha generato lo shock di mercato a inizio 2025, anche se Sharka non lo nomina esplicitamente. L'Europa nel frattempo discute l'AI Act.
La conseguenza operativa che Sharka esplicita per chi guida un'azienda industriale europea: anche se hai i fondamentali migliori, anche se fai le auto migliori del mercato, se il tuo competitor americano vale 100x o 1.000x ti compra mentre prende un caffè. La capitalizzazione di mercato, in un mondo dove l'AI compete sulla potenza di calcolo e sulla quantità di capitale, è la variabile decisiva. Per Sharka l'AI per l'Europa è prima di tutto sicurezza nazionale, poi sovranità culturale e linguistica, e solo in terza battuta opportunità economica.
La leva specifica europea che Sharka rivendica: la frammentazione linguistica del continente, finora vista come debolezza, diventa punto di forza con AI generativa. Un italiano che parla italiano e un tedesco che parla tedesco possono fare una transazione tradotta in tempo reale. Il "sistema operativo" europeo, che oggi è il vero collo di bottiglia del mercato unico, può essere riscritto dal software AI-native nei prossimi anni.
Nota: il video è del canale italiano Chapeau, format intervista a founder italiani di scaleup. 16 minuti, registrato a inizio 2025 dopo l'annuncio dell'accordo NVIDIA. Per la storia di Uljan Sharka raccontata nel suo arco professionale - infanzia in Albania, lavoro in Apple, fondazione di iGenius nel 2016 - questa intervista è la sintesi più compatta disponibile in italiano. Per altri case-study di founder italiani vedi le interviste ad Alberto Dalmasso di Satispay e a Luca Ferrari di Bending Spoons.
**Key takeaways**: - iGenius ha chiuso a giugno 2024 un ticket da 25 milioni di euro su premoney da 1 miliardo di dollari: tecnicamente unicorno già allora, prima della raccolta annunciata da 650 milioni. - Sharka ha raccolto i primi 40 milioni solo da Angel investor privati, evitando i fondi americani per non sprecare tempo sulla discriminazione verso deeptech europee in fase early. - L'accordo con NVIDIA prevede l'acquisto di 6.000 chip Blackwell di ultima generazione per costruire entro l'estate uno dei supercomputer AI più grandi d'Europa, in Sud Italia. - L'asset supercomputer ha un valore intrinseco che garantisce da solo il fundraising: la trattativa attuale è su chi mantiene il controllo, non su se chiudere il round. - La tesi di Sharka sull'Europa: senza un'infrastruttura AI sovrana non è un tema economico, è sicurezza nazionale. Mistral in Francia ha raccolto 645 milioni a 6 miliardi di valutazione per la stessa ragione. **FAQ**: - Q: Quanto vale iGenius e quanto ha raccolto davvero? A: iGenius ha raccolto 70 milioni di euro complessivi nelle fasi precedenti. A giugno 2024 ha chiuso un ticket aggiuntivo da 25 milioni di euro su una premoney di 1 miliardo di dollari, diventando tecnicamente unicorno. Il round da 650 milioni di euro al miliardo di valutazione è stato annunciato come prossima raccolta in apertura, con interessi e garanzie già allineati ma non chiuso al momento dell'annuncio. - Q: Cosa fa iGenius e chi sono i suoi clienti? A: iGenius produce software di analisi dati per aziende basato su intelligenza artificiale, con focus enterprise. Fondata nel 2016 da Uljan Sharka, ha uffici a New York e in Italia. Il caso d'uso che la differenzia dai concorrenti è la combinazione tra modelli linguistici proprietari e infrastruttura di calcolo dedicata, ora amplificata dal supercomputer in costruzione. - Q: Cos'è l'accordo con NVIDIA e dove sarà il supercomputer? A: iGenius ha annunciato a dicembre 2024 un accordo con NVIDIA per acquistare 6.000 chip Blackwell di ultima generazione e costruire un supercomputer AI in Sud Italia, operativo entro l'estate 2025 secondo Sharka. L'investimento totale dichiarato per l'asset è nell'ordine del miliardo di dollari. Il riferimento per il contesto italiano è il Leonardo di Bologna, attualmente nono supercomputer più potente al mondo. - Q: Perché Sharka ha evitato i fondi VC americani all'inizio? A: Sharka spiega che esiste una discriminazione strutturale verso le deeptech europee da parte dei fondi americani in fase early, e che parlare con loro nelle prime fasi era tempo sprecato. Ha raccolto i primi 40 milioni solo da Angel investor privati, persone vicine all'azienda con la pazienza di seguirla anche quando i numeri non erano ancora pronti per un istituzionale. Cita Bezos e i family and friends di Amazon come precedente. - Q: Perché Sharka considera l'AI europea una questione di sicurezza nazionale? A: Sharka argomenta che 9 delle 10 aziende più grandi al mondo sono tecnologiche e solo 3 sono europee. Senza un'infrastruttura AI sovrana, anche un'azienda industriale europea con fondamentali migliori può essere acquisita da un concorrente americano grazie alla differenza di capitalizzazione di mercato. La leva specifica europea che rivendica è la diversità linguistica come punto di forza dell'AI generativa, non come ostacolo al mercato unico. ### 6 Tips on Being a Successful Entrepreneur | John Mullins URL: https://startupmentors.it/video/john-mullins-ted-6-tips-entrepreneur YouTube: https://youtu.be/eHJnEHyyN1Y Channel: TED · 15 min · founder-skills Personas: founder **Perché vale**: John Mullins (London Business School) racconta sei mindset che vanno controcorrente rispetto a quello che si insegna nelle business school. Non motivational pep talk: filtri concreti per founder che vogliono evitare di costruire prodotti che il mercato non vuole. **Riassunto**:John Mullins insegna entrepreneurship alla London Business School e in questo TED Talk del 2024 mette in fila sei mindset che vanno deliberatamente contro le best practice insegnate nelle business school e adottate dalle grandi aziende. Sono filtri pratici, non slogan, costruiti su casi concreti di founder che hanno reinventato i propri settori partendo da poco. Vale la pena prenderli sul serio, soprattutto se stai costruendo qualcosa di nuovo in un mercato dominato da player più grandi e strutturati.
Il punto di partenza che apre il talk è la storia di Lynda Weinman, che nel 1995 registra il dominio Lynda.com per dare ai suoi studenti un posto dove vedere i propri lavori, e nel 2002 sposta tutto online. LinkedIn la compra anni dopo per 1,5 miliardi di dollari e la rinomina LinkedIn Learning. Lynda, dice Mullins, è il manifesto del pensiero controcorrente del founder: nessuna delle scelte che ha portato all'exit sarebbe stata "razionale" da una prospettiva corporate.
La strategia di base che si insegna nelle business school è "stick to your knitting": identifica le tue core competencies, investici sopra, rinforzale. Se un cliente ti chiede qualcosa di diverso, devi rispondere "no, non lo facciamo".
Il founder brasiliano Arnold Correia ha costruito Atmo Digital ignorando esattamente questa regola. Quando un cliente con 260 store sparsi in Brasile gli chiede di mettere televisori nelle sale training e costruire un uplink satellitare per trasmettere eventi in tempo reale, Arnold dice "sì, possiamo farlo" anche se non sa nulla di tecnologia satellitare e non ha mai operato fuori da San Paolo. Lo fa, e funziona. Anni dopo Walmart gli chiede di portare gli schermi sul piano vendita per far passare pubblicità mirata corsia per corsia. Anche qui: sì. Nel corso degli anni Arnold reinventa l'azienda quattro volte, ogni volta dicendo sì a una richiesta che lo costringe a uscire dal proprio perimetro.
Il messaggio per il founder è semplice: le opportunità reali arrivano spesso vestite da richieste fuori scope. Rispondere "non è il nostro core business" è il modo più sicuro per restare piccoli.
Le grandi aziende sono ossessionate dai prodotti. Mullins racconta che da anni usa il detersivo Tide e ogni tanto si accorge che è arrivato un nuovo brand manager perché qualche dettaglio del prodotto cambia: i granuli blu diventano verdi e si chiama "new, improved". Coca-Cola passa da Classic a New Coke, Diet Coke, Coke Zero, Vanilla Coke, Cherry Coke. Non è innovazione, è cosmesi sul prodotto.
Il founder ragiona al contrario: parte dal problema. Jonathan Thorne sviluppa una lega argento-nichel per costruire pinze chirurgiche che non si attaccano al tessuto umano. Inizialmente prova a venderle ai chirurghi plastici, ma il mercato non cresce abbastanza. Allora si chiede: "C'è una specialità chirurgica con un problema ancora più grosso?" La risposta è la neurochirurgia, dove le pinze devono lavorare su tessuto cerebrale e ogni millimetro di precisione conta. Costruisce un'azienda solida e la vende a Stryker.
La differenza è strutturale: chi parte dal prodotto ottimizza varianti incrementali; chi parte dal problema trova il mercato dove la soluzione vale di più.
La saggezza corporate dice che i mercati piccoli non valgono la pena: "non incidono sui risultati". Le startup invece prosperano su target market stretti e ben definiti.
Quando Phil Knight e Bill Bowerman fondano Nike, partono da un problema che riguarda una nicchia molto piccola: i corridori di fondo. Le scarpe da running dell'epoca sono fatte per gli sprinter, che corrono su pista liscia. I corridori di fondo invece corrono su sterrato e sentieri di campagna, dove inciampano in rami e sassi e si procurano distorsioni e shin splints. Knight e Bowerman costruiscono una scarpa specifica per quel target: stabilità laterale migliore, suola più larga, più ammortizzazione, peso ridotto di qualche oncia. Una volta che hanno padroneggiato la skill di disegnare scarpe per un target stretto, di importarle dall'Asia e di farle adottare da atleti di riferimento, allargano: McEnroe nel tennis, Jordan nel basket, e da lì il global brand che conosciamo.
La lezione operativa è chiara. Un target stretto ti costringe a costruire un prodotto davvero superiore per quel cliente specifico, e quel prodotto superiore diventa il ponte verso mercati più ampi. Partire largo significa quasi sempre costruire un prodotto mediocre per tutti.
Le grandi aziende hanno cassa in eccesso e non sanno dove metterla: Mullins cita Merck nel 2018, che restituisce miliardi agli azionisti via buyback e dividendi perché non riesce a trovare abbastanza progetti R&D dove investire. Per il founder, al contrario, la cassa è linfa vitale, e il modo più intelligente di trovarla è farsela dare dai clienti prima ancora di costruire il prodotto.
Quando Elon Musk entra in Tesla, il piano del team è fare prima un'auto sportiva premium, poi una di fascia media, poi un'auto di massa. Musk aggiunge un dettaglio: vediamo se si possono vendere prima di costruirle. Organizzano un road show in California invitando persone con tre caratteristiche — sensibilità ambientale, alta capacità di spesa, voglia di avere "the next big thing" nel proprio garage. Vendono 100 Roadster a 100mila dollari ciascuna, cash, prima di aver costruito la Roadster numero 1. Risultato: 10 milioni di dollari in banca per partire. Anni dopo, alla presentazione della Model 3, quasi mezzo milione di persone versa un deposito di mille dollari: mezzo miliardo di dollari in cassa per fare engineering, attrezzare la fabbrica e avviare la produzione.
Per il founder italiano la traduzione è diretta: pre-vendita, deposito, abbonamento annuale prepagato, lettera d'intenti firmata. Qualunque meccanismo che faccia arrivare cassa dai clienti prima della spesa è un asset strategico, perché riduce drasticamente il fabbisogno di funding esterno e contemporaneamente valida la domanda.
Il quinto mindset è "beg, borrow, but please don't steal". Nelle business school si insegna a calcolare ROI di un progetto stimando investimento e cash flow futuri. Tristram e Rebecca Mayhew, fondatori di Go Ape nel Regno Unito, ribaltano il ragionamento. Vogliono costruire un parco avventura sui rami degli alberi. Servono alberi. Chi ha alberi nel Regno Unito? La UK Forestry Commission, che ha bisogno di aumentare i visitatori dei propri siti. Tris e Becs propongono: ci date l'esclusiva per 25 anni se vi facciamo vedere che cinque parchi funzionano. Affare fatto. Oggi Go Ape ha più di 30 siti nel Regno Unito e diversi negli Stati Uniti. Hanno preso in prestito gli alberi, i bagni, i parcheggi. Tutto quello che hanno dovuto comprare è il "kit" da montare sugli alberi.
Il sesto mindset è il più scivoloso: don't ask permission. In una grande azienda qualsiasi cosa di nuovo passa dai legali, e ottenere un sì richiede mesi mentre ottenere un no è immediato. I founder, dice Mullins, e gli imprenditori in generale stanno con il permesso come l'olio con l'acqua. Cita Travis Kalanick e Garrett Camp di Uber: se avessero chiesto al regulator di San Francisco "possiamo aprire una società di taxi senza taxi?", la risposta sarebbe stata un no certo. Mullins specifica subito che non sta avallando le pratiche di Uber lungo il percorso, alcune non etiche e alcune probabilmente illegali. Il principio però resta: quando le regolamentazioni sono ambigue o non considerano cosa si può fare oggi in digitale, il founder va avanti e costruisce.
Mullins chiude con quattro domande pratiche da farsi subito. Quali di questi sei mindset incarni già, anche solo uno o due? Quali degli altri puoi imparare, considerando che sono tutti acquisibili? Puoi insegnarli a qualcuno con cui lavori che ha sfide dove questi filtri aiuterebbero? E soprattutto: c'è una sfida che stai affrontando oggi, dove uno o due di questi mindset potrebbero aiutarti a superare il blocco in cui ti trovi?
Sono sei mindset che rompono le regole della corporate strategy convenzionale. Non sono per tutti, ma per chi sta costruendo qualcosa da zero sono filtri operativi concreti per evitare di replicare la logica del big company in un contesto dove invece serve agilità, focus stretto e creatività finanziaria.
**Key takeaways**: - Dì 'sì, possiamo farlo' quando un cliente chiede qualcosa fuori dalle tue core competencies: è così che reinventi l'azienda invece di restare bloccato nel tuo perimetro. - Parti dal problema del cliente, non dal prodotto: cambiare il colore del detersivo non è innovazione, risolvere un dolore reale lo è. - Pensa stretto, non largo: un target market piccolo e specifico ti permette di costruire un prodotto davvero superiore, come Nike ha fatto con i corridori di fondo prima di diventare globale. - Fatti pagare in anticipo dai clienti per finanziare la crescita: Tesla ha incassato 10 milioni di dollari prima ancora di costruire la prima Roadster. - Chiedi in prestito gli asset invece di comprarli: Go Ape ha costruito un'azienda da decine di parchi avventura senza possedere un solo albero. **FAQ**: - Q: Quali sono i sei mindset di John Mullins per un founder? A: I sei mindset controcorrente sono: dire 'sì, possiamo farlo' anche fuori dalle core competencies; partire dal problema del cliente non dal prodotto; pensare stretto su un target market piccolo invece che largo; chiedere cassa in anticipo ai clienti; prendere in prestito asset invece di comprarli; non chiedere il permesso quando le regolamentazioni sono ambigue. - Q: Cosa intende Mullins con 'problem-first, not product-first logic'? A: Significa partire dal problema concreto del cliente invece che dalle varianti del prodotto. Le grandi aziende ottimizzano dettagli cosmetici (Coca-Cola con Diet, Zero, Cherry; Tide cambiando colore ai granuli) e lo chiamano innovazione. I founder come Jonathan Thorne hanno costruito aziende solide partendo da un problema reale (le pinze chirurgiche che si attaccano al tessuto) e cercando il mercato dove quel problema vale di più, in quel caso la neurochirurgia. - Q: Perché Mullins consiglia di pensare a un target market stretto? A: Perché un target stretto ti costringe a costruire un prodotto davvero superiore per quel cliente specifico, e quel prodotto superiore diventa il ponte verso mercati più ampi. Nike è partita disegnando scarpe esclusivamente per i corridori di fondo, una nicchia piccola con problemi specifici (terreno irregolare, distorsioni, shin splints), e solo dopo aver dominato quella ha allargato a tennis, basket e fitness globale. - Q: Come ha fatto Tesla a raccogliere cassa prima di produrre auto? A: Tesla ha venduto 100 Roadster a 100mila dollari ciascuna, cash, prima di aver costruito la prima auto, organizzando un road show in California per persone con sensibilità ambientale, alta capacità di spesa e voglia di avere 'the next big thing'. Sono entrati 10 milioni di dollari in cassa prima della produzione. Lo stesso meccanismo si è ripetuto con la Model 3, dove quasi mezzo milione di persone ha versato 1.000 dollari di deposito generando mezzo miliardo di cassa anticipata. - Q: Cosa significa il principio 'beg, borrow, but please don't steal'? A: Significa costruire l'azienda prendendo in prestito gli asset di cui hai bisogno invece di comprarli. Go Ape ha creato un'azienda da oltre 30 parchi avventura in UK senza possedere un solo albero: ha negoziato l'esclusiva 25 anni con la UK Forestry Commission, prendendo in prestito alberi, bagni e parcheggi. L'unico investimento è stato il kit da installare sui rami. Il principio è ribaltare il calcolo classico del ROI: prima di calcolare quanto investire, chiediti cosa puoi non comprare affatto. ### Lean Startup Riassunto — Eric Ries (5 Framework Fondanti) URL: https://startupmentors.it/video/lean-startup-summary-eric-ries YouTube: https://youtu.be/RSaIOCHbuYw Channel: The Swedish Investor · 14 min · strategia-business-plan Personas: founder, operator **Perché vale**: Lean Startup riassunto in 13 minuti: perché l'idea conta meno dell'esecuzione, ciclo Build-Measure-Learn, MVP imbarazzanti, motori di crescita, pivot strategico. Punto d'ingresso per ogni founder early-stage. **Riassunto**:Il mito numero uno: basta un'ottima idea, determinazione, genialità e il momento giusto per sfondare. Sbagliato. Le idee di per sé non valgono nulla — il vero problema è l'esecuzione.
Questo riassunto del libro The Lean Startup di Eric Ries — prodotto dal canale The Swedish Investor — presenta i cinque concetti fondanti per costruire un'azienda di successo.
Pianificazione e previsioni funzionano in ambienti stabili — che le startup non hanno. Pianificare per mesi e poi lanciare un prodotto perfetto è un gioco pericoloso: si finisce per costruire qualcosa che nessuno vuole. Ma anche l'approccio "fai e basta" porta al caos.
La soluzione è il ciclo Build-Measure-Learn (Costruisci-Misura-Apprendi). L'obiettivo è capire il più rapidamente possibile cosa sia giusto costruire e per cosa i clienti siano disposti a pagare. Il processo, però, parte al contrario: prima si formula un'ipotesi su cosa imparare, poi si esegue il ciclo per confermarla o scartarla. Così si raddoppia sulle ipotesi che funzionano e si scartano in fretta le idee sbagliate.
Per imparare in fretta servono esperimenti con clienti reali o potenziali. I clienti spesso non sanno cosa vogliono finché non glielo si mostra: la regola d'oro è osserva, non chiedere.
Qui entra in gioco l'MVP (Minimum Viable Product). A differenza della produzione industriale tradizionale — come quella automobilistica giapponese, dove lo spreco è ciò che non crea valore per il cliente — nell'approccio Lean Startup lo spreco è tutto ciò che non genera apprendimento validato. Per questo un MVP deve contenere solo le funzionalità essenziali. Se rilasciare la prima versione non mette a disagio chi la pubblica, è stata rifinita più dello stretto necessario.
Il video mostra tre approcci per testare ipotesi e capire per cosa la gente paga davvero:
Una volta confermato che il prodotto ha valore, la startup deve concentrarsi sulla crescita scegliendo un solo motore principale su cui investire le energie:
Un founder di successo combina perseveranza e flessibilità: non molla al primo ostacolo, ma non si incaponisce su un'idea fino allo schianto. Quando i tentativi di aggiustare l'MVP non producono alcun miglioramento al motore di crescita, è il momento del pivot: un cambiamento di strategia su come raggiungere la visione complessiva.
I pivot più comuni sono:
Concetto cruciale: fare un pivot non è un fallimento. Scoprire che qualcosa non funziona non è ideale, ma è infinitamente meglio che continuare su una strada che porta al fallimento. Quasi tutte le startup di maggior successo hanno operato un cambio di strategia radicale a un certo punto della loro storia.
Nota di contesto: il libro The Lean Startup è del 2011 ma resta lo standard de-facto in YC, a16z e tra i founder early-stage. Per approfondire come Ries stesso applicherebbe il framework oggi nell'era AI, vedi la conversazione di 2 ore con Lenny Rachitsky in Eric Ries: Reflections on the Lean Startup Movement (stessa categoria, order 5).
**Key takeaways**: - Il problema delle startup non è l'idea, è l'esecuzione. - Il ciclo Build-Measure-Learn batte la pianificazione perfetta in ambienti incerti. - Se lanciare il primo MVP non ti mette a disagio, l'hai rifinito troppo. - Scegli un solo motore di crescita: retention, virale o paid. - Il pivot non è un fallimento, è correzione di rotta. **FAQ**: - Q: Qual è il più grande mito sulle startup secondo il Lean Startup? A: Il mito principale: bastano determinazione, genialità, tempismo perfetto e un'ottima idea per sfondare. In realtà le idee in sé non sono così preziose: il vero ostacolo per il successo non è nell'idea, ma nell'esecuzione. - Q: Cos'è un MVP e cosa si intende per spreco nel Lean Startup? A: Un MVP è la prima versione del prodotto, che deve contenere solo le funzionalità essenziali per testare un'ipotesi. Nell'approccio Lean Startup lo spreco è tutto ciò che non genera apprendimento validato: per questo un MVP non va rifinito oltre lo stretto necessario. Se non mette a disagio rilasciarlo ai potenziali clienti, è stato rifinito troppo. - Q: Quali sono i tre motori di crescita di una startup? A: I tre motori sono: 1) Retention (Sticky) — trattieni clienti a lungo termine, KPI principali sono tasso di acquisizione e churn rate; 2) Virale — il prodotto si diffonde a macchia d'olio tramite passaparola, KPI è il coefficiente virale (deve essere superiore a 1); 3) Paid — acquisizione tramite pubblicità, KPI sono CAC e LTV. Una startup deve sceglierne uno solo su cui concentrare tutte le energie. - Q: Cosa significa fare pivot e quando è necessario? A: Fare pivot significa cambiare strategia per raggiungere la visione aziendale a lungo termine. Serve un pivot quando iterare sull'MVP attraverso il ciclo Build-Measure-Learn non sposta il motore di crescita. I pivot più comuni sono: cambio del segmento di clientela, cambio del modello di cattura del valore (es. passare a freemium con monetizzazione tramite pubblicità) o cambio del motore di crescita. - Q: Fare un pivot significa aver fallito con l'idea originale? A: No, un pivot non è un fallimento. Scoprire che una determinata strada non funziona non è ideale, ma è infinitamente preferibile rispetto a continuare su una strada che porta al fallimento. Quasi tutte le startup di successo hanno cambiato strategia in modo radicale a un certo punto. Un founder di successo combina perseveranza e flessibilità. ### Lexroom: come hanno raccolto 16 milioni da Base10 URL: https://startupmentors.it/video/lexroom-made-it-pitch-italiano YouTube: https://youtu.be/tXeKz4LJkio Channel: Made IT Podcast · 45 min · pitch-fundraising Personas: founder, investor **Perché vale**: Se stai pensando di pitchare a un VC americano da fondatore italiano, ascolta come Lexroom ha convinto Base10 in inbound dopo 5x di ARR in 6 mesi e con cosa ha posizionato la propria italianità. **Riassunto**:Lexroom è una startup legaltech italiana fondata nel 2023 da Martina Domenicali, Paolo Fois e Andrea Alonza dentro il programma venture builder Vento. In meno di due anni il team ha portato la piattaforma di intelligenza artificiale per studi legali e dipartimenti legal in-house da MVP a 5 milioni di euro di ARR, con clienti come FastWeb, Satispay, Mediolanum, Osborne Clarke, Generali e i principali studi tier-one italiani. Nell'episodio di Made IT condotto da Ines Macula, Martina e Paolo raccontano end-to-end come hanno costruito il prodotto, validato il mercato, gestito il fundraising e chiuso un Series A da 16 milioni di euro guidato da Base10 Partners, fondo della Silicon Valley dietro a Figma e Notion.
La storia di Lexroom inizia nel 2023 dentro Vento, il programma venture builder che seleziona founder con attitudine imprenditoriale ma senza un'idea o un team già formato. Martina arrivava dal mondo legale dopo un double degree a Londra e una prima startup chiusa, Paolo aveva costruito esperienza in Macai con Giovanni Cavallo durante il boom del food delivery, Andrea si è aggiunto come co-founder CTO negli ultimi due mesi del programma. Vento li ha messi in una stanza con altri 40 aspiranti founder, ha pagato uno stipendio per sei mesi e ha permesso loro di iterare sul team prima ancora che sull'idea, finanziando alla fine del programma circa sei o sette startup con un primo ticket da 50.000 euro. Per Martina e Paolo questo formato ha funzionato come sostituto dei sei mesi che di solito si passano con un coinquilino o un collega prima di decidere di fondare insieme. La prima cosa che si sono detti, raccontano, è che ognuno aveva la stessa ambizione e una complementarietà forte tra background giuridico, finanziario-commerciale e tecnico.
L'intuizione è arrivata quando ChatGPT ha aperto il mercato dei large language model e Andrea e Paolo hanno proposto a Martina di applicare la tecnologia al diritto. Per Martina, abituata a passare giornate intere su tomi giuridici durante il college, la ricerca legale era il caso d'uso più evidente: richiedeva specializzazione e precisione che gli LLM generalisti non potevano garantire per via dell'allucinazione. La strategia di validazione è stata una sola: vendere il prodotto fin dal primo giorno. La squadra ha costruito un MVP, lo ha portato dai primi studi e ha incassato feedback costruttivi del tipo "vorrei fare di più con questo prodotto", che secondo Paolo sono i feedback migliori da avere all'inizio. Quando devi mettere mano al portafoglio dici la verità, dice Paolo, e questo è un principio che ha guidato la pipeline commerciale: niente discovery interview gratuite, solo conversazioni con chi era disposto a pagare.
Martina racconta concretamente come pitchare l'extra a una head of legal di una multinazionale. Il punto di partenza è che oggi nessun general counsel si chiede se adottare l'AI ma quale strumento adottare, perché praticamente tutti hanno già testato ChatGPT e si sono scontrati con l'allucinazione su informazioni giuridiche. La conversazione parte da lì: "hai già provato un generalista? Quale difficoltà hai incontrato?". Da quel problema critico Lexroom presenta una piattaforma che ha la stessa potenza di un LLM generalista ma con fonti ufficiali mappate insieme agli studi tier-one italiani e con la possibilità per l'avvocato di verificare ogni citazione. Il caso d'uso più raccontato è la revisione contrattuale alla luce di una nuova policy AI Act: l'utente carica contratto e policy, Lexroom fa la ricerca, analizza, propone modifiche alle clausole e giustifica ogni scelta con la fonte. Il messaggio di posizionamento è "il giudizio del professionista non viene sostituito ma amplificato", una formulazione che chiude la porta alla paura della disintermediazione e tiene gli avvocati alleati invece che sulla difensiva.
Per arrivare ai grandi nomi enterprise il team ha lavorato su due leve in parallelo. Prima leva, partnership con studi legali tier-one italiani come Gianni & Origoni, Gatti Pavesi Bianchi Ludovici e uno studio legale tier-one per costruire affidabilità di prodotto e brand fin dal day one. Seconda leva, case study concreti: FastWeb è stato uno dei primi enterprise a credere a Lexroom, e da lì il team ha bussato a tutte le altre big italiane raccontando come aveva efficientato dipartimenti privacy, appalti e legal. Avere casi d'uso veri da mostrare è stato decisivo perché le aziende sanno che devono adottare l'AI ma non sanno come implementarla, e un riferimento concreto pre-vendita riduce il rischio percepito.
Sei mesi prima dell'episodio Lexroom aveva chiuso un seed da 2,6 milioni di euro. Sei mesi dopo, il Series A da 16 milioni guidato da Base10 Partners con Curio Ventures, View Different (il fondo di Diego Piacentini, ora advisor) e l'angel Riccardo Zacconi tra i partecipanti. Paolo è molto preciso sui tre fattori che hanno innescato l'inbound dei VC americani. Primo: il prodotto. Lexroom ha il 60% degli utenti mensili che si connette ogni giorno alla piattaforma, con 1.000-1.500 utenti contemporaneamente attivi. La metrica chiave non sono solo le revenue ma il fatto che gli account paganti usano davvero il prodotto, perché nel settore AI è facile prendere budget per esperimenti che poi non vengono adottati. Secondo: la traction commerciale. Lexroom ci ha messo 9 mesi per arrivare a 1 milione di ARR e poi 6 mesi per passare da 1 a 5 milioni, con un raddoppio per trimestre e target di 8 milioni a fine anno. Terzo: l'ambizione internazionale dichiarata fin dall'inizio. Tutti i materiali interni del team erano in un misto di italiano e inglese perché la visione era sempre quella di andare oltre l'Italia, localizzando le fonti dati sul mercato target. Su questo terzo punto Paolo insiste: senza ambizione internazionale dichiarata e visibile nei materiali, i primi due fattori non sarebbero bastati.
Sul fundraising stesso il team scherza definendosi "i re dell'inbound": sia il seed entourage sia Base10 sono arrivati senza pitch a freddo, perché il posizionamento di Lexroom nel settore legaltech AI europeo era abbastanza forte da farsi trovare dai fondi che cercavano deal in quel verticale. La lezione, anche se Martina e Paolo non la formulano esplicitamente, è che il miglior fundraising è quello che non devi cercare attivamente, e ci si arriva costruendo segnali pubblici (clienti enterprise, metriche di adozione, partnership) che fanno il lavoro al posto tuo.
Una delle domande più interessanti dell'episodio riguarda la difendibilità: con LLM sempre più accessibili e con startup AI che crescono in modo esponenziale, come si fa a non essere copiati da chi raccoglie 50 milioni la settimana dopo? Per Paolo la risposta sta nel non confondere l'era dell'AI con il fatto che si fa prodotto come si è sempre fatto. La difendibilità non nasce dal modello LLM (che è commodity) ma da network effect, integrazione nei workflow aziendali e abitudine degli utenti. L'esempio che cita è quello di HubSpot e Salesforce: aziende quotate B2B nate negli anni 2000 il cui prodotto tecnicamente potrebbe essere riscritto in poche settimane, ma che restano in piedi perché sono incastrate nei processi di chi le usa. Sul timing invece c'è una finestra di land grab specifica dell'AI: lo standard di mercato dice che il 10-20% dei clienti sta cercando una soluzione come la tua in ogni momento, ma nell'AI quella percentuale è al 100% perché tutti stanno valutando AI per i loro workflow. Quindi devi essere il primo, devi avere il prodotto migliore e poi devi fare in modo di non perderli più.
Sul piano personale, l'episodio si chiude con due consigli ai founder all'inizio del percorso. Martina dice che si inizia cominciando: la sua prima startup è stata un fallimento, ma senza quel fallimento non sarebbe oggi a Lexroom e i cofounder di quella prima esperienza lavorano ancora con lei. Paolo aggiunge una raccomandazione più pratica: prima di tuffarti, assicurati di avere un anno e mezzo o due di liquidità personale in cassa, perché la solitudine del founder journey e i momenti di down sono inevitabili e bisogna avere il margine psicologico per attraversarli senza compromettere la lucidità. La seconda raccomandazione è trovare cofounder con cui fare il percorso, perché il founder solitario molla molto più facilmente di un trio che si tira su a vicenda quando uno è giù.
Sull'italianità come asset, Paolo la lega alla concretezza: in Italia bisogna mostrare prima di raccontare, mentre il mercato americano è più fuffa-oriented. Avere costruito Lexroom sotto questa pressione di sostanza ha portato l'azienda al break-even prima di ogni round di finanziamento, una caratteristica che Base10 ha apprezzato esplicitamente. Quando Paolo confronta il prodotto Lexroom con quello dei competitor internazionali iper-finanziati, dice che dalla qualità non si direbbe mai che ci sono centinaia di milioni di differenza nel funding raccolto. Tradotto: per i founder italiani che vogliono pitchare a investor globali, frugality e capital efficiency non sono limiti ma argomenti di vendita.
**Key takeaways**: - Vento venture builder ha fatto da sostituto ai 6 mesi di amicizia: Martina, Paolo e Andrea si sono conosciuti dentro il programma e hanno preso 50.000 euro di pre-seed solo dopo aver iterato sul team per mesi. - Lexroom ha venduto un MVP dal giorno zero a clienti paganti per ottenere feedback reali, non quelli da amici e famiglia: a 9 mesi dal lancio era a 1 milione di ARR, oggi a 5 milioni. - Il pitch a head of legal di multinazionale parte sempre dalla domanda 'hai già provato un LLM generalista?' e leva su due pilastri: partnership con studi tier-one (Gianni & Origoni, Gatti Pavesi) e case study concreti (FastWeb, Satispay, Mediolanum). - Base10 Partners è arrivato in inbound: secondo Paolo Fois sono stati tre fattori a innescarlo, prodotto con 60% di utenti mensili attivi giornalmente, traction commerciale (5x in 6 mesi) e ambizione internazionale dichiarata fin dal day one. - La difendibilità di una startup AI non sta nel modello LLM ma nei network effect, nell'integrazione nei workflow aziendali e nell'abitudine degli utenti, esattamente come HubSpot e Salesforce vent'anni fa. **FAQ**: - Q: Quanto ha raccolto Lexroom in totale tra pre-seed, seed e Series A? A: Lexroom ha raccolto circa 18,65 milioni di euro complessivi: 50.000 euro di pre-seed da Vento alla fine del programma venture builder, 2,6 milioni di euro di seed sei mesi prima dell'intervista e 16 milioni di euro di Series A guidato da Base10 Partners con la partecipazione di Curio Ventures, View Different (Diego Piacentini), Riccardo Zacconi e altri. - Q: Chi è Base10 Partners e perché ha investito in una legaltech italiana? A: Base10 Partners è un fondo VC della Silicon Valley con investimenti in Figma e Notion. Secondo Paolo Fois ha investito in Lexroom perché il deal è arrivato in inbound: la combinazione di prodotto con 60% di DAU/MAU mensile, ARR cresciuto 5x in 6 mesi e ambizione internazionale dichiarata dal day one ha posizionato Lexroom come asset interessante nel verticale legaltech AI europeo senza che il team dovesse pitchare a freddo. - Q: Come funziona Vento venture builder e che tipo di founder seleziona? A: Vento è un programma di sei mesi che parte dalle persone invece che dall'idea. I primi tre mesi sono dedicati a formare i team e fare discovery su problemi e ICP, gli ultimi tre alla costruzione dell'MVP. Vento paga uno stipendio durante il programma e a fine percorso un investment committee finanzia con 50.000 euro le startup ritenute pronte. Quando Lexroom ha partecipato, dei 40 founder selezionati sono nate sei o sette startup finanziate. - Q: Cosa fa Lexroom esattamente e chi sono i suoi clienti? A: Lexroom è una piattaforma AI per studi legali e dipartimenti legal in-house che automatizza ricerca normativa, drafting di atti, revisione contratti e analisi di compliance, riducendo il rischio di allucinazione tipico degli LLM generalisti tramite fonti ufficiali mappate con studi tier-one italiani. Tra i clienti: FastWeb, Satispay, Mediolanum, Osborne Clarke, Generali, oltre a studi come Gianni & Origoni e Gatti Pavesi Bianchi Ludovici. Il 60% degli utenti mensili usa la piattaforma ogni giorno. - Q: Quale advice danno Martina e Paolo ai founder che stanno per iniziare? A: Martina dice che si inizia cominciando: la sua prima startup è stata un fallimento ma senza quell'iterazione non sarebbe oggi a Lexroom. Paolo aggiunge due raccomandazioni pratiche: avere almeno un anno e mezzo o due di liquidità personale in cassa prima di buttarsi, e trovare cofounder con cui condividere il percorso, perché il founder journey è troppo solitario per essere sostenuto da soli nei momenti di down. ### From 2 Weeks of Runway to $1B Acquisition: Loom URL: https://startupmentors.it/video/loom-runway-to-1b-saastr YouTube: https://youtu.be/AxX2CmVw1ZQ Channel: SaaStr AI · 43 min · case-study Personas: founder, investor **Perché vale**: Joe Thomas racconta come Loom è passata da 2 settimane di runway e 98 no su 100 pitch a un'exit da quasi 1 miliardo di dollari. Cinque lezioni su mercato, prodotto virale, vision e team che valgono per ogni founder. **Riassunto**:Joe Thomas, co-founder e CEO di Loom, apre il suo intervento a SaaStr con due immagini contrapposte. Nella prima, lui e i co-founder sorridono nei primi giorni dell'azienda, convinti di "conquistare il mondo". Nella seconda, scattata otto mesi dopo alle 3 di notte, c'è un materasso a una piazza sul pavimento della camera del co-founder. Mancavano poche settimane all'esaurimento dei 25mila dollari raccolti da angel investor e di tutti i risparmi personali. Avevano già fatto due pivot drastici, nessuno dei due aveva funzionato. Il terzo co-founder, Vinay, si era chiuso in camera per una settimana a riscrivere un pezzo di tecnologia che ancora non avevano. Era l'ultimo tentativo.
Da quel momento Loom è cresciuta fino a una valutazione di 1,5 miliardi di dollari e all'acquisition da parte di Atlassian. Thomas struttura il talk attorno a cinque lezioni hard-earned, partendo dal framework di Sam Altman su cosa rende grande una startup e applicandolo alla storia di Loom.
La prima lezione è che è molto più facile cavalcare un'onda che crearla. Thomas ammette che da founder al primo giro non avevano capito davvero questa logica: è una rilettura a posteriori. Quando i tre co-founder si sono trovati alla lavagna con tre idee a testa, hanno scelto di portare il video sul posto di lavoro perché lo vedevano esplodere ovunque nel consumer (Snapchat, YouTube) ma totalmente assente nei tool aziendali, ancora dominati da Outlook e Slack.
Il dato che cita è quello del Mary Meeker Internet Trends Report del 2014: il video era il 57% del traffico internet e cresceva al ritmo più alto di qualsiasi altra categoria, arrivando al 64% entro il 2014. Quattro anni dopo, le piattaforme consumer più trafficate erano YouTube e Instagram, con Instagram Stories a guidare la crescita. Entro fine 2022, TikTok diventava il sito più trafficato al mondo, primo platform video-only. La domanda che Thomas suggerisce a chi sta partendo: "il mercato che voglio aggredire ha crescita esponenziale?". Se la risposta è no, costruire diventa esponenzialmente più difficile.
La seconda lezione è una di quelle "facili a dirsi". Loom ci ha messo nove mesi di tentativi per arrivarci. Il primo prodotto si chiamava Open Test: un marketplace a due lati per pagare esperti di prodotto (designer Google, PM Facebook) a fare review di file design o code review per altre aziende. Il lancio su Product Hunt è andato verticale per 12 ore e poi è tornato a zero. Friends and family dicevano "interessante" ma gli sconosciuti del mercato non lo raccontavano a nessuno.
Quello che le persone volevano davvero non era il marketplace, ma il layer di video recording costruito sopra: registratore schermo con bolla camera in sovrapposizione. Vinay ha estratto la tecnologia in poche settimane. Hanno rilanciato su Product Hunt come "OpenVid" (Thomas ammette che è "il peggior errore di branding di sempre" — gente confusa tra Open Test e OpenVid). Sono arrivati primi del giorno.
Il momento di svolta è il sabato successivo al lancio. Thomas è al matrimonio di un amico d'infanzia, fa il testimone, si sente in colpa per i soldi che bruciano. Apre il dashboard analytics la mattina dopo: stanno registrando più video del giorno del lancio. Le persone si raccontavano OpenVid su Twitter tra colleghi. È il motore di crescita ancora oggi: persone che registrano un Loom, lo mandano a qualcun altro, chi lo riceve trae così tanto valore che ne parla con il proprio team. Compounding peer-to-peer.
Una volta trovato il filo, serve costruirci attorno una vision ambiziosa — quella che Thomas chiama "earned secret". QuickTime permetteva di registrare lo schermo da due decenni prima di Loom, ma nessuno aveva costruito un'esperienza end-to-end per il video messaging asincrono al lavoro: record + share + edit + collaboration + storage + sicurezza enterprise. Era l'opportunità holistic che nessuno stava aggredendo.
Quando hanno smesso di pitchare "un altro screen recorder" e hanno iniziato a pitchare "il video asincrono diventerà importante quanto il video conferencing, lo Slack, i Google Docs", gli investor hanno smesso di dire no e hanno iniziato a firmare assegni sopra i 25mila dollari. La vision ambiziosa serve anche per il recruiting: prima di averla chiara, faticavano a portare a bordo le persone giuste.
Per i primi tre-quattro anni Loom faceva l'errore classico: andare sui white paper, calcolare il CAGR (compounding annual growth rate), dire "prendiamo lo 0,5% di un mercato da 100 miliardi". Esercizio retorico vuoto. Il framing che ha funzionato è stato concreto: Loom è video, ma è anche messaging. Il messaging più ubiquo è l'email. Quante email lunghe vengono mandate ogni giorno? Se Loom ne cattura solo l'1%, sono 3 miliardi di Loom al giorno e 40 milioni di creator quotidiani. Storytelling tangibile, non astratto.
La quarta lezione viene dai due prodotti falliti. Prima di Loom non avevano alcuna strategia di distribuzione oltre "lanciamo su Product Hunt e speriamo". Con Loom hanno applicato il framework del flywheel che SaaStr aveva trattato in una sessione del 2021 (il modello Amazon): mappi gli step chiave del volano, allochi risorse contro i punti di frizione, li rimuovi nel tempo.
Per Loom il volano era già lì: prodotto inerentemente virale, persone che registrano e condividono. Il job è abilitare più persone a registrare e condividere, perché la crescita prende cura di sé stessa. Thomas è esplicito su un errore che vede ricorrere: nei primi tempi avevano provato SEO + integration + paid contemporaneamente. La lezione: un founder early-stage ha tempo per un solo canale. Sceglilo allineato al prodotto, e martellaci sopra. Citando Bezos: "migliora la tua birra".
La quinta lezione è team mindset e momentum. Thomas cita Sam Altman: nelle aziende serve un sì lungo tutta la catena gerarchica per fare qualcosa di nuovo, e basta un singolo no per fermare tutto. Nelle startup basta un sì all'1% dei tentativi per costruire qualcosa di significativo. I tre co-founder di Loom hanno fatto circa 100 pitch agli investor per arrivare ai 25mila dollari iniziali — un hit rate del 2%. Il 98% dei no includeva amici e parenti.
L'altro elemento che Thomas considera decisivo sono i valori culturali. Loom li sintetizza nell'acronimo LOOM: optimistic, owners (chi ha share dell'azienda è davvero owner — Thomas racconta di aver svuotato lui i piatti nel lavandino dell'ufficio NY), velocity (bias for action — il valore preferito del CTO Vinay), keeping it real (saying the hard thing always — la sua coach esecutiva gli ha insegnato che essere "deeply empathetic" significa anche evitare la conversazione difficile, e va combattuto), human (rispetto e compassione, allineato con il prodotto stesso che riumanizza la comunicazione).
Quattro di questi cinque valori sono rimasti invariati da quando il team era di sette persone in un offsite in Messico fino alla scala attuale.
Nelle Q&A finali emergono dettagli operativi rilevanti. Monetizzazione tardiva: Loom ha tenuto il prodotto free per circa tre anni perché tutta la team (12 persone, quasi tutti ingegneri) era assorbita dall'infrastruttura video. Il Series A è andato male inizialmente — l'80% dei rifiuti era pre-filter su zero revenue. Quello che ha sbloccato il fundraise sono stati dati strutturati di willingness-to-pay (van Westendorp, Max Diff survey) per ICP e dimensione azienda, presi dal programma Reforge sulla monetization zero-to-one.
Da PLG a sales-led: il primo salesperson è stato assunto a gennaio 2020. Il Covid ha portato panic buying poi unprincipled buying con il denaro a costo zero. A ottobre 2022 hanno resettato a un modello High Velocity sales — listino standardizzato, niente trattativa "da 6 a 45 dollari per seat", focus sul value selling con il numero giusto di seat oggi e fiducia nell'expansion futura. Transizione dura ma in corso.
Verticale vs orizzontale: gli investor seed volevano Loom verticalizzata su sales (target acquisition Salesforce). I dati di product-market fit mostravano distribuzione orizzontale tra engineer, designer, PM, sales, support, executive. Hanno scelto orizzontale ma Thomas ammette: avrebbero dovuto iniziare a fare sprint trimestrali su ICP specifici all'anno cinque o sei, non al sette. Ora lo stanno facendo, partendo dalle sales, perché "se costruisci per tutti, costruisci per nessuno".
AI e il futuro della comunicazione: Loom ha lanciato lo stesso giorno del talk feature AI gratuite (titoli e summary automatici da transcript) per tutti gli utenti. Thomas riflette sul tema più ampio: il video è encoding efficiente di conoscenza (gli umani sono evoluti per parlare, non per scrivere) ma decoding inefficiente. La scommessa di lungo periodo è abilitare le persone a estrarre più conoscenza dalle proprie teste e portarla nel mondo, prima che il photocopy-of-a-photocopy dell'AI generativa renda il knowledge online sempre più scadente.
**Key takeaways**: - Cavalcare un'onda è più facile che crearla: scegli un mercato in crescita esponenziale (per Loom era il video, oltre il 60% del traffico internet già nel 2014) - Costruisci un prodotto così buono che le persone lo raccontano agli amici: il vero motore di crescita di Loom è ancora oggi la viralità peer-to-peer dentro i team - Il TAM si difende meglio con storytelling concreto che con white paper: 'l'1% delle email lunghe equivale a 3 miliardi di Loom al giorno' funziona meglio del CAGR - Strategia di distribuzione: scegli un solo canale allineato al prodotto e martellaci sopra, evita di disperderti su SEO + integrazioni + paid contemporaneamente - Le startup vincono perché basta un sì all'1% per costruire qualcosa di significativo, mentre nelle aziende ti servono sì lungo tutta la catena gerarchica **FAQ**: - Q: Come ha fatto Loom a trovare product-market fit dopo i primi due pivot falliti? A: Costruendo Open Test (marketplace di product expert), il team ha aggiunto come feature di supporto un layer di video recording — schermo + bolla camera. Gli utenti volevano quel layer dissociato dal marketplace. Vinay l'ha estratto in poche settimane, è stato rilanciato come OpenVid e il giorno dopo il lancio Product Hunt registrava più video del giorno del lancio stesso. Le persone lo condividevano spontaneamente su Twitter tra colleghi. Quel passaparola peer-to-peer è diventato e resta il motore di crescita principale. - Q: Quali tattiche di distribuzione ha usato Loom per la crescita virale? A: Loom ha applicato un framework flywheel ispirato ad Amazon: mappare gli step chiave del volano (record → share → ricevente trae valore → diventa creator), allocare risorse contro i punti di frizione, rimuoverli nel tempo. Thomas è netto: un founder early-stage ha tempo per un solo canale di distribuzione. Hanno scelto la viralità inerente del prodotto evitando di disperdersi su SEO, integration e paid contemporaneamente. Le integration sono arrivate dopo, oltre 2.000 piattaforme che espandono inline il link Loom. - Q: Perché Loom ha tardato a monetizzare e cosa ha sbloccato il Series A? A: Loom è rimasta free circa tre anni perché 12 persone — quasi tutte ingegneri — erano assorbite dall'infrastruttura video. Il Series A inizialmente non passava, l'80% dei rifiuti era pre-filter su zero revenue. La svolta è arrivata portando in pitch dati strutturati di willingness-to-pay (van Westendorp price analysis, Max Diff survey) segmentati per ICP e dimensione azienda, presi dal programma Reforge zero-to-one sulla monetization. Ha funzionato sia come segnale agli investor sia come forcing function interno per sapere quali feature monetizzare. - Q: Come gestisce Loom la transizione da PLG a modello sales-led con clienti enterprise? A: Primo salesperson a gennaio 2020 in vista del primo SKU enterprise (SSO, SCIM). Covid ha generato panic buying poi unprincipled buying. A ottobre 2022 hanno resettato a un modello High Velocity sales: listino standardizzato (X seat = Y prezzo), zero trattativa, focus sul value selling con il numero corretto di seat oggi invece di gonfiarli. La sfida principale per Thomas, founder product-oriented, è arrivare a un mix 50/50 sales-led / self-serve sul net new revenue, oggi ancora lontano. - Q: Cosa intende Loom quando parla di valori culturali come moltiplicatore di velocità? A: I valori condensati nell'acronimo LOOM (optimistic owner who acts with velocity keeping it real and human) sono nati in un offsite in Messico con sette persone e quattro su cinque sono rimasti invariati alla scala attuale. La logica: optimismo perché in startup serve 'un po' di vite sciolte', ownership perché chi ha share è realmente owner, velocity perché meglio bias for action che build consensus, keeping it real perché 'say the hard thing always' (anche per founder empatici), human perché rispetto e compassione sono allineati al prodotto stesso che riumanizza la comunicazione. ### Marco Ogliengo (Jet HR): velocità, ownership e talento URL: https://startupmentors.it/video/marco-ogliengo-actually-pod-italian YouTube: https://youtu.be/bkXMN-c-Iwg Channel: Actually Podcast · 57 min · case-study Personas: founder, investor **Perché vale**: Marco Ogliengo ha fondato ProntoPro e oggi guida Jet HR dopo un round da 25 milioni. Racconta perché la velocità decisionale è la learning curve più importante e perché in Italia il problema non è il talento ma il middle management. **Riassunto**:Marco Ogliengo è uno dei pochi serial entrepreneur italiani con due aziende costruite da zero alle spalle. La prima, ProntoPro, marketplace di servizi locali nato come copycat e cresciuto fino a una raccolta di 15 milioni di euro e a una exit a 20 milioni di valutazione: per gli investitori del giorno uno un per 8 sui soldi, per gli standard del venture capital americano un risultato sotto target. La seconda, Jet HR, fondata con Francesco (suo ex capo del prodotto in ProntoPro) e oggi a 175 dipendenti dopo un Series A da 25 milioni con Italian Founders Fund tra gli investitori. Nell'episodio del podcast Actually condotto da Riccardo Pozzoli, Marco torna sulla sua rubrica CEO Insights e ricostruisce con onestà rara cosa ha imparato dieci anni dopo aver fondato la prima azienda: come si costruisce un business "a tavolino", perché la velocità è la metrica più sottovalutata, dove sta il vero collo di bottiglia dell'imprenditoria italiana e perché lui e Francesco hanno rifiutato di vendere Jet HR per fare un altro round.
Marco è esplicito: ProntoPro non è stata un successo per gli standard VC. Doveva diventare l'Amazon dei servizi locali, dove ogni italiano comprasse l'idraulico, il fotografo o il personal trainer con prezzi visibili e default scelto. È diventata una destinazione utile con recensioni affidabili, ma non la soluzione di default. Ha raccolto 15 milioni e venduto a una valutazione di 20: chi ha investito al giorno uno ha fatto un per 8 sui soldi, chi è entrato dopo molto meno. Nessuno ha perso, ma l'azienda non ha stravolto come funziona l'Italia. Per Marco però la differenza tra impatto economico e impatto personale è centrale: ProntoPro è stata la sua scuola, l'azienda dove ha imparato tutto quello su cui sta capitalizzando ora con Jet HR. È anche il motivo per cui rifiuta di vendere ogni esperienza come successo, una postura che torna in tutta l'intervista. Bisogna tenere insieme due verità contemporaneamente: i numeri dicono una cosa, la learning curve ne dice un'altra, e nessuna delle due cancella l'altra.
Sul piano dei round, l'episodio di ProntoPro che Marco rivendica come decisione giusta è il primo aumento di capitale. Puntavano a 2,5 milioni da venti privati a 100mila euro a testa. Quando l'opportunità si è allargata, hanno chiuso a 5 milioni e pochi mesi dopo hanno fatto un secondo aumento da 3 milioni, criticato dagli operatori del mestiere ("hai appena chiuso un round, perché ne fai un altro?"). Quegli 8 milioni hanno permesso loro di non ritrovarsi a fare un terzo aumento minuscolo da una posizione di debolezza, con metriche di trazione ancora troppo piccole. È una delle lezioni operative più dirette del podcast: raccogli da una posizione di forza, non da una di necessità.
Jet HR non nasce da una folgorazione personale ma da una scelta a tavolino. Dopo aver venduto ProntoPro insieme alla moglie e cofounder, Marco e la moglie decidono di non lavorare più insieme per non divorziare. Lei lancia subito un'altra azienda durante il Covid, lui per un anno divide il tempo tra figli e ricerca di "what's next". A un certo punto chiama Francesco, ex capo del prodotto in ProntoPro, e con lui imposta un percorso preciso: vogliamo lavorare insieme, vogliamo fare un'azienda finanziabile con tanto capitale, vogliamo impatto su scala (10 milioni di persone, non 10mila) e vogliamo costruirla in 5 anni anziché in 20, accettando di scendere al 20% di proprietà invece di tenerne il 100%. È una posizione che molti founder italiani non esplicitano e che Marco rivendica: i 15 anni risparmiati hanno un valore inestimabile, da reinvestire in altre cose.
Il prodotto si stratifica sopra questa cornice: una piattaforma per assumere, pagare gli stipendi e gestire la burocrazia HR italiana, ossessivamente pensata per nascondere e automatizzare passaggi stupidi (corso di sicurezza obbligatorio, solleciti, scadenze, multe). La validazione del problema, Marco l'aveva addosso da ProntoPro: stimando il caso d'uso sulla sua azienda precedente, calcola che con Jet HR avrebbe risparmiato circa 300mila euro all'anno tra best practice, multe evitate e tempo recuperato. Scalando questo impatto sulla metà delle aziende italiane, il caso d'uso diventa interessante anche per investitori internazionali. Italian Founders Fund (il fondo dei founder italiani) è entrato tra i primi proprio perché chi gestisce un'azienda è il target ideale del prodotto, e molti investitori sono diventati anche clienti.
Il blocco centrale dell'intervista è una difesa esplicita della velocità come parametro di crescita personale, non solo aziendale. Marco racconta un episodio recente: un nuovo assunto vuole testare l'effetto SEO di una sezione del sito facendolo gratis con tempi lunghi. Marco gli dice di pagare Google ads per 5mila euro e togliersi il dubbio in tre giorni, anziché rimandare. La logica è chiara: ogni cosa che resti sulla tua to-do list per settimane ti appesantisce e ti distoglie dalla cosa successiva. Il capitale, quando ce l'hai, va usato per accelerare i cicli di apprendimento, non solo per ottimizzare il costo. È una postura che si scontra frontalmente con la cultura italiana del "facciamolo bene anziché in fretta" e che Marco difende su un piano controintuitivo: la velocità è la cosa più formativa per il tuo team, non la più stressante. Imparare in 5 anni quello che impareresti in 20 è il motivo per cui un terzo dei suoi 175 dipendenti gli dice in colloquio "voglio lanciare la mia azienda in futuro, qui è la scuola migliore". Vedi tre aziende dentro la stessa: Jet a 30 dipendenti, Jet a 100, Jet a 300.
Sui colloqui Marco è esplicito: nel suo step finale prova a spaventare i candidati. Niente equilibrio vita-lavoro perfetto, sì target ambiziosi e crunch periodici. La verità è che le ore lavorate non sono eccezionali, ma le persone che credono nel target fanno l'extra mile da sole, mentre quelle che hanno bisogno di staccare a un orario fisso non funzionano in un'azienda che cresce così. Ed è una posizione che convive con un ossimoro pragmatico: 175 persone, di cui un terzo entrate nei sei mesi precedenti, lavorano prevalentemente da remoto. Per evitare il rallentamento, Jet HR usa Slack al posto di WhatsApp, calendari aperti dove chiunque può prenotare un meeting a chiunque, e una cultura del "chiama subito invece di scrivere un'email per fissare un meeting tra tre giorni".
La parte sul management è la più contraria al senso comune italiano. Marco non crede nella retribuzione variabile come motivante principale (utile solo per i ruoli sales, dove la deadline mensile crea senso di urgenza) e non crede neanche che le stock option, da sole, facciano lavorare di più. Quello che davvero motiva in Jet HR è la delega vera: dare a un 26enne il ruolo di general manager interno di un modulo prodotto, con P&L, team interfunzionale (sales, product, designer) e responsabilità sul successo del modulo nel 2026. Sui prodotti digitali, hanno tolto quasi sempre il product manager dalla classica triade engineer/designer/PM, scaricando sul designer la responsabilità di analisi mercato e ricerca utenti. Meno layer di comunicazione, più fiducia, più velocità.
Sull'Italia Marco ha una diagnosi che ribalta i luoghi comuni. Lo stigma del fallimento? Lo vede sempre meno: nel 2015 doveva chiamare le madri dei neolaureati per rassicurarle che ProntoPro fosse un'opzione valida rispetto a McKinsey, oggi i laureati di Bocconi e Politecnico vogliono fare i founder, è un cambio generazionale acquisito. Il vero collo di bottiglia non è il talento giovane, abbondante e affamato, ma il middle management con 10-20 anni di esperienza che abbia gestito processi di crescita rapida in ambienti digitali. Marco ha appena assunto un Chief Revenue Officer con esperienza di crescita da 7 a 50 milioni di fatturato (uno dei pochissimi profili disponibili in Europa, italiano rientrato dall'estero). Senza quella figura il team passerebbe da 80 a 300 persone facendo errori già fatti da altri, costringendo i fondatori a fare da collo di bottiglia su tutto. È una correzione importante alla narrativa del "università italiane sbagliate": il problema sta a un livello sopra, nel pool di manager esperti che non si è formato nell'ultimo decennio in Italia perché poche aziende hanno scalato così rapidamente da generarli.
L'ultimo blocco è sul rapporto con investitori e sul tema della mission. Marco ha un'opinione decisa: niente documento di mission scritto, perché rischia di sembrare fake. Quello che funziona è essere genuini in modo concreto. Il caso più forte che Marco ha portato al team durante un meeting con i nuovi assunti è una scelta finanziaria personale: nell'ultimo round avrebbero potuto vendere l'azienda invece di raccogliere capitale, sistemandosi a vita lui (con tre figli) e Francesco. Non l'hanno fatto. Hanno preso una decisione contro l'interesse personale immediato perché credono di poter diventare la soluzione di default per fare impresa in Italia, gestendo gli stipendi di un italiano su cinque, su tre, forse su due. Questo, per Marco, comunica più di qualsiasi documento corporate sui valori. La fiducia si crea con le decisioni concrete, non con le parole sui poster.
Sui valori aziendali codificati, Jet HR sta per scriverli ora ma con un motivo molto pragmatico: servono come criterio di decisione condiviso quando i fondatori non saranno più gli unici a decidere chi promuovere. Non è un esercizio di branding, è un'infrastruttura organizzativa per dare gambe all'azienda al di là di Marco e Francesco. Il consiglio finale che Marco lascia ai founder è coerente con la postura di tutta l'intervista: nessuna formula prescrittiva, ma due principi operativi. Primo, raccontare sempre il vero motivo per cui prendi una decisione, perché la semplificazione che ti costringe a fare crea fiducia. Secondo, in fase early stage assumi senior e pagali quattro volte un junior: il ritorno sull'investimento è molto più alto perché non li devi gestire, e ti liberi dal collo di bottiglia che lo stesso Marco ha vissuto nei primi anni di ProntoPro. Quando l'azienda matura, il rapporto si inverte: oggi Jet HR sta tornando ad assumere più junior perché ha già il talento manageriale per gestirli.
**Key takeaways**: - Il primo aumento di capitale di ProntoPro puntava a 2,5 milioni: arrivati a 5, poi subito altri 3 per 8 totali. Senza quella scorta sarebbero rimasti incastrati su round troppo piccoli e in una posizione di debolezza. - Jet HR è nata a tavolino, senza folgorazione: Marco e Francesco volevano un business veloce, scalabile e con grande impatto, da costruire in 5 anni anziché in 20 anche al costo di scendere al 20% di proprietà. - L'Italia non ha un problema di talento giovane (in Bocconi e Politecnico oggi i laureati vogliono fare i founder), ma di middle management con 10-20 anni di esperienza in aziende ad alta crescita digitale. - Il vero motivante in Jet HR non è la retribuzione variabile (utile solo nei ruoli sales) ma la delega: dare a un 26enne il P&L di un modulo prodotto come general manager interno fa la differenza. - L'errore più costoso di ProntoPro è stato assumere solo neolaureati smart senza profili senior: Marco è diventato il collo di bottiglia. In Jet HR ha invertito la rotta partendo da senior pagati 4x un junior, con ritorno sull'investimento molto più alto. **FAQ**: - Q: Cosa fa Jet HR e quanto ha raccolto in totale? A: Jet HR è una piattaforma per assumere, pagare gli stipendi e gestire la burocrazia HR delle aziende italiane: automatizza adempimenti come il corso di sicurezza obbligatorio, scadenze, solleciti e gestione dei dipendenti. È stata fondata da Marco Ogliengo e Francesco e ha 175 dipendenti al momento dell'intervista. Recentemente ha chiuso un round da 25 milioni di euro, con Italian Founders Fund tra gli investitori del primo pre-seed. - Q: Perché Marco Ogliengo dice che ProntoPro non è stata un successo per gli standard VC? A: ProntoPro ha raccolto 15 milioni di euro e ha venduto a una valutazione di 20 milioni. Chi ha investito al giorno uno ha fatto un per 8 sui soldi, ma il piano originario era diventare l'Amazon dei servizi locali in Italia, con prezzi visibili e default per ogni richiesta di servizio. L'azienda è diventata una destinazione affidabile ma non la soluzione di default, quindi per gli standard del venture capital americano il risultato è sotto target. - Q: Qual è il vero problema della cultura d'impresa in Italia secondo Marco? A: Non è lo stigma del fallimento, che secondo Marco si è ridotto molto negli ultimi dieci anni: oggi i laureati di Bocconi e Politecnico vogliono fare i founder. Il vero collo di bottiglia è il middle management con 10-20 anni di esperienza che abbia gestito crescita rapida in ambienti digitali. Quei profili non si sono formati nell'ultimo decennio perché poche aziende italiane hanno scalato così velocemente da generarli. - Q: Come vede Marco Ogliengo la retribuzione variabile e le stock option? A: La retribuzione variabile funziona solo nei ruoli sales, dove la deadline mensile crea senso di urgenza che evita di far slittare i deal. Per la maggior parte degli altri ruoli non sposta la motivazione. Le stock option, da sole, non fanno lavorare di più. Il vero motivante secondo Marco è la delega vera: dare ownership concreta come quella di un general manager interno di un modulo prodotto, con P&L e team interfunzionale, anche a un 26enne talentuoso. - Q: Perché Marco e Francesco hanno rifiutato di vendere Jet HR? A: Nell'ultimo round avrebbero potuto vendere l'azienda invece di raccogliere capitale, sistemandosi a vita personalmente. Hanno scelto di prendere una decisione contro il loro interesse finanziario immediato perché credono che Jet HR possa diventare la soluzione di default per gestire gli stipendi in Italia, arrivando potenzialmente a un italiano su cinque, su tre o su due. Marco racconta questa scelta ai nuovi assunti come dimostrazione concreta della mission, al posto di un documento scritto di valori corporate. ### Pitch deck: gli 8 slide che gli investor vogliono vedere URL: https://startupmentors.it/video/matt-c-smith-pitch-deck-investors YouTube: https://youtu.be/jYWF64Um7pw Channel: Matt C Smith · 13 min · pitch-fundraising Personas: founder, investor **Perché vale**: Se stai preparando il primo pitch deck e non sai cosa mettere e cosa lasciare fuori, questi 8 slide sono lo scheletro minimo che un VC con esperienza su due unicorni si aspetta di vedere. Tactical, niente teoria. **Riassunto**:Matt C. Smith, ex VC su due unicorni londinesi (Farfetch e Vestiaire Collective) e ora investor in proprio, condensa in 13 minuti gli 8 slide che ogni founder deve costruire prima di parlare con un investor. Niente fuffa, niente template scaricabili: solo lo scheletro narrativo che un VC si aspetta di trovare quando apre il deck per la prima volta.
Il primo slide non è un placeholder. Quando pitchi live a un demo day, durante l'handover tra founder lo slide che resta più a lungo sullo schermo è quello iniziale: logo, brand, one-liner. Smith sostiene che proprio in quei secondi l'audience filtra chi vale la pena ascoltare e chi no. Se sei una fintech in una sessione dove sono già passate tre fintech, il logo e la tagline ti permettono di intercettare chi nella sala cercava media, edtech, deep tech. Lo stesso vale per un deck inviato via email: il primo slide deve far capire in tre secondi cosa fai, a chi, perché. Non serve essere creativi, serve essere immediatamente leggibili.
La regola di Smith è netta: vendi il problema, non la soluzione. Se pitchi un prodotto medical a investor non clinici, devi prima farli sentire il dolore di chi vive quel problema ogni giorno, altrimenti la soluzione resta astratta. Una founder infermiera gli aveva presentato un'idea brillante per il pronto soccorso, ma nessuno in sala capiva la dinamica di un emergency room: l'investimento non si è chiuso. La regola pratica: pitcha il problema come se davanti avessi bambini di 10 anni — stesso italiano, vocabolario ridotto, zero buzzword di settore.
Sul market opportunity (slide 4) il numero che funziona è il CAGR — compound annual growth rate. Mostra che il mercato cresce di anno in anno componendo, non in modo lineare. Smith insiste sul fatto che il founder deve conoscere a memoria i propri numeri: se non sai a che velocità cresce il tuo mercato e chi sono i player principali, l'investor inizia a dubitare della due diligence che hai fatto. Il suo hack pratico: prima di buttarti in ricerche infinite, scarica i deck pubblici dei competitor e vedi quali numeri usano loro.
Lo slide traction (5) è dove molti founder pre-seed bloccano. Smith ribalta la prospettiva: traction non significa solo MRR o utenti paganti. Se sei pre-revenue, traction è aver assemblato un co-founding team complementare, aver fatto research su 2.000 o 200 o anche solo 20 utenti, aver costruito una timeline che dimostra esecuzione costante nel tempo. Il messaggio sottostante: gli investor scommettono su team che eseguono, mostralo con una timeline pulita.
Sul business model (slide 6) il consiglio è controintuitivo: se il modello è complesso e non riesci a spiegarlo in 10 secondi, lascialo fuori dal deck e fai sì che sia la prima domanda che ti pongono — così controlli la conversazione e arrivi pronto. Niente DCF, niente forecast a cinque anni se la company ha un anno: bastano numeri ambiziosi che dimostrino l'esistenza di un business case.
Lo slide team (7) è quello che Smith definisce il più importante. La domanda che si fa prima di firmare un assegno — sia da VC con 10 milioni in gioco, sia oggi con ticket personali da 10K — è sempre la stessa: "se qualcuno deve farcela, è questa la squadra che ce la fa?". Per founder solo o team con background omogeneo, il consiglio è ammettere apertamente i known unknowns e mostrare che hai già identificato i profili da assumere appena chiudi il round.
L'ottavo slide è il più dimenticato: l'ask. Non è solo "quanto chiedo": è cosa l'investor o il lettore può fare per te. Soldi, sì, ma anche intro, expertise verticale, accesso a clienti enterprise. Smith chiude ricordando un dettaglio operativo banale ma efficace — pitcha sempre indossando branded apparel della tua startup. Quando dopo l'evento la gente ti cerca per il networking, ti riconosce per il colore della maglietta e associa volto, brand e ask in un'unica memoria visiva.
**Key takeaways**: - Slide 1 conta più di quanto pensi: logo + one-liner restano sullo schermo durante l'handover, sono i primi 30 secondi in cui filtri il pubblico interessato al tuo settore. - Vendi il problema, non la soluzione: pitcha come se l'audience avesse 10 anni di vocabolario, evita buzzword di settore, soprattutto se la platea non è verticale come te. - Sul market opportunity usa il CAGR (compound annual growth rate) per mostrare momentum. Hack: cerca i numeri sui pitch deck pubblici dei competitor invece di partire da zero. - Traction non significa solo revenue. Se sei early stage, il co-founding team formato, una research su 200 utenti o una timeline di execution sono traction valida. - Chiudi sempre con l'ask. Non serve solo soldi: contatti, expertise, intro. La maggior parte dei founder dimentica lo slide finale e lascia l'investor senza next step. **FAQ**: - Q: Quanti slide deve avere un pitch deck per una pre-seed in Italia? A: Smith parla di 8 slide come scheletro minimo: logo+one-liner, problema, soluzione, market opportunity, traction, business model, team, ask. Funziona sia per pitch live che per deck inviato via email. Aggiungere slide oltre questi 8 ha senso solo se hai metriche specifiche da mostrare (es. unit economics consolidati per una Series A). - Q: Cosa metto nello slide traction se sono pre-revenue? A: Traction non è solo revenue. Se sei early stage puoi mostrare: co-founding team formato e ruoli coperti, research utente fatta (anche su 20 persone), MVP rilasciato, lettere di intent da clienti pilota, partnership firmate, timeline di execution che dimostra delivery costante nei mesi precedenti. - Q: Cos'è il CAGR e come lo calcolo per il mio mercato? A: CAGR sta per compound annual growth rate, il tasso di crescita annuo composto del mercato. Mostra che il settore cresce di anno in anno componendo, non in modo lineare. L'hack di Smith: prima di fare research da zero, scarica i pitch deck pubblici dei competitor (sui loro siti, su demo day passati, su YouTube) e usa i numeri che hanno già validato loro. - Q: Devo includere il financial model nel deck? A: No. Smith è esplicito: niente DCF, niente forecast a cinque anni dettagliati linea per linea, soprattutto se la company ha un anno di vita. Bastano numeri highlight che dimostrino ambizione e l'esistenza di un business case. Il financial model dettagliato lo invii dopo, quando l'investor te lo chiede esplicitamente. - Q: E se sono founder solo o il team ha background simile? A: Smith consiglia di ammettere apertamente i known unknowns invece di fingere di sapere tutto. Esempio: due founder con background finance dichiarano che stanno cercando profili tech e marketing, e mostrano che hanno già individuato candidati pronti ad entrare appena il round chiude. Per un investor educato, conoscere i propri buchi è un segnale di maturità, non di debolezza. ### PandasAI: Y Combinator visto da founder italiano (Venturi) URL: https://startupmentors.it/video/pandasai-gabriele-venturi-yc YouTube: https://youtu.be/371fVe1Ya0Q Channel: Risorse Artificiali · 94 min · ai-stack Personas: founder, builder **Perché vale**: PandasAI ha 22.000 stars su GitHub e un batch YC alle spalle. Gabriele Venturi racconta cosa significa candidarsi come founder italiano, il pivot da Chatpick, il mindset Silicon Valley e il futuro delle AI agency nel 2026. **Riassunto**:Gabriele Venturi arriva all'aeroporto di San Francisco due giorni prima dell'inizio di Y Combinator. Ha l'ESTA, lo stesso visto turistico che YC suggerisce a tutti i founder europei. Lo fermano alla dogana, lo trattengono 24 ore in stato di arresto, gli revocano l'autorizzazione e lo rimandano indietro: sospettavano volesse migrare clandestinamente. Il suo Y Combinator inizia così, con l'ambasciata americana e un visto B1/B2 ottenuto a tempo di record. Il batch dura due mesi invece di tre.
Questa intervista di Risorse Artificiali (Stefano Maestri) a Gabriele Venturi, founder di PandasAI (22.000 stars su GitHub, YC alumnus), è uno dei pochi approfondimenti italiani su cosa significhi costruire una startup AI tra Europa e Silicon Valley. Novanta minuti densi di lezioni operative su Y Combinator, pivot, fundraising, open source, agent AI e mercato enterprise.
Venturi nasce a Siena, impara a programmare a 12 anni andando in biblioteca a prendere libri di programmazione. La prima startup arriva a 17 anni, durante gli studi di economia mai completati. Sceglie economia "perché volevo qualcosa di complementare all'ingegneria": già allora pensava sia da builder sia da venditore.
Tra il 2018 e il 2022 fa un passo indietro consapevole. Lavora come software engineer in startup tra Berlino, Monaco, Parigi e Londra. La motivazione è esplicita: "Volevo vedere come funziona un'azienda strutturata da dentro. Per crescere, per andare oltre certe barriere che poi trovi, devi averle viste". È la trappola che molti founder italiani sottovalutano: l'ossessione per il "fai da subito" può far saltare l'apprendimento delle logiche enterprise che servono al primo round serio.
Ad aprile 2023, durante il ponte del 25, Venturi nota un gap nei modelli LLM appena usciti: generano codice in modo straordinario, ma non hanno skill matematiche native. Una libreria che traducesse domande in linguaggio naturale in operazioni su dataframe pandas avrebbe colmato la lacuna. In due giorni costruisce il core di PandasAI: una riga di codice, un dataframe, una query in linguaggio naturale, una risposta strutturata con grafici via matplotlib.
Il progetto esplode. Oggi PandasAI ha 22.000 stars su GitHub. I VC iniziano a contattarlo da soli.
Prima di PandasAI, Venturi aveva lanciato Chatpick: un Photoshop conversazionale dove modificavi immagini scrivendo in linguaggio naturale. Secondo Venturi era esattamente l'idea dietro a quello che Google ha sviluppato dopo, da lui chiamato Nano Banana. La differenza è il momento: Chatpick arriva troppo presto, con tecnologia immatura, founder solitario e zero esperienza di fundraising.
Le lezioni che Venturi esplicita sono tre, e valgono per qualunque founder pre-seed.
Prima: senza tecnologia matura nessuna scommessa sulla vision (vision-driven bet) regge un round serio. Chatpick richiedeva investimenti da Big Tech per funzionare, non a caso quella tecnologia oggi è in mano a Google con Nano Banana. Seconda: VC e accelerator vogliono team, non eroi solitari. PandasAI ha avuto lo stesso difetto, ma la traction ha compensato. Terza: il fundraising è un mestiere a sé. Venturi era abituato al bootstrapping. Sul primo round di PandasAI ha sbagliato tutto nelle prime settimane; una volta capite le regole del gioco, ha aperto e chiuso il round in due settimane.
La lezione operativa: il fundraising è un mestiere a sé, non una conseguenza naturale del prodotto. Se non l'hai mai fatto, parti dal presupposto che la prima fase sarà un disastro.
Y Combinator riceve migliaia di applicazioni per batch. Circa il 10% raggiunge l'interview, e di quelli circa il 10% viene accettato. L'imbuto totale è intorno all'1%. Venturi è entrato alla terza o quarta applicazione.
La prima volta era arrivato all'interview con un'altra startup AI (rifiutato: "team forte, ma non crediamo nell'idea"). Anche con PandasAI, già a 12.000 stars, è stato rifiutato senza neppure interview. Il post-mortem: probabilmente il sito non comunicava la professionalità necessaria, non emergeva che PandasAI veniva usato dal Fortune 500. Il dettaglio fa la differenza tra "tanto hype" e "tanto hype, e ti usa Google".
Il colloquio dura dai cinque ai dieci minuti. La prima domanda è quasi sempre la stessa: "So what do you guys do?". Devi avere il one-liner pronto, perché ti interromperanno presto. Venturi descrive l'esperienza come una sessione di speed dating con i partner più amichevoli del previsto: la pressione te la metti da solo.
Una volta dentro, il vero valore di YC non sono le porte aperte (che sono molte di più dopo, non durante). Il valore è il network e la competizione interna. Vedere altre startup crescere del 100% settimana su settimana ti porta a dare il meglio. Tre mesi che ti prosciugano nel senso positivo.
Il vero shift è culturale. Il founder europeo, soprattutto se tecnico, è ossessionato dal prodotto: costruisce, costruisce, costruisce, e poi vende. Silicon Valley ribalta il pattern: vendi, e poi costruisci quello che hai venduto. Venturi cita founder usciti dal demo day con una pipeline commerciale da centinaia di migliaia di dollari per prodotti che ancora non esistevano. Bisogna tenere a mente il survival bias (delle 2.000 startup che pivotano due settimane prima del demo day, una diventa unicorno; le altre no), ma il punto resta chiaro: la fase di vendita non viene dopo, viene prima.
PandasAI resta open source. Su questa scelta Venturi è netto: la community è il principale asset di difendibilità. Costruisci un prodotto per qualcuno che ti dà feedback, non nella tua cameretta. Open source significa anche audit, fiducia e contributi esterni. Lo svantaggio è la cannibalizzazione del mercato e il calo della sponsorship: Venturi cita il caso di Tailwind CSS, che secondo lui sarebbe stata costretta a licenziare gran parte della workforce perché gli AI agent leggono la documentazione e nessuno chiede più supporto a pagamento. Aggiunge anche un'osservazione amara sulla tossicità crescente di alcune community open source ("GitHub sta diventando il nuovo Instagram"): utenti senza cultura del contributo che pretendono feature gratis.
Annie è il prodotto closed source costruito sopra PandasAI. È un ibrido tra Power BI e Tableau in versione AI-native: connetti il tuo database con un prompt, e in 30 secondi hai una dashboard editabile e condivisibile. La parte più innovativa, secondo Venturi, è il data meshing: l'AI permette di interrogare in modo trasversale fonti diverse senza ETL. Hai dati su HubSpot, Stripe, il tuo database operativo e Meta Ads? Una query omnicomprensiva li mette insieme in pochi secondi.
Il target è enterprise. Non perché le startup non interessino, ma perché il pain principale (data team che diventa collo di bottiglia, decisioni rallentate da una settimana di attesa per un report) è strutturale solo nelle organizzazioni con più stakeholder. La strategia go-to-market è bottom-up: pricing accessibile per data analyst e CFO che testano in autonomia, e poi conversazione enterprise quando il prodotto è già adottato.
Sulla domanda affidabilità Venturi è realista. I workflow agentici stanno diventando deterministici (eseguili dieci volte e ottieni lo stesso risultato), ma il problema vero non è più l'allucinazione: è la prompt injection. Se un agent può eseguire codice, l'attaccante esterno può forzarlo a cancellare il sistema operativo. Per il code execution servono per forza sandbox e virtualizzazione.
L'approccio scelto da Annie è radicale: invece di generare SQL diretto, genera un DSL (un'astrazione sopra SQL) che per costruzione produce solo SELECT, mai UPDATE o DELETE. La chiave di accesso al database è in sola lettura. Il problema dell'affidabilità diventa così un problema by design, non di runtime. Sopra c'è un semantic layer che documenta la funzione di ogni colonna, riducendo la simmetria informativa quando il database ha colonne nominate male.
Venturi ribadisce la necessità di alfabetizzazione AI nelle aziende. Esistono due tipi di C-level pericolosi: quelli che vietano l'AI per principio, e quelli che spingono progetti AI inutili che producono disillusione. Entrambi vanno educati. Su privacy, segnala il paradosso: i log con password verso Sentry vanno bene, ma dati anonimizzati a un LLM provider no. Per chi ha vincoli reali (sanità, finanza, regolamentati) la risposta sono modelli locali self-hosted, e i lavori dei team cinesi ne stanno producendo di eccellenti.
Il consiglio operativo di Venturi per chi vuole lanciare oggi una startup AI è netto: padroneggiare l'agentic AI e cavalcare il trend delle AI agencies. La differenza rispetto al SaaS classico è il modello di vendita. Non si vende più un tool che permette al cliente di fare qualcosa meglio. Si vende direttamente il risultato end-to-end. Esempio: un'azienda enterprise spende l'equivalente di 200 giorni-uomo al mese in reporting? Non le proponi un SaaS che riduce quel costo del 50%. Le proponi i report fatti da agenti, con SLA. Il cliente non si occupa più del processo.
Questo modello, secondo Venturi, è un approccio nuovo: difendibile, perché lavora su pain talmente specifici che le Big Tech non hanno né l'esperienza né l'incentivo a coprirli. Il rischio per i prodotti orizzontali (come Cursor o Windsurf nel coding) è invece tangibile: quando Anthropic o OpenAI capiscono il pain, te lo prendono. Il caso di Claude che ha escluso Windsurf dopo l'acquisizione da parte di OpenAI mostra quanto sia rischioso costruire sopra il layer di intelligenza di altri.
Per chi si sta affacciando al mondo da universitario, Venturi cita il paradosso di Jevons: l'abbassarsi del costo di sviluppo software non sta riducendo la domanda di software engineer, la sta aumentando. Le aziende decidono di investire in più software, non di fare lo stesso software a meno. La conseguenza è che il mercato per i senior si allarga, ma per i junior diventa più difficile: la proattività e il fare progetti pratici già durante l'università sono diventati discriminanti.
L'ultima raccomandazione è la più sottovalutata: isolare il rumore. Venturi racconta di aver lanciato un anno fa un post su Bitnet di Microsoft (modelli quantizzati a 1,5 bit) diventato virale; nei giorni successivi una pioggia di influencer ha copiato il post chiedendo a ChatGPT di riscriverlo per non sembrare plagio. Bitnet alla fine non ha funzionato, ma il telefono senza fili degli influencer ne ha amplificato comunque la presunta rilevanza. Provare tutto, ma non lasciarsi trasportare. Avere una vision propria, sposarla, assecondarla. Saltare da un trend all'altro è il modo più rapido per non costruire niente.
Nota: il video è del canale italiano Risorse Artificiali, uno dei pochi canali italiani con focus su builder e founder tecnici. Format intervista, 1 ora e 33 minuti, registrato a inizio 2026. Per approfondire il tema dei pivot e dei motori di crescita citati indirettamente da Venturi, vedi il riassunto del Lean Startup di Eric Ries (categoria Strategia & Business Plan, order 1).
**Key takeaways**: - Y Combinator seleziona il team, non l'idea: solo l'1% degli applicanti viene ammesso, e il vero valore è il network e la competizione interna. - Il mindset Silicon Valley ribalta il founder europeo: vendi prima, costruisci dopo. Niente prodotto perfetto in stealth. - PandasAI ha funzionato dove Chatpick è fallito perché c'erano traction, tecnologia matura e VC che bussavano da soli. - Annie risolve il data meshing: query multi-sorgente (HubSpot, Stripe, database, Meta Ads) senza ETL grazie agli agent AI. - Il trend startup AI 2026 è vendere la soluzione end-to-end (AI agency), non più il tool: dal SaaS al risultato. **FAQ**: - Q: Cos'è PandasAI e perché ha avuto successo? A: PandasAI è una libreria open source che permette di interrogare un dataframe pandas in linguaggio naturale e ottenere risposte strutturate con grafici. Ha funzionato perché è arrivata nel momento giusto (aprile 2023, esplosione LLM), ha colmato un gap concreto (skill matematiche degli LLM ancora deboli) e ha generato traction rapida. Oggi ha 22.000 stars su GitHub. - Q: Come si entra a Y Combinator come founder italiano? A: Il processo è competitivo: circa l'1% delle applicazioni viene accettato (il 10% raggiunge l'interview, il 10% di quelli passa). Il colloquio dura dai cinque ai dieci minuti, informale ma intenso, parte quasi sempre dalla stessa domanda: 'So what do you guys do?'. YC seleziona il team, non l'idea. Venturi è arrivato alla terza o quarta application, dopo aver lavorato molto su sito e materiali di candidatura. - Q: Qual è la differenza di mindset tra founder europeo e Silicon Valley? A: Il founder europeo, soprattutto se tecnico, tende a costruire prima e vendere dopo. Silicon Valley ribalta il pattern: si vende prima, e si costruisce quello che si è venduto. Nel batch di Y Combinator, founder escono dal demo day con pipeline da centinaia di migliaia di dollari per prodotti che ancora non esistono. Il messaggio è che la validazione di mercato non arriva dopo il prodotto: arriva prima. - Q: Cos'è il data meshing e perché cambia il modo di lavorare con i dati? A: Il data meshing è la possibilità di interrogare in modo trasversale fonti dati diverse (CRM, sistemi di pagamento, database operativo, piattaforma pubblicitaria) senza dover fare ETL preventivo. Annie sfrutta gli agent AI per estrarre solo i dati necessari da ogni fonte e produrre analisi omnicomprensive in pochi secondi. È la differenza tra un Power BI tradizionale e una dashboard AI-native. - Q: Quali consigli per chi vuole lanciare una startup AI nel 2026? A: Padroneggiare l'agentic AI e valutare il modello AI agency: non si vende più il tool, si vende direttamente il risultato end-to-end. Cliente con 200 giorni-uomo al mese di reporting? Lo si fa fare agli agenti, con SLA. È un approccio più difendibile rispetto ai prodotti orizzontali, perché lavora su problemi specifici che le Big Tech non hanno incentivo a coprire. Il consiglio finale: isolare il rumore, avere una vision propria e seguirla senza saltare da un trend all'altro. ### Come pitchare la tua startup seed (Michael Seibel, YC) URL: https://startupmentors.it/video/pitch-seed-startup-seibel YouTube: https://youtu.be/lw2X3PxKlAY Channel: SaaStr AI · 29 min · pitch-fundraising Personas: founder, investor **Perché vale**: Michael Seibel ha condotto oltre 2.000 colloqui Y Combinator. In questo intervento al SaaStr Annual smonta i miti del pitch da seed e ti consegna un framework concreto: cosa dire, in che ordine, e perché chiarezza batte sempre lo show. **Riassunto**:Michael Seibel, partner di Y Combinator e co-founder di Twitch, ha visto oltre 2.000 founder pitchare al primo colloquio YC. Sul palco di SaaStr Annual prende quei colloqui e li traduce in un framework tattico per chi sta raccogliendo un seed o pre-seed. Niente teoria, niente storytelling motivazionale: solo cosa funziona quando hai 10 minuti e un investor di fronte.
Un pitch seed contiene sei blocchi: cosa fa l'azienda, il team, la traction, gli unique insight, la dimensione di mercato, l'ask. Solo il primo e l'ultimo hanno una posizione fissa. Gli altri quattro vanno ordinati dal più impressive al meno impressive. Se hai una traction forte, viene subito dopo aver spiegato cosa fai. Se hai un team straordinario (founder che hanno costruito il software del Mars rover, per dire), parti da lì. Il problema, dice Seibel, è che molti founder credono esista un format standard rigido e finiscono per nascondere i loro punti di forza in fondo al deck. Errore: non ti regaleranno mai trenta minuti di attenzione, te ne guadagni due alla volta. Se gli ultimi due minuti sono stati noiosi, l'investor sta già controllando la mail.
Devi saper rispondere a "cosa fa la tua startup" in due frasi e con un esempio concreto. L'esempio canonico di Seibel è Airbnb: prima frase, "permette a chi possiede una casa o un appartamento di affittarlo online"; seconda frase, "raccoglie il pagamento online e prende una commissione del 15% per ogni prenotazione". L'esempio: immagina di essere un cameriere a Washington DC, è il 2009, c'è l'inaugurazione di Obama, gli hotel sono pieni, e tu affitti casa per 4.000 dollari pagandoti l'affitto per due mesi. Specifico, memorabile, immediato. L'errore opposto è raccontare cosa fai con il linguaggio gergale che useresti con gli utenti, oppure cercare di essere accurati al 100%. L'obiettivo è 80% di accuratezza e 100% di chiarezza, non il contrario. E soprattutto: non lasciare la prima slide senza che l'investor abbia capito di cosa parlerete. Un trucco semplice è chiedere direttamente "ti è chiaro o vuoi un altro esempio?".
Sulla slide team conta chi siete, ruoli, accomplishments specifici, e idealmente come avete vissuto sulla pelle il problema che state risolvendo. Niente storia della vita: non c'è mai spazio nel pitch per la tua biografia, a meno che l'investor non la chieda due volte. Il founder JPL che ha contribuito al Mars rover non l'aveva nemmeno menzionato nella sua application: due mesi dopo, in office hours, Seibel ha dovuto tirarglielo fuori a forza. Se hai fatto qualcosa di forte, dillo senza giri.
Sulla traction, l'errore più diffuso è omettere la dimensione temporale. Cento utenti su TestFlight in un mese sono impressive; cento utenti su TestFlight dopo due anni sono il segnale opposto. Gli investor seed non cercano fatturato già acquisito, cercano momentum: dimostraci che spedite. E se la traction non c'è, non infilare cose finte (survey advisor, partnership di facciata): la slide vuota è meno dannosa della slide patetica. In quel caso stanno finanziando il team, e basta.
Gli unique insight sono la parte intellettualmente più interessante del pitch, ma puoi giocartela solo se l'investor ha già capito cosa fate e si è convinto del team. Sono le cose non ovvie che avete imparato sul problema, sul cliente o sulla soluzione, idealmente sostenute da numeri e fatti. L'insight di Airbnb era che processare i pagamenti come terza parte fidata sblocca un mercato dove host e guest non si fidano l'uno dell'altro. Niente di filosofico: una conseguenza tattica osservata sul campo. Se l'insight lo condividerebbe la metà delle persone in sala, non è unique.
Sulla dimensione di mercato, l'errore è citare un report ("JP Morgan dice che l'e-commerce vale 120 trilioni"). Non frega niente a nessuno. Quello che conta è il calcolo bottom-up: quanti utenti potete raggiungere, quanto fate pagare, perché quel prezzo regge rispetto a prodotti comparabili. Se mostri la matematica, l'investor ti percepisce come esperto, e gli investor finanziano gli esperti.
Sull'ask, l'errore è semplicemente non farlo. Seibel descrive una categoria di investor che chiama "se mi chiedono i soldi sarà imbarazzante dire no, quindi firmo": stima che valga fino al 10% dei casi. Questi investor sperano che il founder non chieda mai, perché preferiscono firmare un assegno da 25.000 dollari piuttosto che gestire il fastidio di un rifiuto esplicito. Se non chiedi, non li intercetti. L'ask deve includere quanto raccogli, quale milestone di revenue o usage raggiungerai nei prossimi 18-24 mesi, e qualche social proof (chi ha già investito). Niente piani di assunzione: a nessuno interessa chi assumi, interessa cosa farete con i soldi.
L'ultimo blocco è il più controintuitivo. Il pitch ideale non è una performance lineare: è una conversazione che porta l'investor a parlare. Nelle vendite si dice che se il cliente parla per più del 50% del tempo, è probabile che chiuda. Stessa logica con gli investor: più articolano da soli perché la cosa funziona, più si convincono a darti i soldi. Tu non stai convincendo loro a investire, sono loro che stanno convincendo se stessi. Il tuo lavoro è creare lo spazio perché lo facciano.
Pratica: se vedi un picco di interesse su un punto, esploralo. Se l'investor è curioso della slide quattro, salta lì subito, non rispondere "ci arriviamo dopo". Su Zoom hai un primo piano del loro volto e gli investor non sono giocatori di poker professionisti, le tells sono leggibili: noia, curiosità, scetticismo, riconoscimento. Guarda la faccia, non lo schermo della tua presentazione. Le slide stesse devono essere visivamente noiose: vuoi che ti guardino in faccia, non che ammirino il lavoro del designer. Un designer, peraltro, non ha idea di quali siano i punti chiave del tuo business e finirà per enfatizzare le cose sbagliate. Chiarezza e concisione, non Sizzle. È un consiglio che cozza con quasi tutto ciò che si insegna a scuola e nei corsi di public speaking, e proprio per questo funziona quando lo applichi davanti a un VC seed.
In chiusura Seibel pitcha YC dal vivo come esempio finale: due frasi su cosa fa l'acceleratore (fund con 500.000 dollari, deal standard), un esempio personale (la sua esperienza da founder di Twitch quando si chiamava Justin.tv), traction (oltre 75 portfolio companies che generano più di 100 milioni di ricavi), team (i partner YC sono tutti ex founder che hanno fatto il programma), tre unique insight stringati, market size con la matematica, ask in una parola: "apply". Niente Sizzle, niente storytelling lungo, niente design ricercato. Funziona perché è esattamente come consiglia di pitchare ai founder che ascolta in colloquio.
**Key takeaways**: - Spicchi rispetto agli altri founder essendo conciso e chiaro, non aggiungendo energia o effetti scenici. Se l'investor non capisce cosa fai nei primi 30 secondi, non ti finanzia. - Servono due risposte diverse alla domanda "cosa fai": una per i clienti (gergale, sintetica) e una per gli investor (semplice, con esempio concreto in due frasi). - La traction non è un grafico: è la dimostrazione che fate cose in fretta. Senza la dimensione temporale (quanto tempo ci avete messo) qualsiasi traguardo perde valore. Se non hai traction, salta la slide. - Devi chiedere i soldi esplicitamente. Seibel stima che nel 70% dei pitch il founder non chiede mai. Per circa il 10% degli investor, l'ask convertirebbe un "no" silenzioso in un assegno. - Il pitch non è un tema in classe: è una conversazione. Se l'investor parla per il 50% del tempo, sta convincendo se stesso a investire. Skippa alle slide che lo interessano e fallo parlare. **FAQ**: - Q: A che stadio si rivolge questo framework? A: Seibel parla esplicitamente di pre-product market fit: founder che stanno raccogliendo pre-seed o seed. Non è un framework per Series A, dove le aspettative degli investor cambiano (ricavi ricorrenti, unit economics, team scalato). - Q: Quanto deve durare il pitch? A: Seibel non fissa un tempo rigido, ma il messaggio è chiaro: l'attenzione di un investor si guadagna due minuti alla volta. Per una call seed da 30 minuti su Zoom, conta che parlerai tu solo per i primi 5-10 minuti e che il resto sarà conversazione, idealmente con l'investor che parla almeno la metà del tempo. - Q: Come gestisci la slide traction se sei davvero alle prime settimane? A: Se sei alla settimana due e non hai dati significativi, semplicemente ometti la slide. Mettere survey, lettere d'intenti o partnership di facciata fa più danno che lasciarla fuori. In quella fase l'investor sta finanziando il team e l'idea, non i numeri. - Q: Quanto è importante il design del deck? A: Per un pitch seed, secondo Seibel, vale poco o nulla. Slide visivamente complesse distraggono dal founder, che è la persona di cui l'investor deve fidarsi. Un designer non sa quali sono i punti chiave del tuo business e finirà per enfatizzare le cose sbagliate. Slide essenziali, focus sul founder. - Q: Si può candidarsi a YC con questo stesso pitch? A: Il colloquio YC dura circa 10 minuti ed è strutturato come domande mirate, non come pitch lineare con slide. Però gli stessi principi di Seibel (chiarezza in due frasi, esempio concreto, traction con dimensione temporale, unique insight specifici) sono esattamente quello che i partner YC valutano in quei 10 minuti. ### How Google sets goals: OKRs / Startup Lab Workshop URL: https://startupmentors.it/video/rick-klau-okrs-google-startups YouTube: https://youtu.be/mJB83EZtAjc Channel: GV (Google Ventures) · 82 min · operations Personas: operator, founder **Perché vale**: Come Google fissa gli obiettivi: il framework OKR raccontato da chi l'ha implementato dentro l'azienda. Workshop di ottantadue minuti distillato nei principi operativi che puoi applicare oggi nella tua startup, anche se sei un team di cinque persone. **Riassunto**:Rick Klau, partner di Google Ventures, conduce un workshop dello Startup Lab dedicato agli Objectives and Key Results, il sistema con cui Google ha gestito la propria crescita dal millenovecentonovantanove ad oggi. Klau parte da una premessa che vale per ogni founder italiano tentato di liquidare il discorso con un "tanto noi non siamo Google": quando John Doerr arrivò a presentare gli OKR a Larry Page, Sergey Brin e Marissa Mayer, Google aveva meno di un anno di vita. Il framework non è un lusso da big tech, è uno strumento per imporre disciplina a un'azienda giovane e ambiziosa.
Gli OKR nascono in Intel sotto Andy Grove negli anni Settanta. John Doerr li impara lì come dipendente, poi diventa partner di Kleiner Perkins e nel millenovecentonovantanove li porta a Google insieme al primo investimento del fondo. Steven Levy, nel libro In the Plex, racconta che il framework fu accolto immediatamente dai googler perché era percepito come dato, non come burocrazia. La distinzione è centrale: gli OKR servono a quantificare il lavoro invece di limitarsi a descriverlo qualitativamente.
Klau cita Mayer testualmente: un dipendente non scrive "renderò Gmail un successo", scrive "lancerò Gmail a settembre e avrò un milione di utenti entro novembre". Due key result, due numeri, due date. La frase di Doerr che Klau ripete più volte è: non è un key result se non ha un numero.
Doerr usò la squadra di football per spiegare la struttura cascata. Klau riprende l'analogia con i San Francisco Forty-Niners. Il general manager ha l'obiettivo di vincere il Super Bowl e riempire lo stadio all'ottantotto percento. Il head coach non si preoccupa degli incassi: il suo obiettivo è solo vincere, declinato in key result tipo "duecento yard di passaggi", "differenziale di palloni recuperati positivo". Il responsabile public relations possiede il riempimento dello stadio: ingaggio di giocatori carismatici, copertura media, evidenziazione dei key player.
Scendendo, il defensive coordinator si concentra solo su statistiche difensive, l'offensive coordinator solo su completamento passaggi, lo special teams su return e block. Non tutti gli obiettivi individuali risalgono fino agli OKR aziendali, ma il flusso bottom-up si ricongiunge naturalmente a quelli più alti. Il news team con i suoi tre featured article della domenica non vedrà mai quel numero negli OKR del team owner, ma quel lavoro serve a riempire lo stadio, che invece è un obiettivo aziendale.
Doerr nelle slide originali scrive che il sessanta percento degli obiettivi deve venire dal basso. Klau riformula: più della metà degli obiettivi aziendali deve emergere dagli individui che salgono attraverso l'organizzazione. Se la dettatura top-down è troppo forte, le persone si limitano a eseguire ordini invece di portare spunti su cosa funziona davvero. Il caso Gmail è emblematico: Paul Buchheit era un ingegnere infastidito dai mail client su Linux, partì per conto suo, e quel suo OKR personale è poi diventato un obiettivo strategico aziendale.
Klau condivide i propri OKR di quando era product manager di Blogger nel duemilaotto. Contesto: Blogger era l'ottava property web al mondo, terza per page view in Google dopo Search e YouTube, ma generava pochi ricavi ed era ignorata internamente.
Il dettaglio cruciale è il modo in cui i key result sono scritti. Implementare il targeting non basta: il key result è scritto in modo tale che, se l'implementazione non muove gli RPM, il grade è zero o zero virgola due. La misura non è l'output (lo abbiamo lanciato), è l'outcome (ha avuto impatto sui ricavi).
Klau mostra i grade reali di quel trimestre. Lancio del monetize tab: uno (binary, fatto, lanciato). Host channel targeting: fallito perché non spostò gli RPM. Tre esperimenti: zero virgola sette perché due dei tre furono significativi, il terzo mal disegnato. PRD ad network: zero virgola otto perché il documento era pronto ma c'era ancora horse trading sull'allocazione ingegneri. Media obiettivo: zero virgola sette.
La lezione operativa: il punteggio target è zero virgola sei o zero virgola sette. Se prendi costantemente uno, stai sandbaggando, ti sei dato obiettivi troppo facili. Sotto lo zero virgola quattro è territorio rosso e diventa forcing function per ripensare se quell'obiettivo va portato avanti o accantonato. Klau insiste: non spendere più di pochi minuti sul grading, il lavoro deve andare nel fare, non nel valutare cosa hai fatto.
Mai dodici. Klau racconta un trimestre con sette obiettivi e descrive l'esperienza come mentalmente sfiancante. Tredici settimane di trimestre divise per sette obiettivi danno meno di due settimane per spostare l'ago su ciascuno: irrealistico. La cifra giusta è tre, massimo cinque obiettivi, ognuno con tre o quattro key result. Non riempire ogni obiettivo di key result solo per limitare gli obiettivi: anche i key result hanno una quota di attenzione limitata.
Punto che sorprende molti. In cinque anni di OKR a Google, Klau non ha mai avuto i suoi grade trimestrali considerati nelle annual review. Gli OKR sono uno strumento di focus operativo, non di valutazione delle persone. Mischiarli con bonus e promozioni distrugge il framework: la gente comincia a sandbaggare per essere sicura di prendere uno, e perdi tutto il valore della tensione ambiziosa.
Ogni dipendente Google ha gli OKR pubblici nella directory aziendale, accanto al numero di telefono e all'email. Vedi quelli di Larry e Sergey, vedi quelli del collega della scrivania accanto, vedi quelli di trimestri precedenti con i grade. Klau racconta un caso pratico: quando era PM della homepage YouTube, chiunque volesse promuovere un prodotto sulla homepage poteva consultare i suoi OKR del trimestre prima ancora di parlargli. Se la richiesta si allineava ai suoi obiettivi, conversazione facile. Se no, l'altro sapeva di partire in salita.
Klau propone un calendario concreto per chi vuole adottare il framework da gennaio. Novembre: il CEO definisce gli OKR aziendali Q1 e annuali, l'azienda decide il tool di tracking (wiki, Google Sites, app interna semplice). Dicembre: comunicazione aziendale degli OKR di company, ogni individuo abbozza i propri OKR personali e negozia con il manager. Inizio gennaio: meeting aziendale con presentazione di OKR di company e team. Metà febbraio: check-in mid-quarter individuale per ricalibrare. Fine marzo / inizio aprile: grading individuale, di team e di company, meeting aziendale dove i team owner spiegano cosa hanno mancato e perché.
Klau cita un'email memorabile di Jonathan Rosenberg, head of product di Google, che a inizio novembre fece un public shaming dei nove PM su diverse centinaia che non avevano ancora postato gli OKR del Q4. Il messaggio era inequivocabile: questo conta, dal CEO in giù.
Klau è esplicito: il tool conta meno della disciplina. Google internamente usa un'app proprietaria minimale (text field, button "average my scores", basta). Per startup piccole vanno benissimo Google Sites, una wiki, un Google Spreadsheet. La cosa che deve esistere è la visibilità incrociata: tutti devono poter vedere gli OKR di tutti.
Le domande dal pubblico fanno emergere principi che Klau ribadisce. Quando iniziare: il prima possibile. Klau ha implementato OKR su sé stesso anche da team di una persona allo Startup Lab, perché la disciplina di guardare avanti dichiarando cosa farai e cosa non farai vale a qualsiasi scala. Cadenza di check-in: una o due volte per trimestre col manager, niente meeting settimanali sugli OKR, il punto è fare il lavoro non riunirsi sul lavoro. Allineamento bottom-up con top-down: dopo aver abbozzato i tuoi OKR, partecipi al meeting aziendale dove vengono presentati quelli di company. Se non vedi gli OKR aziendali riflessi nei tuoi, è il momento della penna rossa per riallineare.
Klau chiude con una nota personale. In un trimestre da PM della homepage YouTube possedeva due dei cinque OKR aziendali in un'azienda da trentamila persone. Esperienza terrificante e formativa. Gli OKR funzionano perché ti costringono a vedere se quello che fai conta davvero, o se stai galleggiando.
**Key takeaways**: - Limita gli obiettivi a 3-5 per trimestre, ognuno con 3-4 key result quantificabili: se non c'è un numero, non è un key result - Punta a un grade tra 0,6 e 0,7 sulla scala 0-1: prendere costantemente uno significa che stai sandbaggando, non che stai eccellendo - Rendi gli OKR pubblici dentro l'azienda dal CEO in giù: la trasparenza è il meccanismo di allineamento, non un nice-to-have - Gli OKR non sono uno strumento di performance review: servono a focalizzare il lavoro trimestrale, non a determinare promozioni o bonus - Almeno il sessanta percento degli obiettivi deve nascere bottom-up: il top-down puro distrugge la motivazione e perde spunti preziosi dal team **FAQ**: - Q: Quanti OKR per trimestre dovrebbe avere un team? A: Tre obiettivi è il numero giusto, massimo cinque. Klau racconta che con sette obiettivi in un trimestre era mentalmente sfiancato e finì per essere stirato troppo. Ogni obiettivo dovrebbe avere tre o quattro key result quantificabili. Più di così, ti spalmi su tutto e non sposti l'ago su niente. - Q: Come si differenziano gli OKR dai KPI? A: I KPI misurano lo stato continuo della salute del business (tasso di churn, MRR, NPS). Gli OKR sono impegni temporali: un obiettivo da raggiungere nel trimestre con key result quantificabili che dichiarano come misurerai il successo. Un KPI può diventare un key result se serve un cambio di rotta su quella metrica nel trimestre, ma KPI tracciato e OKR sono cose diverse. - Q: Gli OKR devono essere ambiziosi o realistici? A: Ambiziosi al punto da farti sentire scomodo. Klau dice che entrando nel trimestre dovresti essere incerto se ce la farai. Il target di grade è 0,6-0,7 su scala 0-1. Se prendi costantemente 1, stai sandbaggando. Se sei sotto 0,4, è territorio rosso e devi capire se l'obiettivo va riformulato o accantonato. Per i key result binari (lanciato sì/no) prendi 1 se hai lanciato, ma il bilancio medio per obiettivo deve restare in zona 0,6-0,7. - Q: Gli OKR vanno usati per le performance review? A: No, e questo punto è critico. Klau in cinque anni a Google non ha mai avuto i grade trimestrali considerati nella annual review. Mischiare OKR e valutazione delle persone distrugge il framework: la gente abbassa l'asticella per garantirsi grade alti e perdi la tensione ambiziosa. Gli OKR servono a focalizzare il lavoro trimestrale, le review annuali sono un'altra conversazione. - Q: Da quante persone in azienda ha senso introdurre gli OKR? A: Il prima possibile, anche da team di cinque persone. Klau ha implementato OKR su sé stesso quando era team di uno allo Startup Lab. Più aspetti, più si formano abitudini sul come si fanno le cose, e più inerzia dovrai vincere quando proverai a introdurre il framework. Anche se a cinque persone sembra artificiale, la disciplina che porta è incommensurabile. ### Content marketing B2B SaaS: i 5 stadi secondo Rob Walling URL: https://startupmentors.it/video/rob-walling-b2b-content-saas-2026 YouTube: https://youtu.be/Sxn1ji7vYzU Channel: Rob Walling · 29 min · crescita-marketing Personas: operator, founder **Perché vale**: Se stai partendo con il content marketing del tuo SaaS e non sai da dove iniziare, Rob Walling ti dà un framework concreto: i 5 stadi di consapevolezza del cliente applicati al B2B. Smetti di scrivere blog post generici, parti dal fondo del funnel. **Riassunto**:Rob Walling apre raccontando un fallimento personale. 2012-2013, sta costruendo Drip insieme a Derek Reimer (allora si chiamava Velvet Mail). Spende cinquemila dollari da bootstrapper per far scrivere a un freelance un pacchetto di blog post: "Sette miti dell'email marketing", "Guida per principianti all'email marketing", "Cinque cose da sapere sull'email marketing". Sei mesi dopo il lancio, il rumore di fondo: zero traffico, zero conversioni.
Cosa era andato storto? Non c'era una strategia di prioritizzazione. I titoli erano tutti top-of-funnel, generici, indistinguibili da quelli di chiunque altro. Nessun framework per decidere quale contenuto produrre prima.
Dieci anni dopo, durante un kickoff TinySeed a Londra, un founder gli chiede in privato: "Come prioritizzo questi quindici post che mi hanno suggerito?". Walling capisce che il framework giusto esisteva da sessant'anni ma nessuno lo applicava al B2B SaaS in modo strutturato: i 5 stadi di consapevolezza del cliente di Eugene Schwartz, copywriter pubblicitario degli anni Sessanta.
Stadio 1 — Unaware. Il prospect non sa di avere un problema. Nel B2B questo stadio è quasi sempre da evitare: devi fare cold outreach, educazione di categoria, contenuti molto generici tipo "Dieci consigli di email marketing". Costoso e lento. Walling è netto: se sei bootstrap, qui non ci stai.
Stadio 2 — Problem aware. Il prospect sa di avere un problema ma non conosce le soluzioni. Esempio: un agente immobiliare cerca "come mando email in massa", "cos'è l'email marketing". Non sta ancora cercando MailChimp. Non sa nemmeno che esista una categoria.
Stadio 3 — Solution aware. Conosce la categoria ma non i prodotti specifici. Cerca "miglior software di email marketing", "email marketing software comparison". Spesso atterra su Capterra, G2, Reddit, Quora.
Stadio 4 — Product aware. Conosce il tuo prodotto e lo sta confrontando con la concorrenza. Cerca "MailChimp vs Klaviyo", "alternative a HubSpot". Qui i lead valgono molto.
Stadio 5 — Most aware. Ha deciso ed è pronto a comprare. Cerca pricing, coupon, "buy [prodotto]". Vuole vedere feature dettagliate, demo lunghi, case study, documentazione di compliance.
Il consiglio principale di Walling ribalta l'intuizione di chi inizia. Non partire dai contenuti top-of-funnel. Parti dallo stadio 5 e risali.
Il ragionamento è semplice: i contenuti most aware servono sia al marketing organico sia alla vendita diretta. Anche se fai solo outbound e non hai ancora un blog, le pagine versus e i case study chiudono deal in sales call. Il blog post generico "cos'è l'email marketing" ti porta traffico che non converte per mesi, mentre una pagina "MailChimp vs Klaviyo" può chiudere un cliente la settimana stessa.
C'è un'eccezione interessante a questa regola: le pagine alternative-to. Funzionano quando sei early-stage e nessuno cerca ancora il tuo brand, ma le persone cercano alternative ai competitor consolidati. Userlist, ad esempio, ha molte pagine alternative-to perché in fase iniziale c'è poco volume su "Userlist vs". Quando cresci e il tuo nome inizia a circolare, aggiungi le versus.
Metodo 1 — Chiedi in sales call. Quando comprate? Ci state confrontando con altri prodotti? Quali? Le risposte ti dicono lo stadio quasi automaticamente. Se ti stanno confrontando con due competitor specifici, sono allo stadio 4 o 5. Se non hanno ancora valutato nessuno, sono allo stadio 2 o 3. Walling suggerisce di mettere lo stadio stimato direttamente nel CRM, accanto a budget e timeline, e di tracciare il movimento da una conversazione all'altra.
Metodo 2 — Analizza le keyword. SEMrush mappa le keyword in quattro intent: navigazionale, informazionale, commerciale, transazionale. Si sovrappongono ai 5 stadi: informazionale è stadio 2-3, commerciale ("best email marketing software", "top X review", "compare X vs Y") è stadio 3-4, transazionale ("buy", "discount", "coupon") è stadio 5. La corrispondenza non è uno-a-uno ma è abbastanza precisa da guidare la prioritizzazione editoriale.
Metodo 3 — Usa tool dedicati. SEMrush e Similarweb classificano automaticamente l'intent di ogni keyword. Per il monitoring delle menzioni di brand (segnale forte di stadio 4), Walling consiglia F5Bot e Syften: ti notificano quando qualcuno parla del tuo prodotto su Reddit, Hacker News, Twitter, anche su canali Slack pubblici nel caso di Syften.
Walling porta esempi concreti dalla community MicroConf di founder bootstrap che eseguono bene questo framework.
Stadio 2 (problem aware). SignWell di Ruben Gamez offre venticinquemila template di contratti gratuiti. Il prospect non sa ancora di aver bisogno di un software di firma elettronica, sa solo che gli serve un template. SignWell glielo dà e lo accompagna nel funnel. SessionLab fa lo stesso con i template di workshop.
Stadio 3 (solution aware). Userlist pubblica "SaaS Email Marketing Strategy: Everything You Need to Know". VEED.IO ha SEO-fatto le pagine "add subtitles to video", "add music to video" — keyword di volume alto dove l'utente sa di avere un problema specifico ma non conosce ancora la categoria di software.
Stadio 4 (product aware). Pagine versus e alternative-to. Walling mostra un dettaglio divertente: cercando "MailChimp vs Klaviyo" su Google in incognito, MailChimp e Klaviyo si rispondono a vicenda con copy passive-aggressive. Posizione numero uno per quella keyword? Zapier. Zapier non ha un email marketing tool, ma ha così tanta autorità di dominio che cattura quel traffico ad altissimo valore e lo gira nei suoi funnel.
Stadio 5 (most aware). Feature pages dettagliate (non più benefit generici), knowledge base curata, demo lunghi 30-45 minuti registrati. Pagine di compliance — SOC 2, HIPAA, GDPR, network security — che SignWell pubblica integrale. Sono contenuti che pochi founder producono perché non sembrano "sexy", ma sono quelli che chiudono il deal quando il prospect sta per firmare.
Il framework di Walling è particolarmente utile per chi è early-stage con budget limitato. Invece di disperdersi su quindici idee di blog post top-of-funnel, mappa ogni contenuto al suo stadio e parti dal fondo. Se hai zero contenuti, scrivi prima:
Solo dopo, se hai banda, sali agli stadi superiori. Il content marketing che funziona non è quello che genera più traffico, è quello che converte traffico qualificato.
**Key takeaways**: - I 5 stadi di consapevolezza (Eugene Schwartz, anni Sessanta) si applicano anche al B2B SaaS: unaware, problem aware, solution aware, product aware, most aware. - Parti dal fondo del funnel (most aware) e risali: pagine versus, alternative-to, case study e demo lunghi convertono molto di più dei post top-of-funnel generici. - Tre modi per capire in che stadio si trova un prospect: chiedere in sales call (budget, timeline, competitor confrontati), analizzare le keyword (intent navigazionale/informazionale/commerciale/transazionale), usare tool come SEMrush o Similarweb. - Pagine alternative-to funzionano nei primi mesi quando nessuno cerca ancora il tuo brand: ti agganci alla SEO dei competitor. Le pagine versus arrivano dopo, quando il tuo nome inizia a circolare. - Stadio 5 (most aware) richiede contenuti che pochi founder producono: feature pages dettagliate, knowledge base curata, demo lunghi 30-45 minuti, pagine compliance (SOC 2, GDPR, HIPAA). **FAQ**: - Q: Devo per forza partire dallo stadio 5 anche se ho già qualche blog post top-of-funnel? A: No, ma se hai pochi contenuti complessivi e zero conversioni, sposta la priorità verso il fondo del funnel. I post generici hanno valore SEO nel medio termine, ma non chiudono deal nel breve. Pagine versus, alternative-to e feature dettagliate convertono in settimane, non mesi. - Q: Le pagine alternative-to non rischiano di sembrare aggressive verso i competitor? A: Walling consiglia un tono fattuale, non polemico. L'esempio MailChimp vs Klaviyo che mostra è proprio quello da non imitare (passive-aggressive da entrambe le parti). Funziona meglio una comparison onesta che evidenzia il caso d'uso ideale di ciascun prodotto, includendo casi in cui il competitor è la scelta migliore. - Q: Come gestisco lo stadio 5 se il mio prodotto è ancora in beta o ha poche feature? A: Lavora sui contenuti che non dipendono da una feature list ricca: knowledge base curata, demo registrato passo-passo, pagina sulla sicurezza dei dati, case study anche di un singolo cliente early adopter. Sono asset che esistono indipendentemente dalla maturità del prodotto e che il prospect cerca prima di firmare. - Q: F5Bot e Syften sono ancora rilevanti nel 2026 con LLM e AI search? A: Il monitoring delle menzioni di brand è ancora più importante con AI search: gli LLM citano fonti che ti menzionano. F5Bot resta utile per Reddit, Hacker News, forum minori. Per coverage più completa servono tool che monitorano anche Discord, Slack pubblici, podcast trascritti — il panorama si è frammentato rispetto a quando Walling ha dato la talk. - Q: Il framework funziona anche se vendo a self-serve senza sales call? A: Sì, anzi è ancora più rilevante. Senza sales call non puoi chiedere direttamente lo stadio al prospect, quindi devi appoggiarti totalmente all'analisi delle keyword e al comportamento on-site. Le pagine versus e alternative-to fanno il lavoro di qualifica che altrimenti farebbe un commerciale. ### Primi 100 clienti SaaS senza paid ads: playbook organico URL: https://startupmentors.it/video/saas-mastery-100-customers-no-ads YouTube: https://youtu.be/67MX3_N4Lfo Channel: SaaS Mastery · 15 min · crescita-marketing Personas: operator, founder **Perché vale**: Sei un founder bootstrap o indie hacker e vuoi arrivare ai primi 100 clienti SaaS senza bruciare budget in ads? Qui trovi il sistema in tre fasi: evita gli errori che frenano l'80% dei founder, parti dal network per i primi 10, scala con un GTM ripetibile. **Riassunto**:Il video di SaaS Mastery è un'intervista a Margot, consulente go-to-market per founder B2B early-stage, e racconta come arrivare ai primi 100 clienti SaaS senza dipendere da paid ads. Il taglio è pratico: poche teorie, molti esempi concreti, qualche tattica che funziona davvero anche con budget zero.
Margot apre con tre errori che vede ripetersi in quasi tutti i founder al primo SaaS. Il primo è il targeting troppo ampio. La frase tipo "aiutiamo le aziende a essere più produttive" è la condanna a non raggiungere nessuno. Se parli a tutti, non parli a nessuno: meglio uno strumento che risolve un problema specifico per un tipo specifico di cliente.
Il secondo errore è costruire per sei mesi o un anno senza mai parlare con i clienti. Il giorno del lancio ti chiedi perché non firma nessuno, ma la risposta è semplice: non hai validato né il problema né il mercato. Il terzo errore è il messaging generico. Headline come "il futuro della produttività" non significano niente. Margot porta un caso reale: per un tool di fatturazione, sostituendo l'headline generica con la promessa concreta "genera una fattura in meno di 30 secondi", il conversion rate della landing è cresciuto di 2,5 volte.
La fase più dura sono i primi 10 clienti, perché richiedono attività che non scalano. Non serve un'audience enorme su Twitter: meglio costruire una rete di altri founder e operator in community come Microconf Connect o Dynamite Circle. L'obiettivo non è vendere, è avere conversazioni che facciano emergere i pain point. I primi clienti sono di fatto early adopter amici, e la valuta non è solo il pagamento ma anche il feedback.
Quando il network si esaurisce serve un sistema. Margot lo struttura in cinque passaggi. Prima si definisce un ICP profondo: firmographics, decision maker e influencer, pain point, paure, "nemici" percepiti. "Aziende edili" non è un ICP, è una categoria. Poi si lavora sul messaging con A/B test su subject line, headline e ad copy, misurando aperture e click. Solo dopo aver trovato un messaging che converte si scala l'outreach.
Le tre tattiche che cita come efficaci nel 2025 sono interessanti perché vanno oltre il cold email blast classico. La prima è il social engagement: trovi i tuoi prospect su LinkedIn, segui, commenti, metti like, costruisci familiarità prima del DM. Quando scrivi non parti con un pitch ma con "ho costruito una cosa per persone come te, mi diresti se è utile?". La seconda è l'outreach value-first: invece dell'email "compra il mio prodotto" mandi un report sui competitor del prospect o un'analisi che risolve un problema concreto. La terza, quella con il response rate più alto secondo Margot, è il video Loom personalizzato di quattro-cinque minuti con il sito o il profilo LinkedIn del prospect a schermo, in cui spieghi in 60 secondi come il prodotto risolve la sua sfida.
Quarto step: la landing page come strumento di customer development, non solo come punto di conversione. Mockup mandati alla mailing list, copy che parla esattamente del pain point dell'ICP, social proof, CTA forte. Quinto step: il feedback loop continuo, ossessione per cosa manca e cosa frustra i primi utenti.
Per andare oltre i 100 clienti Margot suggerisce tre leve. Una libreria di case study usati come storytelling nelle vendite, perché "uno dei nostri clienti nel tuo settore aveva esattamente lo stesso problema" funziona meglio di un numero astratto. Un referral program incentivato e integrato nell'onboarding. E una posizione di thought leadership con content top-of-funnel che parla dei pain point dell'ICP, non del prodotto: è la leva che nel lungo periodo abbatte il customer acquisition cost e ti permette di smettere di rincorrere singoli prospect.
**Key takeaways**: - Tre errori che azzerano la trazione iniziale: targeting troppo ampio, costruire sei mesi senza parlare con i clienti, messaging generico tipo "lavora in modo più smart". - I primi 10 clienti arrivano dal tuo network, non dal cold outreach: community di founder, conversazioni 1-a-1, friend-of-friend con feedback come moneta di scambio. - GTM ripetibile in cinque step: ICP iper-specifico, messaging testato A/B, outreach personalizzato, landing page come strumento di validazione, feedback loop continuo. - Tre tattiche outreach che funzionano nel 2025: social engagement prima del DM, email value-first (non pitch), video Loom personalizzati di quattro-cinque minuti con il sito del prospect a schermo. - Per scalare oltre i 100 clienti servono case study come storytelling di vendita, referral program automatizzato nell'onboarding e thought leadership per abbattere il CAC. **FAQ**: - Q: Posso davvero arrivare a 100 clienti SaaS senza spendere in paid ads? A: Sì, ma a due condizioni: il prodotto risolve un problema specifico per un ICP molto definito e tu sei disposto a fare attività che non scalano nei primi 10-20 clienti, tipo conversazioni 1-a-1 e video personalizzati. Il paid serve quando hai già validato messaggio e funnel, non per cercare il product-market fit. - Q: Quanto deve essere specifico l'ideal customer profile? A: Molto più di quanto pensi. "Aziende edili" è una categoria, non un ICP. Ti servono firmographics (dimensione azienda, location, stack di tool usati), decision maker e influencer, pain point notturni, paure, obiettivi. Quando l'ICP è preciso, messaging, pricing e prioritizzazione delle feature si decidono quasi da soli. - Q: Il cold email funziona ancora nel 2025 per un SaaS bootstrap? A: Il cold email blast generico no, gli inbox sono saturi. Funzionano gli approcci ibridi: prima social engagement per farti vedere dal prospect (commenti, like, follow), poi un'email che porta valore concreto come un'analisi competitor, oppure un video Loom personalizzato di quattro-cinque minuti. Il response rate è ordini di grandezza superiore al blast classico. - Q: Quando ha senso passare al paid ads dopo aver validato l'organic? A: Quando hai messaging che converte sulla landing, un funnel misurato e capisci la lifetime value media di un cliente. A quel punto il paid serve ad accelerare un canale che già funziona. Lanciare ads prima di aver chiuso il loop ICP-messaggio-conversione significa pagare per scoprire cosa non va, ed è il modo più costoso di farlo. - Q: Quanto tempo serve in pratica per arrivare ai primi 100 clienti? A: Il video non dà una timeline secca, ma il pattern descritto suggerisce mesi, non settimane: i primi 10 vengono dal network, poi serve costruire un sistema GTM ripetibile e iterare su ICP e messaging. Per un founder bootstrap full-time, una finestra realistica è 6-18 mesi, in funzione di quanto stretto è l'ICP e quanto è doloroso il problema che risolvi. ### Sam Altman - How to Succeed with a Startup URL: https://startupmentors.it/video/sam-altman-succeed-startup-yc YouTube: https://youtu.be/0lJKucu6HJc Channel: Y Combinator · 16 min · founder-skills Personas: founder **Perché vale**: Sam Altman (allora YC president, oggi CEO di OpenAI) condensa in 16 minuti la formula con cui valuta le startup: prodotto che la gente ama, mercato in crescita esponenziale, founder evangelist, team che dice 'ce la facciamo'. Lezione asciutta, zero hype. **Riassunto**:Sam Altman tiene questo intervento alla Stanford CS183F nel 2018, quando è ancora president di Y Combinator. È un compendio condensato di cosa, dopo migliaia di startup viste passare per il programma, sembra correlare davvero con il successo. Non è una formula magica e Altman lo dice subito: il consiglio numero uno è banale da formulare ma durissimo da eseguire. Costruire qualcosa che la gente ami al punto da raccomandarlo spontaneamente agli amici. Tutto il resto, dice, è ottimizzazione attorno a questo singolo asse.
Il punto di partenza è la metrica più semplice e più scomoda: la gente parla di te ai propri amici senza che tu glielo abbia chiesto? Se sì, hai fatto l'80% del lavoro che serve per essere una startup di successo. Se no, nessuna leva di growth ti salva. Altman fa l'esempio di Google e Facebook: probabilmente li hai conosciuti perché un amico ti ha detto "devi provarli, sono fortissimi". Quella è l'asticella, non il numero di download o le metriche di vanity.
Un indicatore secondario, ma utile, è la chiarezza della spiegazione. Se non riesci a dire in poche parole cosa fa il tuo prodotto e a far reagire qualcuno con "interessante", di solito è il sintomo di un pensiero confuso o di un bisogno troppo piccolo. La compressione dell'idea in una frase è un proxy della qualità del problema che stai risolvendo.
Il secondo grande tema è il mercato. Gli investitori guardano sempre il growth rate, dice Altman, e perdonano un fatturato piccolo se cresce in fretta. Però per qualche motivo la maggior parte dei founder ragiona sul TAM di oggi e non sulla traiettoria. È un errore. Le startup più importanti partono in mercati piccoli che stanno crescendo molto velocemente. Undici anni prima di questo talk, il mercato delle iPhone app valeva zero dollari. Quello che vuoi è salire su un ascensore che continua a salire ogni anno.
Per non scommettere su mercati che non si materializzano, Altman propone un test pratico per distinguere trend reali da trend finti. Nei trend reali una nuova piattaforma arriva, gli early adopter la usano in modo ossessivo, ne parlano agli amici. Nei trend finti la gente magari compra il prodotto, ma poi non lo usa. L'iPhone nel 2007 ha venduto un paio di milioni di unità: chi ce l'aveva lo usava per ore al giorno e lo raccomandava. Trend reale. La VR ad agosto 2018, dice Altman, è il caso opposto: molti la comprano, pochissimi la usano davvero. Trend potenzialmente futuro, non ancora presente. La regola da tenere in tasca è semplice: prima di scommettere su una piattaforma nuova, guarda l'intensità d'uso degli early adopter, non il volume di vendita.
Almeno un founder, di solito il CEO, deve essere il chief evangelist della startup. Vende il prodotto ai primi clienti, recluta i primi dipendenti, parla con la stampa, raccoglie capitale. Senza qualcuno capace di "infettare di entusiasmo" il mondo intero su quello che state facendo, è quasi impossibile costruire un team, figuriamoci scalare.
Da qui Altman tira un'osservazione controintuitiva sul 2018 in Silicon Valley: è più facile fare una startup difficile che una startup facile. Sembra paradossale ma la logica regge. In un ambiente dove raccogliere capitale è relativamente facile e le startup spuntano ovunque, il problema vero è attirare talento. I primi due dipendenti li trovi dando equity. Il decimo, il ventesimo, il quarantesimo, no: quelli vogliono lavorare su qualcosa che conta. Una visione ambiziosa, mai grandiosa, è uno strumento di recruiting prima ancora che un esercizio di branding. L'ecosistema startup è strutturato per supportare aziende con bassa probabilità di successo ma enormi se funzionano: tanto vale puntare in quella direzione.
Un altro tratto che Altman vede nei migliori founder è una visione del futuro confidente e definita. Confidenti perché credono di aver capito qualcosa, definite perché sanno articolare con precisione cosa accadrà. È legittimo essere flessibili sui dettagli, ma il founder deve poter dire "questo succederà ed è il motivo per cui costruiamo X". Avere il coraggio delle proprie convinzioni davanti al dubbio diffuso correla fortemente con il successo.
Sul team Altman salta i consigli ovvi (intelligenti, dedicati, che comunicano bene) e mette a fuoco tre tratti meno scontati. Cita Vinod Khosla: il team che costruisci è l'azienda che costruisci. Pochi founder, dice, dedicano abbastanza tempo al recruiting. Mark Zuckerberg è una delle eccezioni note.
Il primo tratto è avere alcuni "idea generators": persone che sparano costantemente idee nuove, la maggior parte delle quali sarà cattiva, ma che mantengono fertile il flusso strategico. Non ne servono troppi, ma servono. Il secondo tratto è lo spirito del "we'll figure it out": davanti ai problemi che sembrano poter uccidere l'azienda, e ce ne saranno parecchi, il team deve dire "ce la facciamo" invece di paralizzarsi. Il terzo è il "I've got it": persone che davanti a un problema non dicono "non è il mio reparto" ma "ci penso io". Bias all'azione, capacità di agire con meno dati di quelli che vorrebbero avere, e di adattarsi in fretta se l'azione non funziona.
C'è anche una nota sulla blessing of inexperience: alcune startup fanno cose incredibili perché nessuno ha detto loro che erano impossibili. Altman cita Steve Wozniak. La conclusione operativa: come founder, puoi prenderti più rischi del normale su persone inesperte ma ad alto potenziale.
Un job centrale del founder è non perdere mai momentum. Le startup nei primi anni vivono di momentum: se le persone continuano a consegnare risultati oltre le proprie aspettative è perché si sente il vento in poppa. Quando si perde, recuperarlo è dolorosissimo. Tradotto in pratica: la startup deve avere una cadenza di vittorie piccole e prevedibili, e tocca al founder garantirla. Niente piede sul freno nei primi anni, ed è uno dei motivi per cui Altman è onesto sul fatto che le startup non sono il setup migliore per il work-life balance.
Tre domande, infine, che Altman vede sempre più founder fare scena muta davanti, e che invece andrebbero preparate prima dell'application a YC. Qual è il vantaggio competitivo di lungo periodo (network effect, monopoly, switching cost)? Qual è un business model sensato, anche solo come prima ipotesi? Come pensi di acquisire utenti in modo concreto? Non servono risposte definitive, ma un'idea di partenza ragionata sì. Paul Buchheit, riporta Altman, ha distillato i tratti dei migliori founder YC in quattro parole: frugality, focus, obsession, love.
Chiusura sul perché alcune startup diventano grandi nonostante l'asimmetria di risorse. Tre pattern ricorrenti. Primo: cerca idee che sembrano cattive ma sono buone. Dentro una grande azienda un product manager con quell'idea ha bisogno che decine di livelli, fino al CEO, dicano sì; un solo no la affossa. Una startup ha bisogno di un solo investitore che dica sì. Asimmetria a favore della startup.
Secondo: i mercati che cambiano in fretta. Più velocemente il mercato evolve, più decisioni si fanno, più la velocità della startup accumula vantaggio sulla lentezza decisionale di un competitor grande. Terzo: i platform shift. Quando arriva una piattaforma nuova, le grandi aziende girano lentamente come una corazzata; una startup la mattina può svegliarsi e dire "andiamo all-in su questa direzione". È storicamente da lì che nascono i cluster di aziende che diventano valuable. Tre filtri che Altman suggerisce di applicare a ogni idea di startup, prima ancora di pitchare a un investitore.
**Key takeaways**: - Costruisci un prodotto che gli early adopter raccomandano spontaneamente: l'80% del lavoro per arrivare al successo è già lì, il resto è esecuzione. - Non guardare il TAM di oggi, guarda un mercato che cresce in modo esponenziale: meglio salire un piccolo ascensore veloce che restare fermo dentro uno grande. - Distingui i trend reali da quelli falsi guardando l'uso: nei trend reali gli early adopter usano il prodotto ossessivamente, nei falsi lo comprano e basta. - Almeno un founder deve essere evangelist: vende, recluta, parla con la stampa, raccoglie capitale. Senza questa figura è quasi impossibile costruire un team. - Cerca idee che sembrano cattive ma sono buone: contro un product manager di una grande azienda ti basta un sì da un investitore, lui ne ha bisogno di dieci. **FAQ**: - Q: Perché Altman dice che il mercato conta più dell'execution? A: Non lo dice così, ma quasi. La sua osservazione è che gli investitori perdonano un revenue piccolo se il growth rate è alto, e che le startup più importanti partono in mercati piccoli ma in crescita esponenziale. Tradotto: un'execution mediocre dentro un mercato che esplode batte quasi sempre un'execution perfetta dentro un mercato fermo. Il consiglio operativo è guardare la traiettoria del mercato, non il TAM di oggi. - Q: Come capisco se un trend è reale o falso secondo Altman? A: Guarda l'intensità d'uso degli early adopter, non il volume di vendite. In un trend reale chi adotta il prodotto lo usa ossessivamente e lo raccomanda agli amici (esempio iPhone 2007). In un trend falso la gente magari compra ma non usa abbastanza (esempio VR 2018 secondo Altman). Prima di scommettere su una piattaforma nuova, fatti questa domanda sull'uso quotidiano, non sui dati di spedizioni. - Q: Cosa intende Altman per 'idee che sembrano cattive ma sono buone'? A: Idee che dentro una grande azienda morirebbero subito perché ogni livello di approvazione le boccia, ma che fuori, nel mercato libero, possono attirare il sì di un investitore disposto a scommettere. L'asimmetria è strutturale: una grande azienda ha bisogno di tanti sì per partire, una startup di uno solo. Se la tua idea sembra cattiva ai più ma a te sembra buona per ragioni difendibili, è un buon segnale, non un problema. - Q: Come faccio a capire se ho un product-market fit secondo questa lezione? A: Altman non usa esplicitamente l'espressione, ma il proxy che propone è chiaro: la gente parla del tuo prodotto agli amici spontaneamente, senza che tu glielo abbia chiesto. Se questo accade, hai fatto l'80% del lavoro. Se non accade, nessuna spinta di growth, marketing o sales risolverà strutturalmente il problema. Il word of mouth organico è il segnale che il prodotto ama il mercato e non il contrario. - Q: Quanto è importante davvero la visione ambiziosa per una startup early-stage? A: Per Altman è una leva di recruiting più che di marketing. I primi due dipendenti li convinci con equity e amicizia, ma il decimo, il ventesimo, il cinquantesimo no: vuole lavorare su qualcosa che conta. Una visione ambiziosa (mai grandiosa) attira talento, mindshare e capitale. Senza visione si compete solo sul cash, ed è una battaglia che una startup early-stage non può vincere. ### La Startup Italiana che Ha Creato 15 Milionari URL: https://startupmentors.it/video/satispay-alberto-dalmasso-chapeau YouTube: https://youtu.be/jjlSJH8VqWE Channel: Chapeau · 31 min · case-study Personas: founder, investor **Perché vale**: Satispay vale un miliardo e 15 dipendenti sono diventati milionari grazie alle stock option. Alberto Dalmasso racconta i primi due anni di buio, gli errori sui round e perché in Italia oggi c'è una finestra rara per fare impresa. **Riassunto**:Alberto Dalmasso ha 28 anni quando si licenzia dalla società di gestione patrimoniale dove era entrato dopo l'università. Aveva una carriera in salita, stipendio decente, riconoscimento dei suoi capi. Si sveglia una mattina nel suo letto a Torino e si rende conto che sta diventando troppo lentamente quello che vuole essere. Quella, racconta nell'intervista a Chapeau, è stata l'unica vera paura della sua vita imprenditoriale: non il fallimento, ma la lentezza.
Pochi mesi dopo fonda Satispay con Dario, il cofounder con cui condividerà tutto il decennio successivo. Oggi Satispay vale circa un miliardo, ha raccolto quasi mezzo miliardo di euro in dieci anni e ha trasformato circa quindici dipendenti in milionari grazie alle stock option (founder esclusi). L'intervista del podcast Chapeau scava nei capitoli che di solito non finiscono nei comunicati stampa: i primi due anni di buio, gli errori sui round, l'ownership come unica leva realistica, il lancio dei buoni pasto.
Quando Dalmasso parla di pagamenti digitali, all'inizio non c'è ancora niente da mostrare. L'app non esiste, le banche partner si tirano indietro la notte prima del closing, gli amici investono per fiducia personale più che per analisi finanziaria. Per due anni non c'è alcun numero da guardare: niente nuovi iscritti del giorno, niente metriche di funnel, solo l'idea raccontata a chiunque chiedesse cosa stessero facendo. La fatica psicologica di sostenere una visione che non ha ancora prove tangibili è, secondo Dalmasso, il vero filtro del primo periodo da founder. Chi resiste lì, resiste a tutto.
La regola che ne ricava è netta: non hanno mai pensato che il progetto potesse non realizzarsi. Non per ottimismo cieco, ma perché ogni momento di crisi (banca partner che salta, round che si blocca, capitale che finisce) veniva tradotto in operazioni concrete da chiudere entro X settimane. Mai un "qui crolla tutto", sempre un "qui dobbiamo cambiare ritmo". La differenza tra un founder che continua e uno che molla, in quei due anni, sta tutta in questa traduzione operativa.
Il primo aumento di capitale puntava a 2,5 milioni. Dalmasso e il cofounder pensavano di prenderli da venti privati a 100mila euro a testa, perché muoversi con i fondi era troppo lento. Quando il direttore generale di una banca partner (Leonardo Rubattu, ancora oggi nel CDA di Satispay) decide di mettere quei 2,5 milioni da solo, i due cofounder cambiano subito strategia: si fermano, riaprono la conversazione con i privati e chiudono a 5 milioni totali. Pochi mesi dopo, dopo aver lanciato l'app e averla annunciata insieme al round, un secondo aumento da 3 milioni porta la dote complessiva a 8.
Quei 3 milioni in più sono arrivati con critiche dagli operatori del mestiere ("hai appena chiuso un round, perché ne fai un altro?"). Con il senno di poi, Dalmasso è esplicito: senza quegli 8 milioni iniziali si sarebbero ritrovati a fare un terzo aumento minuscolo, in difficoltà, con numeri di trazione ancora troppo piccoli per giustificare una valutazione decente. La lezione è doppia: il capitale serve più di quanto sembra perché gli effetti network richiedono tempo (Satispay ha dovuto sbagliare nelle grandi città per capire che doveva partire dalle piccole), e raccogliere "tanto" da una posizione di forza è infinitamente più facile che raccogliere "il giusto" quando hai già il fiato corto.
Da lì la traiettoria si dispiega: 20 milioni nel 2017, 80 nel 2020, 320 nel 2022 (round dell'unicorno). Investitori americani che entrano e impongono cambi di mentalità: il dipartimento "Tech" smette di essere chiamato così, perché chi lavora al prodotto non sviluppa tecnologia ma fa product management, analisi di mercato, design di interazione. Sono competenze che in Italia all'epoca quasi non esistevano e che Satispay ha dovuto importare via investitori e founder italiani rientrati dalla Silicon Valley.
Dalmasso è esplicito su un punto che pochi founder italiani esplicitano: lo stipendio, da solo, non porta al livello di ricchezza che la maggior parte delle persone immagina da bambino. La via realistica è una sola: avere ownership in qualcosa che cresce di valore e che a un certo punto diventa parzialmente o totalmente monetizzabile.
Per i fondatori questo significa due cose, nei round di crescita. Da un lato i grandi investitori americani hanno spinto Dalmasso e il cofounder a vendere una piccola parte delle loro azioni durante un round, così da togliere le preoccupazioni economiche di base (mutuo, famiglia, sostegno ai genitori) e poter restare concentrati al 100 per cento sull'azienda. Dall'altro hanno imposto piani di stock option che li mantenessero vicini al 10 per cento a testa: percentuale necessaria per restare allineati alla logica dell'investitore, che vuole fare valere l'azienda miliardi di euro e non i 100 milioni che basterebbero a sistemare la vita personale di un founder con il 23 per cento.
Questa logica vale anche per il team. Quindici persone in Satispay (founder esclusi) sono diventate milionarie grazie alle stock option: hanno comprato casa o pagato il mutuo ai genitori. È uno dei pochi casi italiani in cui un piano di equity esteso al team ha prodotto effetti distribuiti reali, e Dalmasso lo cita come esempio di pratica che vorrebbe vedere replicata da più startup nel paese.
Quando gli si chiede l'errore più grande dei dieci anni, Dalmasso non cita un pivot sbagliato o un mercato letto male. Cita la lentezza. Decisioni che andavano prese più rapidamente, persone sbagliate lasciate troppo a lungo nel ruolo (non per cattiveria, ma perché ridistribuire le responsabilità in tempo avrebbe sbloccato il team prima), progetti rimandati di mesi che potevano essere lanciati subito.
Se rifacessero Satispay oggi, dice, ci metterebbero la metà del tempo ad arrivare dove sono e sarebbero tre o quattro volte più grandi. Non perché abbiano sbagliato strategia, ma perché ora saprebbero accelerare. Per un founder early-stage la traduzione operativa è esplicita: la maggior parte degli errori che ti costano davvero non sono di scelta, sono di tempistica. Hai già visto la cosa giusta da fare; il problema è che ci hai messo sei mesi a deciderla.
Su un secondo tema, Dalmasso invita a non cedere alla moda del pivot continuo. La narrativa "non scala, pivot" è secondo lui sopravvalutata: quasi nulla cresce da un giorno all'altro, quasi tutto è difficile, e se l'idea ha senso e il mercato esiste va portata avanti continuando a lavorare sulla crescita, non saltando alla cosa successiva. Il lancio recente dei buoni pasto da parte di Satispay (mercato apparentemente lontano dai pagamenti digitali) non contraddice la regola: arriva dopo dieci anni di focus assoluto, sfrutta i 70mila esercenti già a network e si inserisce in un circuito chiuso strutturalmente identico a quello dell'app principale. È espansione, non pivot.
L'ultimo blocco dell'intervista è sull'ecosistema italiano. Dalmasso non è preoccupato dai 250 milioni investiti in VC negli ultimi sei mesi (cifra che molti commentatori hanno letto come segnale negativo). Il suo punto è che mancano i mega-round perché il costo del capitale è alto, ma i pre-seed e i seed da milioni esistono, sono attivi, e founder come lui investono in prima persona portando competenze oltre al capitale.
Per chi vuole costruire oggi in Italia il messaggio è doppio. Da un lato c'è una finestra: il mercato italiano è grande abbastanza per costruire campioni locali su servizi specifici, e la tecnologia ha abbassato la barriera d'ingresso. Dall'altro c'è un avvertimento: raccogliere 5, 6, 10 milioni è tanto, e bisogna restare umili. Non sei bravo perché hai raccolto soldi; sarai bravo se con quei soldi costruisci qualcosa di grande. Il capitale è il mezzo, non l'obiettivo. È una distinzione che Dalmasso ha visto tradire troppi founder negli ultimi anni, finiti male per aver assunto troppo, speso troppo, e dovuto licenziare prima ancora di aver trovato un product-market fit difendibile.
**Key takeaways**: - Il primo round Satispay puntava a 2,5 milioni: arrivati a 5, poi subito altri 3 per 8 totali. Senza quella scorta di capitale sarebbero rimasti incastrati su round troppo piccoli. - L'ownership è la sola via realistica per costruire ricchezza personale: lo stipendio non basta, mai. Vale per i founder e per i primi dipendenti con stock option. - I primi due anni dopo il licenziamento sono stati un buco nero: nessun numero da guardare, nessuno che capiva il prodotto, banche partner che si tiravano indietro la notte prima del closing. - L'errore più grande non è stato strategico ma di velocità: decisioni prese troppo tardi, persone sbagliate lasciate troppo a lungo nel ruolo, progetti rimandati che andavano lanciati subito. - Tre milioni che ti cambiano la vita non bastano se hai il 23% di un'azienda che ne può valere miliardi. La posta in gioco deve restare grande anche per i fondatori, altrimenti vendi presto e male. **FAQ**: - Q: Quanto vale oggi Satispay e quanto capitale ha raccolto in totale? A: Satispay è valutata circa un miliardo di euro ed è entrata ufficialmente nel club degli unicorni con il round del 2022. Ha raccolto quasi mezzo miliardo in dieci anni: 8 milioni nel primo round (2014, in due tranche da 5 + 3), 20 milioni nel 2017, 80 milioni nel 2020 e 320 milioni nel 2022. - Q: Quanti dipendenti di Satispay sono diventati milionari grazie alle stock option? A: Circa quindici persone, founder esclusi. Hanno usato i proventi delle stock option principalmente per comprare casa o pagare il mutuo ai genitori. Dalmasso lo cita come esempio di piano di equity esteso al team che ha prodotto effetti distribuiti reali, una pratica ancora rara nel panorama italiano e che vorrebbe vedere replicata da più startup. - Q: Qual è stato l'errore più grande di Satispay nei primi dieci anni? A: Non un errore strategico, ma di velocità. Decisioni prese troppo tardi, persone sbagliate lasciate troppo a lungo nel ruolo, progetti rimandati che andavano lanciati prima. Dalmasso dice che se rifacesse Satispay oggi ci metterebbe la metà del tempo ad arrivare dove sono e l'azienda sarebbe tre o quattro volte più grande. - Q: Perché Satispay ha lanciato i buoni pasto se sembra un mercato lontano? A: Perché è un circuito chiuso strutturalmente identico a quello dei pagamenti digitali: aziende che danno il buono ai dipendenti, dipendenti che lo spendono presso esercenti che già accettano Satispay (70mila al momento del lancio). Non è un pivot ma un'espansione che sfrutta il network già costruito. Dalmasso ribadisce che è arrivata dopo dieci anni di focus assoluto sul prodotto principale, non come fuga in avanti. - Q: Cosa consiglia Dalmasso a un founder italiano che vuole partire oggi? A: Cercare ownership: lo stipendio non porta al livello di ricchezza che la maggior parte delle persone immagina, l'unica via realistica è essere proprietario di qualcosa che cresce di valore. Restare umili dopo un round: raccogliere 5-10 milioni è tanto, vanno fatti durare. Non cedere alla moda del pivot continuo: quasi nulla cresce da un giorno all'altro, quasi tutto è difficile, e se l'idea ha senso bisogna continuare a lavorarci. ### Primi 100 utenti SaaS: il sistema di Simon Hoiberg URL: https://startupmentors.it/video/simon-hoiberg-saas-first-100-users YouTube: https://youtu.be/6P_H9eDNBcA Channel: Simon Høiberg · 11 min · crescita-marketing Personas: operator, founder **Perché vale**: Hai un MVP pronto e zero utenti. Hoiberg ti dà la roadmap che ha usato su tre SaaS bootstrap: come arrivare ai primi cinque utenti via outgoing manuale, scalare a cento con i referral, poi a mille col content marketing. Tactical, niente fuffa, dieci minuti. **Riassunto**:Simon Hoiberg ha costruito tre SaaS in bootstrap e in questo video condensa il sistema che usa per portarli da zero a numeri seri. La premessa è semplice: l'acquisizione utenti non è fortuna, è un'equazione con variabili note. Ogni acquisizione ha tre componenti: metodo, canale e costo, e i metodi possibili sono solo quattro: incoming (l'utente ti trova), outgoing (lo contatti tu), referral (gli utenti portano altri utenti), advertising (paghi per stare davanti agli occhi). Tutto il resto sono combinazioni di questi quattro elementi su stage diversi del percorso.
Lo stage più sottovalutato. Hoiberg insiste che i primi cinque utenti sono i più importanti che avrai mai, e per ottenerli devi fare la cosa che non scala: scrivere a mano una per una a persone del tuo network ristretto. Famiglia, ex colleghi, partner, founder che conosci di persona. Il messaggio è secco: ho un MVP pronto, credo possa risolverti questo problema specifico, ti offro un account gratuito a vita, in cambio voglio il tuo feedback. Costo zero, canale email o DM, conversion rate alta perché parli con persone che si fidano.
Il punto critico non è chiuderli, è quello che fai dopo. Mettili in una micro-community su Discord, WhatsApp o Slack, ascolta cosa rompe, correggi i bug, implementa quello che chiedono, fai sentire che la loro voce sposta il prodotto. Non stai cercando utenti, stai costruendo advocate. Senza questo passaggio lo stage successivo crolla.
Qui la maggioranza dei founder sbaglia stage. Pensano di dover già fare ads o content. Hoiberg dice no: se hai servito bene i primi cinque, hanno già voglia di parlarne. Il modello è referral con costo zero, canale link tracciati personali, leva uno sconto generoso per chi arriva tramite loro. Lo sconto fa due cose insieme: dà ai tuoi advocate un'offerta concreta in mano da girare, e fa sentire i nuovi utenti parte di qualcosa che sta nascendo.
Hoiberg è scettico sulle revenue share in questo stage, e ha ragione: se hai bisogno di pagare i primi advocate per parlare di te, probabilmente non li hai serviti abbastanza bene nello stage uno. Il referral organico è il segnale che il prodotto risolve davvero un problema sentito.
Questo è lo stage lungo e doloroso, dove molti founder mollano. L'outgoing manuale non scala più, i referral organici da cento utenti non bastano per arrivare a mille in tempi ragionevoli. Serve incoming: utenti che ti trovano da soli su Google e YouTube, e per farti trovare devi creare contenuti consistenti su più canali. Long form su YouTube, articoli SEO, short e Reels per intercettare attenzione, post LinkedIn con alti e bassi del building in public, lezioni operative su Indie Hackers e Hacker News.
Il costo qui è reale, sia in tempo che in soldi se esternalizzi parte del content. Hoiberg avverte che ci saranno settimane di engagement piatto e zero conversioni. La regola è non mollare e lasciare che il revenue degli utenti esistenti finanzi l'acquisizione dei nuovi finché non sblocchi la soglia dei cinquecento. Sotto quella soglia non hai abbastanza segnale per ottimizzare, sopra inizia a girare.
Stage tre è diverso dai precedenti perché qui scegli la direzione strategica. Growth mode significa reinvestire ogni euro nei due nuovi modelli: ads sui contenuti che hanno già dimostrato di convertire (Google Ads search e video, Meta per Facebook e Instagram, TikTok per video ads), più un affiliate program aperto con revenue share aggressiva, dal 20 al 50% sul ricorrente. Automation mode significa accontentarsi di un ritorno tre a uno sugli ads (un euro speso, tre incassati, uno reinvestito, due in tasca) e tenere l'affiliate su compensi più leggeri come gift card o feature sbloccate.
La nota finale di Hoiberg vale ricordarla: questa roadmap non è l'unica. Puoi partire con gli ads molto prima, oppure scalare il cold outreach anche nello stage avanzato. Ma è il sistema che lui ha usato su tre SaaS, e sa cosa funziona quando sei solo, in bootstrap, e devi tirar fuori i primi numeri prima che finisca il runway.
**Key takeaways**: - Ogni acquisizione utente ha tre componenti: metodo (incoming, outgoing, referral, advertising), canale e costo. Devi disegnarle a tavolino prima di muoverti, non improvvisare. - Primi cinque utenti: outgoing a costo zero. Scrivi a mano email o DM al tuo network ristretto, offri account gratuito a vita in cambio di feedback, raccoglili in una micro-community Discord o WhatsApp. - Da cinque a cento: referral organici. Se hai servito bene i primi cinque, diventano advocate e portano nuovi utenti senza bisogno di pagarli, basta uno sconto early adopter per i nuovi arrivati. - Da cento a mille: incoming via content marketing e building in public. Video YouTube, articoli SEO, post LinkedIn, lezioni su Indie Hackers. Lento, costoso, ma è l'unico modello che scala in questa fascia. - Oltre i mille: advertising sui contenuti che già funzionano (Google Ads, Meta, TikTok) più affiliate program con revenue share del 10-50%. Sceglie tra growth mode e automation mode in base a quanto vuoi reinvestire. **FAQ**: - Q: Cosa devo avere pronto prima di partire con questo sistema? A: Un MVP funzionante che risolve un problema specifico per un segmento ristretto. Hoiberg lo dice esplicitamente: il video presuppone che tu abbia già il prodotto. Senza MVP testabile, anche il primo stage di outgoing al network ristretto non funziona, perché non hai nulla di concreto da far provare. - Q: Quanto tempo realistico serve per arrivare a 100 utenti con questo metodo? A: Hoiberg non dà una stima precisa, ma il pattern dei SaaS indie in bootstrap parla di tre-sei mesi per i primi cento utenti se il prodotto risolve un problema sentito e il founder è disciplinato sull'outgoing manuale. La parte più lenta è dopo: lo stage da 100 a 1.000 via content marketing richiede tipicamente 12-18 mesi di pubblicazione consistente. - Q: I revenue share dal 10 al 50% per gli affiliate non sono troppo alti? A: Dipende dal LTV e dal margine. Un SaaS con churn basso e LTV alto può sostenere il 30-50% sul ricorrente perché l'affiliate ti porta utenti che restano anni. Per prodotti con churn alto la matematica non torna sopra il 20%. Calcola sempre il payback period: quanto ci mette l'utente referrato a coprire il costo della commissione. - Q: Funziona anche per SaaS B2B con ticket alti, o solo per prodotti self-serve? A: Il framework regge per entrambi, ma cambia la composizione. Il B2B con ACV sopra i 5.000 euro tende a pesare di più sul metodo outgoing anche oltre lo stage uno (cold email targettizzato, LinkedIn outbound), e meno su content broad e ads. I primi cinque utenti del network restano comunque il punto di partenza universale. - Q: Conviene farlo da solo o serve un team? A: I primi due stage sono fattibili da solo se hai 15-20 ore a settimana dedicate. Lo stage del content marketing è dove emerge il bottleneck: produrre video, articoli e post in modo consistente per 12 mesi mentre fai anche prodotto è il punto in cui molti founder solo bruciano. A quel punto vale la pena valutare una mezza giornata a settimana di content writer freelance o un editor video. ### Come trovare i primi clienti secondo Gustaf Alstromer (YC) URL: https://startupmentors.it/video/yc-alstromer-first-customers YouTube: https://youtu.be/hyYCn_kAngI Channel: Y Combinator · 23 min · crescita-marketing Personas: operator, founder **Perché vale**: Se sei un founder pre-launch o early-stage, qui Gustaf Alstromer (YC Partner, ex Airbnb growth) ti spiega perché i primi clienti li devi cercare a mano tu, come scrivere email di vendita che funzionano e perché il sales funnel è l'unica strada onesta. **Riassunto**:Gustaf Alstromer è Group Partner a Y Combinator e prima ha guidato il growth di Airbnb. In questo intervento di Startup School smonta una convinzione che blocca la maggior parte dei founder pre-launch: l'idea che basti un buon prodotto e che la growth si occupi del resto. Non è così. Le startup non decollano da sole, decollano perché i founder le fanno decollare. E il primo lavoro è andare a recuperare i clienti uno per uno, manualmente.
Il punto di partenza è l'essay di Paul Graham "Do things that don't scale", scritto raccontando i primi giorni di Airbnb. La traduzione operativa è semplice: nei primi mesi devi fare cose che non scalano, perché è l'unico modo per capire chi sono davvero i tuoi clienti e cosa vogliono. Premere un bottone su una rete pubblicitaria non basta. Scrivere più codice nemmeno.
Alstromer mostra la classica startup curve disegnata da Trevor Blackwell: lancio, calo dopo l'effetto novità, "trough of sorrow", poi crescita lenta verso il product-market fit. La differenza tra chi ce la fa e chi muore in mezzo non è il prodotto in sé: sono i founder che imparano sales, ascoltano i clienti, cambiano mercato se serve. Quindi imparare a vendere non è opzionale, ed è probabilmente il job più facile da imparare in una startup, perché sei tu il vero esperto del problema che stai risolvendo. La passione per il problema è contagiosa: il cliente lo sente.
Il caso citato è Brex. Pedro e Henrique, founder di Brex, hanno reclutato i primi 10 clienti direttamente dal batch YC Winter 2017. Versione minima del prodotto: una virtual credit card. Henrique faceva l'onboarding di ogni singolo cliente di persona. L'email che hanno mandato apriva con "stiamo aprendo la beta per il batch winter 17 friends, 10 spot disponibili", spiegava in due righe il valore (corporate card per startup, no personal guarantee, gratis perché pagano i merchant) e funzionava. Era un po' troppo lunga per gli standard di Alstromer, ma ha portato 10 clienti.
Le regole che Alstromer dà sono concrete e replicabili. L'email deve essere corta, massimo 6-8 frasi. Linguaggio chiaro, niente jargon, niente buzzword: dici esattamente cosa fai e come funziona. Punta sul problema specifico che il destinatario ha. Plain text, niente HTML, niente immagini di marketing: deve sembrare una mail scritta a un amico. Dichiari subito che sei il founder. Dai social proof reale (se sei in YC, se hai lavorato in aziende note, dillo) ma senza vantarti dell'esperienza in astratto: show, don't tell. Includi un link al sito, e il sito deve avere screenshot del prodotto e bullet su cosa fa, non grafica decorativa. A volte funziona un video YouTube breve embeddato. E chiudi sempre con una CTA esplicita: una call, una demo, un signup self-serve, qualcosa di concreto.
Il sales funnel poi è più semplice di quanto sembri. Alstromer lo traduce dal "sales speak" al "founder speak": fai una lista di prospect (un Google Sheet basta per partire, poi passi a un CRM), li contatti via email o LinkedIn, scheduli una demo, parli di prezzo, chiudi. E poi il passo che quasi tutti dimenticano: onboarding. Se non li accompagni nell'uso del prodotto, churnano. I prodotti early-stage non sono mai facili da usare al primo accesso, l'onboarding manuale è parte del lavoro.
Il consiglio più controintuitivo, ed è probabilmente il più utile, è questo: i tuoi primi clienti devono essere i più facili. Non è il momento di andare a chiudere il deal più complicato. Hai pochissimo tempo, costruisci una pipeline grande, poi prioritizza chi ha più probabilità di chiudere in base alle risposte alle qualifying question. Non avere paura di lasciar andare un prospect che ti tira per le lunghe due o tre call: "ci risentiamo tra sei mesi" è una risposta perfettamente legittima.
Ordine di facilità pratico: persone che già conosci (sfrutta il network), poi altre startup (decisioni rapide, niente procurement, niente ufficio acquisti), poi tutto il resto. Le aziende grandi hanno reparti dedicati a negoziare con te, e quel processo non finisce mai. Le startup decidono in giornata. Inoltre, la maggior parte delle persone non è early adopter: se mandi 500 email, la massa non risponderà non perché odia il tuo prodotto ma perché archivia e basta. Non hai tempo di convertire chi non è early adopter, devi solo trovare gli early adopter e andare lì dritto.
Sui prezzi Alstromer è netto: se non ti pagano, non sono clienti, e tu non hai un'azienda. La paura di perdere il prospect per via del prezzo è un segnale che stai sbagliando target, non un segnale di sconto. Free trial in B2B no. Money back guarantee a 30 o 60 giorni sì. Opt-out mensile invece del contratto annuale, ancora meglio. E poi alza i prezzi finché i clienti si lamentano ma continuano a pagare: è il segnale che il valore c'è davvero.
L'errore più comune che vede nei founder, però, è un altro: non lavorare a ritroso dal goal. Esempio numerico che usa nel video: 500 email outbound, 50% open rate (250 aperture), 5% response rate (~20 risposte), 50% di queste portano a una demo (10 demo), 20% di chiusura sulle demo. Risultato: 2 clienti. Se invece mandi 100 email con gli stessi tassi, finisci con zero clienti, e la conclusione sbagliata che molti founder traggono è "il sales non funziona per me, faccio marketing o SEO". È falso: semplicemente non hai mandato abbastanza email per avere dati statistici. Senza CRM e senza tracciare le conversion rate, nessuno può darti feedback su cosa stai sbagliando, esattamente come non puoi migliorare un prodotto senza metriche di utilizzo.
La chiusura di Alstromer è una citazione di Lenny Rachitsky (anche lui ex Airbnb), che nella sua newsletter ha mappato la go-to-market iniziale di decine di startup B2B. Aziende oggi enormi come Stripe, Amplitude, Front sono partite così: founder che mandano email outbound a mano. I canali scalabili (Google ads, SEO, referral program, Facebook) sono lo stato finale, non il punto di partenza. Anche Airbnb non è partita facendo SEM. I primi clienti li recuperi a mano, sempre. Tool consigliati per partire: Apollo.io, Close.com, Pipedrive, Hunter.io. Libro: "Founding Sales".
**Key takeaways**: - I primi clienti non arrivano da soli: il founder deve fare sales in prima persona, non delegare a un team finché non sa lui stesso cosa funziona. - L'email di vendita efficace è corta (6-8 frasi max), in plain text, con link al sito e una CTA chiara per call o demo. - Punta sui clienti facili: persone che già conosci, altre startup (decisioni rapide), early adopter. Non perdere tempo a convincere chi non è early adopter. - Se non fai pagare, non hai clienti: niente trial gratis in B2B, meglio money back guarantee o opt-out mensile. - Lavora a ritroso dal goal: per chiudere 2 clienti servono ~500 email outbound, non 100. La maggior parte dei founder molla prima di avere abbastanza dati. **FAQ**: - Q: Devo davvero fare sales io come founder, o posso assumere un commerciale subito? A: Alstromer è categorico: non assumere un sales team finché non sai vendere tu. Non saprai cosa significa 'bravo' in un commerciale, non saprai distinguere un cattivo pitch da un cattivo prodotto, e non potrai dare feedback utili. Sales è parte del DNA del founder all'inizio, esattamente come l'engineering. - Q: Quanti clienti dovrei avere come obiettivo nei primi mesi? A: Il numero conta meno della metodologia. Brex ha aperto la beta con 10 spot dichiarati ai friend del batch YC. La logica è: parti da una pipeline grande, prioritizza i clienti facili (persone che conosci, altre startup, early adopter), traccia ogni step del funnel e usa i tassi di conversione per dimensionare l'outreach. Se vuoi 2 clienti chiusi e i tuoi tassi sono quelli dell'esempio (50% open, 5% response, 50% to demo, 20% close), servono ~500 email outbound. - Q: Posso offrire trial gratuiti per ridurre la frizione iniziale? A: In B2B no, dice Alstromer. Il free trial è un'abitudine consumer che funziona perché chiede la carta e poi addebita a oblio. In B2B preferisci una money back guarantee a 30-60 giorni, oppure la possibilità di opt-out dal contratto annuale dopo un mese. Se non ti pagano, non sono clienti e non sai se il valore è reale. - Q: Quanto deve essere lunga un'email outbound? A: Massimo 6-8 frasi. L'esempio di Brex citato nel video era più lungo e secondo Alstromer era ai limiti. Plain text, niente HTML, niente buzzword. Punta sul problema specifico del destinatario, dichiara chi sei (founder), aggiungi un pezzetto di social proof reale, link al sito con screenshot, CTA esplicita per call o demo. Punto. - Q: Quali tool servono per iniziare a fare sales come founder? A: Per partire basta un Google Sheet con colonne per industry, azienda, ruolo, nome, email, LinkedIn. Quando la lista cresce passi a un CRM semplice. Alstromer cita Apollo.io, Close.com, Pipedrive e Hunter.io (utile per estrarre contatti da LinkedIn). Come letture: il libro 'Founding Sales' e la newsletter di Lenny Rachitsky. ### Co-Founder Mistakes That Kill Companies & How To Avoid URL: https://startupmentors.it/video/yc-cofounder-mistakes YouTube: https://youtu.be/dlfjs_eEEzs Channel: Y Combinator · 9 min · operations Personas: founder **Perché vale**: Michael Seibel e Dalton Caldwell raccolgono storie reali di founder YC: il co-founder breakup uccide le startup early-stage più di un mercato sbagliato. 9 minuti per capire come scegliere il socio giusto e blindare la relazione. **Riassunto**:Michael Seibel e Dalton Caldwell aprono questo episodio di Rookie Mistakes con una domanda secca raccolta dai founder YC: cosa va storto tra co-founder, e perché spesso è fatale. La risposta non è tecnica, è relazionale. Le startup early-stage non muoiono perché il socio non sa scrivere codice o vendere: muoiono perché due persone che non si conoscevano davvero finiscono a litigare senza saperlo fare.
Il primo errore raccontato da un founder anonimo riguarda l'inizio, il momento in cui tutto sembra funzionare. È proprio lì che bisogna mettere per iscritto le cose scomode: chi prende quale percentuale, c'è il vesting, cosa succede se uno dei due si comporta male. Quando va tutto bene non vuoi parlarne perché sembra di portare sfiga. Quando va male è troppo tardi, la memoria di ogni persona riscrive la storia a proprio favore e non c'è più modo di trovare un terreno comune.
Dalton smonta il bias più diffuso tra chi cerca un co-founder: pensare che serva qualcuno con skill complementari rispetto alle proprie. Quasi tutto quello che impari, lo impari sul lavoro, dice. Le competenze del co-founder al giorno zero non sono quelle che avrà tra due anni. Quello che invece resta uguale è la qualità della relazione.
Michael lo conferma con un dato dalla loro esperienza diretta: nessun founder breakup che hanno visto è stato causato da skill insufficienti. Nessuno dice "il mio socio è una persona straordinaria, peccato che non sappia fare X". Tutti dicono "il mio co-founder è un incubo vivente, non lo sopporto più". È quello che uccide l'azienda.
La conclusione operativa: scegli qualcuno con cui hai già avuto disaccordi e ne sei uscito bene. Una relazione pressure-tested vale più di qualsiasi CV. Se hai litigato con un amico anni fa e adesso vi parlate meglio di prima, hai trovato un co-founder. Se non avete mai avuto attriti, la prima discussione vera dopo il fundraise rischia di essere anche l'ultima.
Un terzo founder anonimo scrive che ha scelto un socio con cui non poteva condividere disaccordi onesti. Non sapevano litigare bene, e da un mix di evitamento da una parte e gioco sporco dall'altra il rapporto è imploso. Michael e Dalton danno due indicazioni concrete. Primo: non sei obbligato a chiudere ogni discussione con una soluzione. Se la conversazione non è produttiva, metti in pausa, riprendi dopo. Secondo: capisci come il tuo co-founder reagisce allo stress, c'è chi attacca e chi si chiude. Sapere il pattern dell'altro ti aiuta a interpretare cosa sta succedendo davvero.
Poi c'è il caso peggiore. Founder che lavorano fianco a fianco 8-12 ore al giorno e dicono "non gli parlo da una settimana, da un mese, da un anno". Quando si arriva lì, dice Michael, il job del CEO non è più riparare il rapporto, è separarsi nel modo più efficace e meno distruttivo possibile. Tutti, dentro di loro, lo sanno già. Ma rimandano per mesi o anni perché fa male. Il prezzo di rimandare è: cap table compromessa da stock vested, rischio di litigation, energie che potrebbero andare al prodotto bruciate sul rapporto.
Sulla divisione di equity, più ti avvicini all'equal split, meglio è. Squilibri tipo 60-40 generano la dinamica tossica del "questa è la sua azienda, non la mia". Ma il 50-50 puro ha un altro problema: il deadlock. Due voti contrari, nessuno cede, decisione bloccata. Seibel lo ha visto uccidere aziende.
La soluzione tattica che propone: dare al CEO una share in più, simbolica per la ownership ma decisiva nei voti. Si mette per iscritto subito che, in caso di parità 50-50, quella share rompe il pareggio. Così resti psicologicamente equal con il tuo socio ma hai un meccanismo di sblocco già negoziato a freddo, non sotto stress.
Ultimo punto, controintuitivo per chi vuole partire da solo e poi cercare il socio: trova il co-founder prima dell'idea e del fundraise. Se l'idea nasce insieme, la startup nasce vostra. Se aggiungi un co-founder dopo aver già lavorato un mese da solo, nella sua testa quella resterà la tua azienda. E in un momento difficile si farà da parte molto più facilmente. Front-load la scelta: ne vale la pena.
**Key takeaways**: - Scegli un co-founder con cui hai già litigato bene in passato, non chi ha lo skill match perfetto sulla carta - Metti per iscritto equity split, vesting e ruoli prima che le cose vadano bene: dopo, ogni conversazione diventa tossica - Evita lo split 50-50 puro: dai al CEO una share extra come tiebreaker scritto, per sbloccare i deadlock fatali - Trova il co-founder prima dell'idea e del fundraise, così la startup nasce vostra e non sua - Quando il rapporto è compromesso da mesi, il job del CEO non è ripararlo ma separarsi nel modo meno distruttivo **FAQ**: - Q: Quale equity split è giusto tra co-founder? A: Il più vicino possibile all'equal split. Squilibri tipo 60-40 generano risentimento e la sensazione che la startup sia di uno solo. Per evitare i deadlock fatali del 50-50 puro, Seibel suggerisce di dare al CEO una share in più come tiebreaker scritto: ownership psicologica equa, ma sblocco decisionale già negoziato a freddo. - Q: Quando devo mettere per iscritto i patti tra co-founder? A: All'inizio, quando va tutto bene. Equity split, vesting, regole su comportamenti scorretti vanno scritti prima che servano. Una volta che la relazione è deteriorata, ogni discussione su questi temi diventa tossica e la memoria di ciascuno riscrive la storia a proprio vantaggio. - Q: Conviene cercare un co-founder con skill complementari ai miei? A: No. Dalton Caldwell è netto: quasi tutte le skill si imparano on the job. Le competenze del co-founder al giorno zero non sono quelle che avrà tra due anni. Conta molto di più la qualità della relazione e l'aver già affrontato un disaccordo insieme. Una relazione pressure-tested vale più di un CV perfetto. - Q: Cosa faccio se il rapporto con il mio co-founder è compromesso da mesi? A: Probabilmente sei oltre il punto di no return. Il job del CEO in quel momento non è riparare il rapporto, è separarsi nel modo più efficace e meno distruttivo. Rimandare peggiora la situazione: cap table compromessa, rischio litigation, stock vested in mano a chi non contribuisce più. Front-load anche la separazione. - Q: Conviene partire da solo e aggiungere il co-founder dopo? A: No, secondo Seibel e Caldwell. Se aggiungi un co-founder dopo aver già lavorato sull'idea o aver già raccolto il primo round, nella sua testa la startup resterà tua. La ownership condivisa nasce solo se idea e fundraise li costruite insieme dal giorno zero. Trova prima la persona, poi insieme decidete cosa fare. ### Primi utenti: il minimum evolvable product secondo YC URL: https://startupmentors.it/video/yc-first-users-ankit-gupta YouTube: https://youtu.be/0kARDVL2nZg Channel: Y Combinator · 6 min · crescita-marketing Personas: operator, founder **Perché vale**: Ankit Gupta (YC Partner) ribalta l'idea di MVP: i primi utenti non vanno convinti, vanno trovati. Sei minuti tattici per chi sta per lanciare e non sa da dove iniziare il customer development. **Riassunto**:Ankit Gupta (YC Partner) parte da una domanda scomoda per ogni founder pre-launch: quanti dei prodotti che usi oggi ti hanno visto fra i primi dieci utenti? Per la maggior parte delle persone la risposta è zero. Quasi nessuno vuole essere il primo cliente pagante di una startup. Eppure ogni grande prodotto, prima o poi, qualche pioniere lo trova.
La conclusione cambia tutto il modo in cui pensi al lancio. Trovare i primi utenti è più un search problem che un problema di persuasione: non ti serve convincere il mercato, ti serve scovare le poche persone che hanno già un dolore acuto o che amano provare cose nuove.
Esistono due profili che convertono velocemente. Il primo è quello di chi prova prodotti nuovi per mestiere o per gusto, come il collega di Gupta che in Airbnb portava dentro le startup appena uscite dall'incubatore. Il secondo è quello di chi ha un problema talmente urgente da provare qualunque cosa prometta di risolverlo. Lo stesso Gupta racconta di aver pagato in tre giorni una startup sconosciuta perché il suo team aveva bisogno di un'inference API senza dover gestire billing e endpoint pubblici. Reputazione e dimensione del fornitore non contavano: contava il problema.
Da qui arrivano alcune implicazioni controintuitive che vale la pena prendere sul serio. Fai pagare presto e fai pagare un prezzo vero. Gli early adopter e chi ha un burning problem non sono price sensitive. L'obiettivo della prima fase non è fare revenue, è avere feedback. Un cliente arrabbiato che paga molto ti dice cose più utili di un utente gratuito che non è davvero coinvolto. Usa outreach personale e mirato: nelle prime settimane un cold email scritto a mano o un knock-on-the-door virtuale arrivano dove un billboard non arriverà mai. Lancia presto: nei primi giorni non sai chi sono davvero questi utenti e devi creare la massima superficie di contatto perché ti trovino.
Quando arrivano, non trattare gli early adopter come numeri in una dashboard. Gupta consiglia di studiarli come un antropologo che ha appena scoperto una civiltà nascosta. Come prendono decisioni? Perché hanno fatto la scelta strana di fidarsi di te? Cosa pensano davvero, cosa vogliono?
Allo stesso tempo, sperimenta velocemente: pricing, landing page, onboarding, feature, tutto. Parla con i primi utenti e prova a farglielo amare il prodotto, ma non andare in panico se ne perdi qualcuno. Se uno si arrabbia, di solito riesci a recuperarlo perché la relazione è personale. E se va in churn, va bene comunque: ce ne sono molti altri che ancora non sanno che esisti. È uno dei vantaggi delle startup sulle aziende grandi: quando fai un esperimento sbagliato non ne scrive nessuno. Stai combattendo per la rilevanza, non contro i titoli di giornale.
Nell'era AI questo discorso ha un risvolto economico. La spesa media in software personale è molto bassa, mentre una corporate card regge tool da centinaia di euro al mese senza battere ciglio. Le app consumer fanno fatica perché gli ad spesso non coprono i costi di inferenza e gli abbonamenti devono entrare in un budget personale già stretto. Per questo molti founder AI scelgono di partire da prosumer, da business o da target ad alto advertising value (Gupta cita i medici come esempio). Le aziende consumer continueranno a esistere, ma il default per chi parte oggi è un altro.
La punchline arriva con un'analogia. Pensa alla startup come a un albero filogenetico: il root node è un'ameba, le foglie sono organismi complessi come un cane o una persona. Quasi tutti i prodotti che oggi compri sono partiti da ameba e hanno fatto evoluzione fino a maturità: milioni di utenti, sales pitch raffinato, valore chiaro. Le startup early-stage sono amebe. Hanno solo le funzioni base per esporsi alle pressioni esterne, e da lì i founder fanno una ricerca evolutiva nell'albero delle direzioni possibili.
Tesla è il case study che Gupta porta. La Roadster era un'auto da 150.000 dollari poco pratica, brutta da vedere, con autonomia limitata e zero rete di ricarica. La narrativa ufficiale dice che serviva a finanziare il capex per Model S, 3 e Y. È probabilmente vero, ma c'è una seconda lettura: Tesla stava cercando gli early adopter, le persone abbastanza pazze da comprare quell'auto. Quegli utenti hanno deciso il DNA dei modelli successivi. Perché una Model Y, vettura da mass market, ha uno 0-100 più veloce di una Lamborghini e tech superiore a una BMW, ma sospensioni e comfort peggio di una Toyota? Perché gli early adopter di Tesla volevano accelerazione e tech, non comfort. Una macchina mass-market progettata in un vacuum non avrebbe quei valori.
È per questo che il tuo primo prodotto non deve essere un minimum viable product, ma un minimum evolvable product. Qualcosa di semplice che sopravvive al contatto con gli utenti e si adatta in fretta a quello che ti spingono a diventare. Sapere che il prodotto cambierà tanto è liberatorio: non deve essere perfetto al day one. Ciò che diventerà dipende da dove inizi e con chi inizi.
**Key takeaways**: - Trovare i primi utenti è un search problem, non un problema di persuasione: cerchi i pochi early adopter o chi ha un dolore acuto, non convinci la massa - Costruisci un minimum evolvable product, non un MVP: una versione semplice che sopravvive al contatto con gli utenti e si trasforma in base a ciò che imparano - Fai pagare subito, anche tanto: gli early adopter non sono price sensitive e i clienti paganti danno feedback più affilati di quelli gratuiti - Outreach personale e mirato batte la distribuzione di massa: cold email targettizzate o un bussare alla porta valgono più di un billboard nelle prime settimane - I primi clienti non danno solo feedback, decidono in che direzione evolve il prodotto: Tesla Roadster ha forgiato il DNA del Model Y di oggi **FAQ**: - Q: Qual è la differenza fra MVP e minimum evolvable product? A: L'MVP punta a essere la versione minima che fornisce valore. Il minimum evolvable product, secondo Ankit Gupta di YC, deve fare una cosa diversa: sopravvivere al contatto con un piccolo gruppo di early adopter e potersi trasformare velocemente in base ai loro feedback. La forma finale del prodotto sarà il risultato di quel processo evolutivo, non un disegno fatto a tavolino. - Q: Perché fare pagare i primi utenti se l'obiettivo non è il fatturato? A: Perché un cliente pagante è molto più coinvolto di uno gratuito. Gupta sostiene che gli early adopter e chi ha un burning problem raramente sono price sensitive: chiedere un prezzo vero filtra chi è davvero interessato e produce feedback più affilati. Un cliente arrabbiato che paga ti dice cose utili, un free user che non si è impegnato di solito sparisce in silenzio. - Q: Quali canali funzionano per trovare i primi 10 clienti? A: Outreach personale e mirato. Gupta cita esplicitamente cold email targettizzate e knock-on-the-door (anche metaforico) come più efficaci di canali di massa tipo billboard o ad generaliste. Il punto è che gli early adopter non sono raggiungibili con tattiche da prodotto maturo, e il volume non è quello che ti serve in questa fase. - Q: L'analogia dell'albero filogenetico: come si applica al lavoro di un founder? A: Significa che la tua startup parte come un'ameba con poche funzioni base e attraverso la pressione del mercato evolve verso forme più complesse. Il founder non disegna il prodotto finale, esegue una ricerca evolutiva nell'albero delle direzioni possibili. Il caso Tesla mostra che le scelte degli early adopter (acceleration, tech, no comfort) restano nel DNA del prodotto anche quando va in mass market. - Q: L'argomento AI-era favorisce davvero il B2B sul B2C? A: Per molti founder AI di oggi sì. Gupta osserva che la spesa media in software personale è bassa, mentre una corporate card sostiene tool costosi senza problemi. Le app consumer faticano perché gli ad spesso non coprono i costi di inferenza e gli abbonamenti devono entrare in budget personali ridotti. Per questo molti scelgono di partire da prosumer, business o target con alto advertising value come i medici. Non significa che il B2C sia morto, ma il default è cambiato. ### Errori da rookie nel fundraising: cosa insegna YC ai founder URL: https://startupmentors.it/video/yc-fundraising-mistakes-rookies YouTube: https://youtu.be/6606a2ka-jQ Channel: Y Combinator · 8 min · pitch-fundraising Personas: founder, investor **Perché vale**: Pensi di raccogliere capitale prima del lancio perché temi che il mercato non voglia il prodotto? Michael Seibel e Dalton Caldwell di Y Combinator smontano i tre errori che vedono ripetuti dai founder al primo round. **Riassunto**:Michael Seibel e Dalton Caldwell aprono l'episodio con una nota arrivata da un founder YC che racconta due esperienze opposte. Nella prima startup, senza crescita, ha parlato con 140 investor e ha portato a casa solo due assegni angel. Nella seconda, con metriche in crescita, ha chiuso il seed round in una settimana mentre quasi tutti i VC noti cercavano di entrare in contatto.
La conclusione di Seibel è netta: nel 97% dei casi avere demo, prodotto, MVP con customer reali ti dà molta più leva nel fundraising. La voce che gira tra i founder rookie - secondo cui il momento ideale per raccogliere è prima di avere qualunque metrica, perché poi sarai giudicato sui numeri - è una razionalizzazione di un'altra cosa: paura.
Dalton la chiama fear-based decision making. Se nel cuore credi che il tuo prodotto sia debole e che fallirà, ha senso razionale provare a raccogliere prima che il mondo se ne accorga. Ma stai costruendo l'azienda al contrario: stai cercando di chiudere un round difficile prima di affrontare la vendita difficile, invece di risolvere il problema vero che è capire se il prodotto serve a qualcuno.
Il secondo errore ricorrente è strutturale: i founder mettono l'investor al centro del gioco, come se il pitch fosse un esame e i soldi il voto. Dalton lo collega a come siamo cablati, dipendenti o studenti, a cercare validazione dalla figura di autorità: capisci chi devi compiacere, lo compiaci, sali di livello. Funziona in azienda, non funziona in una startup.
Il customer al centro al posto dell'investor cambia tutto. Seibel propone un audit semplice da fare a fine settimana: quanto del tuo tempo da sveglio negli ultimi sette giorni è andato a parlare con i customer e a costruire prodotto? Se sei sull'80-90% probabilmente stai facendo le cose giuste. Se sei sul 20%, qualcosa di molto serio non va.
La frase customer obsession è abusata, ma presa alla lettera vuol dire una cosa precisa: nelle ore in cui sei sveglio, è ai tuoi customer che pensi e sono i loro problemi che cerchi di risolvere. Tutto il resto, incluso il fundraising, è secondario.
Il terzo punto arriva da un'altra nota di un founder YC: raise what you need and nothing more. Troverai sempre il modo di spendere tutto quello che hai in banca. Brian Chesky di Airbnb ha detto recentemente alla batch YC che il denaro non è ossigeno, è cibo: ti serve per sopravvivere, ma in molte parti del mondo, America compresa, le persone muoiono per averne troppo, non per averne troppo poco.
Le aziende davvero forti hanno un'altra fonte di ossigeno: il revenue dei customer. È la domanda dei clienti che le tira avanti, non il capitale raccolto. E succede una cosa interessante: quei founder tendono a possedere più della loro azienda al momento dell'IPO o dell'exit, sono più felici, innovano di più. Quando non hai tanti soldi devi fare le cose meglio o in modo diverso dei competitor.
La differenza più grande tra founder che mantengono il controllo della loro company e founder che lo perdono non è il talento o il timing del mercato. È quanto sono stati disperati nel raccogliere capitale lungo la storia dell'azienda, e quanta leva avevano nei singoli round.
Facebook era apparentemente sempre profittevole, anche da social network universitario, grazie agli ad sul sito. Non c'è mai stato un momento in cui ha raccolto a brutte condizioni o più del necessario. Ed è il motivo per cui all'exit Zuckerberg possiede ancora così tanto. Stessa storia per Google: traction enorme da google.stanford.edu prima del primo dollaro raccolto, primo round a condizioni ottime, ogni round successivo con leva crescente.
Seibel chiude con un punto che è quasi filosofico ma molto operativo. Se vuoi tirare un grand slam con la tua startup, confrontati con chi i grand slam li ha fatti davvero. Non con i peer del tuo pitch competition, non con la startup che ha appena chiuso a valutazione unicorno.
Cerca eroi da emulare con almeno 100 milioni di revenue, preferibilmente un miliardo. Le loro storie, anche se sembrano vecchie, ti insegnano molto di più. Non stai cercando di replicare una valutazione unicorno, stai cercando di replicare un'azienda da multi-billion in revenue. Sono due bersagli completamente diversi.
Per un founder ambizioso, dice Seibel, scegliere i propri peer e scegliere chi vuoi essere è una delle cose più potenti che puoi fare. Sui round e sulla disciplina del fundraising vale lo stesso: i modelli di riferimento determinano i comportamenti, e i comportamenti determinano la cap table al momento dell'exit.
**Key takeaways**: - Il momento migliore per fare fundraising non è prima del lancio per nascondere la mancanza di traction, ma quando hai una metrica che cresce: il founder citato nel video è passato da 140 investor parlati e 2 assegni a un seed round chiuso in una settimana. - Mettere l'investor al centro come fosse un professore da impressionare è il pattern peggiore. La validazione che conta arriva dai customer, non dai VC: 80-90% del tempo dei tuoi ultimi 7 giorni dovrebbe essere su cliente e prodotto. - Raccogli solo quello che ti serve. Il denaro è più simile al cibo che all'ossigeno: troppo capitale uccide tante startup quanto troppo poco, perché toglie pressione a innovare e diluisce il founder. - Facebook e Google sono diventati Facebook e Google perché ai primi round non erano disperati: Facebook era profittevole anche come social universitario, Google aveva traction enorme da google.stanford.edu prima del primo dollaro. - Scegli con cura chi vuoi emulare. Non i peer del pitch competition o l'ultima startup a valutazione unicorno, ma aziende con 100M+ di revenue, meglio se sopra il miliardo. Si impara molto di più dai loro errori reali. **FAQ**: - Q: Quando è meglio fare fundraising secondo Y Combinator? A: Quando hai una metrica che sta crescendo. Seibel cita un founder YC che con una startup senza crescita ha parlato con 140 investor ottenendo due assegni angel, e con la startup successiva in crescita ha chiuso il seed in una settimana. Nel 97% dei casi demo, prodotto e MVP con customer reali aumentano la leva nel pitch. - Q: Perché molti founder vogliono raccogliere prima del lancio? A: Dalton Caldwell lo chiama fear-based decision making. Se nel cuore credi che il prodotto fallirà, ha senso razionale raccogliere prima che il mercato se ne accorga. È una razionalizzazione della paura, non una strategia, e porta a costruire l'azienda al contrario. - Q: Quanto tempo dovrebbe dedicare un founder early-stage al customer rispetto al fundraising? A: Seibel propone un audit settimanale: 80-90% del tempo da sveglio dovrebbe andare a parlare con customer e costruire prodotto. Se sei sotto il 20%, qualcosa nel modo in cui stai gestendo la startup non funziona. - Q: Quanto capitale dovrebbe raccogliere una startup al primo round? A: Solo quello che serve davvero. La citazione del video da Brian Chesky di Airbnb è che il denaro è cibo, non ossigeno: ti serve per sopravvivere ma troppo capitale uccide tante startup quanto troppo poco, perché toglie pressione a innovare e diluisce il founder. - Q: Cosa rende diversi i founder che mantengono il controllo della loro azienda? A: La differenza principale citata da Seibel è quanto sono stati disperati nei round lungo la storia della company. Facebook era profittevole già come social universitario, Google aveva traction da google.stanford.edu prima del primo dollaro: in entrambi i casi il primo round è arrivato con leva forte, e quella leva si è composta nei round successivi. ### YC: Gli Errori di Hiring più Comuni nelle Startup Pre-PMF URL: https://startupmentors.it/video/yc-hiring-mistakes-rookies YouTube: https://youtu.be/CUZ6PKJZvXE Channel: Y Combinator · 20 min · operations Personas: founder, operator **Perché vale**: I tre partner YC Michael Seibel, Harj Taggar e Brad Flora discutono gli errori più ricorrenti dei founder pre-PMF sull'hiring. La sintesi è netta: prima del product-market fit, assumere è quasi sempre un modo per accelerare il fallimento. **Riassunto**:Una delle conversazioni più sottovalutate sull'hiring early-stage. Tre Group Partner di Y Combinator — Michael Seibel, Harj Taggar e Brad Flora — discutono perché ripetono ai founder lo stesso consiglio settimana dopo settimana: non assumere.
Il punto di partenza è una contraddizione apparente: le top company di YC hanno migliaia di dipendenti, quindi è ovvio che bisogna assumere per costruire qualcosa di grande. Ma quando i partner suggeriscono di non assumere, la critica frequente è che YC non capisca come si scala. La realtà è più sottile. Il consiglio non vale per le grandi company già scalate: vale per la startup pre-product-market-fit, che è la condizione di quasi tutti i founder che entrano in batch.
Brad Flora apre con la prima e più diffusa: "se solo avessimo più persone, faremmo più cose". Il founder ha bisogno della feature mancante, della app Android, dell'integrazione che il cliente chiede. La logica di "aggiungo persone, accelero output" funziona in fabbrica, non in startup pre-PMF. Più persone equivalgono a più meeting, più coordinamento, più strade divergenti, meno chiarezza.
Harj Taggar aggiunge la seconda bugia: l'hiring come marker di progresso. I founder pensano che gli investor saranno più impressionati con un team più grande. Pensano che i clienti percepiranno credibilità. Diventa un KPI vanitoso, qualcosa di cui parlare alle cene con i founder amici. Il second-time founder reagisce in modo opposto al first-time: capisce che gestire 100 persone è una sofferenza, non una medaglia.
La terza è la trappola della disponibilità: "questo smart guy è disponibile in questo momento, devo prenderlo". Le grandi company come Google si possono permettere di assumere talento opportunistico. Una startup pre-PMF no: deve assumere solo per problemi che oggi sono fuoco vivo, non per problemi ipotetici futuri.
La quarta è la più pericolosa secondo Seibel: "so che avremo questo problema in futuro, tanto vale risolverlo adesso assumendo lo specialista". Sembra prudente. È invece dispendioso. Ogni startup ha 50 fuochi che fumano in qualunque momento, di cui solo 1 o 2 diventeranno incendi reali. Assumere preventivamente per ognuno dei 50 significa bruciare runway per 48 problemi che non si materializzeranno mai. Meglio combattere il fuoco quando diventa fuoco vero, anche se intellettualmente frustrante.
La sezione più contro-intuitiva del video è la timeline di hiring delle top YC company. Airbnb ha aspettato 18 mesi dopo il lancio (e 6 mesi dopo essere uscita da YC) per assumere il primo dipendente, due designer e un engineer. Stripe è partita con 8-10 persone pre-launch, poi è rimasta a 3 persone per il primo anno e mezzo. Justin.tv/Twitch ha assunto un engineer specialista in video infrastructure (preso da YouTube) solo quando il problema concreto del costo bandwidth è diventato urgente, non prima.
Il pattern è chiaro: i founder che riescono assumono tardi e assumono lentamente, almeno fino al PMF. Il volume di assunzioni è sempre back-loaded, concentrato dopo che la company ha trovato la sua macchina. Prima è quasi sempre danno.
Seibel chiude con un calcolo che fa riflettere. Assumendo che il 5-10% delle assunzioni si riveli tossica per la cultura del team (numero conservativo), e che mediamente si licenzia solo il 10% delle persone assunte (perché licenziare è doloroso e si rimanda), un team di 25 persone ha sempre qualche persona tossica nel pipeline. Con 100 persone i numeri diventano gestibili solo se si è disciplinati nel firing.
La conclusione operativa è netta: i founder con il bar più alto sul talent finiscono per assumere meno, perché trovano pochi candidati che soddisfano gli standard. Il famoso "ogni hire deve alzare il QI medio della company" è scomodo ma utile. Quando lo si applica davvero, ci si accorge che molte assunzioni quasi fatte si rivelano sotto la soglia, e si capisce che si può fare di più con meno persone.
Una delle cause principali di burnout dei founder, aggiunge Seibel, è proprio la gestione delle persone. Si pensa che avere un team grande sia energizzante. Spesso è esattamente il contrario.
La sintesi finale è una bussola in tre stati:
Il video è breve (venti minuti) ma denso di concretezza. Funziona meglio se guardato dopo aver applicato il Hiring Playbook YC sui primi engineer e AE: il primo costruisce il sistema operativo dell'hiring, questo costruisce la disciplina di quando usarlo.
**Key takeaways**: - Quasi tutti i consigli sull'hiring online sono scritti per company post-PMF. Applicarli a una startup pre-PMF accelera la morte invece che lo scaling. - Le bugie ricorrenti dei founder: 'più persone = più output', 'hiring è un marker di progresso', 'questo smart guy è disponibile, lo prendo'. - Stripe e Airbnb hanno aspettato mesi prima del primo hire post-YC: il pattern di chi ce la fa è hire late, hire slow. - Il 5-10% degli hire si rivela tossico, ma se ne licenzia solo il 10%: la matematica dice che con un team di 25 persone hai sempre qualcuno che ti rovina la vita. - Pre-PMF? Non assumere per scoprire il PMF. Trova prima il PMF, poi pensa a scalare il team. **FAQ**: - Q: Perché YC consiglia ai founder pre-PMF di non assumere? A: Perché quasi tutti i consigli sull'hiring online sono scritti per company post-PMF in fase di scaling. Applicarli a una startup pre-PMF accelera la morte invece che la crescita: più persone significano più meeting, più coordinamento, più strade divergenti, meno chiarezza. Il problema della startup pre-PMF non è output, è direzione. - Q: Quando hanno fatto il primo hire Airbnb e Stripe? A: Airbnb ha aspettato 18 mesi dopo il lancio e 6 mesi dopo essere uscita da Y Combinator per assumere i primi tre dipendenti (due designer e un engineer). Stripe è partita con 8-10 persone pre-launch ma è rimasta a 3 persone per il primo anno e mezzo. Il pattern delle top YC company è hire late, hire slow, almeno fino al product-market fit. - Q: Cos'è il rischio del 5-10% di hire tossici? A: Statisticamente il 5-10% delle assunzioni si rivela tossica per la cultura del team. Ma mediamente si licenzia solo il 10% delle persone assunte, perché licenziare è doloroso e si rimanda. La matematica: in un team di 25 persone c'è quasi sempre qualcuno che rende la vita pesante. Con 100 persone i numeri diventano gestibili solo con disciplina nel firing rapido. - Q: Quando ha senso assumere uno specialista per un problema futuro? A: Quasi mai prima del PMF. Ogni startup ha 50 fuochi che fumano in qualunque momento; solo 1 o 2 diventeranno incendi reali. Assumere preventivamente per ognuno significa bruciare runway per 48 problemi che non si materializzeranno mai. Justin.tv/Twitch ha assunto lo specialista in video infrastructure SOLO quando il costo bandwidth è diventato un problema concreto, non prima. - Q: Come capire se la startup è pre-PMF o post-PMF? A: Indicatori principali: tasso di crescita organico (settimanale e mensile), retention, NPS dei clienti, ratio referral vs acquisition pagata. Se non c'è sicurezza, probabilmente è pre-PMF. La regola di YC: non assumere per scoprire dove sei. Trova prima il PMF, poi pensa a scalare il team. Pre-PMF il problema è validare l'idea, non scalare l'esecuzione. ### Hiring Playbook YC: Come Assumere Engineer e AE in Startup URL: https://startupmentors.it/video/yc-hiring-playbook-engineers-aes YouTube: https://youtu.be/i_PjjXKNpA4 Channel: Y Combinator · 43 min · operations Personas: founder, operator **Perché vale**: Hiring nei primi anni di startup è un problema di sales, non di interview. David Paffenholz (Juicebox CEO) e Harj Taggar (YC) raccontano come trovare, contattare e chiudere i primi engineer e AE quando la tua azienda non la conosce nessuno. **Riassunto**:La maggior parte dei founder pensa che il problema dell'hiring sia l'interview. In realtà è la vendita. Il primo errore sistematico è trattare i candidati come applicanti quando dovrebbero essere trattati come prospect.
Questa sessione di Y Combinator Startup School vede David Paffenholz (co-founder e CEO di Juicebox, piattaforma di sourcing AI usata da Ramp, Cursor e Perplexity) e Harj Taggar (Group Partner YC) condividere il playbook operativo per i primi hire. Quarantatré minuti di tattica, niente teoria.
I primi 10 dipendenti definiscono cultura, velocità e traiettoria della startup. I successivi 40 amplificano il pattern. Per i primi 50 in totale ogni assunzione è una scommessa che si auto-rinforza: i futuri candidati guardano ai founding engineer e founding AE come benchmark del talent bar interno.
La parte difficile è che gli engineer di valore ricevono outreach a raffica. Lo screenshot di una casella inbox di un senior engineer mostrato nel video chiarisce il problema: cinquanta DM LinkedIn alla settimana, decine di email recruiter. Per emergere serve smettere di sembrare un recruiter generico.
Paffenholz divide il talento in tre cluster con motivazioni nette:
Il primo passo è capire verso quale pool pende il candidato. Se sta intervistando anche con Google mentre parla con te, il segnale è ambiguo: probabilmente sta ancora decidendo che tipo di azienda vuole. La conversazione deve tornare al perché lavorare in startup, non al perché lavorare nella tua startup. Solo quando la prima domanda è risolta ha senso passare alla seconda: perché proprio voi.
Le quattro leve più efficaci per chiudere su "perché noi" sono mission, equity upside, problema tecnicamente interessante, cultura del team. Ogni founder dovrebbe sapere quali due delle quattro vende meglio.
Tre canali principali, in ordine di leva crescente: referral, distribuzione del job (work at a startup, LinkedIn), sourcing proattivo. Il sourcing è quello sotto il controllo diretto del founder e produce i migliori risultati nel tempo.
Per gli AE i segnali da cercare sono concreti: President's Club, attainment quota oltre il 100%, percorsi di promozione rapidi nello stesso team (sintomo che qualcuno li ha visti performare), esperienza in startup serie A-C dove i go-to-market team scalano. Gli AE pre-seed o seed esistono ma sono rari.
Per gli engineer Paffenholz sposta l'asticella: cerca builder, non solo engineer. Contributi a progetti open source, side project che assomigliano a startup, esperienza di founder pregressa. Suggerisce anche leve creative legate al background del founder: Paffenholz è tedesco e ha targetizzato altri tedeschi nella Bay Area come prima coorte.
Sull'outreach: campagne multi-step (email + LinkedIn + eventualmente Twitter DM), automazione solo sull'email, LinkedIn manuale per rispettare i ToS della piattaforma. Il founder deve essere il sender, non un recruiter delegato. Il reply rate target è del 10-20%, ma le startup top arrivano al 40% e oltre con outreach veramente personalizzato. La differenza non è solo il template: è quanto tempo passi a leggere il profilo del candidato prima di scrivere.
Una metrica più utile del reply rate è l'interested rate: di chi risponde, quanti sono effettivamente interessati al ruolo. Se il reply rate sale ma l'interested rate resta fermo, il problema è che stai pescando attenzione, non interesse.
Il consiglio operativo è netto: ogni founder deve fare sourcing personalmente. Pianifica un blocco settimanale (Paffenholz lo fa la domenica sera), 100 email a settimana di base, target di 10 candidate call alla settimana. Se le call non arrivano a 10, il volume di outreach va alzato a 150-200 email. Niente delega della prima call ad altri founder o recruiter.
La regola da tatuarsi: vendi prima, valuta dopo. L'errore più ricorrente nelle prime call dei founder è saltare il pitch della company e passare direttamente alle domande di assessment. Il candidato lo percepisce come un processo burocratico e l'engagement crolla. La prima call dovrebbe essere quasi conversazionale, simile a un intro pitch a un investor.
Il vantaggio competitivo concreto della startup è la velocità. Big tech e growth stage impiegano settimane a coordinare un offer attraverso più livelli. La startup può chiudere un processo in 7-10 giorni, massimo due settimane. Questo va comunicato esplicitamente al candidato e usato come arma.
Quando arrivi all'offer, due tattiche concrete fanno la differenza. La prima è personalizzare la conversazione sui selling point specifici emersi nelle prime call (mission, problema tecnico, equity, cultura): no offer template generici. La seconda è coinvolgere altri founder o angel investor strategici in una call diretta con il candidato — il modo in cui Andreessen ha chiuso Brian Chesky chiamandolo costantemente.
Sul recruiter esterno la guida è chiara: ha senso solo dopo i primi multiple hire fatti dal founder. Tre opzioni in ordine di commitment crescente: contingency recruiter (paghi il 20-25% del placement, massima flessibilità), embedded recruiter (contratto a ore, predicibilità sui costi), in-house recruiter (full-time, dedicato). Sotto i 2 hire al mese in pipeline non vale la pena strutturarsi.
Taggar chiude la conversazione con la triade degli errori più ricorrenti che osserva nelle batch YC:
Il pattern di fondo è uno: il top founder in YC recluta sempre, anche quando non sta cercando attivamente. Costruisce una rete di talent nel tempo, fa coffee chat con candidati che assumerà tra dodici mesi. Il primo hire arriva spesso con sei mesi di courtship.
Nota: la presentazione completa è disponibile sul canale Y Combinator. Per il framework complementare su quando NON assumere (con Michael Seibel + Brad Flora), vedi Don't Make These Hiring Mistakes (stessa categoria, order 2).
**Key takeaways**: - I primi 10 hire definiscono cultura, velocità e traiettoria della startup: ogni assunzione successiva guarda a loro come benchmark. - Tre pool di candidati con motivazioni diverse: big tech (stabilità), growth stage (upside prevedibile), startup (impatto + ownership). Capire dove pende il candidato è il punto di partenza. - Outreach a freddo: la regola d'oro è sales-mindset, non recruiter-speak. Email personalizzate al singolo candidato producono il 40% di reply rate, contro il 10-15% degli outreach generici. - Nelle interview, vendi prima e valuta dopo. L'errore più comune dei founder è saltare il 'selling' della company e passare subito alle domande di assessment. - Il vantaggio strutturale della startup è la velocità: chiudere un offer in 7-14 giorni mentre big tech impiega settimane è leva concreta. **FAQ**: - Q: Perché i primi 10 hire di una startup contano più degli altri? A: I primi 10 dipendenti definiscono cultura, velocità e traiettoria della company. I successivi 40 amplificano il pattern impostato dai primi. Per i primi 50 in totale ogni assunzione è una scommessa auto-rinforzante: i candidati futuri guardano ai founding engineer e founding AE come benchmark del talent bar interno. Sbagliare qui costa molto più che sbagliare un hire al cinquantesimo dipendente. - Q: Come si fa outreach efficace ai primi engineer quando la startup non la conosce nessuno? A: Multi-step (email + LinkedIn + Twitter DM se hai presenza), founder come sender (mai un recruiter delegato), email automatizzata e LinkedIn manuale. La differenza tra il 10% di reply rate medio e il 40% delle startup top non è il template: è il tempo che si passa a leggere il profilo del candidato. Personalizzazione vera, non variabili dinamiche. - Q: Qual è l'errore più comune dei founder nelle prime interview? A: Saltare il selling e passare direttamente alle domande di assessment. La prima call dovrebbe essere quasi conversazionale, simile a un intro pitch a un investor: si vende la company, si racconta perché esiste, e solo dopo si capisce se il candidato è il fit. Il candidato percepisce subito quando viene trattato come una pratica e l'engagement crolla. - Q: Quando ha senso assumere un recruiter esterno invece di farlo da founder? A: Solo dopo i primi multiple hire chiusi personalmente, e quando si hanno più di 2 ruoli aperti contemporaneamente. Tre opzioni in ordine di commitment: contingency recruiter (si paga il 20-25% del placement, massima flessibilità), embedded recruiter (contratto a ore, predicibilità costi), in-house recruiter (full-time). Sotto i 2 hire al mese in pipeline non vale la pena strutturarsi. - Q: Come si chiude un candidato che sta intervistando anche con Google o Meta? A: Velocità come leva strutturale: si chiude l'offer in 7-10 giorni mentre big tech impiega settimane. Si personalizza la conversazione sui selling point emersi nelle prime call (no offer template generici). Si coinvolgono altri founder o angel investor strategici in call dirette con il candidato. La startup ha sempre svantaggio sul comp, ma vantaggio su velocità di processo, ownership e impatto: la leva è quella. ### Kevin Hale (YC): come pitchare la tua startup URL: https://startupmentors.it/video/yc-kevin-hale-pitch-startup YouTube: https://youtu.be/17XZGUX_9iM Channel: Y Combinator · 28 min · pitch-fundraising Personas: founder, investor **Perché vale**: Kevin Hale (YC) smonta il modo in cui i founder seed-stage descrivono la startup e mostra come confezionare il pitch per farsi capire in trenta secondi. Niente storytelling, niente buzzword: tre nomi concreti, struttura riproducibile, descrizione che innesca la curiosità. **Riassunto**:Kevin Hale legge migliaia di application Y Combinator ogni batch e in questa lecture spiega un punto contro-intuitivo per chi sta preparando il primo pitch deck: la maggior parte dei founder seed-stage non viene rifiutata perché ha un'idea debole, ma perché non riesce a comunicarla in modo riproducibile. Hale cita una stima interna di YC: per ogni company che invitano al colloquio, ce n'è probabilmente un'altra altrettanto valida che hanno scartato solo perché l'application non si capiva. La sua tesi è che chiarezza e concisione siano la fondazione del growth organico, e che il founder debba lavorare meno sulla narrativa e molto di più sulla struttura della frase con cui descrive la startup. Il talk è il seguito di una lecture precedente sul valutare le startup idea (problema, soluzione, insight): qui non si parla di cosa rende una idea buona, si parla di come confezionarla perché un investor la legga in dieci secondi e voglia approfondire.
Hale parte da un'osservazione che ribalta l'aspettativa diffusa. L'investor mediocre fa le pulci al pitch, cerca i punti deboli, prova a smontarlo. L'investor bravo fa il contrario: sa che servono eventi rari per costruire una company da miliardi e usa l'ottimismo per immaginare quali di quegli eventi rari possono accadere a te. Tradotto operativamente: non devi venderti, ci pensa lui. Il tuo lavoro è metterlo nelle condizioni di farlo, e per farlo serve che capisca tre cose in pochi secondi: di cosa stai parlando, se la cosa lo eccita, se vuole lavorare con il tuo team. Sono le stesse domande che YC chiede ai founder di porsi a vicenda nelle weekly group sessions, e non è un caso.
Le startup migliori crescono per passaparola, e il passaparola richiede che la persona seduta a tavola si ricordi cosa fai abbastanza bene da raccontarlo a qualcun altro. Hale tira la riga: "marketing e advertising sono la tassa che pagano le aziende che non hanno fatto qualcosa di remarkable". Per essere ricordata, l'idea deve prima essere capita, e per essere capita deve essere legibile. La metafora viene dal demo day: in sala ci sono mille investor, molti seduti dietro con la vista non più giovanissima, e una slide leggibile è quella che arriva anche a chi sta in fondo. Una idea legibile è la stessa cosa: la capisce chiunque, anche chi del tuo settore non sa nulla.
Hale elenca quattro nemici della chiarezza: ambiguità (la frase si presta a due letture), complessità (più idee intrecciate dove ne basterebbe una), mistero (jargon, pronomi vaghi, sottintesi) e ignorabilità (marketing speak, MBA speak, buzzword che l'investor scarta in automatico). L'antidoto è il registro conversazionale, quello con cui racconteresti la startup a tua madre: niente preamboli, niente nomi propri capitalizzati, niente difese preventive contro obiezioni che nessuno ha ancora sollevato.
Il test pratico che Hale propone è semplice. Chiedersi: dalla mia descrizione, l'investor riesce a "riprodurre" la mia startup nella sua testa? Vede un oggetto concreto? Per arrivarci servono tre nomi. Cosa stai costruendo (il prodotto, l'oggetto). Qual è il problema. Chi è il cliente. Senza questi tre nomi non c'è immagine mentale, e senza immagine non possono partire le domande successive che fanno scattare la curiosità.
Esempi che Hale considera vincenti:
Esempi che bocciano: "Trasformeremo la relazione tra individui e informazione" (zero nomi concreti), descrizioni narrative tipo "una volta c'era questo problema e arriva qualcuno a salvarci" (Hale deve leggere altre mille application, non ha tempo per la fiaba), descrizioni come "IT security services" o "a meritocratic decision support system" che sono talmente generiche che dieci team diversi costruirebbero dieci prodotti diversi a partire dalla stessa frase.
Il pattern "X for Y" è un'ottima scorciatoia perché eredita business model e comportamento da una company già nota. Ma funziona solo a tre condizioni precise. La X deve essere una household name, una company da miliardi che chiunque riconosce come successo (non l'azienda di nicchia di tuo zio). La Y deve volere il modello di X (deve essere chiaro perché quel segmento ha bisogno di quella struttura). E la Y deve essere un mercato grande, perché stai dicendo che sei un sottoinsieme e quel sottoinsieme deve avere abbastanza headroom per arrivare al miliardo. "Buffer for Snapchat" è l'esempio negativo che Hale porta: Buffer è una nice company, ma è una X troppo piccola per il pattern.
L'ultima sezione della lecture è sulla brevità. Hale legge mille application a batch e ammette che la sua attenzione si esaurisce. Una descrizione concisa fa due cose: comunica il prodotto e manda un secondo segnale silenzioso al lettore. Dice che hai pensato a fondo all'idea (perché solo chi ha riflettuto a lungo riesce a stringere), che sei un team efficiente con le parole e quindi probabilmente con i pensieri e le azioni, e che sai distinguere il segnale dal rumore. Hale mostra il caso di una startup che si descriveva così: "La nostra company farà dispositivi medici a basso costo e basso consumo basati su intelligenza artificiale e IoT adatti per le comunità sub-sahariane". Funziona, ma è grasso. Tolti i buzzword (artificial intelligence, IoT) che sembrano messi lì per impressionare e non aggiungono unfair advantage, e tolto un modificatore secondario (low power consumption), la versione finale diventa: "Affordable medical devices for sub-Saharan Africa". Stesso prodotto, metà delle parole, e l'investor ora ha spazio mentale per fare le domande giuste sul team, sulla traction, sull'esecuzione.
La regola finale che Hale lascia ai founder è una: lead with what, not why or how. Il "perché" e il "come" sono importanti ma vengono dopo, e arrivano da soli quando il "cosa" è abbastanza chiaro da innescare la curiosità di chi ti sta ascoltando.
**Key takeaways**: - Un buon investor non cerca buchi nel pitch, immagina il percorso che ti porta al miliardo. Il founder deve solo essere chiaro: ci pensa lui a vendersi la storia. - Una descrizione efficace contiene tre nomi: cosa stai costruendo, qual è il problema, chi è il cliente. Se mancano, l'investor non riesce a riprodurre la tua idea in testa. - L'X for Y funziona solo se X è una household company da miliardi (Airbnb, Uber, LinkedIn) e Y è un mercato grande. 'Buffer for Snapchat' non funziona: la X è troppo piccola. - La concision è un segnale secondario: dice all'investor che hai pensato a fondo al business e che sai distinguere ciò che conta da ciò che è rumore. - Niente preamboli narrativi, niente difese preventive, niente buzzword come AI o IoT messe lì per impressionare. Il guardrail di Hale: lead with what, not why or how. **FAQ**: - Q: Devo descrivere subito la mia startup come 'X for Y' nel pitch? A: Solo se la X è una household name da miliardi e la Y è un mercato grande. Hale è chiaro: 'Buffer for Snapchat' non funziona perché la X è troppo piccola per innescare l'aggancio mentale. Se non hai una X riconoscibile da chiunque, meglio una descrizione diretta con i tre nomi (cosa, problema, cliente). - Q: Quanto deve essere lunga la descrizione della company nell'application YC? A: Hale non dà un limite di parole, ma il benchmark è la one-liner di Airbnb e Dropbox: una frase, soggetto-verbo-oggetto, riproducibile. La concision è un segnale secondario di qualità del founder: dice all'investor che hai pensato a fondo all'idea e sai distinguere ciò che conta dal rumore. - Q: Posso menzionare AI, machine learning o altre tecnologie nella descrizione? A: Hale lo sconsiglia se il termine è usato come buzzword. Nel caso dei dispositivi medici sub-sahariani, ha tagliato 'AI e IoT' perché non era l'unfair advantage del prodotto ma una decorazione tecnologica. Cita la tecnologia solo se è il vero secret weapon che spiega perché la company crescerà più veloce delle altre. - Q: Cosa fare se la mia startup è davvero complessa e una frase non basta? A: Hale dice che ogni founder pensa la propria company sia complessa, ma nessun investor parte dall'idea che un business sia 'semplice'. Il rischio non è essere riduttivi: il rischio è che l'investor non capisca e passi all'application successiva. La descrizione concisa serve solo a creare la fondazione per la curiosità, da lì in poi puoi approfondire tutto. - Q: Cosa intende Hale con 'non ti serve vendermi la company'? A: Un investor seed-stage bravo non cerca buchi: usa l'ottimismo per immaginare il percorso raro che ti porta al miliardo, e poi te lo racconta. Il founder deve solo essere chiaro su cosa fa, qual è il problema e chi è il cliente. La narrativa di crescita la costruisce l'investor da solo, se gli dai i tre nomi giusti su cui ragionare. ### Michael Seibel (YC): come pianificare un MVP davvero minimo URL: https://startupmentors.it/video/yc-plan-mvp-seibel YouTube: https://youtu.be/1hHMwLxN6EM Channel: Y Combinator · 14 min · mvp-build Personas: founder, builder **Perché vale**: Se stai per scrivere la prima riga di codice del tuo MVP, fermati 14 minuti. Michael Seibel (CEO di Y Combinator) smonta il mito del lancio perfetto e ti mostra perché Airbnb, Twitch e Stripe sono partiti con prodotti oggi imbarazzanti. Pratico, diretto, senza fuffa. **Riassunto**:Michael Seibel ha guidato Y Combinator come CEO e prima ha fondato due startup passate dall'acceleratore (nel 2007 e nel 2012). In questo intervento di quattordici minuti smonta il concetto di MVP riportandolo all'essenziale: la prima cosa che puoi mettere in mano a un piccolo gruppo di utenti per capire se riesci a portare loro un minimo di valore. Niente di più. Il messaggio centrale è uno solo, ripetuto in cinque modi diversi: lancia qualcosa di brutto, lancialo presto. Seibel apre con una constatazione tipica di YC: i founder vengono ripresi quando usano gergo da startup, eppure MVP è proprio uno di quei termini gonfiati. Riportarlo al significato letterale aiuta a togliere pressione e a partire prima.
Seibel sintetizza in quattro mosse cosa deve fare una startup prima del lancio: lanciare in fretta, ottenere i primi customer (anche pochissimi), parlare con loro dopo il lancio, iterare. Il punto critico è il secondo: la maggior parte dei founder abbandona il percorso prima che un singolo utente abbia interagito con il prodotto. Il terzo nasconde un'altra trappola classica, quella di considerare inutile il feedback su una versione iniziale "tanto non è il prodotto vero". Seibel ribalta la prospettiva: la versione completa che hai in testa va tenuta flessibile, perché potrebbe scoprirsi che non è affatto quello che gli utenti vogliono. La sua formula: hold the problem tightly, hold the customer tightly, hold the solution loosely.
Qui Seibel introduce una distinzione che vale tutto il video. Quando un founder costruisce qualcosa, ci si affeziona. Se lo strumento non funziona per gli utenti scelti, la tentazione è chiedersi: "Quali altri problemi potrebbe risolvere?". L'analogia è quella del cacciavite che non avvita: invece di aggiustarlo, ci si convince che potrebbe servire a cucinare o a pulire. Il problema è che il customer originale (il meccanico) ha ancora bisogno di avvitare. Iterare significa tenere fermo il problema e il customer, e fixare lo strumento.
Quasi tutte le startup dovrebbero costruire un MVP molto lean: settimane, non mesi. A volte basta una landing page e uno spreadsheet. Funzionalità ridotte all'osso, focus sui primi customer e sui loro problemi più urgenti, tutto il resto rimandato. Seibel porta tre esempi che oggi valgono miliardi di dollari ma che al day one erano evidentemente incompleti: Airbnb senza pagamenti integrati e senza vista mappa, con Nate che programmava part-time; Twitch (allora Justin TV) come reality show con un solo canale, video a bassissima risoluzione, zero videogame; Stripe (allora slashdev/payments) senza accordi bancari e con i founder che andavano fisicamente in ufficio dai customer per integrare il prodotto, sia per disperazione sia per scoprire bug prima degli utenti. Esiste anche il caso dell'heavy MVP, in settori regolati come insurance, banking, biotech o hard tech. Anche lì però il punto di partenza può essere un sito che spieghi cosa fai, costruito in giorni e non in settimane.
Seibel chiude con quattro accorgimenti operativi. Time-box dello spec: decidi quante settimane hai e tieni dentro solo ciò che puoi costruire in quel tempo. Scrivi lo spec nero su bianco, perché senza documento ogni chiacchierata con un utente o un investor sposta il piano e il piano da tre settimane diventa da tre mesi senza che te ne accorga. Taglia lo spec a metà sprint: se ti rendi conto che non ce la fai, taglia prima le cose non importanti, poi anche quelle importanti. L'obiettivo è uscire con qualcosa: una volta che il prodotto è nel mondo, il momentum si genera da solo. E infine: non innamorarti del tuo MVP. Nessuno dei tre prodotti citati assomiglia a quello che è diventato. L'MVP è il primo passo, non la destinazione.
**Key takeaways**: - Lancia qualcosa di brutto, ma lancialo subito: il vero rischio non è uscire con un prodotto incompleto, è non uscire mai. - Tieni stretto il problema e il customer, tieni lasco lo strumento. Se non risolve il problema, non cambiare il problema: aggiusta lo strumento. - Time-box dello scope: decidi prima quante settimane hai (idealmente 3) e tieni dentro lo spec solo ciò che puoi costruire in quel tempo. - Scrivi lo spec nero su bianco. Senza un documento di riferimento, ogni conversazione con un utente o un investor sposta il piano e nessuno se ne accorge. - Iterare non è pivotare: continua a migliorare la soluzione finché non risolve davvero il problema dei tuoi primi customer, invece di cercare nuovi problemi che la tua soluzione potrebbe risolvere. **FAQ**: - Q: Quanto deve durare la costruzione di un MVP secondo Michael Seibel? A: Settimane, non mesi. Seibel suggerisce di ragionare con sprint da circa 3 settimane: tutto cio' che non rientra in quel time-box va escluso dallo spec iniziale. Per gli heavy MVP (settori regolati, hard tech, biotech) il primo passo puo' essere un sito esplicativo costruito in giorni. - Q: Qual è la differenza tra iterare e pivotare in un MVP? A: Iterare significa tenere fermi il problema e il customer e migliorare la soluzione finché non funziona. Pivotare è cambiare problema o tipologia di customer. L'errore comune è affezionarsi alla soluzione: quando non funziona, cercare altri problemi che possa risolvere invece di aggiustarla. - Q: Come si trovano i primi utenti per testare un MVP? A: Seibel risponde che la domanda stessa è un campanello d'allarme. Se hai scelto di risolvere un problema reale, i primi utenti sono le persone che sai già avere quel problema. Se sei tu stesso il customer, è ancora più semplice. Se non sai chi è il tuo utente, è il caso di fermarsi e ridiscutere il problema. - Q: Bisogna preparare un lancio in grande stile per il proprio MVP? A: No. Seibel distingue tra il lancio inteso come 'mettere il prodotto in mano ai primi customer' e il press launch (articoli, buzz, copertura mediatica). Il primo va anticipato il più possibile, il secondo va rinviato. Pochi ricordano il giorno in cui Google, Facebook o Twitter hanno lanciato: i lanci da copertina non sono così decisivi come sembrano. - Q: Cosa significa innamorarsi del proprio MVP e perché è un problema? A: Significa attaccarsi alla visione mentale del prodotto perfetto. Seibel ricorda che nessuno dei prodotti che ha mostrato (Airbnb, Twitch, Stripe) somigliava al day one a quello che è diventato. L'MVP serve a iniziare a imparare dagli utenti reali, non è la destinazione: meglio considerarlo come un tema scritto in prima elementare e non come l'opera della vita. ### How To Build A Tech Startup With No Technical Skills URL: https://startupmentors.it/video/yc-tech-startup-no-skills YouTube: https://youtu.be/ZpKu2wvquWg Channel: Y Combinator · 15 min · founder-skills Personas: founder **Perché vale**: Founder business-side che vuole lanciare una software startup senza tech co-founder? Dalton Caldwell e Michael Seibel (YC) spiegano perché fallisce e qual è la sola vera skill che conta: saper reclutare il miglior tecnico che conosci. **Riassunto**:Dalton Caldwell e Michael Seibel guidano questo episodio di Dalton Plus Michael, una delle serie più dirette di Y Combinator. Il titolo del video promette di mostrare come costruire una tech startup senza skill tecniche, ma il messaggio è l'opposto e arriva nei primi trenta secondi: se la tua azienda è software, non puoi farlo. Quello di cui hai davvero bisogno — e che pochi business founder coltivano davvero — è la capacità di reclutare un tech co-founder eccezionale. Tutto il resto del video smonta gli alibi più comuni di chi prova a evitare questa conversazione.
Caldwell e Seibel raccontano che quando incontrano founder aspiranti a conferenze, eventi o per strada, una delle frasi d'apertura più ricorrenti è: "sono un bravo business guy con un'ottima idea, mi serve un tech co-founder, dove lo trovo?". Subito dopo, però, arriva la deriva tipica: "non riesco a trovarlo, quindi vado avanti da solo, assumo un dev shop, prendo qualche freelance". I due la chiamano fuga travestita da spirito imprenditoriale. Sembra resilienza, ma è una scorciatoia che alza la probabilità di fallimento in modo drastico. Seibel cita la sua esperienza diretta a Justin.tv e Twitch: era l'unico non tecnico in un team di quattro fondatori e, senza gli altri tre, niente di quello che è successo dopo sarebbe accaduto. Le idee, ricorda, sono a buon mercato. A fare la differenza è chi le costruisce.
Un'obiezione che YC sente spesso: "non stiamo costruendo una software company in senso stretto, è un marketplace, basta una copia di un prodotto esistente con un piccolo twist". Caldwell ammette che è difficile vincere il dibattito teorico, ma i fatti sono chiari. DoorDash, Airbnb e tutte le aziende vincenti del portfolio YC sono vissute o morte sulla loro speed of shipping. Se avessero comprato software white-label o pagato un dev shop estero per modificare un sito a cinquecento dollari l'ora, oggi non esisterebbero. Il punto non è solo la qualità del codice. È che nessuno fuori dal team fonderà un'azienda con il livello di cura, urgenza e pelle in gioco di un co-founder. Affidarsi a un esterno significa pagare tariffe alte per cambi marginali e non capire nemmeno cosa stai comprando.
Seibel aggiunge un'analogia che colpisce. Nello sport, se sei alto un metro e sessanta, non corri e non salti, nessuno ti dice seriamente che puoi sfondare in NBA. Nelle tech startup, invece, l'equivalente succede continuamente: founder business-side senza un tecnico che provano a competere con team che hanno top engineer dentro. Il risultato è prevedibile.
Qui c'è il cuore del video. Il miglior business founder è quello che riesce a portare a bordo un tech co-founder straordinario. Non è il CV, non sono gli anni in azienda, non è il network di executive con cui hai bevuto. È la capacità di reclutare. Caldwell e Seibel parlano dell'intersezione tra due insiemi: chi sa fare business e chi sa attrarre grandi tecnici. Le persone in entrambi gli insiemi sono pochissime, e proprio per questo chi ci sta riceve opportunità sproporzionate. È, dicono, un golden ticket alla Willy Wonka.
L'errore più comune è proprio non provarci. Chi si dichiara non tecnico spesso si squalifica da solo, costruisce barriere immaginarie e negozia contro sé stesso prima ancora di avere una conversazione. Si convince che il tecnico bravo non accetterà mai, che è troppo pagato, che è impossibile. E così si butta su un'alternativa peggiore.
Seibel propone un esercizio molto concreto. Visualizza la persona più brava con cui hai mai lavorato, il tecnico che tutti riconoscono come il migliore — sia in università sia in azienda. L'hai in mente? Bene: chiedigli di fondare un'azienda con te. La maggior parte dei founder risponde con un automatico "no, non accetterebbe mai". Ma alla domanda successiva — "gliel'hai chiesto?" — la risposta è quasi sempre no. È lì che la maggior parte delle storie si chiude prima di iniziare.
Anche quando si prova a parlarne, l'errore tipico è pitchare l'idea. "Ho un'idea geniale, vuoi venire a costruirla per me?". Caldwell è netto: nessun grande tecnico vuole essere il braccio operativo del brief di qualcun altro. Quello che funziona è chiedersi se quella persona ha idee proprie, e proporre di trovare insieme cosa costruire da co-owner. Quello che pitchi non è un prodotto, è un'avventura. E le avventure sono rare. Quasi nessuno ne ha sei diverse sul tavolo. Seibel racconta che quando il suo co-founder Justin Kan gli propose di lanciare quello che sarebbe diventato Justin.tv — un reality show in cui lui stesso si filmava ventiquattr'ore su ventiquattro — quello che vendeva non era l'idea, era l'ignoto. È così che ha messo insieme un team che è poi diventato Twitch.
Se l'esperimento mentale fallisce perché nel tuo network non c'è nessun tecnico forte, la risposta dei due fondatori è scomoda ma onesta: non lanciare l'azienda adesso. Vai a lavorare in una startup. Cambia le persone che frequenti. Costruisci un network in cui i grandi tecnici esistono e ti vedono lavorare. Quel passo di lato apparente è spesso la rotta più rapida verso una startup con probabilità di successo serie. La tentazione opposta — partire subito, da soli, perché "non posso fermarmi" — è quasi sempre una via più lenta, mascherata da urgenza.
C'è un ultimo punto che Caldwell sottolinea. Se parti con un team di soli business people che valutano ingegneri, il primo ingegnere che assumerai sarà sotto la media. E quello assumerà a sua volta sotto di sé. La cattiva qualità tecnica si compone, esattamente come quella buona. Per questo il momento in cui scegli il primo tecnico è uno dei più importanti nella vita dell'azienda.
Il messaggio finale del video è positivo, anche se duro. C'è un pattern chiaro tra i grandi business founder che YC ha visto passare: sono recruiter eccezionali. Si fanno la domanda "chi è la persona più brava al mondo per questa cosa?" e poi trovano il modo di portarla con sé. Caldwell la chiama bending the universe to your will. Se vuoi i loro risultati, devi tenere il loro standard.
**Key takeaways**: - Se la tua startup è software, costruirla senza un tech co-founder è come voler andare sulla luna senza nessuno che conosca la fisica: non sei nemmeno nello stadio. Smetti di considerarlo un dettaglio risolvibile dopo. - L'unica skill che distingue davvero un grande business founder è una: reclutare un tech co-founder eccezionale. Non il CV, non gli anni in azienda, non le idee — la capacità di portare a bordo il miglior ingegnere che conosci. - Dev shop, freelance pagati a ore o ingegneri white-label hanno probabilità vicine allo zero di portarti a un'azienda funzionante. Speed of shipping è ciò che ha tenuto in vita DoorDash, Airbnb e simili nei primi mesi. - Visualizza il miglior ingegnere con cui hai mai lavorato (università o lavoro) e prova davvero a chiedergli di fondare un'azienda con te. La maggior parte dei founder business-side non lo fa mai — si auto-squalifica prima ancora di provarci. - Non vendere la tua idea: vendi l'avventura. Un grande tecnico non vuole essere il braccio operativo del tuo brief, vuole un partner con cui costruire qualcosa insieme. Ridiscuti l'idea con lui da co-owner, non da capo. **FAQ**: - Q: Posso lanciare la mia startup senza un tech co-founder e cercarlo dopo? A: Caldwell e Seibel sono espliciti: se il prodotto è software, è la strada più rapida per fallire. Senza un tecnico co-fondatore la speed of shipping crolla, le decisioni di prodotto si appiattiscono, il primo ingegnere assunto sarà sotto la media e i successivi peggiori. Meglio rimandare il lancio e investire energia nel reclutarlo, anche se richiede mesi. - Q: Un dev shop o freelance esterni possono sostituire un tech co-founder? A: No, e i fatti del portfolio YC lo confermano. DoorDash, Airbnb e altre aziende vincenti hanno costruito tutto in casa nei primi mesi. Un dev shop pagato a ore non avrà la cura, l'urgenza o la pelle in gioco di un co-founder. Servono per task isolati e ben specificati, non per il core di una software company. - Q: Come faccio a convincere un grande ingegnere a fondare con me se non ha mai sentito parlare di me? A: Seibel suggerisce un esperimento: visualizza il miglior tecnico con cui hai mai lavorato (università o lavoro) e parlagli davvero. La maggior parte dei founder non lo fa mai. Quando parli, non pitchare la tua idea: chiedi se ha idee sue e proponi di costruirne una insieme da co-owner. Vendi l'avventura, non un brief. - Q: Cosa faccio se davvero nel mio network non c'è nessun tecnico forte? A: La risposta dei due YC è scomoda: non lanciare l'azienda adesso. Vai a lavorare in una startup, cambia le persone che frequenti, costruisci un network dove i grandi tecnici esistono e ti vedono in azione. Quel passo di lato apparente è spesso la rotta più rapida verso una startup con probabilità di successo reali. - Q: Sono già un CEO con un po' di skill tecnica. Mi serve davvero un tech co-founder? A: Sì. Seibel racconta di essere stato lui stesso un CEO tecnico e di aver beneficiato comunque di avere un tech co-founder accanto. Anche se cavi da solo le prime righe di codice, avere qualcuno che si gioca tutto come te sul lato ingegneristico cambia la qualità delle decisioni di prodotto e la velocità con cui itera il team. --- ## BANDI ATTIVI ### Bando Impresa Digitale Toscana URL: https://startupmentors.it/bandi/bando-impresa-digitale-toscana Sito ufficiale: https://www.regione.toscana.it/-/servizi-per-l-innovazione-bando-impresa-digitale Ente: Regione Toscana · Tipo: Contributo fondo perduto transizione digitale Regione: Toscana Importo max: Contributo variabile (verifica bando) Scadenza: 2026-12-31T00:00:00.000Z Status: expired Contributo fondo perduto per micro-PMI toscane su transizione digitale e adozione di tecnologie avanzate (manifatturiero, turismo, commercio). **Chi può applicare**: - Micro, piccola o media impresa con sede operativa in Toscana - Settore: manifatturiero, turismo, commercio o servizi correlati - Progetto di transizione digitale o adozione tecnologie avanzate (cloud, AI, IoT, e-commerce) - Cofinanziamento privato richiesto secondo intensità di aiuto **Come applicare**: 1. Verifica criteri sul portale Regione Toscana 2. Predisposizione progetto digitalizzazione + preventivi fornitori 3. Domanda telematica entro deadline 4. Valutazione e graduatoria ### Bando Innovazione Lombardia 2026 URL: https://startupmentors.it/bandi/bando-innovazione-lombardia-2026 Sito ufficiale: https://www.bandi.regione.lombardia.it/ Ente: Regione Lombardia · Tipo: Contributo fondo perduto progetti R&S Regione: Lombardia Importo max: Fino a €100K Scadenza: 2026-07-15T00:00:00.000Z Status: closing_soon Contributo a fondo perduto fino a €100K per progetti di innovazione tecnologica, R&S e digitalizzazione di startup e PMI lombarde. **Chi può applicare**: - Startup innovativa o PMI con sede operativa in Lombardia - Iscrizione al Registro Imprese italiano - Progetto di innovazione tecnologica con TRL 4+ - Cofinanziamento privato come richiesto da bando **Come applicare**: 1. Verifica eligibilità sul portale bandi Regione Lombardia 2. Predisposizione progetto innovazione + business plan 3. Domanda telematica entro deadline 4. Valutazione tecnica + graduatoria ### Bando Startup Lazio 2026 URL: https://startupmentors.it/bandi/bando-startup-lazio-2026 Sito ufficiale: https://www.lazioinnova.it/bandi Ente: Regione Lazio · Tipo: Contributo fondo perduto startup innovative Regione: Lazio Importo max: Fino a €150K Scadenza: 2026-08-31T00:00:00.000Z Status: open Contributo a fondo perduto fino €150K per startup innovative laziali in fase early-stage. Deadline 31 agosto 2026. **Chi può applicare**: - Startup innovativa iscritta alla sezione speciale del Registro Imprese - Sede operativa in Regione Lazio - Costituita da meno di 60 mesi - Progetto coerente con focus tecnologico/innovativo **Come applicare**: 1. Verifica requisiti sul portale Lazio Innova 2. Compilazione progetto e business plan 3. Domanda telematica entro deadline 4. Valutazione + graduatoria ### Bergamo Tecnologica 2026 URL: https://startupmentors.it/bandi/bergamo-tecnologica-2026 Sito ufficiale: https://www.bg.camcom.it/ Ente: Camera di Commercio di Bergamo · Tipo: Voucher digitalizzazione PMI Regione: Lombardia Importo max: Fino a €15K Scadenza: 2026-08-31T00:00:00.000Z Status: open Voucher CCIAA Bergamo fino €15K per progetti di digitalizzazione e adozione tecnologie 4.0 da PMI bergamasche. **Chi può applicare**: - Micro, piccola o media impresa con sede operativa in provincia di Bergamo - Iscrizione e DURC regolare - Progetto di digitalizzazione (software, AI, cloud, cybersecurity, e-commerce) - Spese ammissibili sostenute nel periodo del bando **Come applicare**: 1. Identificazione fornitore qualificato (PID — Punto Impresa Digitale) 2. Predisposizione progetto digitalizzazione 3. Domanda telematica su portale CCIAA Bergamo 4. Erogazione voucher a rendicontazione ### Credito d'imposta incubatori e acceleratori certificati URL: https://startupmentors.it/bandi/credito-imposta-incubatori-acceleratori Sito ufficiale: https://www.mimit.gov.it/it/notizie-stampa/incentivi-credito-dimposta-dell8-per-incubatori-e-acceleratori-certificati Ente: MIMIT · Tipo: Credito d'imposta 8% Regione: Nazionale Importo max: Credito d'imposta 8% sull'investimento Scadenza: 2099-12-31T00:00:00.000Z Status: open Credito d'imposta 8% per incubatori e acceleratori certificati che investono nel capitale di startup innovative (diretto o tramite OICR). **Chi può applicare**: - Soggetto certificato come incubatore o acceleratore (registro MIMIT) - Investimento nel capitale di rischio di startup innovative iscritte alla sezione speciale - Investimento diretto o per il tramite di OICR / società che investono prevalentemente in startup innovative - Mantenimento dell'investimento per il periodo minimo previsto dal decreto **Come applicare**: 1. Verifica iscrizione registro MIMIT acceleratori/incubatori certificati 2. Realizzazione investimento in capitale startup innovativa 3. Compilazione domanda telematica MIMIT a partire dal 30 marzo 2026 4. Documentazione dell'investimento e calcolo credito d'imposta 8% ### Detrazione IRPEF 50% investimenti in startup innovative URL: https://startupmentors.it/bandi/detrazione-irpef-startup-50 Sito ufficiale: https://www.mimit.gov.it/it/impresa/competitivita-e-nuove-imprese/start-up-innovative/incentivi-de-minimis Ente: MIMIT · Tipo: Detrazione IRPEF 50% (regime de minimis) Regione: Nazionale Importo max: Investimento max €100K (€300K per PMI), detrazione 50% Scadenza: 2099-12-31T00:00:00.000Z Status: open Detrazione IRPEF 50% sugli investimenti in startup innovative (max €100K) e PMI innovative (max €300K) per persone fisiche. **Chi può applicare**: - Investitore: persona fisica soggetta a IRPEF in Italia - Investimento in capitale di rischio di startup innovativa o PMI innovativa iscritta alla sezione speciale - Mantenimento della partecipazione per almeno 3 anni - Importo massimo agevolabile: €100K/anno per startup, €300K per PMI innovative **Come applicare**: 1. Investimento sottoscrivendo aumento capitale o equity round 2. Conservazione documentazione (delibera, bonifico, visura) 3. Inserimento detrazione in dichiarazione redditi anno successivo (modello Redditi PF) ### EIC Accelerator 2026 URL: https://startupmentors.it/bandi/eic-accelerator-2026 Sito ufficiale: https://eic.ec.europa.eu/eic-funding-opportunities/eic-accelerator_en Ente: European Innovation Council · Tipo: Grant fino €2.5M + equity fino €15M Regione: Europa Importo max: Fino €17.5M (€2.5M grant + €15M equity) Scadenza: 2026-11-04T00:00:00.000Z Status: open Fino a €17.5M (€2.5M grant + €15M equity) per startup deeptech europee con tecnologie a TRL 6-8 in fase di scaling. **Chi può applicare**: - Startup o PMI con sede in uno Stato Membro UE o Paese associato a Horizon Europe - Tecnologia a livello TRL 6-8 (validata in ambiente operativo) - Mercato globale e potenziale di scaling rapido - Team con competenze tecniche e business per l'esecuzione - Innovazione di rottura (deep tech preferito: AI, biotech, climate, semiconductor, robotics) **Come applicare**: 1. Step 1: short application sul portale Funding & Tenders (~5 pagine + video pitch 3 min) 2. Step 2: full application su invito (~30-50 pagine + business plan dettagliato) 3. Step 3: pitch day di fronte alla giuria EIC (jury panel di investor + esperti) 4. Decisione finale e negotiation grant agreement / equity term sheet **Tip pratici (curatela SMI)**: - Tasso di successo storico ~5%. Investire tempo nel video pitch — è il filtro principale Step 1. - Le cutoff date 2026 sono multiple (4 marzo, 6 maggio, 8 luglio, 2 settembre, 4 novembre): scegli quella che ti dà tempo per preparare un dossier eccellente. ### EIC Pathfinder Open 2026 URL: https://startupmentors.it/bandi/eic-pathfinder-open-2026 Sito ufficiale: https://eic.ec.europa.eu/eic-funding-opportunities/eic-pathfinder/eic-pathfinder-open-0_en Ente: European Innovation Council · Tipo: Grant ricerca early-stage Regione: Europa Importo max: Grant fino €4M per consorzio (budget totale €166M) Scadenza: 2026-10-08T00:00:00.000Z Status: open Grant fino €4M per consorzi che sviluppano tecnologie deep tech early-stage (TRL 1-4), in qualsiasi ambito scientifico. **Chi può applicare**: - Consorzio di almeno 3 entità giuridiche da 3 diversi Stati Membri UE o Paesi associati - Progetto di ricerca cutting-edge con potenziale disruption - Livello tecnologico TRL 1-4 (ricerca fondamentale o proof of concept) - Coerenza con priorità Horizon Europe (deep tech, scienze emergenti) **Come applicare**: 1. Identificazione partner di consorzio (università, centri ricerca, deep tech startup) 2. Predisposizione proposal Horizon Europe (template Funding & Tenders) 3. Submission entro deadline annuale 4. Valutazione peer-review da esperti esterni **Tip pratici (curatela SMI)**: - Tasso successo molto basso (3-5%). Investire 6+ mesi in costruzione proposal. - Adatto principalmente a builder con anchor accademico o spin-off universitario; founder business-only difficilmente eligibili senza partner ricerca. ### EIC STEP Scale Up 2026 URL: https://startupmentors.it/bandi/eic-step-scaleup-2026 Sito ufficiale: https://eic.ec.europa.eu/news/eight-european-startups-set-receive-scale-funding-eic-under-step-scale-scheme-2026-04-27_en Ente: European Innovation Council · Tipo: Equity investment per scale-up deep tech Regione: Europa Importo max: Investimento equity €30M+ (catalizza round €50M+) Scadenza: 2026-11-25T00:00:00.000Z Status: open Investimento equity da €30M (catalizza round €50M+) per startup deep tech UE in fase di scale-up con tecnologie strategiche. **Chi può applicare**: - Startup o scale-up con sede UE o Paese associato Horizon Europe - Tecnologia strategica (digital, clean tech / net-zero, biotech) - Round di finanziamento previsto >€50M con commitments di altri investitori - Tecnologia matura (TRL 8-9) e ricavi documentati - Capacità di crescita su scala globale **Come applicare**: 1. Pre-screening EIC con expression of interest 2. Submission proposal completa via Funding & Tenders 3. Due diligence e term sheet negotiation 4. Sottoscrizione equity tramite EIC Fund (gestito da EIB) **Tip pratici (curatela SMI)**: - Strumento per scale-up già validate, non per early-stage. Verifica revenue traction prima di applicare. - Cutoff 2026: 6 maggio, 9 settembre, 25 novembre. Budget complessivo €300M. ### Fondo di Garanzia PMI URL: https://startupmentors.it/bandi/fondo-garanzia-pmi Sito ufficiale: https://www.fondidigaranzia.it/imprese-innovative/ Ente: Mediocredito Centrale · Tipo: Garanzia pubblica su finanziamento bancario Regione: Nazionale Importo max: Garanzia fino all'80% del finanziamento (max €5M per impresa) Scadenza: 2099-12-31T00:00:00.000Z Status: open Garanzia pubblica fino all'80% sui prestiti bancari per startup innovative, senza richiesta di garanzie reali da parte dei founder. **Chi può applicare**: - Startup innovativa o PMI iscritta al Registro Imprese italiano - Settore ammesso (escluse attività finanziarie e immobiliari) - Finanziamento bancario richiesto a banca convenzionata - Per startup innovative: accesso semplificato senza valutazione del merito creditizio standard **Come applicare**: 1. Identificazione banca convenzionata Fondo di Garanzia 2. Richiesta finanziamento alla banca 3. Banca attiva contestualmente la garanzia Mediocredito Centrale 4. Erogazione finanziamento con garanzia attiva ### Fondo Starter Emilia-Romagna URL: https://startupmentors.it/bandi/fondo-starter-emilia-romagna Sito ufficiale: https://imprese.regione.emilia-romagna.it/ Ente: Regione Emilia-Romagna · Tipo: Finanziamento agevolato (75% pubblico + 25% bancario) Regione: Emilia-Romagna Importo max: Finanziamento agevolato (75-80% provvista pubblica) Scadenza: 2026-05-29T00:00:00.000Z Status: closing_soon Finanziamento agevolato a tasso ridotto per nuove imprese in Emilia-Romagna (75% provvista pubblica, 80% per imprese femminili). **Chi può applicare**: - Nuova impresa con sede operativa in Emilia-Romagna - Iscrizione al Registro Imprese italiano - Progetto di investimento ammissibile - Convenzione con Istituto di credito convenzionato **Come applicare**: 1. Identificazione Istituto di credito convenzionato Fondo Starter 2. Predisposizione progetto + business plan 3. Domanda telematica entro deadline 29 maggio 2026 4. Istruttoria congiunta Regione + banca ### Fondo Veneto Competitività Startup URL: https://startupmentors.it/bandi/fondo-veneto-competitivita-startup Sito ufficiale: https://www.venetosviluppo.it/ Ente: Regione Veneto / Veneto Sviluppo · Tipo: Finanziamento agevolato investimenti Regione: Veneto Importo max: Finanziamento €20K-€150K Scadenza: 2099-12-31T00:00:00.000Z Status: open Finanziamento agevolato €20K-€150K per supportare investimenti di autoimprenditorialità e consolidamento di nuove imprese venete. **Chi può applicare**: - Nuova impresa con sede operativa in Regione Veneto - Iscrizione al Registro Imprese italiano - Programma di investimento documentato - DURC regolare **Come applicare**: 1. Verifica eligibilità sul portale Veneto Sviluppo 2. Predisposizione programma di investimento 3. Domanda telematica (sportello continuativo a esaurimento) 4. Istruttoria e delibera **Tip pratici (curatela SMI)**: - Sportello continuativo a esaurimento — non aspettare scadenze. ### Iperammortamento 2026-2028 URL: https://startupmentors.it/bandi/iperammortamento-2026-2028 Sito ufficiale: https://www.mimit.gov.it/it/incentivi/credito-dimposta-per-investimenti-in-beni-strumentali Ente: Agenzia delle Entrate / MEF · Tipo: Credito d'imposta 20-50% beni strumentali 4.0 Regione: Nazionale Importo max: Credito d'imposta 20-50% sull'investimento Scadenza: 2028-12-31T00:00:00.000Z Status: open Credito d'imposta dal 20% al 50% per investimenti in beni strumentali 4.0 (hardware, software, AI, automation). Sostituisce Transizione 4.0 e 5.0 fino al 2028. **Chi può applicare**: - Impresa italiana iscritta al Registro Imprese - Investimento in beni strumentali nuovi rientranti nei codici Allegato A o B (Industria 4.0) - Interconnessione del bene al sistema aziendale di gestione - Perizia tecnica asseverata per beni con valore unitario superiore alla soglia **Come applicare**: 1. Identificazione beni 4.0 in base alla classificazione MIMIT (Allegato A/B) 2. Acquisto e installazione del bene 3. Perizia tecnica per beni sopra soglia di valore 4. Calcolo credito d'imposta in dichiarazione + utilizzo F24 in compensazione ### Bando Lazio Innova URL: https://startupmentors.it/bandi/lazio-innova Sito ufficiale: https://www.lazioinnova.it/bandi Ente: Regione Lazio · Tipo: Contributo a fondo perduto Regione: Lazio Importo max: €500.000 Scadenza: 2026-06-30T00:00:00.000Z Status: open Contributo a fondo perduto fino a €500K per startup innovative con sede operativa nel Lazio. **Chi può applicare**: - Sede operativa in Regione Lazio - Startup innovativa o PMI innovativa iscritta al Registro Imprese - Progetto R&S con TRL 4-7 - Co-finanziamento privato minimo 30% **Come applicare**: 1. Pre-iscrizione su portale Lazio Innova 2. Compilazione progetto R&S con format ufficiale 3. Allegare bilanci ultimi 2 anni 4. Submission firma digitale **Tip pratici (curatela SMI)**: - I progetti R&S devono avere milestone trimestrali misurabili. - TRL inferiore a 4 viene scartato automaticamente — verificare prima il livello. ### Lazio Pre-Seed Plus URL: https://startupmentors.it/bandi/lazio-pre-seed-plus Sito ufficiale: https://www.lazioinnova.it/bandi/ Ente: Regione Lazio · Tipo: Contributo fondo perduto matching capitale soci Regione: Lazio Importo max: €60K standard / €100K spin-off ricerca Scadenza: 2099-12-31T00:00:00.000Z Status: open Contributo fondo perduto fino al 100% del capitale sociale (max €60K standard, €100K spin-off ricerca) per startup innovative laziali. **Chi può applicare**: - Startup innovativa con sede operativa in Lazio - Capitale sociale versato dai soci (min/max secondo bando) - Per spin-off: provenienza da università o ente di ricerca - Iscrizione (anche pre-iscrizione) sezione speciale Registro Imprese **Come applicare**: 1. Predisposizione progetto imprenditoriale ad alta intensità di conoscenza 2. Versamento capitale sociale dai soci 3. Domanda telematica su Lazio Innova (sportello dal 19 marzo 2026) 4. Valutazione + erogazione contributo **Tip pratici (curatela SMI)**: - Sportello a esaurimento fondi: domande dal 19 marzo 2026 fino a esaurimento. ### Bando MATCHIN Regione Piemonte URL: https://startupmentors.it/bandi/matchin-piemonte Sito ufficiale: https://www.regione.piemonte.it/web/temi/sviluppo/bando-matchin-mobilizing-advanced-talents-for-competence-and-high-innovation Ente: Regione Piemonte · Tipo: Mobilizing Advanced Talents for Competence and High INnovation Regione: Piemonte Importo max: Fino a €274K Scadenza: 2026-09-10T00:00:00.000Z Status: open Contributo fondo perduto fino €274K per attrarre talenti avanzati e sostenere innovazione in startup e PMI piemontesi (PR FESR 21-27). **Chi può applicare**: - Startup o PMI con sede operativa in Regione Piemonte - Progetto coerente con priorità PR FESR Piemonte 2021-2027 - Piano di assunzione/inserimento talenti qualificati - DURC regolare e iscrizione Registro Imprese **Come applicare**: 1. Verifica criteri PR FESR Piemonte 2. Predisposizione progetto MATCHIN con piano talenti 3. Domanda telematica entro 10 settembre 2026 4. Valutazione tecnica + graduatoria ### Nuova Impresa Lombardia 2026 URL: https://startupmentors.it/bandi/nuova-impresa-lombardia-2026 Sito ufficiale: https://www.bandi.regione.lombardia.it/servizi/servizio/catalogo/dettaglio/attivita-produttive-imprese/start-up-impresa/nuova-impresa-2026-UC2025051184 Ente: Regione Lombardia · Tipo: Contributo fondo perduto avvio impresa Regione: Lombardia Importo max: Fino a €10K (50% spese) Scadenza: 2027-01-29T00:00:00.000Z Status: open Contributo a fondo perduto fino €10K (50% delle spese) per nuove imprese e autoimpiego in Lombardia. Dotazione €8M. **Chi può applicare**: - Impresa di nuova costituzione o lavoratore autonomo con partita IVA individuale - Sede operativa in Regione Lombardia - Settori ammessi (verifica esclusi nel bando) - DURC regolare **Come applicare**: 1. Apertura sportello dalle ore 10:00 del 30 aprile 2026 2. Compilazione domanda telematica su piattaforma Restart di Infocamere 3. Firma digitale del Titolare/Legale rappresentante 4. Accesso con SPID/CNS/CIE **Tip pratici (curatela SMI)**: - Procedura valutativa a sportello: presenta domanda appena aperto. Chiusura anticipata se fondi esauriti. ### Nuova Sabatini URL: https://startupmentors.it/bandi/nuova-sabatini Sito ufficiale: https://www.mimit.gov.it/it/incentivi/agevolazioni-per-gli-investimenti-delle-pmi-in-beni-strumentali-nuova-sabatini Ente: MIMIT · Tipo: Contributo in conto interessi su finanziamento bancario Regione: Nazionale Importo max: €20K-€4M (contributo 2,75-3,575% interessi) Scadenza: 2099-12-31T00:00:00.000Z Status: open Contributo MIMIT in conto interessi (2,75-3,575%) su finanziamento bancario tra €20K e €4M per beni strumentali 4.0 e digitali. **Chi può applicare**: - PMI iscritta al Registro Imprese italiano - Settore manifatturiero, turismo, commercio o servizi (escluse attività finanziarie) - Investimento in beni strumentali nuovi, hardware, software, tecnologie 4.0 - DURC regolare - Bilanci ultimi 2 anni (per imprese costituite) **Come applicare**: 1. Richiesta finanziamento a banca o intermediario convenzionato Cassa Depositi e Prestiti 2. Compilazione modulo Nuova Sabatini contestuale al finanziamento 3. Erogazione contributo MIMIT in conto interessi una volta finanziato l'investimento ### ON — Oltre Nuove Imprese a Tasso Zero URL: https://startupmentors.it/bandi/on-tasso-zero Sito ufficiale: https://www.invitalia.it/incentivi-e-strumenti/ON-nuove-imprese-tasso-zero Ente: Invitalia · Tipo: Finanziamento agevolato + fondo perduto Regione: Nazionale Importo max: Fino a €3M (80% tasso zero + 10% fondo perduto) Scadenza: 2099-12-31T00:00:00.000Z Status: open Fino a €3M (80% tasso zero + 10% fondo perduto) per nuove imprese costituite da team con maggioranza under 36 o donne. **Chi può applicare**: - Compagine sociale con oltre 50% under 36 o donne - Impresa costituita da meno di 60 mesi - Sede operativa in Italia - Programma di investimento minimo (verifica soglia su sito Invitalia) **Come applicare**: 1. Registrazione sull'area riservata Invitalia 2. Compilazione business plan con format ufficiale 3. Caricamento documentazione + firma digitale 4. Valutazione cronologica delle domande ### Resto al Sud 2.0 URL: https://startupmentors.it/bandi/resto-al-sud-2 Sito ufficiale: https://www.invitalia.it/incentivi-e-strumenti/resto-al-sud-20 Ente: Invitalia · Tipo: Voucher fondo perduto + contributo investimento Regione: Mezzogiorno Importo max: €40K voucher + fino a €200K contributo investimento Scadenza: 2099-12-31T00:00:00.000Z Status: open Voucher €40K + contributo 70-75% fondo perduto per autoimpiego e nuove imprese nel Mezzogiorno (18-55 anni). **Chi può applicare**: - Età compresa tra 18 e 55 anni - Sede operativa nelle 8 regioni del Mezzogiorno (Abruzzo, Basilicata, Calabria, Campania, Molise, Puglia, Sardegna, Sicilia) - Settori esclusi: agricolo, pesca, acquacoltura - Iniziativa di autoimpiego o nuova impresa **Come applicare**: 1. Registrazione area riservata Invitalia 2. Predisposizione progetto imprenditoriale 3. Caricamento documentazione + firma digitale ### SIMEST Inserimento Mercati Esteri URL: https://startupmentors.it/bandi/simest-inserimento-mercati Sito ufficiale: https://www.simest.it/finanziamenti-agevolati/inserimento-mercati Ente: SIMEST · Tipo: Finanziamento agevolato + quota fondo perduto Regione: Nazionale Importo max: Fino a €200K (Sud/startup innovative), €100K standard Scadenza: 2099-12-31T00:00:00.000Z Status: open Finanziamento a tasso agevolato + quota a fondo perduto fino a €200K per espansione commerciale extra-UE e apertura sedi estere. **Chi può applicare**: - PMI italiana con almeno 1 bilancio depositato - Iscrizione al Registro Imprese - Progetto di espansione commerciale in mercati extra-UE - Capacità di rendicontare le spese estere **Come applicare**: 1. Predisposizione progetto di internazionalizzazione (mercato target, struttura, costi) 2. Domanda telematica sul portale SIMEST 3. Istruttoria SIMEST e delibera 4. Erogazione tranche finanziamento + saldo a rendicontazione ### Smart&Start Italia URL: https://startupmentors.it/bandi/smart-start-italia Sito ufficiale: https://www.invitalia.it/incentivi-e-strumenti/smartstart-italia Ente: Invitalia · Tipo: Finanziamento agevolato Regione: Nazionale Importo max: €1.500.000 Scadenza: 2026-06-14T00:00:00.000Z Status: closing_soon Finanziamento agevolato fino a €1.5M per startup innovative italiane under-5-anni. **Chi può applicare**: - Startup innovative iscritte alla sezione speciale del Registro Imprese - Costituite da meno di 5 anni - Sede in Italia o filiale operativa attiva - Team con almeno 1 founder under-36 o presenza femminile **Come applicare**: 1. Registrazione su area riservata Invitalia 2. Compilazione business plan con format ufficiale 3. Caricamento documentazione (DURC, visura, atto costitutivo) 4. Firma digitale e invio **Tip pratici (curatela SMI)**: - Il business plan è il punto critico. Errore tipico: numeri ottimistici senza assumption esplicite. - Il DURC scade dopo 4 mesi: meglio richiederlo come ultima cosa prima dell'invio. ### Sostegno Startup Innovative Valle d'Aosta URL: https://startupmentors.it/bandi/valle-aosta-startup-innovative Sito ufficiale: https://imprese.regione.vda.it/bandi/avviso-sostegno-allo-sviluppo-delle-startup-innovative Ente: Regione Valle d'Aosta · Tipo: Contributo fondo perduto sviluppo e insediamento Regione: Valle d'Aosta Importo max: Fino a €150K (60% spese) Scadenza: 2027-06-30T00:00:00.000Z Status: open Contributo fondo perduto fino €150K (60% delle spese) per sviluppo, consolidamento e insediamento di startup innovative in Valle d'Aosta. **Chi può applicare**: - Startup innovativa iscritta sezione speciale o in via di iscrizione - Sede operativa in Valle d'Aosta (insediamento ammesso) - Piano di sviluppo triennale documentato - DURC e regolarità contributiva **Come applicare**: 1. Verifica criteri sul portale Regione VdA 2. Predisposizione Piano di sviluppo triennale 3. Domanda telematica (sportello aperto) 4. Valutazione e graduatoria **Tip pratici (curatela SMI)**: - Sportello aperto fino al 30 giugno 2027 — finestra ampia per pianificare. ### Bando Consolidamento Startup Innovative Veneto URL: https://startupmentors.it/bandi/veneto-consolidamento-startup Sito ufficiale: https://bandi.regione.veneto.it/ Ente: Regione Veneto · Tipo: Contributo fondo perduto consolidamento Regione: Veneto Importo max: Fino a €125K Scadenza: 2026-05-21T00:00:00.000Z Status: closing_soon Contributo fondo perduto fino €125K per il consolidamento di startup innovative venete già costituite. **Chi può applicare**: - Startup innovativa iscritta alla sezione speciale del Registro Imprese - Sede operativa in Regione Veneto - Già costituita (focus consolidamento, non avvio) - Programma di sviluppo coerente con focus innovativo **Come applicare**: 1. Verifica eligibilità sul portale bandi Regione Veneto 2. Predisposizione programma di consolidamento 3. Domanda telematica entro 21 maggio 2026 4. Valutazione + graduatoria **Tip pratici (curatela SMI)**: - URGENTE: deadline imminente. Verifica appena possibile completezza dossier. ### Voucher 3I — Brevetti URL: https://startupmentors.it/bandi/voucher-3i-brevetti Sito ufficiale: https://www.mimit.gov.it/it/incentivi/voucher-3i-investire-in-innovazione Ente: MIMIT · Tipo: Voucher consulenza Regione: Nazionale Importo max: €38.000 Scadenza: 2026-06-22T00:00:00.000Z Status: open Voucher fino a €38K per consulenza brevettuale a startup innovative italiane. **Chi può applicare**: - Startup innovativa iscritta al Registro Imprese da almeno 6 mesi - Avere idea brevettabile in corso di valutazione - Non aver già beneficiato del voucher 3I **Come applicare**: 1. Compilazione domanda telematica 2. Allegare attestato di consulenza brevettuale di almeno 1 ora 3. Invio firma digitale **Tip pratici (curatela SMI)**: - Il consulente deve essere iscritto all'Ordine dei Consulenti in Proprietà Industriale. - Il voucher copre fino al 100% delle spese ammissibili — usa interamente il plafond. ### Voucher Cloud PMI MIMIT URL: https://startupmentors.it/bandi/voucher-cloud-mimit Sito ufficiale: https://www.mimit.gov.it/it/incentivi/voucher-per-consulenza-in-innovazione-secondo-sportello Ente: MIMIT · Tipo: Voucher digitalizzazione cloud Regione: Nazionale Importo max: Fino a €50K voucher Scadenza: 2099-12-31T00:00:00.000Z Status: open Voucher fino a €50K per PMI che adottano servizi cloud, infrastrutture as-a-service e piattaforme SaaS verticali. **Chi può applicare**: - Micro, piccola o media impresa con sede operativa in Italia - DURC regolare - Progetto di adozione servizi cloud (IaaS/PaaS/SaaS) - Fornitore cloud iscritto a registri qualificati (es. ACN, MIMIT) **Come applicare**: 1. Identificazione fornitore cloud qualificato 2. Predisposizione progetto di migrazione/adozione cloud 3. Domanda telematica sul portale MIMIT (verifica calendario sportello) 4. Erogazione voucher a rendicontazione spese