MVP: cos'è e come usarlo per validare un'idea prima di investire

Un MVP, dall'inglese minimum viable product, è la prima versione di un prodotto digitale con le sole funzioni indispensabili per risolvere il problema principale dei suoi utenti. Serve a mettere l'idea alla prova con clienti veri, spendendo il meno possibile, prima di investire nella versione completa. Non è una demo e non è un prototipo da buttare: è un prodotto piccolo, ma funzionante e utilizzabile davvero.

Cosa significa minimum viable product?

Le tre parole contano tutte:

• minimum: contiene solo ciò che è necessario, niente di accessorio;
• viable: funziona davvero e risolve un problema reale, abbastanza bene da essere usato (e, se possibile, pagato);
• product: è un prodotto vero, che persone vere usano nel loro lavoro o nella loro vita, non una presentazione.

L'errore più comune è leggere solo la prima parola. Un MVP fatto male, pieno di errori o incompleto proprio nella funzione principale, non valida niente: dice solo che un prodotto scadente non piace.

Perché fare un MVP invece del prodotto completo?

Perché all'inizio di ogni progetto ci sono più ipotesi che certezze. Chi ha un'idea è convinto che il problema esista, che le persone pagheranno per risolverlo e che certe funzioni siano indispensabili. Alcune di queste ipotesi si rivelano giuste, altre no, e lo si scopre solo quando qualcuno usa il prodotto.

Costruire subito la versione completa significa scommettere tutto su ipotesi non verificate. Con un MVP si scommette una parte, si osserva, e si decide dove mettere il resto. Nel mio lavoro lo dico in modo semplice: partire dalle persone che pagheranno, con la funzione più piccola che useranno già dal primo giorno.

Cosa mettere in un MVP e cosa lasciare fuori?

È la parte più difficile, e quella in cui aiuto di più. Il metodo che uso è scrivere tutte le funzioni immaginate e chiedersi, per ognuna: senza questa, il cliente può comunque risolvere il suo problema principale? Se la risposta è sì, la funzione aspetta.

Facciamo un esempio. Un professionista vuole creare una piattaforma per mettere in contatto artigiani e privati che cercano piccoli lavori. L'elenco iniziale comprende profili, recensioni, chat, preventivi, pagamenti online, calendario, app per telefono, notifiche, statistiche. Un MVP ragionevole potrebbe contenere solo:

1. una pagina dove il privato descrive il lavoro e la zona;
2. un elenco di artigiani della zona, verificati a mano;
3. l'invio della richiesta e la risposta dell'artigiano via email.

Pagamenti, recensioni, chat e app arrivano dopo, se le richieste ci sono e gli artigiani rispondono. Se invece nessuno pubblica richieste, il problema non era la mancanza di una chat.

Che differenza c'è tra prototipo, MVP e prodotto completo?

Sono tre cose diverse, e confonderle porta a spendere male:

• il prototipo serve a far vedere come sarà il prodotto: schermate cliccabili, un percorso simulato. È utile per raccogliere opinioni e per allineare chi lavora al progetto, ma nessuno lo usa davvero;
• l'MVP è un prodotto vero, ridotto all'essenziale, che le persone usano nel loro lavoro e per cui, idealmente, pagano;
• il prodotto completo è il risultato di più tappe successive, costruite in base a ciò che l'MVP ha insegnato.

Spesso si passa dal prototipo all'MVP in poche settimane: prima si mostrano le schermate a qualche potenziale cliente, poi si costruisce la versione funzionante delle sole parti che hanno convinto.

Si può fare un MVP senza scrivere codice?

A volte sì, ed è giusto dirlo. Per alcune idee, la prima verifica si fa con strumenti già esistenti: un sito con un modulo, un foglio condiviso, pagamenti con link, molto lavoro a mano dietro le quinte. È un modo legittimo per capire se c'è domanda.

Il codice su misura diventa necessario quando il valore del prodotto sta proprio nella parte tecnica: un calcolo, un flusso di lavoro, un'integrazione, un'esperienza che gli strumenti pronti non permettono. O quando il lavoro manuale dietro le quinte diventa troppo per reggere anche pochi clienti.

Chi deve provare l'MVP?

Non chiunque. Le persone giuste sono quelle che hanno il problema in modo acuto, oggi, e lo stanno già risolvendo male: con fogli Excel, telefonate, strumenti adattati. Sono quelle più disposte a tollerare un prodotto ancora essenziale, perché anche così migliora la loro giornata. Meglio dieci utenti di questo tipo, seguiti da vicino, che cento iscritti curiosi che non torneranno.

Come capire se l'MVP sta funzionando?

Prima di lanciare, conviene decidere cosa si misurerà, altrimenti ogni risultato sembra un successo. Alcuni segnali utili:

• uso ripetuto: le persone tornano a usare il prodotto, non lo provano una volta e basta;
• disponibilità a pagare: anche pochi clienti paganti valgono più di molti utenti gratuiti;
• richieste concrete: gli utenti chiedono funzioni precise, segno che il prodotto è entrato nel loro lavoro;
• passaparola: qualcuno porta altri utenti senza che glielo chieda.

E poi i colloqui. Parlare con i primi utenti, guardarli mentre usano il prodotto, chiedere cosa li ha bloccati, dà informazioni che nessuna statistica fornisce.

Quali errori rovinano un MVP?

Gli errori che vedo più spesso non riguardano la tecnologia, ma le scelte:

1. troppe funzioni: l'MVP diventa un prodotto completo mascherato, con tempi e costi da prodotto completo;
2. nessun utente reale: lo si prova solo con amici e colleghi, che sono gentili ma non pagano;
3. nessuna metrica decisa prima: qualsiasi risultato viene interpretato come un successo;
4. qualità troppo bassa proprio nella funzione principale, che è l'unica che conta;
5. nessun tempo per ascoltare: si lancia e si passa subito alla funzione successiva, senza parlare con chi lo usa.

Un buon MVP è piccolo per scelta, non per fretta.

Un MVP si può vendere?

Sì, e se possibile conviene farlo. Chiedere un pagamento, anche ridotto, ai primi utenti è il modo più onesto per verificare che il problema valga la soluzione. Un utente che paga dà riscontri diversi da uno che usa il prodotto gratis: segnala con più precisione cosa manca, e se smette di pagare è un'informazione chiara. Molti progetti offrono ai primi clienti condizioni vantaggiose in cambio della disponibilità a dare riscontri regolari.

Quanto deve durare la fase di MVP?

Non c'è una durata fissa, ma conviene darsi una scadenza e dei criteri. Alcune settimane o pochi mesi di uso reale bastano spesso per capire se le persone tornano, se pagano e cosa chiedono.

Cosa succede dopo l'MVP?

Le strade sono tre: proseguire, aggiustare la direzione o fermarsi. Fermarsi non è un fallimento, è il motivo per cui si fa un MVP: meglio scoprirlo dopo qualche mese e una spesa contenuta, che dopo un anno di sviluppo.

Se si prosegue, l'MVP non va buttato, e spesso diventa la base di una piattaforma in abbonamento. Se è stato costruito con criterio, cresce: si aggiungono le funzioni che gli utenti hanno chiesto, nell'ordine in cui servono. Per questo, anche in un MVP, alcune scelte tecniche vanno fatte bene da subito, come la separazione dei dati tra clienti in una piattaforma multi-tenant o la struttura degli account.

Quanto costa e quanto tempo serve per un MVP?

Dipende dalla funzione principale. Un MVP con un flusso semplice è un progetto contenuto; uno che deve integrarsi con sistemi esterni, gestire pagamenti o calcoli complessi richiede di più. Il valore dell'MVP, però, sta proprio nel fatto che il costo è delimitato: lo scrivo in un preventivo voce per voce, e si sa prima cosa ci sarà dentro e cosa resterà fuori.

Ne parliamo?

Se hai un'idea ferma nel cassetto e non sai da dove cominciare, scrivimi. Partiamo dal problema che vuoi risolvere e da chi lo ha, e definiamo insieme la versione più piccola che vale la pena costruire. Qui trovi come lavoro sull'MVP, e se prima vuoi un parere su fattibilità e costi c'è la consulenza tecnica.

Crediti delle immagini

• Copertina: foto di Vitalii Abakumov su Unsplash