"È solo un MVP." Questa frase è diventata, in molti casi, una giustificazione per rilasciare software con qualità discutibile. Pagine che caricano in 8 secondi? MVP. Bug nei flussi principali? MVP. Interfaccia che confonde gli utenti? MVP. Come se aggiungere "minimum viable" davanti a "product" rendesse accettabile un prodotto che non funziona.
Il concetto di MVP software, cioè la versione più piccola di un prodotto che abbia comunque senso usare, è stato uno dei contributi più importanti alla cultura startup. Ed è anche uno dei più fraintesi. Fraintenderlo non è solo un errore teorico — è un errore che brucia soldi, utenti, e credibilità.
Cosa significa davvero MVP
Eric Ries, che ha reso popolare il termine, lo definisce come il prodotto con il minimo set di feature che permette di raccogliere il massimo di apprendimento validato con il minimo sforzo.
La parola chiave è viable. Non minimum. Viable. Il prodotto deve funzionare. Deve risolvere un problema reale per un utente reale. Deve farlo in modo affidabile.
"Minimum" si riferisce allo scope, non alla qualità. Fai poche cose, ma falle bene. Un'app che fa una sola cosa perfettamente è un MVP. Un'app che fa dieci cose tutte male difficilmente può essere considerata un MVP: è più simile a un prototipo portato in produzione troppo presto.
Come si riconosce un falso MVP
Un falso MVP di solito si riconosce subito. È lento: se la tua web app ci mette più di tre secondi a caricare, stai testando la pazienza degli utenti più che l’idea. Per chi la usa non esiste la distinzione tra “è lento perché è un MVP” ed “è lento perché è fatto male”. Esiste solo la lentezza, e quindi l’abbandono. Per questo le performance fanno parte del “viable”: una web app lenta difficilmente può esserlo davvero.
Un falso MVP ha anche bug nei flussi principali. Se il tuo tool di prenotazione fallisce una volta su cinque, non stai validando il valore della tua idea, ma solo la tolleranza degli utenti agli errori. Le feature secondarie possono mancare, ma quelle presenti devono funzionare.
Spesso poi nessuno capisce cosa fa. Se gli utenti arrivano e in dieci secondi non capiscono a cosa serve e come si usa, il problema è l’esperienza confusa. Un MVP con una sola funzionalità chiara vale più di un prodotto pieno di parti incomprensibili.
Infine c’è la formula “lo miglioriamo dopo”, che di solito è solo il nome elegante di un debito tecnico che non verrà mai ripagato. Dopo arriverà sempre qualcos’altro. Se non hai il tempo di farlo bene adesso, difficilmente lo troverai in seguito.
Il costo reale di un MVP di bassa qualità
Bruci i primi utenti
I primi utenti sono i più preziosi. Sono quelli che ti hanno dato fiducia prima che tu avessi credibilità. Sono quelli che ti danno feedback onesto. Sono quelli che, se soddisfatti, diventano evangelisti del tuo prodotto.
Se il tuo MVP li accoglie con bug, lentezza e confusione, non torneranno. E non ti diranno perché — spariranno silenziosamente. Peggio: diranno ad altri di non provare il tuo prodotto. Il passaparola negativo tende a diffondersi più velocemente di quello positivo.
I dati che raccogli non valgono nulla
Lo scopo dell'MVP è imparare. Ma cosa impari da un prodotto che non funziona? Se gli utenti abbandonano perché la pagina è lenta, non hai validato che l'idea non funziona — hai validato che un prodotto rotto non piace a nessuno.
Per raccogliere dati validi, il prodotto deve funzionare abbastanza bene da far sì che le decisioni degli utenti riflettano il valore della tua idea, non la qualità dell'implementazione.
Accumuli debito dal giorno zero
Un MVP scritto in fretta e senza struttura diventa la base su cui costruisci tutto il resto. Ogni feature successiva si appoggia su fondamenta fragili. Il debito tecnico si accumula prima ancora di aver validato l'idea.
Se l'idea funziona, ti trovi a dover riscrivere tutto dopo sei mesi. Se non funziona, hai sprecato lo stesso tempo che avresti sprecato facendolo bene — perché spesso la differenza di tempo tra un MVP fatto bene e uno fatto male è molto più legata allo scope che alla qualità del codice.
Come fare un MVP vero
La regola di base è tagliare feature, non qualità. Siediti con il team, fai la lista di tutto ciò che il prodotto “dovrebbe” avere e poi elimina quasi tutto. Tieni solo quello che serve a rispondere alla domanda più importante per il business in quel momento. Se la domanda è “gli utenti pagheranno per prenotare lezioni online?”, allora bastano registrazione, pagamento e prenotazione. Chat, recensioni, programma fedeltà, analytics e notifiche possono aspettare.
Prima ancora di scrivere codice, però, conviene definire cosa vuoi imparare. Una frase semplice del tipo “Con questo MVP vogliamo capire se…” basta a guidare tutte le scelte di scope. Ogni feature proposta andrebbe giudicata in base a quella domanda.
Ci sono poi fondamenta che non conviene tagliare: performance, sicurezza, affidabilità dei flussi principali e una struttura del codice che permetta di evolvere senza ricominciare da capo. Non serve un’architettura enterprise, ma serve un monolite ben strutturato, con codice pulito, test sui flussi critici e un database che risponda in tempi ragionevoli.
Infine, un MVP ha bisogno di un limite temporale. Datti un timebox chiaro: per esempio quattro settimane, al termine delle quali si rilascia quello che si è riusciti a completare bene. Se in quel tempo non sei riuscito a costruire abbastanza per validare l’idea, probabilmente l’idea stessa è troppo complessa per un MVP.
La differenza tra un MVP e un prototipo
Un prototipo è un esperimento interno. Serve a esplorare un'idea, capire la fattibilità tecnica e mostrare qualcosa agli stakeholder. Può essere brutto, fragile, incompleto. Non va in produzione.
Un MVP va in produzione, viene usato da persone reali e le loro decisioni influenzano il futuro del tuo business. Per questo deve funzionare.
Se quello che hai in produzione è un prototipo che hai chiamato MVP per giustificarne la qualità, sii onesto con te stesso. O lo trasformi in un prodotto viable, o lo chiami quello che è.
Minimum viable non è minimum effort
Lo scope minimo non implica lo sforzo minimo. Implica lo sforzo focalizzato. Tutta l'energia del team concentrata su poche cose fatte bene, invece di tante cose fatte male.
I migliori MVP che ho visto facevano una sola cosa. Ma la facevano in modo impeccabile: veloce, affidabile, chiaro. Gli utenti non si chiedevano “cos’altro dovrebbe fare”, ma “dove firmo per pagare”.
Quello è un MVP. Tutto il resto rischia di essere una scorciatoia che nel medio periodo si paga.
Simone Giusti
Consulente software strategico
