La materia di cui sono fatte le startup

Per quale motivo parlare ancora di MVP nel 2020? L’occasione mi ha permesso di fare il punto su numerosi episodi a cui ho assistito anche recentemente nella mia attività di mentore e advisor di startup, e di tornare su molti delle migliaia di articoli scritti sull’argomento da quando Eric Ries ha usato il termine nel 2011, nel libro “The Lean Startup”. L'impressione è che gli MVP siano ancora per molti degli oggetti volanti non identificati.

Nonostante la complicazione del termine, “MVP = minimum viable product”, dovrebbe essere universalmente assodato che si tratta di “qualcosa” che permette alla startup di validare la propria business idea, prima di andare sul mercato con un prodotto finito, dunque risparmiando il più possibile tempo e denaro (parafrasando la definizione di Eric Ries). La validazione serve infatti al founder per decidere se continuare a sviluppare la startup, individuare in quale direzione correggere il tiro se necessario o opportuno, e contemporaneamente a convincere l’investitore a sostenerla finanziariamente.

“Universalmente assodato” è un po’ eccessivo: ancora pochi giorni fa mi hanno parlato di una startup che ha speso 25000 euro in un anno circa, senza mai costruire un MVP e avere un minimo riscontro dal mercato per non parlare di vendite, ed è fallita (l’anno scorso, per esaurimento dei fondi) senza che nessuno l’abbia mai conosciuta

MVP <-> Validazione <-> Startup

In sostanza gli MVP sono la materia stessa di cui è fatta la startup, la cui missione è proprio dimostrare che l’idea di business è valida: quando grazie agli MVP, e ai risultati raggiunti con i test resi possibile, avrà dimostrato la validità delle assunzioni di partenza, tra le quali l’ipotesi di prodotto che intende commercializzare, la startup stessa avrà completato il proprio ciclo di vita (salvo una decina di attività collaterali).

Se la validazione fosse l‘ossatura del ciclo di vita della startup, senza la quale la startup non sta in piedi, gli MVP sarebbero allora le terminazioni nervose. A fronte di ogni test, possono succedere due cose:

- la validazione ha successo, e la startup può proseguire lungo il percorso di sviluppo previsto: sono stati gli MVP a riportare una situazione favorevole;

- la validazione non ha successo, lo sviluppo della startup si arresta, e occorre capire in quale nuova direzione muovere (“pivot”): sono gli MVP che contribuiscono direttamente (anche se non automaticamente) ad informare su cosa non va e come reagire. 

In accordo ad un basilare principio lean, validare non è solo “cercare conferme”: é comprendere “come cambiare” quando necessario, facendoselo dire direttamente dal cliente. Gli MVP servono a proprio a favorire questo processo di interrogazione, ascolto, apprendimento e decisione.

E’ chiaro quindi che l’MVP non può essere “il prodotto finito” che la startup vorrebbe portare sul mercato. In quel caso, se la risposta fosse positiva avremmo sicuramente ottenuto una validazione (in realtà potremmo non essere sicuri del perché del nostro successo), ma tardivamente e con un altissimo rischio di aver bruciato molto tempo e soldi. Ma se non lo fosse, non saremmo in grado di capire quale parte del mondo del cliente non abbiamo considerato a sufficienza, e quale parte del prodotto ha effettivamente dimostrato di non essere adeguata. Lo spreco di tempo e denaro, non ci avrebbe permesso di ottenere nemmeno le informazioni necessarie per correggere lo sviluppo.

Oltre al concetto di MVP

Dunque se volessimo usare “il prodotto finale” come strumento di validazione, questo risulterebbe non solo eccessivo, ma proprio inadeguato. Se lanciamo una pallina contro un sistema di altre palline, e questa ci torna semplicemente indietro, non capiremo mai com'è fatto quel sistema e perché reagisce in quel modo. Possiamo solo ripetere il movimento finché ci pare per puro divertimento (masochistico).

D’altra parte l’MVP è ancora un “prodotto”: etimologicamente parlando, è qualcosa che viene “portato avanti” come conseguenza di un lavoro precedente. Ma è “meno” del “prodotto finale”: meno funzioni, meno dettagli, meno rifiniture, meno lavoro, meno costi. Anzi conviene che sia “il meno possibile” (“minimum”), purché continui ad essere adeguato allo scopo.

Ecco spiegate la “P” e la “M” di “MVP”. Ed ecco spiegato perché Eric Ries ha posto in tale evidenza questo concetto, nel libro col quale ha definito il metodo “Lean Startup”, basato sul ciclo “Build-Measure-Learn”, come metodo di “validated learning”. La “V” resta però la parte della definizione meno compresa e anche meno approfondita.

“Viable” è l’aggettivo usato probabilmente per porre un limite alla riduzione del prodotto ai minimi termini. Cioè, per quanto ridotto, l’MVP deve essere qualcosa di “concreto” col quale il tester è ancora in grado di avere un’esperienza d’uso confrontabile con quella che avrebbe con il prodotto finale. Infatti se il “minimum product” non risultasse “viable”, allora non permetterebbe di ottenere una buona validazione della capacità della soluzione proposta di soddisfare il cliente nel risolvere il suo problema.

In questo modo però tutta l’attenzione si sposta sulla soluzione, e quanto della soluzione finale debba essere incluso e cosa possa essere escluso dal MVP, per rendere significativo il test.  

In realtà durante il ciclo di vita della startup i test riguardano l’intero modello di business, non solo la soluzione, e questo vale anche per la viability. Si realizzeranno molti strumenti di test, inizialmente molto lontani dal prodotto finale, perfino del tutto fasulli e focalizzati solo sulle funzioni cruciali, e poi via via sempre più reali e dettagliati. Questi test focalizzano su svariati ambiti, talvolta disgiunti talvolta sovrapposti a quello della experience: dalla corretta identificazione del problema vissuto dal cliente, ai vari aspetti del modello di offerta e quindi alla reale possibilità di portarlo sul mercato con successo, per finire con gli aspetti connessi alla fattibilità tecnica che pure impatta sulla customer experience. 

Per questo è necessario andare oltre alla definizione di Eric Ries, e non considerare solo l’ MVP che riguarda l‘esperienza d’uso del cliente con un surrogato della soluzione. Si introducono così i concetti di MDP (minimum desirable product), MMP (minimum marketable product), MIP (minimum investable product), MFP (minimum feasible product). Di seguito li chiameremo tutti “MxP”. Si tratta in sostanza di realizzare artefatti lungo tutto il ciclo di vita della startup, con diversi obiettivi, indirizzati a diversi interlocutori. E' necessario che siano distinti? non necessariamente, ma talvolta è utile senza che si traduca in un consistente aggravio di costi. Riprenderò questo tema in un articolo successivo.

Differenze tra MVP e prototipi

Abbiamo già detto che la differenza più importante tra MVP e prodotto finito, consiste nella confidenza con cui vengono proposti all’esame del cliente. Nel primo caso la consapevolezza che la proposta non sia ancora quella definitiva rende l’MVP disegnato in modo da poter raccogliere utili feedback dal tester; nel secondo caso la confidenza sulla qualità del prodotto è massima, e il prodotto finito viene proposto al cliente direttamente per l’acquisto, senza alcuna possibilità di ottenere un feedback articolato. 

La differenza tra MVP e prototipo è più sottile, e potrebbe essere evidenziata in questo modo. Il prototipo risponde al bisogno di procedere con lo sviluppo della soluzione in modo sistemico, cioè gradualmente, modulo dopo modulo, permettendo quindi di testare le prestazioni tecniche dei moduli e l’efficacia delle integrazioni, e di organizzare la segmentazione del lavoro e l’assegnazione a più risorse.

Nella figura si vede un prototipo utile a testare in pista la qualità tecnica del progetto di un’auto da corsa, di una “scuderia indipendente” che possiamo supporre "low budget" quanto potrebbe esserlo una startup. E' un “prototipo”, appunto, e non un “MVP” che permetta di valutare il potenziale di business della sua commercializzazione.  

Ne consegue una situazione notoriamente critica. Prima dell’esito positivo della validazione (dunque prima di un adeguato finanziamento della startup), si cerca di contenere al massimo i tempi e i costi di realizzazione del MVP software, col risultato di costruire spesso qualcosa di tipo “usa e getta” purché funzionale allo scopo della validazione. Dopo l’esito positivo della validazione, quando diventa ragionevole occuparsi dell’ottimizzazione del codice prodotto, si cerca sempre di recuperare il più possibile di quanto già realizzato (proprio come se l’MVP fosse in realtà un prototipo), sempre per ragioni economiche. Si finisce così per intraprendere attività di reingegnerizzazione faticose e costose, che potrebbero vanificare le economie ottenute nella fase precedente.

La soluzione a questa criticità consiste, per prima cosa, nel trattenersi dal fare male e in fretta quello che occorre fare velocemente e con poca spesa. Occorre usare invece framework creati apposta per uno sviluppo software rapido ma anche ben impostato per le evoluzioni successive. Come seconda cosa, nel passaggio reso possibile dalla validazione e dunque nel calcolo del fabbisogno finanziario per coprire i costi delle fasi successive, occorre valutare onestamente anche la spesa necessaria per reingegnerizzare l’ MVP realizzato (che si spera non debba essere riscritto da capo). 

In questo modo, in uno stadio molto maturo del ciclo di vita della startup, quando cioè la confidenza sulla soluzione proposta è ormai molto alta, un MVP software può essere trasformato in un prototipo (ma non viceversa!). In tal caso questo avviene perché previsto da una precisa roadmap, e con la piena consapevolezza che il processo di validazione e il processo di sviluppo dell’applicazione possono convergere.

Riassumendo

Spero di aver reso chiaro che la realizzazione del MVP non è un esercizio riservato solo a quegli startupper particolarmente attenti nel seguire buone metodologie, e che mostrano di essere a proprio agio con acronimi impronunciabili e buzzword di successo. Non vanno realizzati solo perché li chiedono gli investitori, ma per raggiungere precisi obiettivi di apprendimento validato, in base ai quali decidere se vale la pena portare avanti la startup e sostenerla finanziariamente. 

Spero quindi che sia stato compreso che il termine MxP è stato introdotto per chiarire il senso di questa attività così importante, e non per aggiungere un’altra sigla vuota al gergo degli esperti. Non è sufficiente un solo MVP, e non di un solo tipo.

E’ richiesta quindi una grande attenzione. Il fatto che oggi sia possibile realizzarli in poco tempo e con costi molto contenuti (soprattutto nella fase iniziale), non significa che debbano essere fatti male e in fretta. La conseguenza sarebbe presentarsi ad investitori e clienti con proposte inconsistenti, oltre che procedere in modo confuso e dispersivo nello sviluppo della startup. Queste sono proprio due tra le principali cause di fallimento. Sarebbe cioè come viaggiare in auto nella nebbia, e finire per schiantarsi.

#mvp #minimumviableproduct #validation #startup