Su quali criteri decidereste, oggi, se investire un milione di euro in una startup AI early-stage? La maggior parte dei founder e degli investitori risponde citando le metriche classiche del SaaS: ARR, growth rate, retention, CAC payback, magic number, regola del quaranta. Sono tutte metriche utili, tutte ancora rilevanti. Solo che applicate da sole all’AI applicata danno letture incomplete, e qualche volta ingannevoli, e questa è l’osservazione che mi ha portato a costruire lo strumento di cui parla questa puntata.
Una startup AI può crescere rapidamente, mostrare retention buona nei primi sei mesi, avere un CAC payback ragionevole, e tuttavia essere strategicamente fragile, se la crescita non si traduce in accumulazione di contesto e di vantaggio difendibile. L’inverso è altrettanto vero: una startup AI può avere metriche di crescita più moderate e tuttavia essere strutturalmente solida, se sta sedimentando posizione in un workflow specifico con un loop che si rafforza nel tempo. Il problema diventa, allora, come misurare cose che le metriche standard non catturano.
Dagli appunti raccolti lavorando su decine di prodotti AI in fasi diverse è nata una scorecard in dodici punti che uso ormai come strumento di riferimento, e che condivido in questa puntata. Non sostituisce le metriche tradizionali, le integra. La trovo utile sia per chi investe (founder che vogliono fare un’autovalutazione onesta, fondi che vogliono un secondo livello di filtro dopo le metriche standard), sia per chi compra (corporate che valuta un fornitore AI, innovation manager che valuta un pilot interno). La logica di fondo è semplice: dodici domande, ognuna con tre risposte possibili (sì, no, parziale), e un punteggio totale che dà un’indicazione rapida sulla solidità della posizione che la startup sta costruendo.
Indice degli argomenti
Le dodici dimensioni
Le dodici domande sono organizzate per dominio: tre sul problema affrontato, tre sul rapporto con il workflow, tre sull’accumulazione di contesto, tre sulla difendibilità nel tempo.
**Sul problema affrontato.**
La prima domanda è se il problema affrontato è frequente e riconosciuto. Frequente significa che ricorre con regolarità nel lavoro di chi lo subisce, non che è un problema occasionale di poche aziende. Riconosciuto significa che le persone che dovrebbero usare il prodotto, e non solo i loro manager, identificano il problema come prioritario. Se il problema è raro, o se è prioritario solo per il management ma non per chi fa il lavoro quotidiano, l’adozione non avrà la pressione necessaria per superare le resistenze organizzative.
La seconda è se il prodotto è collocato dentro un workflow, non in superficie. Un prodotto in superficie è quello che le persone aprono quando gli serve, lo usano, lo chiudono. Un prodotto dentro il workflow è quello senza cui il workflow rallenta o si ferma. La differenza, come abbiamo visto in altre puntate, è enorme: il primo è facilmente sostituibile, il secondo costruisce dipendenza positiva e diventa progressivamente parte del processo.
La terza è se l’uso del prodotto riduce tempo, errore o rischio in maniera misurabile. Misurabile significa che esiste un numero che lo dice, non un aggettivo. Se la startup non sa quantificare il beneficio prodotto, è probabile che il beneficio sia percepito ma non documentato, e i benefici percepiti ma non documentati hanno una vita breve di fronte al primo riesame di budget.
**Sul rapporto con il workflow.**
La quarta è se la startup ha accesso a contesto proprietario o difficilmente replicabile. Contesto proprietario non significa solo dati esclusivi, significa anche regole codificate, eccezioni gestite, tassonomie costruite, conoscenza tacita verbalizzata, criteri di decisione resi espliciti. Tutto ciò che la startup ha imparato stando dentro il workflow del cliente e che un competitor non possiede.
La quinta è se il feedback degli utenti è raccolto strutturatamente. Raccolto significa esplicitamente catturato dal sistema, non solo verbalizzato in conversazioni informali con il customer success. Strutturato significa categorizzato secondo una grammatica chiara, così che i pattern emergano analizzabili. Se la startup non sa rispondere alla domanda “quali sono le tre correzioni più frequenti che gli utenti fanno al vostro output?”, probabilmente il feedback non sta tornando nel prodotto.
La sesta è se le correzioni che gli utenti fanno al sistema migliorano il comportamento futuro del sistema. Questa è la domanda chiave del loop. Una startup può raccogliere feedback strutturato e poi non utilizzarlo, e questo è quasi peggio del non raccoglierlo affatto, perché crea l’illusione di un sistema che impara senza che impari davvero. Il test concreto è chiedere alla startup di mostrare un esempio specifico di un pattern di errore che è stato individuato, corretto, e che oggi non si ripete più.
**Sull’accumulazione di contesto.**
La settima è se il prodotto è integrato con strumenti e fonti che contano per il cliente. Integrato significa che il sistema legge e scrive dentro CRM, ERP, gestionali, knowledge base, sistemi di workflow management che il cliente già usa. Le integrazioni profonde sono uno dei moat più robusti dell’AI applicata, perché sono costose da costruire e ancora più costose da migrare. Se il prodotto vive in una bolla isolata, e i clienti devono copiare e incollare informazioni dentro e fuori, la posizione è strutturalmente fragile.
L’ottava è se le soglie di errore sono note, gestite, e accettate dal cliente. La startup deve sapere quali errori sono tollerabili, quali richiedono escalation umana, quali sono inaccettabili e devono triggerare un’interruzione del flusso. Se queste soglie non sono esplicitate, il sistema funziona in un’ambiguità pericolosa, e la prima volta che produce un errore di tipo inaccettabile rischia di perdere fiducia in maniera difficilmente recuperabile.
La nona è se esistono log, tracciabilità e responsabilità chiare. Per ogni output del sistema deve essere possibile sapere quale versione del modello l’ha prodotto, quali fonti ha usato, quali controlli ha superato, chi è intervenuto se c’è stata correzione umana. Questa è la condizione per costruire fiducia nei contesti dove la posta è alta, ed è anche un requisito sempre più frequente nei contratti enterprise di una certa dimensione. L’AI Act europeo, in vigore con scadenze progressive tra il 2025 e il 2027, rende questo punto non solo strategico ma anche compliance-critical per molti use case.
**Sulla difendibilità nel tempo.**
La decima è se il valore del prodotto dipende fortemente da un singolo modello sottostante. Se la risposta è sì, la startup è esposta al rischio che cambiamenti di pricing, performance o policy del fornitore del modello distruggano il valore percepito. Se la risposta è no, la startup ha costruito proprietà nel proprio layer (contesto, integrazione, feedback, governance) che sopravvivono a un eventuale cambio di motore. Le startup AI più mature in questa fase sono spesso multi-model nativamente, capaci di scegliere il modello migliore per ogni singolo task senza dipendere esclusivamente da un singolo fornitore.
L’undicesima è se esiste una traiettoria credibile di espansione verso workflow adiacenti. Una startup che presidia un singolo workflow molto bene, ma che non ha visibilità su come crescere oltre quel workflow, può costruire un business solido ma piccolo. Se l’ambizione è venture-scale, la traiettoria di espansione deve essere chiara fin dall’inizio. Le adiacenze sensate sono quelle che usano lo stesso contesto operativo per coprire passaggi a monte e a valle del workflow originario, riducendo il costo marginale di estensione e aumentando il costo di switching per il cliente.
La dodicesima è se togliere il prodotto dal workflow del cliente produrrebbe un costo operativo percepibile. Questa è la domanda finale, quella che misura davvero la posizione di mercato. Se il cliente potesse migrare a un competitor in due settimane senza significativa perdita di valore, la posizione è debole. Se la migrazione richiederebbe mesi di lavoro di re-onboarding, ricostruzione del contesto, riscrittura delle integrazioni, la posizione è solida. La risposta a questa domanda è il proxy più sintetico del moat che la startup ha costruito.
Leggere il punteggio finale
Ogni domanda ammette tre risposte: sì (1 punto), parziale (0,5 punti), no (0 punti). Il punteggio totale va da zero a dodici, e la lettura che faccio nelle mie valutazioni è la seguente.
Da zero a quattro, la startup è in una zona di fragilità strutturale. Non significa necessariamente che il prodotto sia cattivo o che il team sia debole, significa che la posizione di mercato che la startup sta costruendo è esposta a competitor che arrivano dopo con poca fatica. È una zona da cui si può uscire, ma raramente si esce solo aggiungendo feature: di solito serve un ripensamento più profondo del wedge o del workflow presidiato.
Da cinque a otto, la startup è in una zona di costruzione. La traiettoria è promettente, alcuni elementi della posizione sono già in piedi, altri sono ancora in corso di costruzione. Le iniziative che vedo bruciare round in questa zona sono quelle che si lasciano distrarre dalla crescita prima di aver consolidato il loop. Le iniziative che invece reggono sono quelle che usano il round per chiudere i gap della scorecard, non per lanciare nuove funzionalità.
Da nove a dodici, la startup è in una posizione solida. Il loop è in piedi, il contesto si accumula, la dipendenza dal modello sottostante è gestita, la traiettoria di espansione è chiara. Sono le startup che, nei prossimi anni, hanno più probabilità di costruire posizioni difendibili e di durata. La domanda che gli investitori fanno a questo livello cambia natura: non più “questo prodotto è solido?”, ma “questa startup può scalare il modello operativo che ha costruito?”. È un’altra conversazione.
Tre applicazioni reali
Per chiarire come la scorecard funziona in pratica, descrivo tre casi anonimi che ho valutato negli ultimi mesi, senza nomi e con dettagli abbastanza modificati da rendere irriconoscibili le aziende coinvolte.
Il primo caso era una startup AI che operava nel marketing automation. Aveva costruito un assistente per la generazione di contenuti commerciali, integrato con i principali CMS. La scorecard ha dato un punteggio di tre. Il problema era reale ma non particolarmente frequente per i clienti più strategici (che lo gestivano con team interni), il prodotto stava in superficie del workflow di marketing senza occupare un punto di azione, e il valore dipendeva quasi interamente dal modello sottostante. La crescita era buona nei primi sei mesi, ma il churn era alto, e la spiegazione era proprio nella debolezza strutturale della posizione: i clienti provavano il prodotto, non vedevano differenze sostanziali rispetto a usare GPT direttamente, e tornavano alle proprie soluzioni interne dopo qualche mese.
Il secondo caso era una startup AI che assisteva la preparazione di pratiche tecniche per il settore costruzioni, in collaborazione con studi di ingegneria. Punteggio sette. Il problema era frequente, riconosciuto, e il prodotto si stava integrando dentro il workflow di preparazione delle pratiche, ma il feedback degli utenti era raccolto informalmente e le correzioni non tornavano nel sistema in forma utilizzabile. Inoltre il valore dipendeva da un singolo modello sottostante, e una recente variazione di prezzo del fornitore aveva eroso il margine. La startup era solida nella traiettoria, ma aveva bisogno di chiudere alcuni gap operativi prima di un Series A.
Il terzo caso era una startup AI che operava nella compliance per il settore finance. Punteggio dieci. Il problema era frequente, ad alta posta, riconosciuto da tutti gli stakeholder. Il prodotto era profondamente integrato nei workflow di onboarding clienti e di monitoraggio transazionale, con log dettagliati, tracciabilità completa, governance dell’errore esplicitata in contratto. Il valore dipendeva da una combinazione di modello sottostante, contesto regolatorio specifico costruito in due anni di lavoro, e tassonomia di rischio costruita con i clienti stessi. Le metriche di crescita erano più lente di quelle del primo caso, ma il churn era nullo e il NRR (net revenue retention) sopra il centoventi per cento. Una posizione solida, che il fondo che la stava valutando ha effettivamente seguito nel round successivo.
I tre casi mostrano che il punteggio della scorecard non sempre coincide con la velocità di crescita visibile dall’esterno, e che a volte una startup con metriche apparentemente più modeste ha una posizione strutturalmente più solida di una startup con metriche apparentemente più brillanti. È esattamente il tipo di lettura che le metriche tradizionali, da sole, non offrono.
Una conseguenza pratica di questa lettura riguarda anche il pricing dei round. Nei tre casi sopra, i fondi che hanno valutato le startup hanno applicato moltiplicatori di valutazione che riflettevano il punteggio della scorecard più della velocità di crescita istantanea. La startup con punteggio dieci ha chiuso il round a un multiplo significativamente più alto della startup con punteggio sette, anche se entrambe avevano numeri di crescita comparabili nei dodici mesi precedenti. La differenza non era nel passato, era nella probabilità che i numeri continuassero a tenere nei due-tre anni successivi, e quella probabilità è proprio quello che la scorecard prova a misurare.
Cosa la scorecard non misura
Conviene chiarire cosa la scorecard non è. Non è uno strumento di valutazione finanziaria, non sostituisce due diligence, non predice il successo o il fallimento di una startup specifica. È un proxy strutturale che fotografa, in un momento dato, la solidità della posizione di mercato che la startup sta costruendo. Il futuro dipende da molte variabili che la scorecard non cattura: la qualità del team, la capacità di execution, il timing di mercato, la fortuna, l’arrivo di tecnologie disruptive che ridistribuiscono le carte.
Detto questo, in dodici punti la scorecard cattura abbastanza bene la dimensione strategica della posizione, ed è uno strumento che si applica in quindici minuti a fronte di informazioni che sono quasi sempre disponibili in un buon pitch deck o in una riunione iniziale con il team. Per i fondi early-stage, è un secondo livello di filtro dopo le metriche standard. Per i founder, è uno specchio per fare un’autovalutazione onesta e identificare i gap su cui lavorare. Per le corporate che valutano un fornitore AI, è una griglia di domande operative da porre prima di firmare un contratto.
Nel mio uso quotidiano, la scorecard si combina bene con le metriche tradizionali invece di sostituirle. Una startup con ARR e growth solidi e punteggio sette è diversa da una con stessi ARR e growth ma punteggio tre, e quella differenza dovrebbe riflettersi nella valutazione e nelle condizioni del round. Le startup che hanno punteggi alti tendono a sopravvivere meglio ai cicli di mercato, perché la solidità della posizione le rende meno dipendenti dalla disponibilità di capitale di crescita.
Vale anche la pena notare che il punteggio non è statico, evolve nel tempo. Una startup che parte con un punteggio cinque può arrivare a otto-nove in dodici mesi se lavora consapevolmente sui gap, e una startup che parte con un punteggio nove può scendere a sei se trascura il loop e si concentra solo sulla crescita. Per questo trovo utile applicare la scorecard non solo come strumento di valutazione una tantum, ma anche come strumento di monitoraggio trimestrale, sia per i founder che vogliono misurare la propria evoluzione strategica, sia per i fondi che vogliono capire se le aziende in portafoglio stanno consolidando la posizione o stanno scalando il loro vantaggio iniziale verso una posizione più fragile. La domanda da farsi a ogni revisione è semplice: rispetto a tre mesi fa, dove è migliorato il punteggio, e dove è peggiorato, e perché?
L’ultima puntata della rubrica chiude il cerchio guardando il tema che attraversa tutta la lista delle dodici domande, e che è probabilmente il vero discriminante delle prossime due o tre fasi di mercato: la fiducia operativa, la governance dell’errore, il modo in cui un sistema AI guadagna il diritto di entrare in passaggi sempre più critici dei processi reali. La trattazione completa del framework, con la scorecard di difendibilità in versione stampabile e gli altri strumenti operativi, è nel libro Da Zero a Loop.
Partecipa alla community