Creare un prodotto partendo da zero è un impresa non da poco. La quantità di lavoro da fare sembra infinita, e il tempo a disposizione è sempre limitato. Per essere competitivi non serve essere perfetti, ma veloci. Occorre quindi lanciare un prodotto non appena è in grado di svolgere la funzione primaria per cui è stato pensato. Questo prodotto ridotto al minimo indispensabile è chiamato MVP (Minimum Viable Product). Ma come si crea un MVP?
La mia prima esperienza nel creare un MVP è stata in una piccola startup. Quando ho iniziato non c’era altro che un’idea. Nel giro di pochi mesi sono riuscita insieme al resto del team a trasformare quell’idea in un MVP. Questo è a grandi linee il processo che ho seguito:
- Identificare quale problema dell’utente si vuole risolvere
- Verificare la validità del’ipotesi con le user interviews
- Trovare una soluzione con la Value Map Proposition Canvas
- Definire le dipendenze e il flusso di costi e ricavi con il Business Model Canvas
- Pianificare lo sviluppo
- Sviluppare il prodotto
- Lanciare l’MVP
Andiamo a vedere a cosa serve ciascuna fase e com’è possibile attualizzarla per creare un MVP.
Identificare quale problema dell’utente si vuole risolvere
Il primo passo logico nel creare un MVP è conoscere l’utente per cui lo stiamo facendo e in particolare il problema che il nostro prodotto aiuterà a risolvere. È quindi importante partire con una o più ipotesi articolate chiaramente da poter in seguito verificare. Per dare una struttura alle cose e assicurarmi che tutte le mie ipotesi fossero coerenti, ho usato questa formula:
Credo che [l’utente] provi [fatica/fastidio] quando fa / a causa di [attività da svolgere/responsabilità].
Lean Customer Development , Cindy Alvarez
Ho liberamente tradotto dall’inglese la parola “pain” (letteralmente: dolore) come fatica o fastidio. Infatti è importante considerare la dimensione umana dell’utente e cercare di risolvere un problema che crea uno svantaggio reale. Il mito dell’utente che prende decisioni razionali è stato sfatato da tempo e oggi sappiamo con certezza che la maggior parte delle decisioni vengono prese per motivi tutto fuorché razionali. (Per approfondire l’argomento consiglio il libro di Daniel Kahneman Pensieri lenti e veloci, che ha vinto il premio Nobel all’economia per aver dimostrato la nostra inettitudine nel prendere decisioni razionali).
Ora che abbiamo le nostre ipotesi, è ora di metterle alla prova.
Verificare la validità dell’ipotesi con le user interviews
Il modo più efficiente e meno dispendioso per mettere alla prova le nostre ipotesi è testarle su utenti veri (o potenziali) con delle user interviews. Poiché a questo punto non disponiamo ancora di un prodotto, non ci resta che parlare con l’utente, per capire se le ipotesi che abbiamo formulato trovano effettivamente riscontro nella realtà.
Fare domande mirate su un argomento specifico sembra più facile di quanto sia. Ci troveremo a dover utilizzare alcuni stratagemmi al fine di evitare risposte di cortesia o vere e proprie bugie che i nostri utenti ci rifileranno più o meno consciamente. Inoltre, dovremo fare attenzione ai nostri pregiudizi e a come questi influiscono sul modo in cui poniamo le domande e interpretiamo le risposte.
Per suggerimenti ed esempi approfonditi sull’argomento consiglio di leggere Lean Customer Development di Cindy Alvarez. Di seguito delle linee guida da ricordare ad ogni intervista:
- Ascolta attivamente il tuo interlocutore
- Fai domande aperte
- Mantieni note obiettive e trascrizioni accurate delle parole dell’utente
È meglio, se possibile, registrare le interviste per avere una fonte non contaminata da interpretazioni di quello che l’utente ci ha detto. Può capitare di sviluppare nuove ipotesi in un secondo momento, e rivedere le interviste alla luce della nuova ipotesi.
Trovare una soluzione con la Value Map Proposition Canvas
Una volta raccolti abbastanza dati da confermare che le ipotesi formulate sono problemi reali di utenti reali, è giunto il momento di lavorare sul valore aggiunto che il nostro prodotto può portare. Per fare questo uno strumento molto utile è la Value Proposition Canvas teorizzata da Alex Osterwalder.
Si tratta in pratica di descrivere il nostro utente in base alle attività che deve svolgere (jobs), alle fatiche o fastidi legati allo svolgimento di tali attività (pains) e ai vantaggi o soddisfazioni che deriva da queste stesse attività (gains). Allo stesso modo, guarderemo al prodotto che dobbiamo offrire in termini di soluzioni che aiutano l’utente a svolgere tali attività (products or solutions), “antidolorifici” (pain reliever) che permettono all’utente di rimuovere o quantomeno ridurre il disagio collegato alle attività da svolgere e generatori di profitto o vantaggio (gain creators) che renderebbero l’esperienza ancora più soddisfacente.
Definire le dipendenze e il flusso di costi e ricavi con il Business Model Canvas
A questo punto abbiamo definito un problema particolare, un utente specifico e un vantaggio competitivo dato dalla nostra soluzione. Per completare la nostra strategia andiamo ora a tracciare le dipendenze e i principali flussi di liquidità in entrata e uscita del nostro prodotto: un’analisi del mercato e dei partner coinvolti, principali attività e risorse necessarie a creare il prodotto, fonti di guadagno e costi, canali di distribuzione e strategia di servizio al cliente.
Anche in questo caso possiamo sfruttare uno strumento creato da Osterwalder che sostituisce i tradizionali modelli di business e si adatta meglio ad una realtà appena nata e con ancora molti dubbi da chiarire: la Business Model Canvas.
Questo piano andrà aggiornato man mano che le ipotesi verranno validate e servirà da supporto per decidere quali funzioni includere al momento di creare l’MVP.
Pianificare lo sviluppo
Una volta definita la nostra strategia, è arrivato il momento di fare un piano per eseguirla. L’errore comune in questa fase è perdersi in descrizioni dettagliate degli obiettivi e ancorarsi a scadenze fisse. Bisogna tener conto del fatto che questo processo non sarà lineare, ma iterativo. Il nostro bel piano così come lo visualizziamo ora, arriverà alla fine stravolto dagli imprevisti che inevitabilmente incontreremo lungo il percorso. È meglio quindi prioritizzare pochi obiettivi importanti cui vogliamo assolutamente attenerci.
Attenzione a non confondere poco dettagliato con generico. Per quanto privi di dettagli, gli obiettivi devono essere chiari e specifici. Definire delle user stories, darà agli stakeholder un’idea specifica di cosa verrà sviluppato, ma senza troppi dettagli sull’aspetto o funzionamento tecnico del prodotto. Questo eviterà false aspettative e darà modo ai team responsabili di lavorare liberamente alla soluzione. Per quanto sia meglio evitare il più possibile di legarsi a scadenze, è naturale e necessario che ci sia un termine per la creazione e lancio del prodotto. Meglio quindi preferire scadenze flessibili, ad esempio un trimestre anziché una data precisa. Da un lato per permettere ad altri team di organizzare il proprio lavoro, dall’altro perché un po’ di pressione è indispensabile per raggiungere dei buoni risultati e rimanere produttivi.
Una roadmap è lo strumento ideale sia per comunicare esternamente con gli stakeholder, che per mantenere il team responsabile dello sviluppo consapevole dei proprio progressi. L’importante è mantenere anche in questo caso una veduta d’insieme ed evitare dettagli. Una roadmap deve essere uno strumento che aiuta tutti a capire dove ci troviamo e cosa stiamo facendo, non un mostro di documento che il product manager spende ore ad aggiornare!
Sviluppare il prodotto
Adesso che disponiamo di una strategia e un piano d’azione non resta che eseguirlo. Sviluppo e pianificazione sono in realtà due facce della stessa medaglia e si influenzano a vicenda. Come dichiarato nel Manifesto Agile, per creare un ottimo prodotto è importante rispondere al cambiamento più che seguire un piano.
Esistono diversi metodi ispirati alla filosofia agile per gestire lo sviluppo vero e proprio del prodotto e l’interazione con gli sviluppatori, tra cui i più noti sono Scrum e Kanban.
Durante la fase di sviluppo del prodotto le user stories verranno utilizzate come base per la creazione del software. Con l’obiettivo da raggiungere chiaramente specificato, designer e programmatori potranno sfruttare a pieno le proprie competenze per fornire la migliore soluzione rispettivamente di design e tecnica. Per consentire a questi team di lavorare liberamente è importante non creare attese sull’aspetto o i particolari tecnici nel momento di pianificazione.
D’altra parte è utile pianificare dei riscontri regolari da parte degli stakeholder sul lavoro svolto, in modo da poter correggere velocemente eventuali errori o chiarire malintesi, ed evitare di trovarsi con brutte sorprese al momento del lancio.
Per fare questo conviene pianificare fin dall’inizio una serie di incontri a scadenza regolare in cui presentare il lavoro svolto, chiarire dubbi e raccogliere feedback. Il metodo più efficace per comunicare durante questi incontri è tramite supporti visivi, sia del prodotto finito o, se questo non è ancora disponibile, di un mock-up.
Lanciare l’MVP
Finalmente! Con ottime probabilità ci sarà qualcosa che manca alla vigilia del lancio. Qualcosa che non è esattamente come dovrebbe essere. Se questo non compromette la funzionalità del prodotto in maniera irreparabile, è meglio non rimandare il lancio. Ci sarà sempre qualcosa da migliorare. Del resto, stiamo parlando di un minimum viable product. È più importante mettere l’MVP nel mercato e farci dire dagli utenti cosa funziona e cosa manca, piuttosto che perdere tempo prezioso perfezionando qualcosa di cui magari agli utenti non importa nulla.
Un buon lancio non deve per forza essere clamoroso. Soprattutto se è la prima versione o si tratta di un prodotto particolarmente innovativo, può essere una buona idea optare per un lancio soft, un numero limitato di utenti e poca pubblicità. Questo darà tempo di raccogliere feedback e migliorare il prodotto prima di renderlo disponibile ad un pubblico più ampio.
Qualunque sia il tipo di lancio pianificato, è importante avere un piano definito degli obiettivi da raggiungere, come verranno misurati i risultati, e chi è il responsabile per ciascun traguardo.
Nella realtà creare un MVP non è un processo così lineare. Le nuove informazioni e le scoperte che si fanno lungo il percorso vanno a influenzare o addirittura stravolgere il piano originario, e sono necessarie numerose iterazioni prima di raggiungere il risultato desiderato. Mantenere una mentalità aperta è fondamentale per non lasciarsi scoraggiare e riuscire a creare un MVP di successo.
