Abbandona i tuoi preconcetti e impara perché le aziende di successo abbracciano il MVP come chiave per rendere felici i loro clienti.
Di Arbi Vartan e Jeff Brinkerhoff
Slalom ama Agile. Siamo entusiasti dei benefici reali e misurabili che abbiamo visto le aziende ottenere da esso, e stiamo parlando di alcuni dei suoi più grandi vantaggi in una serie di post sul blog e un webinar Agile gratuito – guarda on-demand.
Il MVP, o Minimum Viable Product, è fondamentale per la pratica di Agile. Ed è anche qualcosa che genera resistenza. Abbiamo sentito i nostri clienti dire cose come: “I nostri dirigenti non vogliono il minimo – vogliono la migliore qualità possibile”. Infatti, perché non si dovrebbe voler fare il meglio? È una grande domanda, ma basata su un malinteso del MVP.
Concepito da Frank Robinson nel 2001, e reso popolare da Eric Ries attraverso il suo libro Lean Startup, il MVP è diventato un pilastro dei team di prodotto ad alte prestazioni in tutto il mondo. Perché Google è stato così dominante per così tanto tempo? Perché Apple fa alcuni dei prodotti più popolari al mondo? Perché Netflix non solo è sopravvissuto, ma ha prosperato oltre il suo modello di business originale? Molti fattori hanno contribuito, ma un filo comune è che tutti usano il MVP.
Cos’è dunque il MVP? Ecco la definizione di Eric Ries: Quella versione di un nuovo prodotto che permette ad un team di raccogliere la massima quantità di apprendimento convalidato sui clienti con il minimo sforzo.
Come questa definizione chiarisce, l’MVP non è un prodotto con la minima funzionalità possibile necessaria per un lancio pubblico. Non ha niente a che fare con il rilascio pubblico di un prodotto. Piuttosto, il MVP è la chiave per usare il metodo scientifico per costruire prodotti. È puramente un meccanismo di apprendimento convalidato, usato per testare le ipotesi e scoprire ciò che soddisferà i bisogni dei clienti.
Scaricate il termine se dovete, ma mantenete il concetto
A Slalom, abbiamo integrato il concetto di MVP sia nel modo in cui costruiamo prodotti per le aziende sia nel modo in cui collaboriamo con loro per raccogliere i benefici dell’incorporazione di principi e pratiche Agili nel loro modello di business. Tuttavia – dopo più di venti trasformazioni Agile aziendali e centinaia di partnership in vari settori – abbiamo scoperto che a volte è più semplice non forzare l’uso di termini come MVP. Alcuni sono passati al termine, “Minimum Lovable Product,” e Henrik Kniberg (meglio conosciuto per il suo lavoro con la cultura ingegneristica di Spotify) propone l’uso dei termini Earliest Testable, Earliest Usable, e Earliest Lovable Products.
Tutti questi termini vanno bene. Agile riguarda team più felici e produttivi, non la terminologia. Il nostro approccio a questo o a qualsiasi altro concetto Agile mal interpretato e poco chiaro è di saltare la parola e fare le seguenti tre domande:
- Perché farlo? Nel caso del MVP, si tratta di imparare velocemente, così come i principi sottostanti: soddisfazione del cliente, miglioramento continuo e semplicità.
- Cosa servirebbe per farlo nella mia azienda? Oh, il potere del framing! Invece di chiedere se si può fare, ci concentriamo sui blocchi – organizzativi o di altro tipo. La risposta a questa domanda spesso prende la forma di buy-in da individui che si pensava fossero inamovibili.
- E se non lo facessimo? Un’altra strategia di inquadramento: focalizzarsi sui costi che si devono sostenere per andare avanti con lo status quo. Questo può costruire un senso di urgenza e stabilire un allineamento intorno ad un nuovo modo di lavorare.
Ecco una storia sui pericoli dello status quo: Un progetto per un’azienda con cui abbiamo lavorato di recente ha coinvolto sei mesi su un importante rilascio di software con un impatto su più di 200 utenti interni. Si sono chiusi in una stanza e hanno completato la costruzione e tutti i test. Ed è stato solo a questo punto che hanno sollecitato il feedback di una manciata di proxy analisti di business – non utenti reali. Questo tipo di attività di checkbox, troppo tardi per avere un impatto reale, e senza un vero focus sull’apprendimento convalidato, difficilmente si qualifica come sollecitare il feedback. È davvero un tentativo di convalidare l’inevitabile.
Il risultato era prevedibile. Dato che era già stato speso così tanto tempo e denaro, si sentirono obbligati ad andare avanti, e tutti i 200 utenti rifiutarono il nuovo software a causa delle sue prestazioni lente e della mancanza di usabilità. Sei mesi e più di 12 milioni di dollari spesi, con solo il dito puntato tra i team aziendali e tecnologici per dimostrarlo.
Ora immaginate questo stesso scenario con un MVP distribuito a un gruppo di utenti finali all’inizio del progetto. Gli sviluppatori potrebbero immediatamente imparare cosa stavano sbagliando, quindi distribuire ulteriori MVP migliorando iterativamente con ognuno fino alla distribuzione di un prodotto finale, sviluppato con e approvato da utenti reali. Un ulteriore vantaggio: gli utenti del gruppo di prova sarebbero stati investiti a fondo nel progetto e lo avrebbero evangelizzato tra i loro pari.
Abbiamo visto esattamente questo scenario, ed è per questo che siamo dei convinti sostenitori del MVP, comunque lo si voglia chiamare.