Prodotto minimo vitale (MVP)

Un prodotto minimo funzionante (MVP) è la versione più piccola di un prodotto che permette a un team di apprendere qualcosa di essenziale sulla reale utilità del prodotto per i clienti, concetto reso popolare da Eric Ries nel libro "The Lean Startup". La caratteristica distintiva non è che sia piccolo o economico, ma che sia progettato per rispondere a una domanda specifica, e che tale domanda riguardi informazioni validate sul comportamento dei clienti, piuttosto che opinioni interne sulla fattibilità.

L'uso improprio più diffuso è quello di considerarlo sinonimo di una prima versione con meno funzionalità. Sotto la pressione delle scadenze, i team riducono l'ambito del progetto, rilasciano qualcosa di incompleto, lo chiamano MVP e poi non misurano nulla in particolare, ottenendo così né un buon prodotto né un insegnamento utile. La domanda cruciale è quale ipotesi specifica verrà testata dalla release e quale risultato indurrebbe il team a cambiare direzione. Se non esiste una risposta, la release è un prodotto di piccole dimensioni, non un prodotto minimo funzionante.

Anche la parte "fattibile" del termine viene spesso trascurata. Una versione minimale ma non funzionante, o che fallisce nell'unico compito per cui è stata progettata, fornisce prove sull'implementazione piuttosto che sulla domanda. Il rifiuto di un prodotto da parte dei clienti perché lento, difettoso o confusionario non dice nulla al team sul valore intrinseco della proposta. Qualunque cosa venga inclusa, deve essere sufficientemente valida da consentire un test equo dell'idea, anche se l'ambito circostante viene drasticamente ridotto.

Diversi modelli consolidati rispondono alle domande sulla domanda senza la necessità di sviluppare un prodotto completo. Gli approcci "concierge" offrono il servizio manualmente ai primi clienti per capire di cosa hanno realmente bisogno prima di automatizzare qualsiasi processo. Le implementazioni "Wizard of Oz" presentano un'interfaccia funzionante con operatori umani che si occupano del lavoro sottostante. I test sulle landing page misurano se qualcuno risponde alla proposta prima dell'inizio dello sviluppo. Ognuno di questi metodi produce dati comportamentali, che sono di gran lunga più solidi delle intenzioni dichiarate raccolte tramite sondaggi e interviste su prodotti ipotetici.

Questo approccio si adatta molto meglio ad alcuni contesti rispetto ad altri. Nei settori regolamentati, nei sistemi critici per la sicurezza e nelle vendite aziendali, dove una singola cattiva prima impressione può precludere un mercato per anni, la distribuzione di software deliberatamente incompleto comporta costi che superano i benefici in termini di apprendimento. In questi contesti, la stessa logica si applica meglio attraverso prototipi, progetti pilota con partecipanti informati e lanci graduali a un pubblico limitato, piuttosto che con il rilascio pubblico di un prodotto minimo.

Decidere in anticipo quale risultato indurrebbe il team a interrompere il progetto è ciò che rende significativo l'esercizio, ed è il passaggio che più spesso viene omesso. Senza una soglia concordata in anticipo, qualsiasi risultato può essere interpretato come incoraggiante: un basso utilizzo diventa un problema di marketing, una scarsa fidelizzazione un problema di onboarding e il progetto continua sulla base della spiegazione che lo preserva. Mettere per iscritto, prima del lancio, quale livello di adozione o fidelizzazione giustificherebbe la prosecuzione, quale livello giustificherebbe un cambio di approccio e quale giustificherebbe l'interruzione definitiva trasforma il rilascio in un vero e proprio test. Inoltre, tutela il team, poiché una soglia documentata e concordata dalle parti interessate è molto più facile da invocare rispetto a un giudizio espresso a posteriori.

Se usato correttamente, il concetto mantiene un team onesto sulla differenza tra costruire e imparare, ed è più prezioso quando l'incertezza sulla domanda è effettivamente elevata. In pratica l'ipotesi e lo standard di prova vengono stabiliti attraverso ricerca sul prodotto, la costruzione si trova con sviluppo del prodotto, e la disciplina di definire in anticipo quale risultato innescherebbe un cambio di direzione è ciò che distingue l'approccio dal semplice lancio anticipato. Per startup In particolare, tale disciplina determina se il tempo limitato a disposizione viene impiegato per imparare o semplicemente sprecato.