Le startup sono essenzialmente macchine che costruiscono MVP (prodotti minimi vitali) che aiutano a rispondere alle domande e riducono gradualmente il rischio della proposta di valore dell'azienda.
La chiave è che ogni MVP creato da un'azienda deve essere focalizzato al laser sulla risposta a una domanda molto particolare. Se fai qualcosa di più, è tempo e fatica sprecati. Nella mia esperienza, molte startup si preoccupano di scalare troppo presto, sprecando risorse per qualcosa che potrebbe non essere mai necessario.
Questa tendenza è particolarmente evidente nelle start-up fondate da persone provenienti da discipline ingegneristiche in aziende di grandi dimensioni. Ma le cose che devi fare per inviare il codice su Facebook, Netflix, Amazon o Google non si applicano allo stesso modo alle startup in fase iniziale.
Le startup in fase iniziale possono avere poche centinaia o migliaia di clienti e ogni elenco di clienti presenta una serie unica di sfide.
Non fraintendere; È sempre meglio assicurarsi che il codice sia relativamente sicuro e scritto in modo da non degradare l'esperienza del cliente. Ma i fondatori tecnici spesso sbagliano e passano molto tempo a rafforzare il codice (cioè renderlo sicuro) oltre a scriverlo e implementarlo in modo tale che sia scalabile.
Ma questo non funziona del tutto quando sei in modalità proof of concept.
I fondatori inesperti spesso si mettono sulla difensiva su questo genere di cose, preoccupandosi troppo se il prodotto o la funzionalità che hanno appena creato offrirà un'esperienza utente senza interruzioni o preoccupandosi se può gestire un milione di utenti simultanei. Sì, queste cose sono importanti, ma potrebbero non essere giuste in questo preciso momento.
La mentalità nelle startup in fase iniziale dovrebbe essere quella di creare MVP per rispondere alle domande. Tieni presente che MVP è ancora un termine terribile; non è né un prodotto né praticabile. Inoltre, in molti casi non è così “minimale”. Un MVP è la minima quantità di lavoro che puoi fare per confermare o rifiutare un'ipotesi per la tua startup.
Se l'ipotesi è: "Un milione di clienti può utilizzare questa app contemporaneamente?" Naturalmente, questo è il momento giusto per ottimizzarlo entro un centimetro della sua durata. Ma, quando stai costruendo un'attività nei primi giorni, questa è raramente la domanda e, a meno che tu non sia in particolari categorie di app che devono essere resilienti a notevoli quantità di traffico, è improbabile che gli investitori se ne preoccupino.
In una delle start-up con cui ho aiutato, l'azienda aveva un prodotto in cui mettevano decine di migliaia di persone in una sala d'attesa e quando scadeva un conto alla rovescia, tutti potevano entrare nel prodotto. Questa si è rivelata una sfida interessante: cosa succede quando 10,000 persone accedono esattamente alla stessa parte di un'applicazione Web entro un secondo l'una dall'altra?
Come puoi immaginare, anche piccole inefficienze nella piattaforma hanno causato gravi colli di bottiglia e un potenziale degrado del servizio. A breve termine, ha "risolto" il problema attivando una serie di server aggiuntivi e facendo entrare le persone in pochi minuti; avere 500 persone che accedevano contemporaneamente al codice leggermente inefficiente era molto meno problematico che avere 10,000 persone che accedevano tutte contemporaneamente.
Elegante? No. Ha funzionato? Sì, e aveva senso perché, all'epoca, l'azienda non era esplicitamente interessata alla possibilità che il servizio potesse servire 100.000 clienti contemporaneamente. Avviso: non è stato possibile, e al momento necessario, quella parte del codice è stata rifattorizzata in modo tale da garantirne la possibilità.
Nelle prime fasi, le domande tendono ad essere: "È possibile quello che stiamo cercando di fare?" o "La gente pagherà per questo?" o "Possiamo convincere un partner aziendale a integrare questo?" o "Possiamo acquisire clienti a un costo ragionevole?" o "Possiamo farlo a un prezzo sensato?" o "Come funziona l'economia unitaria di questo prodotto mentre ridimensioniamo?"
Per un'attività pre-seed, non hai bisogno di un design e di una scalabilità perfetti; devi creare abbastanza prodotto e trazione per ottenere il feedback degli utenti. Da lì, puoi iterare e creare valore per i clienti. Una volta che inizi a offrire un valore sufficiente per cui i clienti sono disposti a pagare, puoi iniziare a considerare di investire di più nella scalabilità.
L'overingegnerizzazione di un prodotto troppo presto non è né importante né intelligente. È un controindicatore: dice agli investitori che non sai cosa è importante nella fase attuale della tua startup.
Quando l'attenzione è focalizzata, viene eseguita la cartina di tornasole: la tua attività attuale sta contribuendo alle garanzie per aiutarti con il tuo prossimo round di raccolta fondi? In caso contrario, probabilmente stai lavorando a qualcosa che sembra estremamente importante, ma non è appropriato per lo scenario.
Questo è un problema - potresti sempre dedicare più tempo alla creazione di qualcosa di più elaborato, più veloce, più carino o più scalabile - ma il mantra all'avvio dovrebbe essere "abbastanza buono è abbastanza buono". È incredibile quanto velocemente puoi andare una volta che l'azienda lo interiorizza.
