Il Minimum Viable Product non è un prodotto, ma un processo

“Sapete che il vecchio ha visto un aereo che volava dalla California alle Hawaii fuori rotta per il 99% del tempo, ma che si correggeva continuamente e così facendo riusciva a dirigersi a destinazione? Lo stesso vale per le startup di successo, ad eccezione del fatto che non potranno mai dirigersi verso l’Alaska”. –Evan Williams

IL SOLITO PROCESSO ERRATO

Per prima cosa, un team ha un’idea. Poi realizza un Minimum Viable Product (MVP) come Proof of Concept per dimostrare che ha le competenze necessarie per realizzare il progetto; per farlo spende molto tempo a discutere su quali caratteristiche includere o escludere dall’MVP. Infine, se l’MVP funziona bene, progetta di costruire il prodotto completo, maturo e stabile.

Cosa c’è di sbagliato in questo? Perché va tutto storto poi per il 99% delle startup?

Il problema è che questi team non capiscono il senso di un MVP! Un MVP non è solo un prodotto con un sottoinsieme di “features” o un modo per far uscire il prodotto dalla porta un po’ prima. Infatti, l’MVP non deve essere per forza un prodotto e non è qualcosa che si costruisce una sola volta. Non funziona come nel grafico sotto riportato:

MVP COME PROCESSO

Un MVP è un processo che si ripete più e più volte: identificate la vostra ipotesi più rischiosa, trovate il più piccolo esperimento possibile per testare tale ipotesi e usate i risultati dell’esperimento per correggere la rotta. 

L’MVP è un processo e non un prodotto perché si basa su un obiettivo legato al tempo e le risorse a disposizione, non sulle funzionalità che si vogliono sviluppare. La domanda per realizzare un MVP non è: <<quali funzionalità mettiamo nell’MVP?>>, la giusta domanda è:

Quando si costruisce un prodotto, si fanno molte ipotesi. Si suppone di sapere cosa gli utenti stanno cercando, come dovrebbe funzionare il design, quale strategia di marketing utilizzare, quale architettura funzionerà nel modo più efficiente, quale strategia di monetizzazione lo renderà sostenibile e quali leggi e regolamenti si devono rispettare. Non importa quanto siate bravi, alcune delle vostre ipotesi saranno sbagliate. Il problema è che non si sa quali.(1)

In un’autopsia di oltre 100 startup, CB Insights ha scoperto che la causa numero uno del fallimento nelle prime fasi di sviluppo delle startup (circa il 50% dei casi) era che le startup non rispondevano a nessuna necessità di mercato. Quasi la metà di queste startup ha impiegato mesi o addirittura anni per costruire un prodotto prima di scoprire di essersi sbagliata nella sua ipotesi più centrale, cioè pensare che qualcuno fosse interessato a quel prodotto.

L’unico modo per scoprirlo se il prodotto ha senso di esistere è di metterlo di fronte a clienti e utenti reali il più rapidamente possibile. E quando lo si fa, spesso ci si ritrova a dover modificare il prodotto interpretando i feedback dei clienti/utenti. Infatti, non si dovrà cambiare direzione solo una volta, ma più e più volte. La capacità di essere flessibili nel cambiare direzione in funzione dei feedback, è una caratteristica fondamentale di un team di startup. Troppo spesso si vedono founder che si innamorano della propria idea e sviluppano il prodotto solo sulle proprie ipotesi, ricadendo così in quel 50% delle startup che falliscono perché non incontrano un bisogno di mercato.

Di seguito viene riportato un grafico che mostra il processo corretto di sviluppo di un MVP per una startup.

Questo non riguarda solo lo sviluppo del prodotto, riguarda anche lo sviluppo dei contenuti; ad esempio, quando si scrive un libro o un saggio bisogna produrre molte bozze e dedicare molto tempo all’editing. Allo stesso modo quando si realizza un prodotto, spesso bisogna tornare indietro e modificare quanto sviluppato.(2) Ogni sforzo umano creativo richiede un’enorme quantità di prove ed errori. Non c’è via di scampo.

CAPISCI DOVE SBAGLI E FAI DI MEGLIO

In un mondo di tentativi ed errori, vince chi riesce a trovare gli errori più velocemente. Alcuni chiamano questa filosofia “fallire velocemente”. Eric Ries l’ha chiamata Lean. Kent Beck e altri programmatori l’hanno chiamata Agile. Comunque lo si chiami, il punto è scoprire quali delle vostre ipotesi sono sbagliate ottenendo un feedback sul vostro prodotto da parte di utenti reali il più rapidamente possibile.

Più sei veloce a fallire, più aumenti le probabilità di avere successo, perché vorrà dire che sarai stato bravo nell’investire le risorse che hai in tanti piccoli esperimenti, ognuno che ha l’obiettivo di apprendere cosa il tuo cliente vuole veramente.

Sia che stiate costruendo un prodotto, scrivendo codice o elaborando un piano di marketing, dovreste sempre porvi due domande:

• Qual è la mia ipotesi più rischiosa?
• Qual è il più piccolo esperimento che posso fare per testare questa ipotesi?

MVP-AS-A-PROCESS, UN ESEMPIO PRATICO

Decidete di costruire un prodotto che permetta ai ristoratori di creare un’applicazione mobile per i loro ristoranti in pochi click. Avrà una semplice interfaccia drag and drop, un mucchio di modelli pre-costruiti, un calendario degli eventi, newsletter, check-in, gallerie fotografiche, chat in tempo reale, integrazione con siti di recensioni, social network e Google Maps. E, cosa ancora più importante, offrirà un modo per effettuare prenotazioni, effettuare ordini da asporto e utilizzare i coupon, da cui prenderete una piccola fee per monetizzare il vostro prodotto. Sarà fantastico!

Troverete alcuni amici che si uniranno a voi come co-founder e, se siete un tipico team di startup, raccoglierete un po’ di soldi, vi rinchiuderete in una stanza per 12 mesi e cercherete di costruire tutte queste features. Se siete un po’ più esperti, taglierete alcune funzionalità che non sono essenziali per il primo lancio, così potrete lanciare il vostro “MVP” in 8 mesi invece che in 12.

Tutto perfetto no? No. Procedendo così è molto probabile che fallirete. Perché? Beh, considerate quante ipotesi state facendo che potrebbero rivelarsi disastrosamente sbagliate.

Passate mesi a cercare di capire come lanciare applicazioni mobili personalizzate per i vostri clienti, per poi scoprire che ciò che il proprietario di un ristorante vuole davvero è un sito web ottimizzato per i cellulari, facile da trovare su Google.

Oppure, dopo aver utilizzato tutte le più recenti tecnologie per costruire chat in tempo reale, si scopre che i proprietari di ristoranti riescono a malapena ad usare la posta elettronica e non vogliono stare seduti al computer tutto il giorno.

Oppure, peggio ancora, potreste scoprire che i proprietari di ristoranti non vogliono il fastidio di avere a che fare con la tecnologia e la manutenzione delle applicazioni mobili e non hanno alcun interesse a utilizzare il vostro prodotto in primo luogo.

Aspettare mesi per scoprire questi difetti critici è troppo lungo. Nella migliore delle ipotesi, perdere così tanto tempo è un enorme spreco e, nella peggiore, farà fallire la vostra azienda. Nelle parole di Peter Drucker, “Non c’è sicuramente niente di così inutile come fare con grande efficienza ciò che non dovrebbe essere fatto affatto”.

Proviamo l’approccio MVP-as-a-process e vediamo se possiamo fare meglio. Costruiremo il prodotto in modo incrementale, in ogni fase chiedendoci:

• Qual è la mia ipotesi più rischiosa?
• Qual è il più piccolo esperimento che posso fare per testare questo presupposto?

All’inizio, l’ipotesi più rischiosa è probabilmente che i proprietari di ristoranti vogliano creare applicazioni mobili.

Pertanto, il primissimo MVP potrebbe essere un’imitazione di una tale app mobile – forse anche una che hai fatto sul retro di un tovagliolo di un ristorante (che bello!) Vai dai ristoratori del tuo quartiere e chiedi loro quali problemi hanno con la tecnologia. Hanno già un’app mobile? Se no, perché no? Ne vogliono una? Quanto sono esperti di tecnologia? Capiscono i vantaggi? Mostrate loro la vostra simulazione. Scoprite se questa sarebbe una buona soluzione ai loro problemi.

Potreste scoprire che non c’è abbastanza interesse da parte dei proprietari di ristoranti per rendere la vostra idea redditizia. È un peccato, ma la buona notizia è che ti è costato solo qualche ora di conversazione invece di mesi di sviluppo. D’altra parte, potreste scoprire che i ristoratori non sono interessati alle applicazioni mobili, ma a siti web facili da creare. Questo è un progresso!

Ma non avete ancora finito. Ora dovete ripetere il processo per costruire il vostro prossimo MVP. Qual è la tua ipotesi più rischiosa?

A questo punto, è probabile che i proprietari del ristorante sarebbero effettivamente disposti a pagare per un sito web di questo tipo. Qual è il più piccolo esperimento per testare questa ipotesi? Un’idea per il prossimo MVP potrebbe essere quella di creare a mano siti web statici per alcuni dei ristoratori che hanno espresso interesse e vedere come rispondono.(3) A loro piace? Sono impressionati dal fatto che il sito web sia già stato realizzato? Quanto pagherebbero per il lancio di un sito del genere oggi?

Forse, di fronte alla prospettiva immediata di spendere soldi, si scoprirà che i ristoratori non sono poi così interessati. Beh, meno male che l’hai imparato da pochi giorni di lavoro, invece di sprecare mesi di sviluppo.

O forse scoprirai che sono disposti a pagare. Così accetti il pagamento per alcuni mesi di servizio in contanti o con assegno (in modo da non perdere tempo a costruire un sistema di fatturazione), lanci i loro siti e chiedi loro di mandarti una email se hanno bisogno di aggiornare le informazioni del sito. Sì, questo comporta un grande sforzo manuale da parte vostra e non sarà scalabile se il numero di clienti cresce. Ma quando siete una piccola startup, non abbiate paura di fare cose che non scalano. La scalabilità è un buon problema da avere, perché significa che hai costruito qualcosa che vale la pena far crescere. 

Ma nel frattempo, è necessario ripetere il processo MVP un’altra volta. Di nuovo, Qual è la tua ipotesi più rischiosa?

A questo punto potrebbe essere che la vostra strategia di marketing funzioni. Non puoi andare in giro di persona in tutti i ristoranti del mondo. Qual è il più piccolo esperimento che potete fare per testare questa ipotesi? Il tuo MVP potrebbe essere una landing page che descrive ciò che il tuo prodotto farà, mostra i siti web dei ristoranti che hai costruito a mano in precedenza e permette ai visitatori di fornire il loro indirizzo email se sono interessati a saperne di più quando lo lanci. Potete quindi acquistare qualche centinaio di dollari di pubblicità su Google, Facebook, Twitter o LinkedIn per guidare il traffico verso la vostra pagina di destinazione e vedere cosa succede.(4)

Se i potenziali utenti non ti danno nemmeno il loro indirizzo e-mail, allora probabilmente non ti daranno neanche un soldo. È molto più facile scoprirlo modificando qualche testo e qualche immagine su una landing page piuttosto che riscrivendo migliaia di righe di codice nel prodotto completo! Prima si trovano gli errori, meno tempo si perde a costruire la cosa sbagliata.

CONCLUSIONI

Questo, in poche parole, è il processo MVP. Sia che stiate sviluppando un design di prodotto, un piano di marketing o scrivendo codice, chiedete sempre:

• Qual è la mia ipotesi più rischiosa?
• Qual è il più piccolo esperimento che posso fare per testare questo presupposto?

Yevgeniy (Jim) Brikman è l’autore di Hello, Startup e il fondatore di Atomic Squirrel, un’azienda specializzata nell’aiutare le nuove startup a decollare. In precedenza, ha trascorso più di un decennio presso LinkedIn, TripAdvisor, Cisco Systems e Thomson Financial. Ha conseguito un BS e un Master in Informatica presso la Cornell University.

Note:

(1) Un consiglio a John Wanamaker, il padre della pubblicità moderna, che una volta disse: “So che metà dei miei dollari di pubblicità sono sprecati. Solo che non so quale metà”.

(2) Per dirla con le parole di Fred Brooks: “Pianificate di buttarne via uno; lo farete comunque”.

(3) Invece di passare mesi a costruire un sistema flessibile per generare siti web, si potrebbero realizzare i primi prototipi in pochi giorni utilizzando modelli di siti web statici gratuiti, compilandoli manualmente sulla base delle informazioni apprese dal proprietario del ristorante e lanciandoli su un host statico gratuito. Si potrebbero anche utilizzare strumenti come il Keywords Planner di Google per mostrare ai proprietari quanto spesso le persone cercano il loro ristorante o la loro cucina nell’area generale.

(4) Vedi Risorse di distribuzione per sapere come guidare il traffico verso la tua pagina di destinazione. È possibile apportare rapidamente modifiche alla messaggistica sulla vostra pagina di destinazione e agli annunci e utilizzare il test A/B (vedi Risorse MVP) per scoprire cosa risuona nel vostro pubblico. 

Articolo tratto e rielaborato dal blog di Y Combinator: https://www.ycombinator.com/library/4Q-a-minimum-viable-product-is-not-a-product-it-s-a-process