I miei primi 30, 60, 90 giorni in una startup

Senza filtri #30

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

“Dal business.”

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

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

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

---

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

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

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

Da quella volta ho cambiato completamente approccio.

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

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

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

Le urgenze che nessuno aveva visto

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

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

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

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

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

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

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

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

Giorni 30-60: adesso si fa

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

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

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

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

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

Giorni 60-90: far fare

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

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

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

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

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

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

La cosa che dico sempre ai founder

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

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

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

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

Perché è da lì che parte tutto.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri