Sviluppare un MVP significa costruire la versione più piccola del prodotto che permette a persone vere di fare la cosa per cui il prodotto esiste, e verificare così l'ipotesi più rischiosa prima di investire nel resto. Non è una demo e non è un prodotto fatto male per risparmiare: funziona davvero, ma su un perimetro stretto e scelto con cura. La parte difficile non è scrivere il codice, è decidere cosa lasciare fuori.
Cos'è un MVP, secondo chi ha definito il metodo?
MVP sta per minimum viable product. Eric Ries lo definisce come la versione di un nuovo prodotto che permette a un team di raccogliere il massimo di apprendimento verificato sui clienti con il minimo sforzo (Eric Ries, Minimum Viable Product: a guide). La parola chiave è apprendimento: l'MVP esiste per rispondere a una domanda sul mercato.
Nello stesso testo Ries aggiunge due precisazioni utili a chi sta per spendere soldi. La prima: l'MVP non serve a fare prodotti minimi, serve a imparare qualcosa dalla prima versione, e questo richiede tempo passato con i clienti e con i dati. La seconda: non esiste una formula, serve giudizio caso per caso. Racconta anche di aver speso settimane su una funzione che non voleva nessuno, quando una semplice campagna di prova su AdWords avrebbe dato la risposta molto prima.
MVP, prototipo o proof of concept: cosa ti serve adesso?
Sono tre strumenti diversi, e confonderli è il modo più rapido per chiedere il preventivo sbagliato:
- Proof of concept: dimostra che una cosa si può fare tecnicamente, per esempio che due sistemi riescono a scambiarsi dati. Non lo usano i clienti.
- Prototipo cliccabile: schermate collegate tra loro, senza dati veri dietro. Serve a capire se le persone trovano la strada nell'interfaccia.
- MVP: prodotto funzionante, con dati veri e persone vere che lo usano per un problema reale. Serve a vedere se lo usano, se tornano, se pagano.
La sequenza tipica è prima il prototipo, poi l'MVP. Il proof of concept serve solo quando c'è un dubbio tecnico serio, come un'integrazione mai provata o un uso dell'intelligenza artificiale di cui non conosci ancora i limiti.
Qual è l'ipotesi che l'MVP deve mettere alla prova?
Prima della lista delle funzioni scrivi l'ipotesi, in una frase che potrebbe rivelarsi falsa. Per esempio: «i titolari di piccoli studi tecnici pagherebbero un abbonamento per preparare i preventivi dal telefono». Poi chiediti qual è il test più economico che potrebbe smentirla.
A volte il primo test non richiede software. Una pagina che descrive il prodotto come se esistesse, con un pulsante per iscriversi e una piccola campagna a pagamento che ci porta traffico, misura l'interesse prima di scrivere codice: è il tipo di prova che, secondo Ries, avrebbe mostrato subito il problema. Come si costruisce una pagina così lo spieghiamo nella guida alle landing page per le campagne.
Se l'ipotesi riguarda l'uso ripetuto, invece, serve un prodotto che funzioni. Nessuna pagina di prova ti dirà se una persona tornerà ad aprire l'applicazione ogni lunedì mattina.
Come si decide cosa entra nell'MVP?
Un metodo semplice per mettere ordine è MoSCoW, usato nel framework DSDM dell'Agile Business Consortium: ogni funzione diventa Must have, Should have, Could have o Won't have per questo giro. Per riconoscere un vero Must have, il DSDM propone una domanda secca: cosa succede se questa funzione manca? Se la risposta è che il progetto non ha più senso, è un Must. Se esiste un modo per arrangiarsi, anche manuale e scomodo, non lo è. Il DSDM consiglia anche di tenere i Must have entro il 60% dell'impegno complessivo, per avere margine sugli imprevisti (Agile Business Consortium, MoSCoW).
Un esempio su una piattaforma di prenotazioni. Must have: cercare una disponibilità, prenotare, ricevere la conferma e, per chi offre il servizio, vedere le prenotazioni ricevute. Should have: promemoria automatici e cancellazione online. Could have: recensioni e statistiche. Won't have per ora: app per gli store, programma fedeltà, collegamento con tutti i calendari esistenti.
La lista dei Won't have conta quanto quella dei Must. Scritta nero su bianco, evita che le funzioni escluse rientrino a metà progetto sotto forma di piccola richiesta.
Come si svolge lo sviluppo, e cosa tocca a te?
Il percorso parte dall'ascolto: prima di disegnare qualcosa si parla con persone del tuo pubblico, non con amici e parenti, per capire come risolvono oggi il problema. Poi si fissa il perimetro con MoSCoW, si disegnano le schermate principali e le si fa provare a qualcuno prima di svilupparle.
Lo sviluppo vero e proprio riguarda solo i Must have, con rilasci frequenti in un ambiente di prova dove vedi l'avanzamento. Seguono il collaudo su telefoni e browser diversi con dati realistici, un lancio ristretto a un primo gruppo di utenti scelti e infine la decisione: continuare, cambiare direzione o fermarsi.
A te tocca la parte che nessuno può fare al posto tuo: portare utenti veri da intervistare, decidere in fretta quando ti vengono proposte alternative, difendere il perimetro quando arriva la tentazione di aggiungere. Quello che allunga davvero i lavori raramente è il codice. Sono le decisioni rimandate, le funzioni aggiunte a metà strada e le attese su servizi esterni, come l'attivazione di un sistema di pagamento o l'accesso alle API di un fornitore.
Meglio no-code o codice su misura per il primo MVP?
Dipende da cosa devi imparare. Se il dubbio è sulla domanda, cioè se qualcuno vuole davvero il prodotto, strumenti no-code, fogli condivisi e un po' di lavoro manuale dietro le quinte spesso bastano a scoprirlo. Se il valore sta in una logica particolare, in un'integrazione o nella gestione di dati delicati, ti serve codice su misura fin da subito.
Il punto da chiarire prima di partire è cosa succede dopo. Un MVP no-code che funziona di solito va ricostruito quando arrivano volumi, permessi complessi o integrazioni. Un MVP scritto con uno stack pensato per crescere, come Next.js e React che usiamo nello sviluppo di web app, si può estendere invece di rifarlo. Conviene deciderlo all'inizio e scriverlo nel preventivo.
Se il prodotto sarà venduto in abbonamento, dopo l'MVP arrivano temi come la separazione dei dati tra clienti e la fatturazione ricorrente: li trovi nella guida su come si costruisce un SaaS.
Cosa misurare dopo il lancio?
Decidi le metriche prima di lanciare, altrimenti finirai per scegliere quelle che ti danno ragione. Per la maggior parte dei prodotti bastano poche domande:
- Attivazione: quante persone che si registrano completano davvero l'azione principale?
- Ritorno: quante tornano a usarlo dopo la prima volta, e con che frequenza?
- Uso delle funzioni: cosa usano e cosa ignorano?
- Disponibilità a pagare: qualcuno paga, o si impegna a pagare, anche prima che il prodotto sia completo?
- Motivi di abbandono: perché chi ha smesso ha smesso? Qui servono conversazioni, non grafici.
Per scoprire i problemi di usabilità non servono grandi campioni. Jakob Nielsen sostiene che test piccoli e ripetuti, con circa cinque utenti alla volta, fanno emergere la maggior parte dei problemi e rendono più di un unico test grande (Nielsen Norman Group). Dopo ogni giro si corregge e si ripete.
Un MVP con utenti veri deve già rispettare il GDPR?
Sì. Se l'MVP raccoglie dati personali, e quasi sempre lo fa almeno con nomi e indirizzi email, il GDPR si applica dal primo utente. L'articolo 25 chiede protezione dei dati fin dalla progettazione e per impostazione predefinita: trattare solo i dati necessari per ogni finalità e non renderli accessibili a un numero indefinito di persone senza l'intervento dell'interessato (art. 25 GDPR).
Per un MVP questa regola è quasi un aiuto: meno dati raccogli, meno funzioni devi costruire per proteggerli. Prima di aggiungere un campo al modulo di registrazione, chiediti se ti serve per verificare l'ipotesi. Se la risposta è no, toglilo.
Hai già una lista di funzioni e non riesci ad accorciarla? Scrivici: la rileggiamo insieme partendo dall'ipotesi da verificare.
Domande frequenti
Quanto costa sviluppare un MVP?
Dipende dall'ipotesi da verificare, dal numero di tipi di utente, dalle integrazioni con altri servizi e dal livello di finitura grafica. Un preventivo utile divide le fasi, cioè analisi, design, sviluppo e test, e dice cosa resta fuori, come hosting, manutenzione e pubblicazione negli store. Diffida di una cifra unica senza l'elenco delle funzioni accanto.
Si può fare un MVP senza scrivere codice?
Sì, quando devi verificare se esiste una domanda: strumenti no-code, moduli e un po' di lavoro manuale spesso bastano a capire se le persone vogliono il prodotto. Diventano un limite quando servono logiche particolari, integrazioni o dati delicati. In quel caso conviene partire con codice su misura.
Dopo l'MVP si butta tutto e si riparte?
Non per forza. Se l'MVP è scritto con uno stack pensato per crescere, si estende a piccoli passi; se è un prototipo o uno strumento no-code, spesso va ricostruito. Conviene deciderlo prima di iniziare e scriverlo nel preventivo, così non diventa una sorpresa.
Come capisco se l'MVP ha funzionato?
Lo capisci se si muovono le metriche decise prima del lancio: persone che completano l'azione principale, che tornano e che sono disposte a pagare. Se non si muove nessuna, l'ipotesi va rivista prima di aggiungere funzioni. Le conversazioni con chi ha smesso di usarlo spesso spiegano il perché meglio dei numeri.
