Prodotto Minimo Viabile (MVP)

L'errore più comune sull'MVP è trattarlo come una definizione di qualità piuttosto che una decisione di ambito — rilasciare una versione piena di bug, a malapena funzionante e chiamarla un MVP. Il "Minimo Viabile" in MVP si riferisce all'ambito minimo delle funzionalità, non alla qualità minima. Un MVP dovrebbe essere di qualità di produzione e mantenere pienamente la sua promessa ristretta — semplicemente fa una promessa più piccola rispetto alla visione completa. Un modello mentale migliore è la definizione di Steve Blank: un MVP è il set minimo di funzionalità per cui un segmento specifico di clienti pagherà per risolvere un problema specifico. Eric Ries aggiunge la parola critica: "viabile" — il prodotto deve essere sufficientemente viabile affinché i clienti reali lo utilizzino per imparare, non codice a livello di prototipo che solo i team interni accetterebbero.

L'obiettivo di apprendimento deve essere definito prima di costruire l'MVP — altrimenti non c'è modo di determinare se l'esperimento ha avuto successo. L'obiettivo di apprendimento risponde a una domanda fondamentale: "I clienti che crediamo abbiano questo problema useranno effettivamente questa soluzione, e funzionerà abbastanza bene da fidelizzarli?" Ipotesi specifiche da testare: "I clienti nel segmento X attiveranno la funzionalità Y entro la prima sessione," "Gli utenti che attivano la funzionalità Y torneranno almeno settimanalmente," e "Possiamo costruire il flusso di lavoro principale senza il set completo di funzionalità che avevamo immaginato." Product Ops documenta l'ipotesi dell'MVP, stabilisce i criteri di successo quantitativi (ad esempio, 40% di attivazione entro la settimana 1, 60% di ritorno nella settimana 2) ed esegue l'analisi post-MVP per confermare o confutare ogni ipotesi.

Esistono molteplici archetipi di MVP lungo uno spettro di investimento nella costruzione. Concierge MVP — erogare manualmente il servizio per un piccolo gruppo di clienti per capire se lo apprezzano (nessun codice richiesto). Wizard of Oz MVP — il cliente interagisce con quello che sembra essere un prodotto automatizzato, ma gli esseri umani stanno eseguendo il lavoro dietro le quinte. Prototype MVP — un prototipo cliccabile a media fedeltà testato per la comprensione e i tassi di completamento delle attività. Single-Feature Build MVP — costruire solo il ciclo di interazione principale senza casi limite, gestione degli errori o integrazioni. Tech-Spike MVP — costruire solo il componente tecnicamente rischioso (il resto è simulato), per convalidare la fattibilità tecnica. Il tipo di MVP appropriato dipende dal rischio principale da convalidare — se il rischio è se i clienti desiderano la funzionalità, un Concierge MVP è il più veloce; se il rischio è tecnico, un Tech Spike è necessario.