«Facciamo un MVP, così spendiamo poco.»
Frase che si sente spesso, ed è giusta solo a metà. Spendere poco è un ottimo obiettivo. Il problema è quando “MVP” diventa un modo elegante per dire “facciamolo in fretta, poi si vede”. In quel caso non si sta risparmiando: si sta solo rimandando la spesa, e di solito poi si paga con gli interessi.
Vale la pena chiarire cos’è davvero un MVP, perché se usato bene è uno degli strumenti più utili per chi vuole lanciare un progetto digitale senza bruciare il budget.
Cosa significa davvero
MVP sta per Minimum Viable Product: prodotto minimo funzionante. Delle tre parole, quella che si dimentica sempre è Viable.
Un MVP non è un prototipo da buttare, né una demo che regge solo se nessuno la tocca. È la versione più piccola del prodotto che risolve davvero un problema per un utente reale. Piccola nelle funzioni, non nella qualità.
La differenza si capisce con un esempio. Immaginiamo un’app per prenotare il ritiro del pane in un forno.
- Un MVP fatto male ha dieci funzioni: catalogo, carrello, coupon, raccolta punti, recensioni, chat, notifiche… e metà di queste funzionano a singhiozzo. Il cliente prova una volta, il pagamento si blocca, non torna più.
- Un MVP fatto bene ne ha tre: scegli i prodotti, paghi, scegli l’orario di ritiro. Funzionano sempre, sono veloci, sono chiare. Il cliente torna la settimana dopo.
Il secondo costa meno del primo, e in più dice qualcosa di utile: le persone lo usano oppure no?
A cosa serve un MVP
Lo scopo di un MVP non è avere un prodotto più economico. È imparare il prima possibile, con la minima spesa, se l’idea funziona.
Ogni progetto parte da ipotesi: “i clienti preferiranno prenotare online”, “i dipendenti useranno l’app invece del foglio Excel”, “le persone sono disposte a pagare per questo servizio”. Finché il prodotto non è nelle mani degli utenti, sono solo ipotesi. L’MVP serve a verificarle.
E per verificarle davvero, il prodotto deve funzionare bene. Se un utente abbandona l’app, bisogna poter capire se è perché l’idea non interessa o perché il pulsante “paga” non funzionava. Un MVP fatto male non risponde a nessuna delle due domande.
Le tre trappole più comuni
1. Tagliare la qualità invece delle funzioni
È l’errore più diffuso. Per risparmiare si tagliano test, sicurezza, gestione degli errori. Il risultato è un prodotto che sembra completo ma si rompe al primo utilizzo reale. Meglio tagliare una funzione intera che farne tre a metà.
2. Costruire su fondamenta da rifare
Un MVP dovrebbe poter crescere. Se è stato costruito in modo da dover essere buttato e rifatto da capo appena funziona, il risparmio iniziale si paga due volte. Non servono architetture complesse, ma servono basi pulite.
3. Non decidere cosa si vuole imparare
Un MVP senza una domanda precisa è solo una versione povera del prodotto. Prima di iniziare, conviene scrivere su un foglio: “fra tre mesi, cosa vogliamo sapere?”. Ad esempio: quanti ordini a settimana arrivano dall’app? Quanti clienti tornano? Quelle risposte guideranno tutte le scelte successive.
Come si decide cosa mettere dentro
Il metodo che usiamo con i clienti è semplice. Si scrivono tutte le funzioni desiderate, anche le più ambiziose. Poi, per ognuna, si fa una sola domanda: “senza questa, il prodotto risolve ancora il problema principale?”
Se la risposta è sì, la funzione va nella lista “dopo”. Di solito la lista “dopo” è molto più lunga della lista “ora”, ed è esattamente così che deve essere. La lista “dopo” non è una rinuncia: è una scaletta, da riprendere quando gli utenti avranno detto cosa serve davvero.
Spesso, tra l’altro, alcune funzioni che sembravano indispensabili all’inizio non vengono mai richieste. E altre, a cui nessuno aveva pensato, diventano le più importanti. È il motivo per cui conviene partire col poco.
In sintesi
Un buon MVP è:
- piccolo, perché contiene solo ciò che serve a risolvere il problema principale;
- solido, perché quello che c’è funziona sempre;
- misurabile, perché si sa in anticipo cosa si vuole imparare;
- espandibile, perché è costruito per crescere, non per essere buttato.
Costa meno di un prodotto completo, ma non è un prodotto scadente. È un prodotto onesto: fa poche cose, e le fa bene.
E alla fine, è anche il modo migliore per proteggere il budget. Perché la spesa più grande, in un progetto digitale, non è costruire il prodotto. È costruire per mesi il prodotto sbagliato.
