Consigli startup AI: go-to-market, pivot e hiring (YC)

Portare l'AI in un settore legacy: tre strade, una metrica

L'episodio di Office Hours raccoglie le domande della community di Y Combinator e parte da un nodo concreto: come si va a mercato (la strategia go-to-market) quando si costruisce un'azienda AI in un settore tradizionale, con una visione di automazione completa che però non si può consegnare il primo giorno. Prendendo l'esempio della contabilità, i partner descrivono tre strade. La prima è costruire software AI da vendere agli operatori del settore, concentrandosi sull'area più preziosa e ragionevolmente realizzabile nei primi mesi: è la via più frequente fra le aziende YC. La seconda è aprire una propria attività full-stack che fa tutto il lavoro, assumendo anche professionisti del mestiere; in questo caso la metrica da seguire è la percentuale di lavoro automatizzato, che deve salire nel tempo. La terza è comprare un'azienda esistente e introdurci l'AI: si parte con clienti già acquisiti, ma si deve cambiare la cultura di un'organizzazione che già esiste, tanto più difficile quanto più è grande.

Sul secondo modello i partner segnalano un rischio ricorrente: l'azienda si fa assorbire dall'esecuzione del lavoro che entra e non rilascia mai l'automazione. Chi viene dal software vede prima di altri cosa si può automatizzare subito, e tenere alta la quota di persone tecniche aiuta a non trasformarsi in una normale azienda di servizi con un po' di software sopra. Un altro errore citato è scalare i ricavi troppo presto, prima che l'automazione regga davvero. Dal punto di vista di chi investe, conta più la traiettoria del tasso di automazione che il fatturato in sé: il segnale da dimostrare è la capacità di scrivere software che automatizza il lavoro. Per i founder senza esperienza diretta del settore, viene descritto il caso di chi ha costruito l'MVP lavorando per mesi dentro lo studio di un cliente entusiasta.

Tempo per crescere o difendibilità: la velocità di apprendimento

Nei mercati enterprise — pochi compratori, cicli di vendita lunghi, adozione lenta — l'impazienza di chi investe e cerca crescita rapida si scontra con i tempi reali del prodotto. Per un'azienda agli inizi i partner indicano come priorità la velocità di apprendimento: quanto in fretta si capisce cosa vuole il cliente, qual è il dolore acuto rispetto a quello sordo che si tollera. Puntare dritti ai grandi clienti senza un canale d'ingresso privilegiato significa imparare più lentamente; spesso conviene trovare qualcosa di più piccolo su cui avere successo, per iterare e parlare con gli utenti.

Viene aggiunta una distinzione: alcune aziende crescono partendo dalla coda lunga dei clienti piccoli e salgono di fascia col maturare del prodotto, altre risolvono un problema che è solo enterprise e non hanno scelta se non partire in alto. In quel caso si cerca l'azienda più piccola che ha comunque il problema, oppure si riduce drasticamente lo scope per entrare con uno o due utenti interni e un ciclo di vendita più corto. Oltre alla scelta del segmento — il mid-market viene indicato come spesso più promettente — pesa la qualificazione delle persone: serve verificare che chi sta dall'altra parte abbia potere decisionale e incentivo reale a comprare.

AI SDR e hiring dei primi commerciali: prima il founder

Sul dilemma se assumere un growth hacker, un commerciale, un SDR oppure replicarli con strumenti AI, la posizione è netta: gli AI SDR funzionano quando si innestano su un processo di vendita che già gira, non come ultima spiaggia quando il prodotto non si riesce proprio a vendere. Le due domande difficili — a chi vendo e come ottengo la sua attenzione — restano lavoro del founder; una volta risolte, indirizzare un agente verso le persone giuste diventa molto più semplice. Viene anche notato che chi arriva dalla crescita in grandi aziende deve in parte disimparare: molte tattiche pensate per realtà strutturate non si applicano a una startup che non ha ancora capito cosa funziona.

Il parallelo con l'assunzione del primo commerciale è diretto: quasi sempre è troppo presto, a meno che il founder non abbia già capito come ottenere attenzione e come gestire le obiezioni. Si assume per affidare l'esecuzione di un copione già scritto. Lo stesso vale per ruoli come il VP marketing, descritto come posizione ad alto turnover non perché manchino persone capaci, ma perché i founder arrivano con aspettative sbagliate non avendo prima imparato quel mestiere.

Spendere ora o aspettare il prossimo modello, e il valore dei problemi difficili

Sulla scelta tra spendere in modo aggressivo per un vantaggio temporaneo o aspettare il prossimo salto dei modelli, la prima domanda da porsi è se ciò che si costruisce diventerà irrilevante con il modello successivo o invece migliorerà quando lo si potrà sfruttare. Nel secondo caso, investire e lavorarci porta apprendimento: quando il modello arriva, lo si innesta e il prodotto è migliore dal primo giorno. Viene ricordato l'effetto osservato con un nuovo modello Claude Sonnet, quando strumenti che a malapena funzionavano hanno iniziato a funzionare davvero.

Sul pivot motivato dalla difficoltà tecnica, la prospettiva si ribalta: se qualcosa è molto difficile da costruire, spesso è un'idea migliore, perché pochi ci provano e l'asticella scoraggia i concorrenti. Chi ha le competenze e il coraggio per affrontarlo parte avvantaggiato. Per gestire mesi di lavoro tecnico, i partner suggeriscono modi per ridurre lo scope: costruire prima la versione più grezza per sé, integrare un componente esistente di terzi e curare l'interfaccia, ottenere così utenti e slancio prima di affrontare la parte davvero ardua. L'avvertenza è non usare la difficoltà come scusa per restare mesi chiusi a costruire senza parlare con i clienti.

Quando fare pivot con un po' di traction, e quando fare open source

La situazione più scomoda è avere un po' di traction, ma non abbastanza. Nel video viene raccontato il caso di Firecrawl, nato come crawler costruito internamente per il prodotto precedente Mendable: parlando con altri founder è emerso che ogni azienda di agenti AI aveva bisogno di quella funzione, e ciò che era una nicchia dentro il prodotto più grande si è rivelato più prezioso del prodotto stesso. Non c'è una formula: si esplora una gamma di idee per trovare convinzione, si verifica quanto gli utenti valutino davvero il prodotto (spesso meno di quanto si creda) e si tiene presente che il pivot è un momento fragile, in cui serve l'energia per ricominciare quasi da zero. Il segnale più affidabile per pivotare è smettere di credere che ciò su cui si lavora possa funzionare.

Sull'open source di un prodotto SaaS enterprise, i casi più comuni restano i dev tool, perché chi vende a sviluppatori trova clienti che apprezzano poter leggere il codice e fidarsi. Ma l'open source risulta utile anche oltre i dev tool: per creare fiducia presso i clienti enterprise e accorciare il ciclo di vendita, per il self-hosting quando ci sono preoccupazioni su privacy e dati sensibili, per la compliance. Sapere di poter ispezionare il codice o ospitarlo in proprio spesso basta, anche senza farlo davvero; il rovescio della medaglia è il costo del self-hosting, che impone un prezzo elevato.

Cosa portarti a casa

Se stai costruendo, le domande da rendere operative sono tre. Prima: a chi vendi e come ottieni la sua attenzione — risolvile tu, perché nessuno strumento AI lo farà al posto tuo, e solo dopo innesta un AI SDR su un processo che gira. Seconda: misura ciò che dimostra il tuo valore — se porti l'AI in un settore tradizionale, traccia la quota di lavoro automatizzato invece di gonfiare il fatturato. Terza: assumi quando le cose si rompono perché funzionano, non per sentirti più avanti, e parti dalla tua rete personale. E sul pivot, fidati del segnale interno: quando smetti di credere che funzionerà, esplora una gamma di idee finché non ritrovi convinzione.