Comprendere il Minimum Viable Product (MVP) in Scrum: Outcome vs. Output

Cos’è un Minimum Viable Product, come ti porta al successo lavorarci e quali enormi vantaggi porta tutto ciò per te, il tuo team e i tuoi clienti?

In questo articolo imparerai tutto sull’MVP e scoprirai perché la differenza tra Outcome e Output decide il successo o il fallimento del tuo prodotto.

Differenza tra Outcome e Output nell’MVP

Chi sviluppa un prodotto per i propri clienti dovrebbe chiedersi nel primo passo quali esigenze hanno effettivamente questi clienti e quali problemi il prodotto dovrebbe risolvere. Una volta chiarite queste domande, può iniziare lo sviluppo del prodotto, perché solo allora è chiaro quale risultato (Outcome) desiderano i clienti. Se il risultato desiderato è ad esempio che i clienti possano spostarsi più velocemente da A a B, il prodotto (Output) potrebbe essere un’auto. Ma non necessariamente, perché anche uno skateboard fornirebbe l’Outcome desiderato – e sarebbe anche più economico e veloce da sviluppare rispetto all’auto.

Curiosamente, la maggior parte delle aziende prima dello sviluppo del prodotto non si occupa affatto dell’Outcome per i clienti: partono da un’idea di prodotto fissa e si concentrano esclusivamente sulla consegna di esattamente questo Output con i relativi pacchetti di lavoro o feature.

Il puro focus sull’Output – un rischio imprenditoriale

Perché questo approccio è così rischioso e perché la pura focalizzazione sull’Output può avere conseguenze fatali per un’azienda?

Chi lavora con un approccio Big-Bang vuole completare il proprio prodotto al 100% prima di consegnarlo al cliente. Questo può portare a:

• l’azienda investe troppo tempo e denaro nello sviluppo,

• i clienti non hanno più bisogno del prodotto perché durante il lungo periodo di sviluppo un concorrente ha lanciato una variante migliore,

• il mercato per il prodotto non esiste più perché le circostanze e le esigenze sono cambiate,

• nessuno acquista il prodotto perché è stato progettato completamente lontano dal gusto e dalle necessità dei clienti,

• il prodotto è diventato così sovradimensionato, complesso e costoso che i clienti preferiscono una variante più semplice e conveniente della concorrenza.

In breve: il rischio è grande che le aziende vincolino tutte le risorse per un periodo troppo lungo a un’idea di prodotto rigida, ma che il prodotto poi non venga acquistato. Come aggirare questo problema in modo semplice e agile? La soluzione si chiama: Minimum Viable Product.

Quale soluzione offre il Minimum Viable Product in Scrum?

Se tu e la tua azienda lavorate già con Scrum, potresti averne già sentito parlare: Minimum Viable Product (MVP) significa il più piccolo prodotto consegnabile. Se lavori ad esempio come Product Owner per la tua azienda, dovresti concentrarti sempre sull’Outcome basato sulle esigenze del cliente – nell’esempio sopra citato, spostarsi più velocemente da A a B.

Cosa può essere esattamente un prodotto minimo consegnabile o Minimum Viable Product nel contesto di questa esigenza del cliente, lo mostra la seguente immagine dal blog di Crisp:

Naturalmente l’auto è solo una metafora per il prodotto che il cliente desiderava originariamente: la sua esigenza è spostarsi più velocemente da A a B e pensa di aver bisogno di un’auto come soluzione.

Con l’approccio del Minimum Viable Product, tu come Product Owner fai in modo che tu e il tuo Scrum Team consegniate in iterazioni rapide e piccole i prodotti minimi consegnabili (MVP) al cliente. È importante che tu mantenga sempre in vista l’Outcome desiderato e consegni MVP con cui il cliente possa soddisfare la sua esigenza almeno nelle sue linee fondamentali:

La riga superiore dell’immagine mostra che non ha senso vendere al cliente semplicemente le prime parti finite dell’auto – con quelle sicuramente non può spostarsi più velocemente da A a B. La riga inferiore mostra invece che sia uno skateboard che un monopattino, una bicicletta e una moto possono essere consegnati al cliente come MVP, perché un movimento più veloce è garantito con ciascuna di queste soluzioni.

Quali vantaggi porta un MVP?

La consegna di MVP a clienti, tester e Early Adopter ha i seguenti grandi vantaggi:

• Ricevi feedback molto presto nel processo di sviluppo: questa prima versione del prodotto soddisfa già i desideri del cliente? Funziona come previsto? Il design è adeguato? Ci sono forse desideri diversi o aggiuntivi dietro l’esigenza originale del cliente?

• Un apprendimento rapido porta a grandi progressi: se già dopo il primo feedback sull’MVP sai cosa è importante per il cliente e a cosa può rinunciare, già la seconda iterazione mostrerà un grande miglioramento.

• Gli adattamenti sono sempre possibili: lo sviluppo iterativo garantisce un’elevata flessibilità – invece di dover riprogettare faticosamente un prodotto finito dopo 3 anni di sviluppo, puoi apportare modifiche dopo ogni iterazione senza grande sforzo.

• Generi entrate precocemente: poiché puoi già far pagare i tuoi primi MVP, riduci notevolmente il rischio imprenditoriale.

• Clienti entusiasti grazie alla riduzione del prezzo di acquisto e del tempo di sviluppo: se nel nostro esempio sopra si scopre che il cliente è già completamente soddisfatto della bicicletta perché soddisfa la sua esigenza, come Product Owner fermi lo sviluppo del prodotto esattamente a quel punto. Poiché hai sviluppato la bicicletta 1. più velocemente e 2. più economicamente rispetto a un’auto, puoi offrire al cliente precocemente una soluzione soddisfacente che gli costa meno.

Un tipico esempio di Minimum Viable Product

Un buon esempio di MVP è il tunnel autostradale sulla A1 a Colonia: invece di concentrarsi sulle esigenze di riduzione del rumore dei residenti e consegnare dapprima misure più piccole e relativamente economiche come un limite di velocità, asfalto fonoassorbente e barriere antirumore come Minimum Viable Product, costruendo poi sul feedback dei residenti, i responsabili avevano in mente solo il loro Output: un tunnel antirumore all’avanguardia!

Dopo lunghi anni di costruzione e le conseguenti interruzioni del traffico, è nato un cosiddetto tunnel antirumore costato 200 milioni di euro. Come mostra il feedback forzatamente troppo tardivo dei residenti, il tunnel non ha risolto il problema – al contrario, ha persino peggiorato la situazione rumore.

Perché vale la pena lavorare secondo l’MVP?

Soprattutto quando il prodotto effettivo non è ancora completamente chiaro e non è stato empiricamente confermato che i clienti lo acquisteranno così e non diversamente, è decisivo per il successo pensare in termini di Outcome e di esigenze dei clienti e avvicinarsi ad essi attraverso gli MVP.

E anche per prodotti di cui conosci già il quadro generale, come ad esempio un camion, la consegna incrementale di Minimum Viable Product può essere vantaggiosa. Perché eventualmente il tuo cliente scopre che è soddisfatto anche con molte meno funzionalità di quanto pensava inizialmente. E un cliente che ottiene la soluzione al suo problema più velocemente e a meno soldi è un cliente estremamente soddisfatto.

Vuoi saperne di più sul lavoro con Scrum e su come il lavoro agile rende i tuoi clienti più soddisfatti e la tua azienda più di successo? Nella nostra Scrum Guide trovi tutto ciò di cui hai bisogno per comprendere i fondamenti. Nei nostri training Scrum certificati impari come applicare Agile nella pratica.

Cos’è un prodotto?

Leggi cos’è effettivamente un prodotto in Scrum e come creare una definizione di prodotto.
=> Cos’è un prodotto?

Come rendere il Refinement un successo!

Definisci come Product Owner l’Outcome per il prossimo Sprint e migliora i risultati del Refinement con questi trucchi.
=> Product Backlog Refinement

Come sviluppare una visione di prodotto?

Scopri come puoi sviluppare una visione di prodotto in 3 semplici passi come Product Owner.
=> Sviluppare una visione di prodotto