Le startup AI che reggono nel tempo sono quelle che hanno avuto il coraggio di partire piccole. Sembra una banalità, ma è la cosa più disattesa nei pitch deck che girano sui tavoli dei fondi early-stage.
La maggior parte dei founder, descrivendo la propria startup, attacca con la grandezza del problema. Settecento miliardi di dollari di mercato globale, milioni di aziende potenziali clienti, decine di workflow possibili da automatizzare. È una mossa naturale, perché chi presenta a un fondo VC sa che la dimensione del mercato è una variabile critica nella valutazione del round. Solo che, quando si scende dal pitch deck al prodotto reale, quella stessa ampiezza diventa un problema.
Indice degli argomenti
l wedge nelle startup AI: partire stretti per costruire vantaggio
Una startup AI che vuole risolvere troppe cose contemporaneamente, anche quando ha una tecnologia eccellente, fatica a costruire una posizione difendibile. Non perché manchi di ambizione, ma perché manca della disciplina di scegliere un punto di entrata stretto, dimostrare di funzionare meglio di chiunque altro in quel punto, e da lì espandersi per adiacenze sensate. Quel punto di entrata, nel lessico VC, ha un nome ormai diffuso: wedge. Letteralmente, un cuneo. Un’apertura iniziale stretta che permette di entrare in un mercato e poi, una volta dentro, allargarsi.
Bessemer Venture Partners, in un playbook pubblicato nel 2025 dedicato proprio alla costruzione di startup vertical AI, nomina il “compelling wedge” come uno dei tre pilastri dei prodotti AI che funzionano davvero, insieme al contesto e al ROI immediato.
Il wedge giusto, nella loro lettura, parte da un singolo pain point centrale, spesso linguistico o multimodale, ed è abbastanza intuitivo da essere adottato dentro workflow esistenti senza costringere a un cambiamento drastico. Le startup AI di maggior successo nel 2024-2025, secondo Bessemer, condividono quasi tutte questa scelta strutturale: entrare stretti e con un beneficio immediato visibile, prima di pensare alla scala.
Le caratteristiche di un wedge solido per una startup AI
Un wedge non è semplicemente un caso d’uso ristretto. Un caso d’uso ristretto può essere semplicemente un mercato piccolo, e i mercati piccoli non aprono traiettorie. Un wedge è un caso d’uso ristretto che apre traiettorie. La differenza è nella combinazione di cinque caratteristiche che ricorrono nei wedge che funzionano davvero.
Problema reale, frequenza e costo visibile
Il problema deve essere reale, e questo è il primo filtro che molti deck non superano. Real significa misurabile e ricorrente, riconosciuto da chi lo subisce come una frizione vera, non come un’inefficienza astratta. Se le persone che lavorano dentro il workflow non riconoscono il problema come prioritario, il wedge è probabilmente un’invenzione del founder, non una scoperta del mercato.
Il problema deve essere frequente, perché senza ripetizione il sistema non accumula apprendimento e il loop non si forma. Un task che viene eseguito una volta a settimana è raramente un buon wedge, perché il volume di interazioni necessario a far migliorare il sistema è troppo basso. Un task che viene eseguito decine di volte al giorno è una candidatura più solida, perché ogni interazione produce un segnale che, se raccolto bene, contribuisce a costruire vantaggio.
Il problema deve avere un costo visibile, in tempo, denaro o rischio, perché senza un beneficio chiaro e quantificabile l’adozione non parte. La startup deve essere in grado di rispondere alla domanda “quanto state risparmiando?” con un numero, non con un aggettivo. Bessemer, nel suo playbook, lo formula così: il ROI deve essere chiaro dal primo giorno, senza bisogno di un foglio Excel per spiegarlo all’utente. È un buon test.
Contesto, misurabilità e posizione difendibile
Deve esserci accesso a contesto utile e proprietario, perché il wedge che funziona è quello che permette al sistema di costruire qualcosa nel tempo, non solo di eseguire un task isolato. Un wedge senza contesto sottostante è un wedge che funziona oggi e si commoditizza domani, perché chiunque con accesso allo stesso modello può replicarlo.
Deve essere possibile misurare il miglioramento, perché senza evidenza concreta il progetto smette di essere progetto e diventa narrazione, e una narrazione non sostiene un round Series A. La misurabilità è anche la condizione per imparare: senza metriche affidabili, il sistema non sa se sta davvero migliorando o se sta solo cambiando.
Quando questi cinque criteri convergono, il wedge è candidato a costruire posizione. Quando uno o più di essi manca, conviene chiedersi se il wedge sia davvero quello giusto, o se si stia confondendo un’opportunità con una buona idea generica.
Frizioni reali e mode passeggere nella scelta del wedge
Il miglior wedge è quasi sempre una frizione, ed è quasi mai una moda. Una frizione è un punto in cui il lavoro rallenta, si frammenta, si ripete, richiede coordinamento eccessivo, produce errori evitabili o dipende troppo dalla memoria individuale. Una moda è un tema che attira attenzione e capitale, ma non corrisponde necessariamente a una frizione concreta nel lavoro di qualcuno.
La distinzione pesa più di quanto sembri, perché il mercato AI degli ultimi tre anni ha generato una quantità enorme di mode che si presentano come frizioni. Le mode che hanno attraversato la fase di hype e poi si sono schiantate sul deployment includono almeno quattro grandi categorie. Gli “agenti autonomi end-to-end” che dovevano sostituire interi reparti, e che invece si fermano sulla prima eccezione perché nessuno ha definito chi risponde quando l’agente sbaglia. I “digital twins” cognitivi che dovevano replicare le competenze degli esperti, e che invece producono sintesi plausibili ma incomplete perché la conoscenza tacita non si riversa così facilmente. Le “AI native” enterprise applications che dovevano sostituire il software legacy, e che invece falliscono nell’integrazione perché il software legacy contiene un decennio di logica di business che non si riscrive in tre mesi. I “voice-first” assistants che dovevano cambiare il customer service, e che invece si scontrano con la realtà delle lingue e degli accenti, del rumore di fondo, dei contesti operativi che richiedono molto più lavoro di tuning di quanto i pitch suggerivano.
Costruire su una moda non è un peccato strategico in sé, ma comporta un rischio specifico: quando la moda passa, il prodotto resta orfano di una base di pain point reali che lo sostenga. Costruire su una frizione, invece, ha un vantaggio strutturale: la frizione esiste indipendentemente dal trend di mercato, e finché il problema non è risolto qualcuno è disposto a pagare per risolverlo. Le startup che ho visto reggere il ciclo del 2023-2025 sono quasi tutte partite da frizioni, anche quando il loro pitch suonava di moda.
I migliori wedge li ho trovati, nella mia esperienza, parlando con chi fa il lavoro, non con chi lo dirige. I manager tendono a indicare macro-processi, perché la loro prospettiva è strategica e generale. Gli operatori indicano punti precisi in cui perdono tempo ogni giorno, perché la loro prospettiva è operativa e quotidiana. È lì che si trovano le frizioni vere, e raramente quelle frizioni coincidono con i temi che vanno di moda nei talk di settore.
Il perimetro iniziale del wedge nelle startup AI
Il perimetro iniziale del wedge ne decide gran parte del successo. Troppo stretto e il valore non emerge, perché il sistema gestisce così pochi casi che il beneficio totale per il cliente è marginale. Troppo largo e il sistema collassa sotto il peso delle eccezioni, perché ogni cliente porta varianti diverse e il prodotto non riesce mai a stabilizzarsi.
La disciplina consiste nel definire un perimetro piccolo abbastanza da essere controllabile e grande abbastanza da produrre un beneficio evidente. Non “gestire l’intero processo di onboarding cliente”, ma “preparare il dossier iniziale e segnalare informazioni mancanti”. Non “automatizzare il sales enablement”, ma “produrre una prima bozza di offerta per le richieste standard, recuperando dati dal CRM e dai listini”. Non “fare AI per il legale”, ma “classificare e riassumere le clausole fuori standard in certi tipi di contratti ricorrenti”. Il perimetro è una scelta strategica vera, prima di un dettaglio operativo, e i founder che la sottovalutano si trovano spesso a riprogettare il prodotto dopo i primi sei mesi di mercato.
Ho imparato a diffidare dei wedge definiti con verbi troppo ampi: “ottimizziamo”, “semplifichiamo”, “miglioriamo”. I wedge che reggono si definiscono con verbi specifici: “classifichiamo i documenti in ingresso e segnaliamo quelli incompleti”, “generiamo la prima bozza dell’offerta a partire dal brief e dal listino”, “estraiamo le clausole non standard dai contratti di fornitura e le confrontiamo con le nostre policy”. La specificità del verbo è un buon indicatore della solidità del perimetro, ed è un test rapido che i founder possono fare su sé stessi prima di un pitch.
Un perimetro ben scelto permette al team di capire velocemente dove il sistema funziona e dove no, quali eccezioni sono gestibili e quali vanno escluse, quali feedback sono davvero utili. Un perimetro troppo vago costringe a rincorrere troppi problemi diversi e produce risultati disomogenei che rendono difficile capire se il sistema sta migliorando o no.
Feedback e apprendimento nel wedge startup AI
Se il wedge deve aprire un loop, il feedback non può essere pensato dopo il lancio. Va progettato dall’inizio. Chi correggerà il sistema, come lo farà, in quale forma la correzione verrà registrata, quali segnali sono davvero utili, cosa merita di essere ricordato, come si distinguerà tra errore del modello, errore di contesto, errore di interfaccia, errore di processo.
Molti pilot falliscono perché il feedback resta informale: gli utenti dicono che il sistema “non sempre ci prende”, senza che esista una grammatica delle correzioni. In questo modo il wedge resta una prova di fattibilità e non evolve. Un wedge forte, invece, costruisce fin dall’inizio il sentiero che porta dal primo uso all’apprendimento strutturato.
In pratica, serve un modo semplice per l’utente di segnalare “questo output va bene”, “questo va corretto così”, “questo è sbagliato e deve passare a un umano”. Servono categorie chiare per classificare gli errori. Serve che le correzioni vengano aggregate, analizzate, e che i pattern ricorrenti tornino nel prodotto in forma utilizzabile. Tutto questo va disegnato prima del lancio del pilot, non dopo, perché aggiungerlo retroattivamente è dieci volte più costoso e produce una grammatica del feedback più povera.
Le startup che progettano bene il feedback dal primo giorno sono anche le più rapide a iterare il prodotto. James Currier di NFX, in un saggio diventato citato nel mondo VC, sostiene che le startup AI vincenti non sono tanto quelle che ci prendono al primo colpo, quanto quelle che imparano più rapidamente di tutte le altre. Il design del feedback è il pezzo che rende possibile quella velocità di apprendimento.
Quando il wedge dipende troppo dal modello AI
Disegnare un wedge il cui valore dipende quasi interamente dalla prestazione del modello sottostante è un rischio frequente. Se cambiare provider o modello significa perdere quasi tutto il valore percepito dal cliente, il wedge è fragile. Non vuol dire che la qualità del motore sia irrilevante: vuol dire che il wedge deve costruire proprietà proprie che vivono indipendentemente dal modello scelto.
Le proprietà che il wedge deve costruire sono quelle che abbiamo già nominato in altri contesti: integrazione profonda con i sistemi del cliente, contesto operativo specifico raccolto attraverso l’uso, interfaccia aderente al modo in cui il lavoro viene svolto, memoria che persiste tra sessioni, sistema di valutazione interno, gestione delle eccezioni più frequenti. Ognuna di queste proprietà è qualcosa che il modello da solo non possiede, e che la startup costruisce stando dentro un workflow specifico.
Quando un wedge ha queste proprietà, il modello diventa un moltiplicatore, non l’unica fonte di vantaggio. Cambiare modello, in caso di necessità (un competitor che alza i prezzi, un nuovo modello che diventa più adatto al task, un cambiamento regolatorio che impone scelte diverse), diventa un’operazione tecnica e non strategica. Quando un wedge non ha queste proprietà, cambiare modello significa rifare il prodotto da zero, e questo è un rischio strutturale che i fondi più maturi sanno riconoscere a colpo d’occhio.
Dal pilot al sistema: cosa deve aprire davvero un wedge
Le tre fasi (pilot, prodotto, sistema) hanno una differenza sostanziale che spesso viene sottovalutata. Il pilot dimostra che qualcosa è possibile, su un caso ristretto, con un cliente disponibile a tollerare imperfezioni in cambio di accesso anticipato. Il prodotto rende quella possibilità utilizzabile da altri ripetibilmente, con onboarding strutturato, documentazione, supporto, pricing chiaro, integrazione che funziona senza intervento del team della startup. Il sistema fa sì che l’uso del prodotto migliori progressivamente il prodotto stesso e la sua integrazione nel lavoro del cliente.
Molti team si fermano al pilot e lo chiamano prodotto. Altri arrivano al prodotto e lo scambiano per sistema. In entrambi i casi è un errore di percezione che ha conseguenze reali. Passare dal pilot al prodotto richiede design rigoroso, onboarding ripetibile, misurazione strutturata, ownership chiara, supporto adeguato. Il salto successivo, dal prodotto al sistema, richiede feedback loop progettati, contesto curato, regole codificate, governance esplicita, e una pazienza che non tutti i team hanno. La fretta di saltare passaggi produce spesso delusione: il progetto sembrava promettente ma “non ha scalato”, e quasi sempre la spiegazione vera è che non aveva ancora costruito le condizioni per farlo.
Quando non allargare il wedge è una scelta strategica
Se stai costruendo una startup AI, e sei in fase di scelta o di revisione del wedge, ci sono tre domande che vale la pena farsi a freddo, prima di andare avanti.
La prima è chi possiede il problema dentro l’organizzazione cliente. Molti progetti AI nascono senza un vero owner, promossi dall’innovazione, dal marketing, dall’IT, dal vertice, senza atterrare su una funzione che senta il problema come proprio. In questi casi il wedge è debole, perché manca la forza che trasforma il test in adozione. Un buon wedge ha quasi sempre un padrone preciso: il responsabile customer care, il direttore commerciale, il team legale, l’operations manager, il responsabile crediti, il compliance officer. Se non riuscite a nominare il padrone del problema, probabilmente non avete ancora trovato il wedge giusto.
La seconda è cosa accade dopo il primo successo. Un wedge è una porta d’ingresso, e una porta d’ingresso vale solo se permette di andare oltre la soglia. Se il wedge funziona bene ma non apre traiettorie naturali verso workflow adiacenti, la startup rischia di diventare un tool da venti milioni di ARR senza prospettive di crescita. Va bene se è quello che cercate, ma non è una traiettoria da venture-backed startup. La domanda da farsi è: una volta consolidato il wedge, quali tre o quattro espansioni naturali si aprono? Se la risposta è chiara, il wedge è ben scelto. Se la risposta è generica o forzata, il wedge è probabilmente troppo stretto o disconnesso dal resto del workflow.
La terza è cosa il sistema sta accumulando che gli altri non possono accumulare. Se la risposta è “niente di particolare, usiamo gli stessi modelli e le stesse fonti pubbliche”, c’è da costruire qualcosa di nuovo, perché senza accumulazione il prodotto non migliora con l’uso, e senza miglioramento con l’uso il vantaggio iniziale si erode con la velocità a cui i modelli sottostanti si commoditizzano.
Queste tre domande, applicate prima di un Series A, hanno un effetto concreto: separano i pitch che reggono il due diligence dai pitch che si bloccano sui dettagli operativi. E applicate dopo, nei mesi che seguono il primo pilot, possono salvare un anno di lavoro, perché spingono il founder a riconoscere il pivot necessario quando ancora ha le risorse per farlo.
La prossima puntata cambia prospettiva e guarda il problema dal lato corporate, dove il wedge si chiama pilot e il problema diventa come trasformare un esperimento promettente in un sistema che entra davvero nelle operations. La trattazione completa del framework, con la mappa delle sette domande strategiche e gli strumenti operativi associati, è nel libro Da Zero a Loop.
Partecipa alla community