Un MVP non è una versione economica del prodotto completo.
Non è nemmeno una demo con due schermate e molti pulsanti che “arriveranno presto”.
È la versione più piccola che permette a una persona reale di compiere un’azione utile e a te di imparare qualcosa di importante.
Se non sai che cosa vuoi verificare, non hai definito un MVP. Hai soltanto ridotto la lista delle funzioni.
Prima la domanda, poi il prodotto
Ogni prima versione dovrebbe partire da una domanda.
Per esempio:
- le persone riescono a prenotare senza telefonare?
- le aziende inviano una richiesta completa?
- i professionisti accettano nuovi lavori attraverso la piattaforma?
- i clienti sono disposti a pagare?
- il servizio può essere consegnato in tempi sostenibili?
La domanda cambia completamente ciò che devi sviluppare.
Se vuoi capire se le persone pagano, serve un modo reale per acquistare. Se vuoi verificare se completano una richiesta, servono campi, istruzioni e controlli adeguati.
Una presentazione bella non risponde a nessuna delle due domande.
L’utente deve completare qualcosa
Un MVP non deve contenere tutto. Deve però permettere un percorso completo.
Un utente potrebbe:
- registrarsi;
- inserire una richiesta;
- ricevere una risposta;
- confermare il servizio.
Alcuni passaggi interni possono essere manuali. Per l’utente, però, il risultato deve essere reale.
Se può soltanto esplorare schermate o lasciare un’email, stai misurando interesse. Può essere utile, ma non stai ancora verificando l’uso del prodotto.
“Minimo” non significa fatto male
Togliere funzioni non autorizza a ignorare chiarezza, affidabilità e sicurezza.
La prima versione può avere poche possibilità. Quelle presenti devono funzionare abbastanza bene da permettere una prova credibile.
Un utente che abbandona perché non capisce un pulsante non sta rifiutando la tua idea. Sta reagendo a un problema della prova.
Il rischio è arrivare alla conclusione sbagliata: pensare che non esista interesse quando in realtà il prodotto non permetteva di esprimerlo.
Che cosa può restare manuale
All’inizio puoi gestire a mano attività che richiederebbero molto sviluppo:
- controllare una richiesta;
- scegliere il professionista adatto;
- preparare un documento;
- approvare un profilo;
- inviare una comunicazione particolare.
Questo approccio permette di capire se il servizio funziona prima di automatizzarlo.
Ma il lavoro manuale deve restare dietro le quinte. Se prometti una risposta immediata e poi impieghi due giorni, non stai provando il prodotto che immagini.
Che cosa lasciare fuori
Le funzioni da rimandare sono quelle che non aiutano a verificare la domanda principale.
Spesso possono aspettare:
- dashboard avanzate;
- molte possibilità di personalizzazione;
- automazioni per casi rari;
- app separate per ogni dispositivo;
- sistemi complessi di invito;
- report completi;
- più piani commerciali.
“Potrebbe servire” non è un motivo sufficiente.
Ogni funzione aggiunta richiede sviluppo, prove e manutenzione. Soprattutto rende meno chiaro che cosa stai cercando di imparare.
Quali dati osservare
Non basta chiedere agli utenti se il prodotto piace.
Le persone possono essere gentili, curiose o entusiaste dell’idea senza usarla davvero.
Osserva invece:
- quanti iniziano il percorso;
- quanti lo completano;
- dove si fermano;
- quante volte chiedono aiuto;
- quanto tempo serve;
- se tornano;
- se pagano o accettano un impegno concreto.
I numeri da guardare dipendono dalla domanda iniziale. Non serve riempire una dashboard di dati che non cambieranno nessuna decisione.
Quando la prova è riuscita
Un MVP non deve dimostrare che il progetto avrà sicuramente successo.
Deve darti abbastanza informazioni per scegliere il passo successivo.
Potresti scoprire che:
- il problema esiste, ma la soluzione è troppo complicata;
- gli utenti usano una parte diversa da quella prevista;
- il servizio interessa, ma il prezzo no;
- serve più assistenza del previsto;
- la prima ipotesi era sbagliata.
Anche un risultato negativo può essere utile se arriva prima di un investimento molto più grande.
Il fallimento vero è sviluppare per mesi e scoprire soltanto alla fine che nessuno aveva provato il punto centrale.
MVP, prototipo e prodotto completo
Un prototipo serve soprattutto a mostrare e discutere come potrebbe funzionare qualcosa.
Un MVP viene usato davvero e produce un risultato, anche con limiti chiari.
Un prodotto più completo affronta più casi, automazioni, controlli e volumi.
Non sono tre livelli di qualità. Sono strumenti per momenti diversi.
Se devi capire se un percorso è comprensibile, può bastare un prototipo. Se devi verificare se le persone lo usano e pagano, serve qualcosa di reale.
La prima versione deve meritarsi la seconda
Non costruire un MVP per poter dire che il progetto è iniziato.
Costruiscilo per ottenere una risposta che oggi non hai.
Definisci:
- l’ipotesi più rischiosa;
- l’azione che l’utente deve completare;
- il risultato che riceve;
- il dato che userai per decidere;
- che cosa può restare manuale.
Se la prima versione non cambia nessuna decisione, probabilmente sta testando troppo poco oppure niente.
Definiamo una prima versione che abbia qualcosa da dimostrare
QUODE trasforma l’ipotesi principale in un percorso utilizzabile, lasciando fuori le funzioni che non servono ancora.