Come testare le idee di business del secolo? L’MVP

Ti è venuta l’idea di business del secolo.
L’adrenalina ti scorre nelle vene ogni giorno, sempre di più.
Racconti la tua idea a tutti i tuoi amici che ti dicono che è geniale.
Sei parte di tutti i gruppi di startup e community di innovatori perché vuoi sapere come si crea una startup, chi può sviluppare la piattaforma tecnologica e come fare a trovare investitori che si entusiasmeranno tantissimo appena proietterai il tuo pitch.
Finalmente la tua vita avrà un senso, te lo sentivi dentro che l’imprenditoria era la tua strada.
Tutti parleranno di te e della tua startup e migliaia di persone ne parleranno tra di loro e saranno interessate a usare la  piattaforma. Non vedi l’ora!

Bella storia. Peccato solo che sia un bel romanzo poco in linea con la realtà, condito da errori che aiutano a farci innamorare della nostra idea e che se non risolti ci faranno schiantare.  
L’entusiasmo è utile ma deve essere razionale: le idee considerate geniali da nostri amici potrebbero non essere davvero così geniali per il mercato.
Qualsiasi idea vale l’1% di un progetto, vi ricordate quando dicevo che era importante iniziare a costruirla? Ecco, testare la propria idea è il primo passaggio per ideare  una startup e permette di aggiungere fondamenta solide prima di partire con l’immaginazione e l’innamoramento.
Tutte le idee sono geniali finché non le testiamo.
Se vogliamo costruire dobbiamo farlo in modo razionale e sistematico e l’MVP ci aiuta proprio a fare questo. 

Cosa significa testare l’idea di business del secolo?

Appena si ha un’idea è necessario capire come testarla, per evitare di sprecare tempo e risorse in qualcosa che poi scopriamo non avere un mercato (desirability), non essere tecnologicamente fattibile (feasibility) e non essere monetizzabile o sostenibile  – ossia non conviene costruirci un business sopra (viability).

Quindi appena viene in mente una super idea e si inizia a pensarla, è importante anche capire come testarla.
La validazione di mercato in genere è la parte più difficile perché nella nostra testa può sembrare chiarissima e ben definita, può centrare perfettamente un problema ben presente nel contesto in cui ci troviamo. Ma la nostra percezione iniziale può essere ben diversa rispetto alla realtà, e quelle degli utenti possono essere ancora più diverse o addirittura opposte rispetto alle nostre, potrebbero esserci inoltre frizioni che rendono il progetto poco semplice da costruire. 
Ecco perché come dico sempre appena ci viene un’idea, prima di innamorarci e pensare sia la migliore idea del mondo dobbiamo fare due cose: testarla con il target e parlarne con chiunque, senza aver paura che qualcuno ce la rubi. 

Testare l’idea non è difficile se sappiamo come si fa.
La difficoltà è legata al fatto che non c’è una regola matematica o un’equazione standard che ci permette di testarla.
Ogni progetto ha una validazione diversa. 
Possiamo partire dall’individuazione degli utenti in target, cercando di trovare coloro che hanno davvero il problema che stiamo cercando di risolvere. Oppure potremmo partire dal problema, cercando di determinare il target sulla base di chi reagisce e ci dà un feedback rispetto al problema. Una volta che abbiamo capito tramite analisi quantitative e qualitative che il problema esiste e magari abbiamo anche provato a capire chi ce l’ha (problem/solution fit) possiamo iniziare a validare la soluzione e capire se la nostra idea viene compresa e il target potrebbe essere interessato a utilizzarla, validando la desirability. 

Parallelamente alla validazione di mercato dobbiamo poi procedere alla validazione della tecnologia, lavorando sul proof of concept e sul prototipo per essere sicuri della feasibility. Se la vostra idea riguarda lo sviluppo di un e-commerce o il vostro progetto prevede una tecnologia ormai comune come per un’app, potete anche dare per scontato che sia fattibile. Se si tratta di cutting-edge technology meglio non rischiare, dato che la fattibilità tecnologica e di design potrebbe compromettere la desirability e rendere la startup ancora più rischiosa e la validazione ancora più strategica. 

Come si testa l’idea di business del secolo?

Ora che abbiamo validato il problema, trovato un target e comprovato la tecnologia siamo prooonti al lan…no. Abbiamo superato solo il primissimo ostacolo della maratona.

Validare le idee è dannatamente difficile soprattutto quando, a questo punto ci troviamo a dover validare il modello di business. Se finora ci sono bastati un paio di landing page e il prototipo, d’ora in poi abbiamo bisogno di qualcosa di un po’ più funzionale, che ci dimostri che il prodotto digitale che stiamo costruendo è davvero utile.

All’inizio del percorso di validazione, quello che conta non è la soluzione ma capire il problema e il target di riferimento: ecco che una landing page va benissimo per testare il concetto e capire se c’è interesse.
Sviluppare una mini strategia di acquisizione sulla landing page ci permette di ottenere una serie di dati quantitativi sul target, dai quali poi ricavare sessioni di interviste e/o call per approfondire il problema nei dettagli. I dati quantitativi non sono meno importanti di quelli qualitativi: dai primi ci facciamo un’idea dell’ampiezza e dell’interesse del mercato mentre i secondi ci aiutano a indagare il potenziale problema. Focalizzarsi sul problema piuttosto che sulla soluzione ci permette di ragionare a medio/lungo termine: se la prima versione della soluzione non dovesse essere perfetta o capita dal target possiamo provare a cambiare funzionalità o a fare pivot, perché innamorandoci del problema sappiamo anche da dove partire e come evolvere la nostra idea.
Se invece non sappiamo quale sia il problema di partenza o ci convinciamo non serva validarlo, sarà molto più difficile convincere il nostro target che la nostra soluzione sia la migliore idea del secolo.
E’ vero che i bravi commerciali possono fare miracoli ma ignorare il problem/solution fit prima o poi ti fa schiantare.

Proof of concept e prototipo sono utili per un uso interno.
Si analizzano user flow e si preparano wireframe e mockup che diventeranno parti essenziale per creare lo strumento che è il re di ogni vera validazione: il Minimum Viable Product (MVP).
Il prototipo potrebbe cambiare, potrebbe essere articolato in diverse versioni anche molto differenti, in genere si investe poco tempo nel crearlo perché serve a rappresentare le idee: i designer con cui collaboro usano Sketch, Invision e Adobe XD.
L’MVP non è solo un prototipo: rappresenta una primissima versione del nostro prodotto. Lo scopo è fare in modo che venga usato dal target identificato per risolvere il problema. Guardando come lo usano, analizzando i loro feedback e il loro comportamento in-app possiamo raccogliere nuovi dati quantitavi e qualitativi dal target e continuare ad arricchire e validare le nostre ipotesi su problema, target e soluzione. Attenzione: non siamo ancora pronti a vendere, il nostro scopo è raccogliere insights e imparare quanto più possibile.

“Siamo pronti a lanciare!”

“Abbiamo quasi finito di lavorare sul prodotto, facciamo una mini beta per correggere i bug e possiamo iniziare a pianificare il lancio. Ci serve il growth hacking!”.

No ragazzi, non è ancora il momento di pensare al growth hacking.
Siete pronti alla Beta ma vi consiglio di non dare per scontato che questa andrà bene perché dovrete scalarla e capire se e come integrare i feedback che avete ricevuto.
Potete decidere di fare sia un’Alpha che una Beta, piuttosto che una Beta chiusa o aperta, ma quello che conta è che la facciate con l’idea di mettere in product roadmap gli insight della beta.
Se avete lavorato bene fino a qui la beta non sarà niente di difficile.
Le analisi qualitative e quantitative saranno in linea con quelle iniziali, potreste trovare nuove nicchie dalle quali ottenere feedback su nuove funzionalità e/o frizioni. Lanciare la beta sarà l’ennesimo arricchimento per essere sicuri di essere sulla strada giusta. Potrete imparare ancora una volta dai vostri utenti in target, con un’ennesima validazione delle ipotesi core di prodotto e l’opportunità di raccoglierne altre per aumentare le nicchie in target. Siete praticamente sicuri che otterrete il product market fit, si tratterà solo di fare la domanda di rito e di procedere con la product roadmap pianificando le prime release.

Se invece avete lavorato alla soluzione senza aver mai validato o parzialmente validato le vostre ipotesi vi troverete davanti a una beta con scenari più complicati: utenti che non capiscono come funziona l’app, target di mercato che non hanno davvero il problema, MVP con 10 funzionalità che saranno uguali alla versione finale del prodotto e utenti confusi che non capiranno perché usarle. E non è scontato trovarsi in questa situazione perché come vi dicevo per validare servono tempo e fatica.
Cosa fare in questi casi?
Potreste provare a trovare un target, cercando di focalizzare sul problema che volete risolvere, oppure lanciare sperando che nel lancio troverete il target di mercato e il problema da risolvere. Entrambe le opzioni sono rischiose perché fanno spendere un budget maggiore in acquisition e rendono più difficile e complessa la conversione di download/registrazioni in utenti attivi minando la retention di prodotto, la metrica di growth più importante. Ma d’altra parte, non fermarsi adesso e lanciare pensando che il mondo si innamorerà della vostra soluzione, vi farà schiantare ancora più in fretta. Quindi fermatevi, iniziate a lavorare su acquisition e sulle metriche di prodotto, sperimentate e testate. Non è mai troppo tardi per iniziare a validare e ottimizzare l’esperienza utente!

5 consigli per l’MVP perfetto

L’MVP è importantissimo per raccogliere un feedback concreto e oggettivo dal mercato su problema, target e value proposition.
Tramite l’MVP è possibile infatti analizzare il comportamento degli utenti ed essere sicuri che durante le interviste non venga data un’opinione positiva da un utente che poi potrebbe non diventare mai davvero attivo in piattaforma. L’MVP quindi, a differenza del prototipo, diventa un prodotto digitale usabile nella sua versione base: le funzionalità sono quelle core che serviranno ancora una volta a testare le nostre ipotesi e a confrontare i dati qualitativi e quantitativi degli utenti beta.

Chiudiamo questo lungo essay con 5 consigli finali sull’MVP perfetto:

1) Ho detto per caso “perfetto”? Non esiste l’MVP perfetto

Ho letto da qualche parte che la perfezione spesso non aiuta ad andare veloci, ecco perché l’MVP non può e non deve essere perfetto. L’obiettivo è quello di testare nel modo più semplice e veloce possibile le ipotesi non ottenere l’MVP che lo fa nel modo perfetto, altrimenti è facile si trasformi nella versione finale del prodotto.

2) Partire sempre dalle ipotesi, non dalla tecnologia

Spesso sento che le idee di un nuovo prodotto digitale, un servizio o una piattaforma sono sempre più legate a una specifica tecnologia. Quando sento qualcuno che dice di voler lanciare la “piattaforma per il controllo degli alimenti in blockchain” mi domando se sia la blockchain il valore aggiunto del progetto. In realtà la tecnologia è un abilitatore, e non è detto sia la soluzione migliore per il problema da risolvere. Se vi innamorate del problema invece che della tecnologia, potreste scoprire soluzioni molto più semplici da integrare all’MVP, faranno meno PR ma vi interessa l’ego o il feedback?

3) Quanto contano le performance dell’MVP?

Ecco, questo è un altro punto essenziale: chi se ne frega del costo di acquisizione o dell’ottimizzazione del budget se state validando?
Se non siete in fase di lancio ottimizzare i budget non serve.
E’ utile sempre ma nella fase di beta e di MVP non serve ottimizzare i budget. Quello che conta è acquisire un numero di utenti tale che permetta di validare le vostre ipotesi, quindi utenti in target e/o con il problema.
Non conta quanto siete bravi a ottimizzare il budget perché spesso i canali pubblicitari non aiutano, la relazione da creare non è di vendita ma di condivisione e di feedback.

4) L’MVP non deve essere tecnologicamente avanzato (ma nemmeno fare troppo schifo)

L’MVP sta proprio nel mezzo di queste due considerazioni: deve essere costruito in una versione di qualità sufficiente affinché gli utenti capiscano come usarlo e che effettivamente risolva il problema. Dall’altra parte, non deve per forza essere tecnologicamente avanzato, altrimenti ci potreste mettere due anni a rilasciarlo e correre il rischio che la vostra idea diventi obsoleta e vecchia. Anche qui non si tratta di fare calcoli quantistici ma di usare il buon senso ricordandoci sempre qual è l’obiettivo fondamentale dell’MVP: validare le nostre idee e ipotesi.

5) L’MVP deve imbarazzarti (almeno un po’)

Per essere sicuri di essere giusti con i tempo c’è una regola che in genere si usa tra chi fa startup: se condividere il tuo MVP non ti imbarazza almeno un po’, hai lanciato troppo tardi. Come ripeto, è essenziale testare e ricordarsi che se hai fatto il percorso giusto, sarà solo una primissima versione di una soluzione che si arricchirà mano a mano di nuove funzionalità, di un design sempre migliore e di un’esperienza utente sempre più sofisticata. So che non è una motivazione sufficiente per convincervi, ma ricordatevi che quando lanciate un MVP siete a 150km/ora in autostrada, rallentare per essere sicuri che l’auto non prendi una buca non è una buona idea per testare se regge la velocità e la strada.

— — —

Se mi avete seguito fino a qui, spero vi sia piaciuto.
Lasciatemi un commento, mi farebbe piacere avere un vostro feedback visto che è costato quattro giorni di lavoro.
Se avete domande o considerazioni segnalatele nei commenti e keep pushing, builders!

ps: non hai un’idea ma vuoi scoprire il processo per testare nuove idee e prototipi? Iscriviti a Exploratorium.