Esperti di startup discutono del fare cose che non scalano
- Aisha Washington
- 1 giorno fa
- Tempo di lettura: 8 min
I fondatori nelle prime fasi sono spesso incoraggiati a pensare alla scalabilità fin dall’inizio. Viene chiesto loro come i sistemi supporteranno milioni di utenti, come l’acquisizione dei clienti diventerà ripetibile e come le operazioni potranno espandersi senza che i costi crescano allo stesso ritmo. Sono domande legittime, ma gli esperti di startup in questa discussione di Y Combinator sostengono che spesso vengano poste troppo presto.
I relatori riprendono l’influente saggio di Paul Graham “Do Things That Don’t Scale” e spiegano perché il suo messaggio resti centrale per costruire un’azienda da zero. Attraverso esempi che includono Airbnb, Fleek, Stripe, Algolia, Instacart e DoorDash, sostengono che lo sforzo manuale non sia semplicemente un compromesso temporaneo accettabile. Se usato deliberatamente, è un modo potente per testare la domanda, comprendere i clienti e scoprire quali parti di un’attività meritino davvero di essere scalate.
Perché il mondo delle startup aveva bisogno di un approccio diverso
Secondo i relatori, l’entusiasmo della Silicon Valley per i sistemi scalabili è cresciuto in parte osservando aziende internet di straordinario successo. Google ha dimostrato come il software e la distribuzione online potessero raggiungere un pubblico enorme con uno sforzo incrementale relativamente ridotto. Fondatori e investitori hanno naturalmente iniziato a cercare modelli di crescita altrettanto ripetibili.
Questa ambizione è gradualmente diventata un vincolo. Gli imprenditori si sono sentiti sotto pressione per presentare una soluzione scalabile prima di aver dimostrato che qualcuno ne avesse bisogno. Potevano trascorrere mesi a progettare sistemi automatizzati per una domanda ipotetica, restando al contempo lontani dai clienti reali.
Il saggio di Paul Graham ha messo in discussione questa sequenza. Come spiegano i partecipanti al panel, la maggior parte delle giovani startup non è minacciata da una domanda eccessiva o dal collasso dell’infrastruttura. Il rischio immediato è molto più semplice: potrebbero non attirare mai abbastanza utenti, oppure costruire qualcosa che le persone non apprezzano.
La priorità pratica è quindi risolvere il problema direttamente, anche se il primo metodo richiede molto lavoro. La scalabilità conta alla fine, ma solo dopo che l’azienda ha trovato qualcosa che valga la pena scalare.
Arrivare da zero a uno viene prima
La discussione presenta il progresso di una startup come una serie di vincoli immediati. All’inizio, la sfida non è servire in modo efficiente il milionesimo cliente. È conquistare il primo cliente, offrire il primo risultato positivo e capire perché quella persona ha scelto il prodotto.
Questo cambia il modo in cui i fondatori dovrebbero valutare il lavoro iniziale. Un’attività che appare inefficiente in un’azienda matura può essere del tutto razionale quando risponde rapidamente a una domanda cruciale. Accompagnare personalmente un cliente nell’onboarding, assemblare manualmente un servizio o improvvisare un flusso di lavoro interno può rivelare più di settimane trascorse a costruire infrastrutture in isolamento.
I relatori usano Airbnb come esempio emblematico. I suoi fondatori avevano bisogno di inserzioni migliori, quindi aiutarono gli host a produrre fotografie di qualità più elevata. Viaggiare verso le proprietà e migliorare le inserzioni una per una non avrebbe mai potuto essere il modello operativo permanente. Eppure affrontava il problema urgente dell’azienda: rendere il marketplace più attraente e generare abbastanza attività perché la crescita potesse iniziare.
La lezione non è che ogni fondatore debba replicare la tattica di Airbnb. È che i fondatori dovrebbero identificare l’ostacolo direttamente davanti a loro ed essere disposti a risolverlo senza aspettare un sistema elegante.
Fleek ha imparato il marketplace prima di costruirlo
Fleek offre un’illustrazione particolarmente vivida dell’apprendimento attraverso operazioni manuali. L’azienda è iniziata senza un sito web completo, un inventario di abbigliamento o una sofisticata infrastruttura di marketplace. I fondatori si sono invece recati presso grossisti londinesi, hanno sviluppato relazioni e collegato direttamente l’offerta con i negozi.
Il panel descrive come il team abbia persino trasportato vestiti tra grossisti e rivenditori. Da una prospettiva convenzionale di efficienza, vedere i fondatori trasportare personalmente la merce sembra un fallimento del processo. Da una prospettiva di apprendimento, tuttavia, li ha collocati dentro la transazione.
Partecipando al lavoro, Fleek poteva osservare ciò che i rivenditori desideravano, come si comportavano i grossisti, quali prezzi funzionavano e come la domanda rispondeva ai cambiamenti. Non erano risposte astratte raccolte tramite sondaggi. Erano intuizioni ottenute aiutando acquirenti e venditori reali a completare acquisti reali.
Dopo circa quattro mesi di attività manuale, i fondatori avevano conoscenze sufficienti per spostare l’attività online. Il marketplace è stato informato dal comportamento che il team aveva già osservato, anziché da supposizioni su come il mercato avrebbe dovuto funzionare.
Un onboarding pratico crea prodotti migliori
I relatori citano Stripe e Algolia come ulteriori esempi di fondatori che riducono la distanza tra lo sviluppo del prodotto e la realtà dei clienti. I fondatori di Stripe aiutavano i primi utenti a installare il loro software di pagamento invece di limitarsi a inviare documentazione e aspettare. Allo stesso modo, Algolia ha assistito Product Hunt nell’implementazione della ricerca.
L’implementazione diretta ottiene più dell’attivazione di un nuovo account. Espone passaggi di configurazione confusi, dipendenze tecniche nascoste e differenze tra ciò che i clienti dicono di aver bisogno e ciò con cui faticano nella pratica.
Può anche cambiare la relazione. Un cliente che ha lavorato a fianco di un fondatore è più propenso a condividere feedback sinceri rispetto a chi invia un ticket di assistenza a un’azienda sconosciuta. Questa fiducia offre alla startup accesso a intuizioni di prodotto più precise.
I partecipanti al panel descrivono questa attenzione personale — il “FaceTime” del fondatore — come un vantaggio che le aziende consolidate spesso non possono eguagliare. Un concorrente più grande può disporre di maggiori risorse, ma di solito non può avere i propri fondatori personalmente impegnati nel successo di ogni piccolo cliente. Per una startup con un prodotto incompleto e una credibilità limitata, una cura visibile può diventare parte della proposta di valore.
Ottimizzare il lavoro iniziale per l’apprendimento
L’argomento centrale della discussione è che i fondatori dovrebbero ottimizzare la fase iniziale per l’apprendimento anziché per l’eleganza operativa. L’erogazione manuale aiuta a stabilire se il risultato promesso sia realmente prezioso prima che il team codifichi quel processo nel software.
Questo principio può essere tradotto in una semplice sequenza:
Identificare l’incertezza più importante dell’attività.
Progettare il modo credibile più rapido per testarla con clienti reali.
Svolgere il lavoro manualmente quando l’automazione ritarderebbe la risposta.
Registrare ciò che crea ripetutamente valore o genera attrito.
Costruire sistemi solo dopo che il modello diventa chiaro.
Questo non significa trattare ogni processo improvvisato come prova di un’attività sostenibile. Il lavoro manuale è utile quando genera evidenza. I fondatori devono comunque determinare se la domanda si ripete, se i clienti pagheranno e se il servizio sottostante potrà infine sostenere un modello di business attraente.
Ciò che dovrebbero evitare è confondere la rifinitura tecnica con la convalida. Una piattaforma progettata magnificamente non può compensare un prodotto indesiderato.
Instacart e DoorDash hanno testato la domanda con strumenti improvvisati
La storia di Instacart mostra come i fondatori possano testare un marketplace prima di ottenere tutte le partnership che una versione matura richiederebbe. Come raccontato nel video, l’azienda è stata lanciata senza relazioni formali con i supermercati. Il team acquistava articoli da Trader Joe’s, li fotografava e li inseriva online per vedere se i clienti avrebbero ordinato generi alimentari con consegna a domicilio.
Questo approccio ha aggirato un ciclo potenzialmente lungo di negoziazioni per le partnership. Invece di chiedere ai rivenditori di sostenere un concetto non dimostrato, i fondatori hanno prima raccolto prove che i consumatori desiderassero il servizio.
DoorDash ha seguito una strada altrettanto pragmatica. I relatori descrivono il suo prodotto iniziale come qualcosa assemblato in un solo giorno con strumenti comuni, inclusi Google Drive e Find My Friends. L’obiettivo non era creare immediatamente una piattaforma logistica durevole. Era scoprire se i consumatori locali avrebbero ordinato consegne di ristoranti e se i fondatori fossero in grado di evadere quegli ordini.
Questi esperimenti hanno sfruttato un autentico vantaggio delle startup: piccoli team possono coordinare temporaneamente il lavoro in modi che sarebbero impraticabili per grandi organizzazioni. Hanno meno processi da proteggere, meno infrastrutture da integrare e maggiore libertà di cambiare direzione dopo ogni risultato.
I sistemi imperfetti rendono l’adattamento più rapido
Fare le cose manualmente consente a un team di rivedere l’esperienza senza ricostruire un intero prodotto. Se ai clienti non piace un passaggio, i fondatori possono cambiarlo all’ordine successivo. Se un’ipotesi si rivela falsa, possono abbandonarla prima che venga incorporata in mesi di lavoro ingegneristico.
I relatori sostengono inoltre che i fondatori non dovrebbero temere eccessivamente gli errori operativi iniziali. I problemi creati dalla crescita della domanda spesso generano forti incentivi a trovare rapidamente soluzioni. Quando una startup ha finalmente più utenti di quanti il suo processo improvvisato possa supportare, la necessità di automazione diventa concreta, urgente e più facile da definire.
Ecco perché le startup raramente falliscono perché hanno attirato troppi clienti e non sono riuscite a scalare. I problemi di capacità sono dolorosi, ma portano con sé prove della domanda. La mancanza di utenti è molto più pericolosa perché non offre né ricavi né una ragione chiara per continuare a costruire.
L’implicazione per l’ingegneria è importante: rimandare l’infrastruttura può essere una forma di velocità, non di negligenza, purché le scorciatoie siano comprese e non creino rischi inaccettabili per i clienti.
Sapere quando costruire per la scala
Il lavoro non scalabile è un metodo di scoperta, non una filosofia permanente. Una volta che una startup comprende il lavoro ricorrente, osserva una domanda sostenuta e incontra colli di bottiglia manuali, deve iniziare a trasformare ciò che ha imparato in sistemi ripetibili.
Il panel osserva che consulenti e investitori esperti possono aiutare i fondatori a riconoscere questa transizione. Scalare troppo presto spreca risorse su ipotesi non verificate. Scalare troppo tardi può danneggiare la qualità del servizio, esaurire il team e impedire all’azienda di cogliere la domanda.
Un segnale utile è la ripetizione. Se i fondatori continuano a risolvere lo stesso problema più o meno nello stesso modo, il software potrebbe standardizzare il processo. Un altro è il costo opportunità: quando l’erogazione manuale consuma tempo che potrebbe produrre apprendimento o crescita più preziosi, l’automazione diventa sempre più attraente.
L’obiettivo non è eliminare il coinvolgimento umano fine a sé stesso. È automatizzare le parti che ora sono comprese, preservando al contempo il contatto ravvicinato ovunque i clienti stiano ancora insegnando qualcosa di importante all’azienda.
La consulenza può essere un ponte, ma non la destinazione
I relatori affrontano anche il confine tra una startup software e una società di consulenza. Una giovane azienda può generare ricavi fornendo servizi pratici alle imprese, e il suo primo prodotto può semplicemente rendere quel servizio più rapido o affidabile.
Questo può essere un punto di partenza produttivo. Il lavoro di consulenza espone i fondatori ad ambienti operativi reali e offre loro una conoscenza dettagliata dei problemi dei clienti. Può anche finanziare lo sviluppo iniziale.
Tuttavia, il panel avverte che i soli ricavi dai servizi non creano un’azienda software ad alta crescita. Il lavoro personalizzato si espande principalmente aggiungendo persone, mentre un prodotto scalabile può servire molti più clienti senza una crescita proporzionale dell’organico. Obiettivi di crescita ambiziosi aiutano a imporre la distinzione: se si prevede che l’attività cresca di un ordine di grandezza, i fondatori devono infine trasformare le competenze ripetute in un prodotto anziché vendere indefinitamente lavoro su misura.
Il vantaggio duraturo dello sforzo dei fondatori
Il messaggio conclusivo del video è che la disponibilità a svolgere compiti scomodi, manuali o apparentemente minori rappresenta uno dei vantaggi più forti di una startup rispetto ai concorrenti consolidati. Questo lavoro avvicina i fondatori ai clienti, accelera gli esperimenti e crea opportunità per offrire un servizio insolitamente attento.
Il principio più profondo non è una celebrazione dell’inefficienza. È una sequenza disciplinata. Prima, capire di cosa hanno bisogno le persone. Poi dimostrare che agiranno in base a quel bisogno. Fornire il risultato con qualunque metodo responsabile sia disponibile, studiare il modello ricorrente e solo allora investire nel renderlo ripetibile.
La scalabilità diventa preziosa quando la domanda se l’è meritata. Prima di quel momento, il sistema più efficace del fondatore può essere semplicemente curiosità, urgenza e disponibilità a svolgere personalmente il lavoro.
