Il termine MVP (Minimum Viable Product) è entrato da tempo nel lessico aziendale: viene spesso usato per definire versioni non definitive dei prodotti digitali.
Ma non è solo un oggetto con meno funzionalità rispetto al prodotto finale: è un modo per scoprire quello che non sappiamo, per limitare i rischi e l’incertezza. A volte non è nemmeno un “prodotto”.
Il tuo MVP è veramente “minimo”?
A volte capita di sentire chiamare “MVP” prodotti digitali con lunghe liste di specifiche tecniche, con dettagliati calendari di rilascio che a volte comprendono più territori nel mondo. Mi sono chiesto: questi prodotti sono veramente minimum?
La mia sensazione è che oggi il termine MVP abbia sostituito la vecchia “versione beta” nel lessico aziendale: descrive versioni preliminari, non complete, da testare su un pubblico più o meno ampio. Quello che mi sembra si perda, o almeno finisca in secondo piano, è che alla base di un MVP ci dovrebbe essere una domanda di cui non si conosce la risposta: l’MVP è lo strumento per cercare di ottenere le informazioni necessarie per rispondere a quella domanda.
Un MVP ha cioè a che fare con l’incertezza e la necessità di attenuarla cercando di imparare delle cose, spendendo meno risorse possibile: la riduzione dello spreco è uno dei principi fondamentali Agile/Lean.
D’altra parte se un MVP ha 5 funzionalità su 15 previste a monte, definite da una lista di requisiti tecnici, non è un MVP, perché sappiamo già cosa verrà dopo: ci troviamo cioè di fronte a un processo Waterfall, non Lean, in cui non c’è spazio per la scoperta e l’iterazione.
Per chiarire, credo possa essere utile fare un passo indietro e ricordarci cos’è in origine l’MVP e a cosa serve.
Un MVP comincia con una domanda
Il termine Minimum Viable Product è stato coniato da Eric Ries nel suo ormai classico The Lean Startup. Per Ries l’MVP è qualcosa che
permette a un team di raccogliere la massima quantità di informazione validata (validated learning) riguardo i clienti con il minimo sforzo.
Un’altra definizione è quella di Jeff Gothelf e Josh Seiden in Lean UX, che la articolano in due domande:
Qual è la cosa più importante che dobbiamo scoprire (learn) per prima rispetto a un’ipotesi di lavoro? In altre parole, qual è il rischio più grande attualmente associato al nostro approccio?
Qual è la quantità di lavoro più piccola che possiamo fare per scoprirlo?
La risposta alla seconda domanda è l’MVP.
In entrambe le definizioni l’enfasi è su imparare, scoprire qualcosa sui nostri clienti attraverso il minor sforzo: capire se il nostro progetto sta andando nella giusta direzione. Il processo parte da una domanda, non da una lista di requisiti. L’accento quindi si sposta dalla realizzazione materiale di una “cosa” al quesito che c’è dietro, molto più fondamentale: se ci poniamo la domanda sbagliata siamo completamente fuori strada.
A ben vedere, un MVP potrebbe non essere per nulla un “prodotto” per come lo intendiamo comunemente.
Un MVP non è necessariamente un “prodotto”
Jared Spool racconta un’esperienza esemplare: una compagnia di assicurazioni vuole ridurre i costi facendo in modo che siano i clienti a inviare le foto dei sinistri, invece di impiegare fotografi professionisti. Qual è l’MVP in questo caso? Forse una app mobile che permette ai clienti di inviare le foto? In realtà la domanda più urgente è: i clienti saranno in grado di fare foto rispondenti ai requisiti della compagnia?
Per scoprirlo non è necessario sviluppare software: gli agenti dell’assicurazione forniscono a un gruppo di clienti istruzioni su come fare le foto, e un indirizzo email a cui inviarle. Inizialmente i risultati sono poco incoraggianti: ma attraverso iterazioni successive, con istruzioni più chiare ed esempi, le cose migliorano, finché la maggioranza delle foto ricevute diventa accettabile.
L’MVP illustrato da Spool risponde a tutti i requisiti fondamentali:
- parte dalla domanda più urgente per il proseguimento del progetto, cioè dal rischio più grande in quel dato momento;
- richiede il minimo sforzo: non una riga di codice viene scritta, è sufficiente un indirizzo email;
- viene iterato più volte: ad ogni nuova iterazione si parte da quello che non ha funzionato, cioè da quello che si è imparato.
L’unica cosa che manca a questo MVP è proprio… il prodotto. Non è una versione beta o alfa, non è nemmeno un proof of concept: dal punto di vista materiale è quasi niente. Molti tipi di MVP hanno questa caratteristica di “intangibilità”, come ad esempio i cosiddetti MVP “mago di OZ” o “button to nowhere”.
AND EMILI si occupa di sviluppo e consulenza strategica sui canali digitali.
Un MVP è usa e getta (o quasi)
Un approccio ancor più radicale è quello illustrato da James O’Brien, secondo il quale un MVP dovrebbe avere quattro attributi:
- Economico: ci permette di scoprire cose al minor costo possibile;
- Rapido: deve permetterci di farlo velocemente per avanzare al passo successivo;
- Misurabile: i suoi risultati devono essere quantificabili in relazione ai criteri di successo/insuccesso che ci siamo dati;
- Morto: un MVP è fatto per scoprire ed essere gettato via; un MVP troppo elaborato o costoso finisce per sembrare “troppo bello” per essere eliminato o cambiato, il che va contro al principio di iterazione.
Secondo O’Brien, idealmente un MVP non dovrebbe avere budget dedicato per la sua realizzazione: nel momento in cui qualcuno autorizza la spesa per la realizzazione di qualcosa si sentirà investito della responsabilità del suo successo. A quel punto come si fa a spiegare che il successo del progetto è il suo fallimento, perché abbiamo bisogno di sbagliare per imparare?
D’altra parte, possiamo ancora chiamare MVP delle cose che assomigliano di più a prodotti “veri”: ad esempio, possiamo immaginare che nella storia di Jared Spool siano arrivati a un certo punto MVP in forma di siti o app dove gli utenti potevano caricare le foto dei sinistri.
Forse però potremmo fare qualche distinzione, partendo da quale fase dell’ideazione ci troviamo per capire di cosa abbiamo bisogno.
Un MVP per ogni occasione
Le tipologie di MVP che vado ad elencare non vanno intese come categorie rigide: sono coordinate per capire se quello che ci serve in un dato momento assomiglia di più al “quasi niente” nell’esempio di Jared Spool o a un prodotto “quasi finito”, o di qualcosa a metà strada.
MVP (la P sta per Proof)
Un MVP nella sua accezione più pura è focalizzato su imparare cose che non conosciamo: i suoi requisiti fondamentali sono partire da una domanda, essere economico e iterativo. Il fatto di essere una “cosa” concreta invece non è un requisito. Per questo motivo James O’Brien sostiene che si dovrebbe usare il termine Minimum Viable Proof: Quello che cerchiamo è la prova che stiamo andando nella direzione giusta, oppure in quella sbagliata. Non stiamo cercando di fare qualcosa di bello o che duri.
Questa accezione si adatta particolarmente alle fasi iniziali di un progetto, quando stiamo esplorando la possibilità che un’idea possa effettivamente avere un pubblico e soddisfare un bisogno. Ad esempio, ci potrebbe bastare un modulo web per raccogliere l’interesse del pubblico per una applicazione che dobbiamo ancora sviluppare.
ETP: testare, testare, testare
Altra cosa è quando abbiamo bisogno di un prodotto concreto, perché vogliamo metterlo di fronte a utenti reali in un contesto simile a quello del futuro prodotto finale: a questo punto il nostro MVP ha come requisito addizionale quello di essere funzionante rispetto a quello che promette di fare, cioè deve mettere effettivamente gli utenti in grado di soddisfare l’esigenza per il quale è stato progettato.
E’ il caso della classica illustrazione di Henrik Kniberg, dove vediamo gli MVP per un cliente che ha la necessità di viaggiare dal punto A al punto B:
Per questo tipo di MVP Kniberg propone la definizione di Earliest Testable Product: l’attributo importante è che il nostro prodotto (perché di prodotto si tratta ora) sia testabile, quindi funzioni e permetta all’utente di fare la cosa che desidera (in questo caso spostarsi da A a B). Sono fatti salvi tutti gli altri principi: partire da una domanda, essere economici, e soprattutto iterare. Quello che infatti si tende a dimenticare è che all’inizio il percorso ha questo aspetto:
La reazione del cliente all’MVP 1 determinerà il passo successivo, e così via.
Il percorso non è cioè tracciato all’inizio: ogni passo successivo è determinata dai risultati del precedente, e non sappiamo quanti passaggi ci vorranno. Gli utenti compiono i test e ci forniscono i feedback positivi e negativi che ci permettono di determinare la prossima domanda a cui rispondere.
MDP: funziona, ma mi piace?
Quando valutiamo le possibilità che il nostro prodotto abbia effettivamente successo sul mercato, non ci basta che esso sia funzionante e testabile: deve offrire all’utente un assaggio dell’esperienza d’uso finale, che comprende anche aspetti emotivi. Non deve limitarsi a fare il minimo indispensabile, ma deve promettere di lasciarci sentimenti ed emozioni positive. Parliamo in questo caso di Minimum Desirable Product (o di Earliest Lovable Product secondo Kniberg).
IBM ha esemplificato questo tipo di prodotto nel suo approccio al Design Thinking con l’illustrazione di un MDP di pizza: è importante che ci sia la possibilità di un assaggio di tutte le sue parti, comprese quelle che oltre a sfamarci ci dovrebbero far venire voglia di mangiarne un altro pezzo: quindi non solo crosta, ma anche pomodoro, mozzarella…
L’MDP è la parte gialla della piramide, e la fettina di pizza (© IBM)
Il nostro MDP quindi fornisce non solo valore funzionale, ma anche emotivo, in modo che l’utente possa valutarlo nel suo complesso: capire se oltre a poterlo usare vuole usarlo.
Qualche promemoria
Vorrei chiudere questa chiacchierata con qualche suggerimento per scegliere l’MVP giusto in base alle nostre necessità progettuali.
- Focalizzarsi sul problema, ovvero sul rischio più imminente: cos’è che potrebbe far naufragare il nostro progetto? Che cosa stiamo cercando di imparare sui nostri clienti o utenti?
- Determinare di cosa abbiamo bisogno per imparare quello che ci serve: nelle fasi iniziali, potremmo non avere bisogno di nessun prodotto in senso stretto (che anzi sarebbe eccessivamente rischioso e dispendioso); più avanti possiamo concentrarci su aspetti funzionali ed emozionali, sempre un passo alla volta per ridurre gli sprechi.
- Essere disposti a reiterare, e, se è il caso, eliminare: se un MVP (o ETP, o MDP) è fatto seguendo i principi Lean non dovrebbe mai essere “troppo costoso” per essere cambiato o eliminato, altrimenti non otteniamo il beneficio più importante, cioè migliorare la nostra comprensione del problema. Se a un certo punto avremo MVP “costosi” (come la motocicletta nell’illustrazione di Kniberg) il loro rischio sarà mitigato da tutto ciò che abbiamo imparato prima.
- Familiarizzare con l’incertezza: il product design non è una strada tracciata all’inizio, ma un percorso di esplorazione, interrogazione e scoperta continua.
Vuoi esplorare le possibilità per ridurre i rischi e scoprire nuove opportunità per soddisfare i tuoi clienti? Parlane con noi.
AND EMILI si occupa di sviluppo e consulenza strategica sui canali digitali.
