Settembre 6, 2021 - di Pompilio Fiore
Ciao!
Mi chiamo Pompilio Fiore, sono il founder di “OkMe” e vivo a San Diego, in California.
Cosa è OkMe?
OkMe è un pulsante di emergenza per autisti Uber (2M negli USA) e funziona in questo modo: in caso di emergenza durante una corsa, l’autista può premere “OkMe Button”, un pulsante Bluetooth collocato dietro lo sterzo e “OkMe app”, l’app mobile connessa ad esso, invierà messaggi di emergenza a contatti prestabiliti oppure alle autorità, mostrando loro la posizione live GPS dell’autista in pericolo.
Si accede al servizio pagando una sottoscrizione mensile.
Come siamo andati dall’idea al lancio di OkMe in tempi rapidi e con soli 500 dollari?
Abbiamo ottenuto questo risultato attraverso un approccio Lean Startup/Design Thinking strutturato in 4 fasi:
VALIDATION (10 giorni e 150 dollari)
Dopo aver individuato il problema, e cioè “la sicurezza dell’autista ride-share”, ho lavorato molto rapidamente su 3 diverse fasi di validazione:
Allo stesso tempo ho sviluppato una landing page del sito (collegandole un sistema di analitica) e lanciato micro campagne marketing su Facebook volte ad analizzare l’interesse verso il prodotto, il CPC (cost per click) e a capire quale approccio marketing avesse potuto funzionare meglio (A/B testing).
La validazione è un passaggio fondamentale per un founder e non solo a livello di business. Spesso, è anche la chiave che ti permette di trovare co-founders.
Nel mio caso, grazie proprio alla validazione e alla presentazione di un prodotto in parte strutturato (app design, una bozza del brand, draft della strategia business e tech) ho trovato un incredibile technical co-founder (raro quando si lavora solo per equity), con il quale siamo arrivati al lancio del prodotto vero e proprio.
Tip
In generale, la cosa migliore è validare il prodotto senza scrivere una linea di codice, posticipando qualunque tipo di sviluppo fino al momento in cui questo fosse davvero necessario (semmai lo fosse).
MVP (4 settimane e 300 dollari)
Dopo questa validation rapida ma strutturata, avendo già un gruppo di beta testers pronti, abbiamo deciso di sviluppare un MVP.
Il Minimal Viable Product è la versione più basica possibile del prodotto, attraverso la quale si inizia il testing con veri users (beta testers).
A cosa serve l’MVP?
Secondo Eric Ries, autore di “The Lean Startup” (libro del 2011, ma con principi ancora molto validi) l’MVP è “la versione di un nuovo prodotto che permette al team di collezionare il numero massimo di validazioni, e conoscere in profondità lo user, con meno sforzo possibile”.
L’MVP inoltre deve essere “scrappy” (incompleto) e scalabile (cioè strutturato sin dall’inizio con in mente la sua scalabilità).
È inoltre, nella maggior parte dei casi, necessario se si cerca un finanziamento.
Come abbiamo lanciato un MVP (app + pulsante Bluetooth) con circa 300 dollari quando c’era di mezzo anche un hardware?
Premesso che il team deve essere in grado di costruire in house il prodotto e avere solo costi vivi necessari (server, domini internet, APIs etc), una delle tecniche più efficaci, quando si ha un hardware nel progetto, è quello di identificarne uno “off the shelf” (già disponibile sul mercato) da riadattare al tuo scopo.
Cosa abbiamo fatto?
Per OkMe, il pulsante da noi utilizzato era originariamente collegato ad una applicazione per fare selfies.
Abbiamo individuato questo pulsante su Alibaba, piattaforma B2B di e-commerce cinese, contatto la fabbrica in Cina, ottenuto l’SDK (Software Development Kit) della loro app di selfie e ordinato una trentina di pezzi (ordine minimo).
Abbiamo quindi creato la prima versione Android di “OkMe app” in grado di collegarsi a questo pulsante e, nel giro di 4 settimane, rilasciato un MVP.
Grazie a ciò, abbiamo azzerato i costi di sviluppo hardware e abbattuto drasticamente i tempi sia di testing che di GTM (go to market).
TESTING (6 settimane)
Con un MVP tra le mani, abbiamo iniziato il beta testing con gli autisti reclutati durante la fase di validazione.
Il testing, organizzato in sprints settimanali, è durato circa un mese e mezzo. Con i drivers abbiamo creato un feedback loop rapido e pragmatico volto alla massima comprensione delle funzionalità del prodotto, e allo studio di alcune metriche (anche se con dati molto limitati) che ci interessavano particolarmente.
Con i loro feedback, abbiamo raffinato l’app dando priorità alle funzioni con maggiore impatto e minor tempo di sviluppo.
Siamo quindi arrivati al lancio di un prodotto basato sui feedback degli users, in tempi rapidi e con 500 dollari.
LANCIO
Il GTM (go to market) è qualcosa che deve essere strategicamente pensato sin dall’inizio (già nelle fasi di validazione) soprattutto se il budget è limitato.
Noi abbiamo deciso di fare una prima release ufficiale su Product Hunt per vedere le reazioni della comunità tech e cercare quel minimo di visibilità utile ad aprirci altre porte.
Product Hunt, con la sua community mondiale, può essere una vetrina molto importante per il prodotto. Ci sono tecniche per ottimizzare un lancio su questa piattaforma che possono fare la differenza.
Fortunatamente OkMe è stato votato tra i “5 prodotti top del giorno” portando migliaia di visite sul sito da tutto il mondo e dandoci quella iniziale visibilità che cercavamo in modo organico e gratuito.
POST LANCIO
Grazie a questo piccolo successo su Product Hunt, la notizia di OkMe è stata ripresa da qualche media e, nei giorni successivi al lancio, diverse aziende interessate a collaborare con noi hanno iniziato a contattarci.
Abbiamo quindi deciso dai mettere da parte l’idea della vendita diretta all’autista e di focalizzarci su una strategia B2B2C.
Dopo aver chiuso una prima partnership con una startup americana, l’occasione più grande è arrivata quando una società tech europea, con una rete importante di distribuzione nel modo dei taxi, ci ha approcciati con l’interesse di rivendere OkMe su scala.
Ci siamo quindi focalizzati su questa opportunità lavorando al meglio sulla parte commerciale, di business strategy e prodotto: sfortunatamente, dopo diversi mesi, non siamo riusciti a chiudere l’accordo.
Questo reselling agreement sarebbe stato molto importante perché avrebbe creato il primo cash flow ed aiutato a smuovere un investimento sul quale stavamo lavorando parallelamente con un investitore molto noto negli Stati Uniti.
Non avendo chiuso questo accordo commerciale e di conseguenza neanche l’investimento, abbiamo tentato diversi pivots sia a livello di prodotto che di business.
Per ampliare il TAM (total addressable market) ed essere più appetibili agli occhi di investitori che a quale punto pensavamo indispensabili, abbiamo tentato di riadattare la tecnologia sviluppata per OkMe a nuovi prodotti di sicurezza.
Esempi sono stati “GoGo Walk”, un pulsante di emergenza per dog walkers, e “Scudo”, un’app di sicurezza per studenti universitari.
Allo stesso tempo abbiamo cercato investitori “strategici” (in grado di favorire per esempio partnerships con Uber o Lyft), acceleratori di startup, e tentato di avere una forte esposizione mediatica.
Dopo un pitch competition a Las Vegas, “Shark Tank”, uno degli show televisivi più popolari e competitivi negli USA, è interessato ad OkMe. Dopo diversi steps, che comunque hanno richiesto molto lavoro, non siamo riusciti ad arrivare alla messa in onda.
Il momento conclusivo è giunto con il Covid che, danneggiando fortemente l’industria ride-share, la supply chain e in generale tutti i mercati, ha dato la spallata finale ad un lavoro che, a quel punto, stavamo già portando avanti con difficoltà.
ABBANDONARE OkMe
Dopo diversi errori, imprevisti (come pandemia e guerra commerciale USA-Cina), pivots non riusciti e problematiche nate nel team, abbiamo deciso di abbandonare OkMe e intraprendere nuovi percorsi.
Questa è stata una scelta molto difficile, ma credo professionalmente matura.
Penso sia sinonimo di crescita e di esperienza arrivare ad un giusto bilanciamento tra il “never give up” (quella ferrea determinazione e resistenza che una/un founder deve avere) e il capire quando è il momento di cambiare direzione o chiudere un percorso.
Così è stato per OkMe.
ERRORI E SUGGERIMENTI
Qui di seguito alcuni errori che ho fatto e qualche suggerimento che spero possa essere utile.
TEAM
Il Team, è la startup.
L’errore più grande che ho fatto penso sia stato sviluppare e lanciare OkMe su una struttura societaria pre-esistente, danneggiando involontariamente il team.
Mi spiego meglio: prima di OkMe, ho raccolto qualche fondo, creato una società e lanciato una dating app.
Quando ho cambiato rotta, ho ancorato OkMe e il nuovo team a quella struttura societaria formatasi intorno al progetto della dating app.
Creare un prodotto ex novo su una società pre-esistente, ha procurato problemi sia a livello di team che di investimenti.
A livello di team, per motivi legali, il mio cofounder, con il quale ho sviluppato OkMe (ma non la dating app), non ha potuto essere socio alla pari della società.
Il fatto che il mio cofounder non fosse un socio con pari quote, ha creato un senso di “ownership relativa” e non di “ownership totale” come invece dovrebbe essere.
Una ownership relativa si rispecchia in uno “sforzo relativo” (soprattutto nei momenti difficili), indebolendo la coesione del team e quindi aumentando le possibilità di fallimento.
Questo mio errore ha impattato sicuramente OkMe in uno dei pilastri fondamentali che è l’affiatamento del team, ostacolando e rendendo macchinoso quel lavoro che forse ci avrebbe fatto andare avanti.
A livello di investimenti, una situazione del genere rende il cap table societario sballato in partenza, andando, molto probabilmente, a compromettere futuri rounds di investimento e complicando la parte legale in modo esponenziale. È molto importante mantenere il cap table “clean”.
Tip: struttura e coesione
Nel momento in cui si decide di fondare una startup, cosa che dovrebbe avvenire quando si ha un minimo di validazione, un funding team e un MVP, è importante impostarla correttamente sia a livello burocratico che tra le/i founders.
A livello burocratico dipende dal Paese, dal tipo di impresa che si sta effettuando e dalle strategie business che si pensano di attuare.
A livello interpersonale, è meglio che le/i founders abbiano quote paritarie perché si presume che lo sforzo e il lavoro messo a disposizione sia paritario. Non esiste “l’idea è mia” quando non si sa neanche quale, alla fine, sarà il prodotto.
Una parità di quote nel team è un modo per mantenere entusiasmo, coesione, solidità e senso di ownership durante il percorso complesso (soprattutto iniziale) di impresa.
Sarebbe ideale che, anche il founding team, avesse le quote in vesting (cioè non ancora acquisite).
Un sistema di vesting tra le/i founders, oltre a creare obiettivi interni da raggiungere, dà fiducia a investitori e partners poiché, se qualcuno andasse via troppo presto, non porterebbe con sé un pezzo di società solo perché “founder”.
La cosiddetta “one year cliff” è la norma per iniziare a maturare le quote in vesting.
Fondare una startup non è una scelta da prendere alla leggera: bisogna essere pronti ad affrontare un percorso complesso che, esaurito l’entusiasmo iniziale, può diventare molto faticoso sia fisicamente che mentalmente.
Per questo è fondamentale farlo, quando necessario, strutturalmente nel modo migliore (per garantire una fluidità legale nei passaggi successivi) e con le persone giuste (per avere maggiori possibilità di arrivare a quei passaggi successivi).
SVILUPPO
Dopo errori fatti in passato, OkMe è stato sviluppato e lanciato utilizzando tecniche basate su rapidità di esecuzione e budget molto bassi (lean startup). Soprattutto, però, è stato sviluppato e lanciato senza ricorrere a persone esterne al team.
Prima di OkMe, lavorando su altri progetti, ho fatto una miriade di sbagli.
Uno dei più grandi è stato quello di affidare la parte dello sviluppo tecnologico a terzi, cosa non indicata per startup che vogliono lanciare un prodotto, scalarlo e tentare una exit (acquisition/IPO).
Anche se non direttamente collegato ad OkMe, qualche suggerimento a riguardo credo possa essere utile.
Tip: il “Founding team”
Il prodotto iniziale dovrebbe essere validato, sviluppato e lanciato in house, con fondi minimi e personali per coprire i costi vivi di MVP e validazione.
Un MVP ha bisogno di molte iterazioni per arrivare, si spera, ad un product market fit: affidare ad esterni lo sviluppo del prodotto iniziale non è funzionale né a livello tecnologico, né economico, né di business.
Cambiare programmatore più volte crea un codice frammentato, difficile da scalare e spesso ostico per la/il programmatore successivo, la/il quale tenderà, se possibile, a riscrivere il codice da capo.
Tutto ciò, oltre a creare una dipendenza tecnologica da terzi, è anche molto costoso quindi, spesso, non sostenibile: avere un technical cofounder è fondamentale per un tech product.
Inoltre, è davvero difficile che un investitore professionista investa in una startup dove il core team non sia in grado di sviluppare e gestire almeno un MVP.
Riuscire a creare un team, oltre ad essere essenziale, è anche una sorta di prima validazione sia dell’idea che della leadership del founder(s): qualcuno oltre te ci crede e ti sta seguendo!
È da considerare che, se non si riesce a creare un primo team (anche molto piccolo, ma in grado di sviluppare un MVP), probabilmente c’è qualche cosa che non va a livello di leadership o di prodotto.
Cofounders “non tecnici”, comunque, dovrebbero capire per grandi linee l’infrastruttura tecnologica che si sta utilizzando e come funziona il prodotto tecnicamente. Questo aspetto è importante ed aiuta molto sia a livello di management (prodotto e business) che nel rapporto interpersonale con il technical cofounder ed il resto del team.
PRODOTTO
Un punto di forza di OkMe è stata la sua specificità.
Allo stesso tempo però, lavorare su un problema di nicchia è stato sicuramente anche uno svantaggio.
Il mercato a cui puntavamo era di circa 2 milioni di users che, se convertiti ad esempio al 5% avrebbero generato un MRR (monthly recurring revenue) di circa 400K dollari lordi al mese.
L’occasione, quindi, era abbastanza grande per essere interessante, ma allo stesso tempo troppo piccola per attirare l’interesse di tech investors abituati, soprattutto qui negli Stati Uniti, a numeri ben più alti.
Un’altra problematica è stata la parte relativa alla protezione del prodotto e alla sua vulnerabilità.
Dato che non avevamo un patent, oppure accesso a dati “unici” da garantirci un solido vantaggio competitivo, abbiamo puntato molto sul “first to market” e quindi su branding, storytelling e, soprattutto, partnerships strategiche.
Avere Mark Cuban come investitore, apparire su Shark Tank o chiudere accordi di business con grandi aziende ci avrebbe dato quel vantaggio competitivo che non potevamo ottenere da un punto di vista prettamente tecnologico.
Prima di iniziare a lavorare su OkMe, abbiamo calcolato, valutato e accettato questi rischi.
Di certo potevamo fare meglio, come, ad esempio, allargare da subito il TAM (total addressable market) mettendo sulla roadmap più prodotti che utilizzavano la stessa tecnologia sviluppata per OkMe.
Dovevamo puntare in quella direzione sin dall’inizio, ed essere molto strategici ed aggressivi sotto quell’aspetto.
Inoltre dovevamo calcolare meglio il fattore hardware il quale innalza le problematiche a tutti i livelli (costi, sviluppo, distribuzione, resi, adoption, supply chain, costumer care) e crea elementi di rischio molto più alti rispetto ad un prodotto unicamente software.
Per esempio, nel momento in cui è iniziata la guerra commerciale tra USA e Cina sotto Trump, le ripercussioni si sono sentite anche per noi. L’ordine minimo per il nostro pulsante Bluetooth è sbalzato, nel giro di qualche giorno, da poche decine a migliaia di pezzi, complicando le cose rapidamente.
Anche a livello di GTM (go to market), con un hardware, le problematiche aumentano considerevolmente soprattutto con budget limitati.
Basta un intoppo nella supply chain, come è stato il Covid, o un cambio di tecnologia che danneggia la comunicazione tra hardware e software, per creare grandi difficoltà.
Inoltre, ogni Paese ha le sue regole di import/export quindi la distribuzione deve tener conto delle specifiche caratteristiche di ogni legislatura nella quale si vuole operare, aumentando considerevolmente le problematiche di scalabilità del prodotto.
Tali dinamiche hanno ostacolato potenziali accordi commerciali di distributori interessati alla rivendita di OkMe in Brasile e Sud Africa.
Questo è stato uno dei motivi per cui abbiamo puntato su partnerships e localizzazione: avere grossi pre-ordini di OkMe, minimizzare l’up front cost, puntare su mercati specifici e ridurre i rischi di vendita diretta al consumatore ci sembravano la cose migliori da fare.
Il nostro scopo, essenzialmente, era quello di mantenere il team molto ristretto (massimo 3 persone) e agile, costi di operazione ai minimi e un numero discreto di users per arrivare, nel più breve tempo possibile, a vendere l’azienda ad uno dei giganti di ride-share o di sicurezza.
Tip
Chiaramente ogni situazione è diversa, ma è importante analizzare tutte le dinamiche dirette e indirette che girano intorno al prodotto e valutarle accuratamente sin dall’inizio.
Poi gli imprevisti (anche quelli personali) sono sempre da mettere nel conto ed è fondamentale imparare a gestirli nella maniera più lucida e dinamica possibile.
CONCLUSIONE
OkMe è stata un’esperienza di crescita professionale e personale senza precedenti.
Una sfida che ha aperto e continua ad aprire nuove porte, che ha fortemente rafforzato competenze tecniche, umane e mentali e che ci ha connesso a persone incredibili.
Non voglio essere banale, ma davvero la cosa fondamentale è capire gli errori, maturare professionalmente, incrementare il network e applicare tutte le nuove capacità acquisite alle future imprese professionali e personali.
Un growth mindset è fondamentale per chiunque lavori in tech, un’industria dove, come nella “società liquida” di Bauman,“il cambiamento è l’unica cosa permanente, e l’incertezza è l’unica certezza”.
Questa attitudine, per me indispensabile, credo sia un modo per crescere costantemente come leader, professionista e cittadino.
Links utili:
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management