Qual è la caratteristica chiave dei migliori technical founder

Come software engineer, abbiamo sempre creduto che i technical founder 🤙 siano l'elemento più critico nella creazione di una startup. Vediamo perché.

“You never achieve what you want without falling on your face a few times.”

Se ti hanno inoltrato questa mail o arrivi da Linkedin, puoi iscriverti al Silicon Valley Dojo per ricevere un post come questo ogni lunedì mattina:

Quando sono atterrato per la prima volta a San Francisco nel 2008, mi sono innamorato dell'energia che permeava la zona, e, più ancora, del valore unico al mondo che veniva assegnato alle persone con competenze tecniche, a volte anche un po’ sopra le righe¹: gli ingegneri, insomma. Era la prima volta nella mia vita che vedevo programmatori, amministratori di sistema o esperti di sicurezza e hacker alla guida delle proprie aziende.

Il fatto più straordinario era che anche gli investitori spingevano affinchè queste persone guidassero le loro startup. Volevano capire la visione, la Go-To-Market strategy e la roadmap del prodotto direttamente dal creatore, da chi ne aveva scritto il codice sorgente.

È stata un'illuminazione perché, come sapete meglio di me, da dove veniamo noi il ruolo di leader tecnologico è limitato a questioni tecniche o, al massimo, a guidare altre persone con competenze simili alle sue. Per fare carriera, insomma, nel nostro e in tanti altri paesi, si deve smettere di fare ciò che sappiamo fare meglio—e che ci diverte—per iniziare a occuparsi di questioni diverse. Sicuramente il 99.9% dei CEO delle nostre aziende tech non sanno programmare in Python e Rust o configurare Kubernetes.

La Silicon Valley è sempre stata diversa, ma anche qui essere un grande technical founder è qualcosa che devi imparare negli anni. Ad esempio, è molto diverso dall'essere il CTO di una grande azienda. Essere un technical founder è anche molto diverso dall’essere il lead developer del team.

Vi siete mai chiesti perché? Per me è sempre stato molto chiaro, forse perché non sono mai riuscito a separare il mio amore per la tecnologia dalla voglia di costruire qualcosa che altre persone utilizzassero ogni giorno.

Grazie a un eccellente video della Group Partner di YC Diana Hu— che vi suggerisco di guardare dopo aver letto questo articolo—ho deciso che è giunto il momento di scrivere qualcosa sul perché è così difficile essere un grande technical founder.

Iniziamo con breve preambolo per quanto riguarda l’essere "founder".

---

Sponsored | Mayer Brown offers early-stage companies and venture investors sophisticated advice to navigate an increasingly regulated and decentralized environment, where industry vertical expertise comes at a premium.

---

A founder never sleeps

La differenza più importante tra i founder e il resto del team è che un fondatore non dorme mai. Essendo stato io stesso founder di diverse aziende, devo ammettere che ho sempre lavorato giorno e notte a quello che stavo creando. In questo caso specifico però, non mi riferisco direttamente alla quantità di ore che si spendono in uffico.

Come founder, finisci per essere strettamente connesso emotivamente con la tua azienda, e anche se ti prendi una pausa, la testa è costantemente agganciata a ciò che stai costruendo. Non so se è capitato anche a voi, ma si arriva a non percepire la differenza tra giorni lavorativi e weekend. Stai facendo qualcosa che ti piace e non capisci perché tanti altri dicano: “Finalmente è venerdí”. Per te è sempre festa!

Ogni momento della giornata può regalarti una nuova idea e senti il bisogno di annotare costantemente nuovi pensieri, idee e soluzioni.

Quando tutto va bene, pensi a come migliorare il prodotto, a come rendere più felici i tuoi clienti e come far crescere la tua attività. Quando le cose non vanno troppo bene, devi trovare modi per risolvere i problemi il prima possibile.

La sensazione che ti pervade non è sempre di euforia, anzi. Sei costantemente “on call” perché stai puntando tutto—e molti altri con te—su quello che stai costruendo.

Tutto questo lo darei per assodato, perché ogni founder agisce cosí senza che nessuno debba spiegare a lui o lei il perché. In questo senso il founder di un startup non è diverso da ogni altro imprenditore.

In cosa un technical founder è profondamente diverso dal un imprenditore qualunque?
Cos’è che non sappiamo nel momento in cui ci mettiamo in gioco come technical (co)founder di una startup?

Ecco la risposta: capire quanto velocemente deve muoversi una startup per rimanere rilevante nel mercato di riferimento.

Questo è qualcosa che deve avere un impatto su ciascuna delle decisioni che prendiamo ogni giorno.

Nella mia esperienza di founder e investitore, posso affermare con grande certezza che questo è il punto più frainteso dell'intero processo di creazione di una startup.

Ci sono molte cose che potrei dire su quelli che vengono considerati great technical founder, ma per questo articolo mi concentrerò solo su una cosa:

Move Fast!

Se perdi queste due parole, il 90% delle volte sei condannato a creare una startup di serie B, C, D o fallire miseramente.

Udite, udite 🥁🥁🥁

Nessuno farà a gara per investire in una startup che ha impiegato troppo tempo per "mettere il naso fuori dall'ufficio"—get out of the office²—e iniziare a parlare con gli utenti.

I tempi vanno battuti velocemente con in testa un obiettivo chiaro 👆(vedi sopra).

Spoiler Alert: Costruire un prototipo o prodotto più grande, complesso o raffinato rispetto agli obiettivi nell’immediato è il motivo più comune per cui una startup non si rilascia abbastanza velocemente.

P.S. Il video di Diana Hu spiega efficacemente quale dovrebbe essere il ritmo nelle fasi iniziali che precedono il lancio per cui userò la stessa terminologia.

Move fast: ma quanto velocemente?

Ideation Stage

Si inizia sempre con un'idea. Subito dopo si ha bisogno di un prototipo per mettere qualcosa di fronte agli utenti.

📣 Assioma: Il prototipo va rilasciato in giorni.

Spesso può essere qualcosa di diverso da un prototipo funzionante. Può essere un mockup Figma o un prodotto fake con dati codificati o una landing page. L’obiettivo è “solleticare” l’interesse degli utenti ed osservarne la reazione.

Come fai a sapere se avranno bisogno di ciò che vuoi creare?
Potresti dire: "Non lo so; prima mi serve un prodotto che possano usare".

🤔 Riformuliamo:
Sono entusiasti di ciò che stai creando?
Se un prodotto come il tuo fosse pronto adesso, vorrebbero usarlo?
Esiste un sottoinsieme di utenti per i quali il tuo prodotto sarebbe un bisogno urgente—urgent need?

Prima lo capisci, meglio è. E di sicuro, non vorrai passare giorni e notti a scrivere 100.000 righe di codice prima di rendertene conto.

Quindi, non dire "Ma nel mio caso è diverso" o "È impossibile; mi servono almeno un paio di mesi perché la costruzione richiede tempo".

Non stai ancora costruendo, stai acquisendo abbastanza fiducia—e possibilmente dati tangibili—che almeno un sottoinsieme dei tuoi utenti target è entusiasta di ciò che realizzerai.

Ottenere dati o, in generale, prove tangibili di questo fatto è fondamentale, soprattutto se si desidera raccogliere capitali prima di costruire il prodotto.

Building Stage

Quando inizi a costruire il prodotto, ricorda le due parole esatte che ho menzionato alcuni paragrafi sopra: move fast. Ancora?

L'obiettivo qui è convincere gli utenti a utilizzare il tuo prodotto, ma non il prodotto completo 🫨. Vogliamo rendere disponibili solo la quantità minima di funzioni—quelle chiave per soddisfare, in parte, la urgent need—affinchè gli utenti siano spinti ad usare—e pagare—il prodotto.

Si chiama MVP o qualsiasi altro nome vi aggradi. In un MVP la maggior parte delle funzioni non è automatizzata.

Ricorda che, dietro le quinte, gli utenti non sanno se un programma software gestisce le loro richieste o se il 70% del back office e back end siete tu e il tuo co-fondatore. Agli utenti, non importa.

In questa fase, vuoi più dati per consolidare la tua tesi, ovvero, “gli utenti vogliono disperatamente quello che sto costruendo”.

📣 Assioma: L’MVP va rilasciato in settimane.

Si parte da quest'ultima affermazione—settimane—e si costruisce a ritroso, non viceversa. E questo significa tonnellate di hacking e scorciatoie, quindi, come ha detto Diana nel video, "Kill the great engineer in you, and choose for speed instead of scaling".

Quando si parte e si affrontano le prime fasi di validazione della propria idea di prodotto è sempre necessario avere un approccio estrememente pragmatico e sviluppare un’attenzione maniacale ai tempi di rilascio. In questo modo si riescono a provare diverse strade, nel caso la prima o la seconda idea non producano dati sufficientemente confortanti.

I dati e non le sensazioni, sono quelli che vi faranno raccogliere capitale quando la vostra startup è ancora poco più che un pugno di slide.

In questo senso la famosa frase dal film “Field of Dreams”—L'uomo dei sogni— che diceva "If you build it, they will come", non funziona mai³ quando parliamo di startup.

Abituarsi ad agire in questo modo come technical founder è lo scoglio maggiore, perchè non ci viene naturale. Un software engineer vorrebbe metteresi a testa bassa e scrivere il miglior codice possibile, progettando un’architettura che scali all’infinito. Invece no.

I grandi e grandissimi technical founder hanno capito che prima di tutto devono collegare delle tracce per convincere loro stessi e gli investitori che la loro company ha trovato un blind spot sotto gli occhi di tutti, ma non coperto da quello che il mercato già offre.

Cosí si possono raccogliere un paio di milioni con il prodotto quasi totalmente da fare. Ma lo stesso approccio focalizzato sugli utenti porterà quasi sicuramente grandi frutti negli anni successivi.

Fino a quando si lavora in un clima di estrema accelerazione e incertezza, le iterazioni su prodotto e funzionalitá saranno all’ordine del giorno. Potenzialmente rilascerai una nuova versione del software ogni poco, anche più volte nel corso delle 24 ore.

E’ quindi meglio aspettare per assumere altra gente. Ciò rallenterebbe il processo di costruzione, impedendo al founding team di gestire queste prime fasi con l’agilità necessaria.

Di solito non sono un grande fan dei team con più di 2 co-fondatori, ma faccio eccezioni per i gruppi di N persone dove N-1 sono molto tecnici. I technical founder sono essenziali per costruire e iterare rapidamente senza assumere.

P.S. Però non esagerate. Il capitale diviso 4 o 5 persone puo lasciare velocemente scontenti tutti man mano che i round si susseguono e la diluizione aumenta.

Ci sarebbe molto altro da poter dire e diverse altri fasi da poter dettagliare, ma questo articolo è già abbastanza lungo.

Ultimo punto

Commentate, interagite, fateci sapere se il tema vi interessa e cercheremo di produrne altro. 📣 Ci serve molta più partecipazione da parte della community per alimentare le nostre speranze che il lavoro che facciamo con il Silicon Valley Dojo sia utile ai founder italiani.

Se avete anche solo un’idea buona, con qualche segnale come quelli che ho descritto sopra, applicate all’interview con noi sullo spazio che abbiamo riservato a chi parte dall'🇮🇹.

Ho appena allargato le maglie per i team composti in gran parte da founder con un Ph.D. perchè in quel caso l’etá può essere maggiore di quella prevista.

---

Per quelli di voi che non vedono l'ora di esplorare il tema che ho appena accennato, ecco il video di Diana Hu che ho citato nell’articolo:

P.S. Diana non credo che vada oltre ai 32-33 anni, ha già fatto una exit e oggi lavora come partner di YC.
Forza ragazzi e ragazze, hurry up!

1. I misfit, come si suol dire.

2. Con questo termine ci si riferisce al fatto che quasi sempre pensiamo di sapere cosa voglioni i nostri utenti senza chiede ai diretti interessati.

3. Quindi pensandoci bene, la foto di Jobs and Woz che ho messo in cima non è molto azzeccata, ma mi piace troppo.