Guida pratica all’MVP: quali feature includere e quali tagliare?

Un MVP, ossia Minimum Viable Product, è un ottimo metodo per testare le acque e capire se ci sia mercato per un’applicazione. Ne abbiamo parlato in altri articoli, ad esempio questo.

Quello che però sembra emergere a volte è che l’MVP viene visto come una versione sciatta e incompleta del prodotto finale, ma che trae il suo successo dalla velocità con cui può essere costruita e commercializzata. Ma sarà proprio così?

Cos’è un MVP e a cosa serve

Diciamolo chiaro e tondo: un MVP non è un prodotto incompleto e poco curato. È una versione minima del prodotto, ma non per questo ci si può permettere di lanciare un prodotto non funzionante e mal realizzato.

Lo scopo di un MVP è quello di validare il prodotto, cioè comprendere se questo possa avere mercato o meno. Concretamente significa:

• Capire se ci sono persone realmente interessate al prodotto, al di là dell’interesse ipotetico, raccolto con questionari e interviste.
• Confermare che il prodotto sia in grado di risolvere il problema identificato per i suoi utenti target.
• Testare che ci sia un utilizzo oggettivo del prodotto e l’eventuale predisposizione a pagarlo.

Il segreto per costruire un buon MVP è quello di non costruire né troppo, né troppo poco. 

Da un lato, investire eccessivamente su un MVP, praticamente rendendolo un prodotto finito, con molteplici funzionalità secondarie, invalida lo scopo della validazione. Infatti, idealmente è bene aver compreso se il prodotto può funzionare prima di investirci eccessivo tempo e denaro.

Ma non solo: introdurre troppe variabili fin dal lancio non consente di determinare cosa eventualmente non stia funzionando, nel caso questo non riscuotesse il successo atteso.

Dal canto opposto, l’MVP non dev’essere un prodotto grezzo e costruito di fretta. Se l’MVP è poco curato non è possibile determinare quali siano i fattori che hanno allontanato l’utente: è colpa dello scarso interesse o di una UX terribile?

È chiaro quindi che dev’essere trovato il giusto compromesso tra un prodotto troppo rifinito e uno che invece non rispetta i minimi canoni di funzionamento.

Come decidere quali feature vanno incluse

In Mabiloft, quando costruiamo un MVP non ragioniamo sul prodotto come una lista di feature, ma leggendolo come un flusso ordinato che serve a validare l’ipotesi di funzionamento dell’applicazione finale.

Partendo da questo presupposto, la domanda da farsi è: cosa deve funzionare abbastanza bene perché il test sia valido?

Un MVP fatto bene ha:

• Poche feature core
• Un flusso chiaro
• UX semplice

Grazie a questi elementi essenziali è possibile validare la premessa principale, fornendo all’utente il valore promesso. Solo così possiamo misurare il comportamento dell’utente in una situazione realistica.

Facciamo alcuni esempi concreti:

• Il login deve essere presente solamente quando è necessario per poter usare il prodotto.
• Il pagamento viene introdotto (anche in forma primordiale) solamente quando ci interessa validare la disponibilità a pagare il prodotto.
• È bene inserire un minimo di tracciamento per capire come si comporta l’utente in piattaforma.
• Sono necessari tutti i pattern di interazione classici, come i messaggi di errore, i modali di conferma per azioni rischiose, ecc.
• Si dà sempre per scontato che un prodotto esposto al pubblico disponga di tutti i criteri di sicurezza base.

Assolutamente importante è che l’MVP non contenga bug bloccanti: se l’utente viene allontanato da un frustrante malfunzionamento dell’applicazione, non si può dire che il concetto alla base del prodotto sia validato.

In generale, quindi, devono essere presenti tutti quegli elementi senza i quali il test di validazione risulterebbe falsato. 

Il branding è importante?

Un aspetto spesso trascurato in un MVP è quello legato al branding. Intuitivamente, si può pensare che non si tratti di un aspetto critico per validare il funzionamento. Ciò è spesso vero, specialmente quando ci sono altre figure che si occupano del marketing e che quindi introducono l’utente al prodotto.

La questione però è ben differente se l’utente è invitato a scoprire il prodotto da solo, soprattutto quando il prodotto coinvolge aree sensibili come quella finanziaria o della salute. In quel caso, il branding contribuisce a far percepire la solidità del prodotto e a costruire la fiducia necessaria perché l’utente conceda i propri dati personali.

Inoltre, nel caso specialmente di prodotti dedicati a un target specifico, diventa anche un mezzo necessario per il posizionamento. Ad esempio, un prodotto rivolto a un pubblico giovane in cui la comunicazione è fredda e tecnica potrebbe allontanare il target solo per una questione comunicativa, invalidando di fatto il test.

Ad ogni modo, spesso non è necessario un brand completo, ma un’identità anche minima che sappia parlare al pubblico giusto e che trasmetta affidabilità.

Cosa non è necessario in un MVP

A volte, quando viene progettato un MVP, la vera difficoltà non è decretare cosa includere, ma cosa possa essere escluso. Abbiamo già detto che è necessario tutto ciò che fa parte del flusso core dell’applicazione. Su cosa possiamo invece tagliare?

A restare escluse dall’MVP sono tutte le feature secondarie, che arricchiscono e migliorano il prodotto ma non sono strettamente necessarie per il suo funzionamento principale. Alcuni esempi di ciò includono:

• Dashboard complesse
• Personalizzazione avanzata
• Pannelli admin evoluti
• Branding completo

Fake it until you make it… letteralmente

In particolare, tutto quello che può essere simulato o gestito manualmente dietro le quinte non è necessario che sia presente in una prima versione. Ciò che importa è che l’utente abbia la percezione che tutto funzioni, e poco importa se il funzionamento reale è, in un primo momento, solo apparente.

Può sembrare che ciò sia controintuitivo: perché simulare un funzionamento apparente? Facciamo l’esempio di un’applicazione che dai dati raccolti e caricati genera dei report dettagliati. La feature di generazione del report potrebbe richiedere molto tempo per essere sviluppata. 

Se il nostro interesse è quello di comprendere se gli utenti scaricano l’applicazione, se caricano davvero i dati e se sono interessati al report, potrebbe essere più conveniente inizialmente creare a mano il report e inviarlo all’esterno dell’app. 

In questo modo, prima di imbarcarci nello sviluppo di una feature complessa sapremo già se questa ha importanza o meno per l’utente.

Come si gestisce il debito tecnico

Costruire un MVP comporta spesso creare del debito tecnico, cioè richiede di scendere a compromessi sulla qualità dell’intero sistema e sulla sua scalabilità pur di avere un go-to-market più rapido.

Attenzione però: purché sia consapevole, il debito tecnico non è il male assoluto, ma spesso rientra nelle scelte strategiche. 

Nella costruzione dell’MVP, infatti, ci si concentra sulla validazione del prodotto, non sulla sua qualità da un punto di vista tecnico, se non, ovviamente, per avere il minimo necessario perché il prodotto appaia come solido e non presenti falle di sicurezza.

Per quanto riguarda le killer feature, cioè quelle per le quali l’utente scarica l’applicazione o si iscrive alla piattaforma, è fondamentale che siano messe a punto. Il cuore del prodotto deve essere solido, perché è ciò che veramente interessa validare con l’MVP. 

Ma tutto il resto? Ogni altro aspetto è sacrificabile, riscrivibile in un secondo momento se necessario.

La guida pratica: va incluso o tagliato?

Chiudiamo questo articolo con delle linee guida concrete su come decidere cosa vada inserito nell’MVP del tuo prodotto. 

Le domande da porsi per scegliere se una feature è da rinviare a una seconda versione oppure è necessaria subito sono:

• Senza questa feature, il prodotto perde il proprio valore?
• Se manca questa feature il test di validazione è falsato?
• La feature è necessaria per creare fiducia nel prodotto?
• È impossibile sostituire la feature con una simulazione della stessa?

Se la risposta ad almeno una di queste domande è sì, allora la feature deve essere inclusa. Altrimenti, si tratta di feature che potenzialmente aiutano a far sembrare più completo il prodotto, ma possono attendere.

Un MVP fatto bene non è una versione minima solo per una questione di risparmio, ma anche perché si sceglie accuratamente cosa mostrare all’utente.

Se stai pensando di lanciare il tuo prodotto e hai difficoltà a capire cosa includere nel tuo MVP, rivolgiti a noi. Ti aiuteremo a determinare cosa va incluso e cosa può aspettare, quali sono i flussi essenziali e le feature immancabili. Grazie al nostro Sprint Check, abbiamo aiutato decine di startup a fare altrettanto e possiamo aiutare anche te.