Nel 2008 Drew Houston voleva spiegare Dropbox agli investitori, ma il prodotto non esisteva ancora. Costruire la sincronizzazione tra dispositivi richiedeva mesi di lavoro e nessuno voleva finanziare un’idea senza prove. Così Houston registrò un video di tre minuti: una demo finta che mostrava come avrebbe funzionato il prodotto. Nella notte la lista d’attesa passò da 5.000 a 75.000 iscritti. Quel video era un minimum viable product, anche se non conteneva una sola riga del codice definitivo.

Questo esempio dice già molto su cosa sia (e cosa non sia) un MVP. Non era un prodotto incompleto: era il modo più rapido per rispondere a una domanda precisa. La gente vuole davvero questa cosa? La risposta arrivò prima di spendere mesi a costruire.

Cos’è davvero un minimum viable product

Il termine lo ha reso famoso Eric Ries nel libro The Lean Startup. La sua definizione è scomoda perché sposta il focus dove di solito non lo mettiamo: l’MVP è la versione di un prodotto che permette di raccogliere la massima quantità di apprendimento validato sui clienti con il minimo sforzo. La parola chiave è apprendimento, non prodotto.

Un MVP serve a verificare un’ipotesi. Stai assumendo che un certo tipo di utente abbia un certo problema e che la tua soluzione lo risolva abbastanza bene da farlo pagare, iscrivere o tornare. L’MVP è l’esperimento più piccolo che conferma o smonta quell’assunzione.

Cosa NON è un MVP

Qui nascono quasi tutti gli equivoci. Un MVP non è un prodotto fatto male, non è la versione 1.0 tagliata a metà, non è una scusa per rilasciare qualcosa di scadente e chiamarlo “lean”.

• Non è un prodotto a metà. Quello che includi deve funzionare bene. Se Dropbox avesse fatto perdere file agli utenti, il test sarebbe stato inquinato: la gente avrebbe rifiutato la sincronizzazione affidabile, non l’idea.
• Non è “tutto, ma in piccolo”. Non si tratta di fare ogni funzione al 30%. Si tratta di fare poche cose, complete, e lasciare fuori tutto il resto.
• Non è un prototipo. E su questo vale la pena fermarsi.

MVP e prototipo: la differenza che conta

Un prototipo serve a esplorare una soluzione: testi un flusso, un’interfaccia, un’interazione, di solito senza utenti reali e senza dati di mercato. È uno strumento di design e di discovery interno. Un MVP, invece, va in mano a utenti veri che lo usano per risolvere un problema vero, spesso pagando. Il prototipo risponde a “questa cosa è usabile?”. L’MVP risponde a “qualcuno la vuole abbastanza da adottarla?”.

Detto in modo brutale: con un prototipo impari sul prodotto, con un MVP impari sul mercato.

Come costruire un MVP: cosa includere e cosa tagliare

La domanda giusta non è “quante funzioni metto”, ma “qual è l’unica cosa che questo prodotto deve fare bene per dimostrare la mia ipotesi”. Tutto ciò che non serve a quella prova è rumore.

Un metodo concreto che funziona:

• Scrivi l’ipotesi in una frase. Esempio: “I freelance pagano 9€/mese per uno strumento che genera fatture in meno di un minuto”.
• Identifica il momento di valore. Qual è l’istante in cui l’utente dice “ok, funziona”? Tutto deve portare lì.
• Taglia tutto il contorno. Login social, dashboard analitiche, integrazioni, temi personalizzabili: rimandali. Nessuno abbandona perché manca il dark mode.
• Decidi come misurerai. Conversioni, retention a 7 giorni, richieste di rimborso. Senza una metrica, l’MVP non ti dice niente.

A volte la parte “minima” non è nemmeno software. Zappos nacque così: il fondatore fotografava scarpe nei negozi locali, le pubblicava online e, a ogni ordine, le comprava e le spediva a mano. Voleva sapere una cosa sola, se la gente avrebbe comprato scarpe su internet. La risposta valse poi miliardi.

Gli errori più comuni

Due trappole ricorrono in quasi tutti i team, ed entrambe svuotano l’MVP del suo senso.

La prima è l’MVP gonfio. Parti con l’intenzione di fare il minimo, poi qualcuno dice “già che ci siamo aggiungiamo anche…”, e in tre settimane hai ricostruito il prodotto completo. Hai speso tempo, hai rimandato l’apprendimento e hai legato il tuo ego a funzioni che forse nessuno vuole. La regola: ogni volta che aggiungi qualcosa, chiediti se serve a confermare l’ipotesi. Se la risposta è “no, ma sarebbe carino”, taglia.

La seconda, più insidiosa, è l’MVP che non misura nulla. Rilasci, ricevi qualche complimento, ti senti incoraggiato e vai avanti. Ma i complimenti non sono dati. Senza una metrica decisa prima del lancio, l’MVP diventa un atto di fede travestito da esperimento. Devi sapere in anticipo quale numero ti dirà “vai avanti” e quale ti dirà “fermati”.

MVP, product-market fit e gestione del rischio

L’MVP non esiste per produrre un prodotto piccolo, esiste per accorciare la strada verso il product-market fit, cioè il momento in cui hai un prodotto che un mercato chiaro vuole davvero. Ogni MVP è un passo che ti avvicina o ti allontana da quel fit, e in entrambi i casi hai imparato qualcosa.

Per un product manager questo si traduce in una cosa molto pratica: gestione del rischio. Costruire un prodotto completo basandosi su intuizioni significa scommettere mesi di budget e di lavoro del team su un’ipotesi non verificata. L’MVP spezza quella scommessa in tanti esperimenti economici. Investi poco, impari presto, correggi rotta finché i dati non ti dicono di accelerare. Un buon PM non si innamora della soluzione: si innamora del problema e usa l’MVP per scoprire se la soluzione regge.

Domande frequenti

Un MVP deve sempre essere software?
No. Un video, una landing page con un form, un servizio fatto a mano dietro le quinte (il cosiddetto “Wizard of Oz”) sono MVP a tutti gli effetti, purché ti permettano di misurare il comportamento reale degli utenti. Conta l’apprendimento, non la tecnologia.

Quanto deve durare la costruzione di un MVP?
Non c’è un numero fisso, ma se ci stai mettendo più di qualche settimana è probabile che tu stia costruendo troppo. Se il tuo MVP richiede mesi, quasi sempre puoi spezzarlo in un esperimento ancora più piccolo che risponde alla domanda più urgente.

Cosa faccio se l’MVP fallisce?
Un MVP che smonta la tua ipotesi non è un fallimento, è il suo lavoro. Hai appena evitato di sprecare mesi sulla strada sbagliata. A quel punto fai un pivot, cambi segmento di utenti o riformuli il problema, e progetti il prossimo esperimento.

Il punto che resta vale per qualsiasi prodotto: un minimum viable product non serve a costruire di meno, serve a sapere di più, prima e con minor rischio. Chi padroneggia questa logica smette di chiedersi “come faccio a costruirlo” e inizia a chiedersi “come faccio a sapere se vale la pena costruirlo”. È un cambio di mentalità, ed è esattamente ciò che distingue un buon product manager.