Dalla visione al prodotto

II parte: Primi passi con i canvas. La Vision Boarddi e

Proseguiamo la nostra serie di articoli sulla ideazione e realizzazione di prodotti utilizzando metodologie quali il Lean Canvas, molto utile per una rapida e proficua identificazione delle caratteristiche fondamentali di ciò che vogliamo realizzare. In questo articolo parleremo in particolare di un utile strumento: la Vision Board.

Condividere l'idea di prodotto

Nell'articolo precedente abbiamo parlato di prodotti e progetti e di quanto sia importante identificare i problemi e i bisogni degli utenti finali per creare un prodotto utile e di valore. Il Lean Canvas ci viene in aiuto per questo aspetto e permette di condividere le strategie di progettazione; da solo però, non è uno strumento sufficiente per descrivere il prodotto al team e al business.

La domanda che è naturale farsi è la seguente: "come condividere l'idea di prodotto che abbiamo in mente?", vale a dire "come renderla comprensibile a tutti i partecipanti al progetto in modo che lavorino tutti nella stessa direzione?".

In questo articolo parleremo di una tecnica che sfrutta nuovamente i Canvas e che è stata proposta la prima volta da Roman Pichler: la Vision Board di prodotto [1]. Si tratta di un ottima fonte di ispirazione che poi abbiamo usato effettivamente nei progetti per descrivire la vision e il backlog dei diversi prodotti.

Sono passati ormai due anni da quando abbiamo cominciato a usare la Vision Board, sia nei corsi che durante le prime fasi di analisi con i clienti, e il riscontro sul campo ha dimostrato che si tratta di uno strumento sempre molto utile ed efficace.

Un grosso rischio: non condividere l'idea

Tipicamente, alla partenza del progetto, qualcuno (il Project Manager, il Product Manager o un'altra figura di rilievo) prepara una presentazione che descrive la vision del prodotto che si realizzerà e la presenta alle persone interessate per condividerne i punti e raccogliere i pareri.

Non sempre tutte le persone che dovrebbero essere coinvolte lo sono o si presentano alla riunione. A volte la presentazione è letta distrattamente in un'email dopo il meeting. A volte i partecipanti alla riunione non sono attenti, ma vengono distratti da telefonate ed email. Fortunamente non sempre è così. Capita anche di avere partecipanti attenti e proattivi, che portano le loro opinioni e consigli.

Comunque vada la persona che ha svolto la presentazione dell'idea di progetto si trova con un problema da risolvere: come gestire il feedback sulla vision? In genere, una volta che questo sia stato raccolto, chi ha fatto la presentazione, fa un riassunto delle opinioni e dei consigli e lo manda via email. Raramente avviene un secondo meeting dove si rivede la vision modificata.

I limiti del "metodo classico"

Quello appena visto è un metodo piuttosto classico di lavorare, diffuso in aziende e gruppi di tipologia anche differenziata. Però, in situazioni come quelle descritte sopra, cosa succede durante il progetto?

Ci sono molte change request! Ora, che ci siano delle richieste di cambiamento è anche normale, ma quello che invece può minare alla base l'andamento del progetto è che queste change request spesso sono anche discordanti tra di loro. Il team non capisce la direzione imposta dal business e il business pensa che il team stia facendo di testa propria.

In realtà il problema non è nè dall'una nè dall'altra parte, ma sta nel modo in cui viene percepito l'obiettivo del prodotto da parte del team e del business. Questa percezione molte volte non è allineata ma discordante e spesso addirittura ortogonale.

Per il team il prodotto deve essere il più tecnologicamente avanzato e aperto; per il business il prodotto deve essere pronto subito, semplice da usare e ricco di funzionalità, anche di quelle non dette perchè "è ovvio che ci siano…".

Eppure i documenti sono stati scritti e le riunioni periodiche sono state fatte. Come mai questo scollamento di visione? Perchè la visione non è stata condivisa e compresa veramente da tutti, perchè non è stata fatta propria da coloro che lavoreranno al progetto. I documenti non sono stati letti con attenzione e le riunioni sono state seguite distrattamente. Un grande spreco di tempo e di soldi…

Il modo migliore che abbiamo trovato per raggiungere l'obiettivo per condividere la visione con un gran risparmio di tempo e di soldi è quello di trovarsi tutti insieme, team di sviluppo e reparto business, e scrivere collaborativamente la vision del prodotto. Vediamo come tutto ciò sia possibile tramite un workshop!

Costruire una vision condivisa: i vari passi del workshop

Partendo da un'idea, una frase, un "titolo", possiamo man mano descrivere una vision completa e coerente, condividendola da subito con tutte le persone coinvolte le progetto.

 

 

Figura 1 - Le fasi di envisioning di prodotto: dall'idea al product backlog.

 

Il workshop si svolge in sessioni da circa 2-3 ore l'una per 2-4 incontri con un numero di partecipanti che varia dai 4 ai 15 circa. Il materiale necessario è costituito da post-it, nastro adesivo di carta e una ampia lavagna a fogli mobili dove andrete a disegnare i canvas.

Il primo canvas è la Product Vision Board dove sono sintetizzati gli aspetti principali del prodotto. Dopo questo si passa al Business Model Canvas dove sono identificati i fattori portanti del prodotto dal punto di vista del business. Come ultimo è identificato il Product Backlog grazie alle personas che raccontano le "storie" con i loro "viaggi" nel Product Canvas.

 

 

Figura 2 - Ciclo di miglioramento continuo del Product Backlog con il Product Canvas.

 

Le storie del Product Backlog sono raffinate grazie a iterazioni successive e alla verifica del prodotto incrementale confrontando i "viaggi" degli utenti reali con quelli delle personas pensate durante il workshop.

La cosa importante della vision basata su questi tre canvas è che sia sempre coerente e allineata con il mondo reale che sta usando il vostro prodotto.

Vision Board

Vediamo il primo canvas che utilizzeremo, ossia, appunto, la Vision Board. L'obiettivo della Vision Board è quello di catturare quattro aspetti fondamentali di un prodotto:

  • Target Group. A chi è rivolto: le categorie di utilizzatori finali del prodotto che state pensando. Cercate di non essere troppo dettagliati ma di identificare le macro-categorie. Man mano che completerete la vision, potrete far emergere nuove categorie oppure aggregarne di esistenti.
  • Needs. Quali bisogni soddisfa o che problemi va a risolvere il vostro prodotto. Cercate di identificare almeno un "need" per ogni gruppo bersaglio. Nel caso il need sia sentito da più target group e un gruppo bersaglio non abbia un bisogno unico, prendete in considerazione di aggregare i Target Group. Ricordatevi: è importante essere sintetici nella Vision Board.
  • Product. Quali sono le caratteristiche principali e di maggior rilievo del prodotto? Descrivetene da 3 a massimo 5. In questa lista ristretta, non elencate quelle scontate ma cercate di descrivere quelle di maggior rilievo.
  • Business Value. Quali sono le aspettative di business che ha l'azienda che sta realizzando questo prodotto o che erogherà il servizio oggetto della vision? Le aspettative possono essere sia di incremento di ricavi sia di altra natura come risparmio di costi di esercizio, mantenimento della quota di mercato, miglioramento della soddisfazione dei propri clienti.

Le informazioni contenute in queste quattro colonne sono poi riassunte nel Vision Statement, una frase che tutte le persone coinvolte nel progetto doverebbero conoscere e fare propria, il faro guida del progetto.

 

 

Figura 3 - Vision Board, con le colonne per "gruppi bersaglio", "bisogni", "caratteristiche di prodotto" e "aspettative di business".

 

Essendo la vision il "faro" guida del progetto, se questo faro si spegnesse o venisse perso di vista, il progetto stesso potrebbe subire dei danni e dei cambi di rotta molto richiosi che potrebbero portaro al fallimento.

La sintesi della vision aiuta a mantenere i concetti semplici da condividere, da memorizzare e da verificare costantemente. L'ideale sarebbe avere la Vision Board sempre a portata di sguardo sia per il team che per il business, insieme agli altri information radiators ("diffusori di informazione").

In figura 4, abbiamo riportato un un esempio di Vision Board fatta durante il gioco "Agile the Board Game" [2].

 

 

Figura 4 - Esempio di Vision Board costruita durante il gioco "Agile the Board Game".

 

Esempio: Vision Board di Enjoy

Molti lettori conosceranno il sistema di car sharing che consente di condividere automobili non di proprietà tra diversi utenti. Partito da Milano l'anno scorso con Car2Go ed Enjoy, il servizio si sta diffondendo rapidamente nelle maggiori città italiane. Proviamo a descrivere la vision di questo servizio attraverso una Vision Board.

 

 

Figura 5 - Esempio di Vision Board per il servizio di car sharing Enjoy.

 

Provate a leggere le 4 colonne della Vision Board da sinistra verso destra e poi a sintetizzare in una frase i quattro fattori che compongono la vision. Penso che vi risulterà naturale comporre una frase del tipo:

"Per chi  vuole noleggiare un'auto, velocemente, pagando solo per quanto l'utilizza, Enjoy offre Fiat 500 a portata di app e ci permette di aumentare i margini sul noleggio delle autovetture creando un nuovo mercato nel settore della mobilità cittadina".

Notate la parte "…e ci permette di aumentare…". Il "ci" sta a significare "noi, azienda che commercializza questo servizio". È molto importante sottolineare questo aspetto.

Troppo spesso viene trascurato dal team il motivo aziendale per il quale il prodotto viene realizzato. È bene invece dirselo e ricordarselo. Infatti il motivo aziendale influisce sul ranking del Product Backlog; dimenticarsi questo particolare potrebbe essere fatale.

Passi successivi

Una volta che la Vision Board sia stata completata e sintetizzata in una frase esplicativa, lasciatela sedimentare un po' di tempo, qualche giorno, e poi rivedetela insieme per verificarla e consolidarla. Una volta rivista e migliorata, la Vision Board sarà pronta e a disposizione di tutti e sarete pronti a passare ad altri due canvas molto importanti: il Business Model Canvas e poi il Product Canvas. Questi due strumenti saranno oggetto dei prossimi articoli.

Riferimenti

[1] Roman Pichler, "The Product Vision Board", maggio 2011

http://www.romanpichler.com/blog/agile-product-innovation/the-product-vision-board

 

[2] Il gioco "Agile the Board Game", utilizzato per trasmettere i concetti alla base di Scrum

http://www.agilereloaded.it/2013/08/12/agile-the-board-game/

 

 

 

 

 

Condividi

Pubblicato nel numero
200 novembre 2014
Giulio Roggero è consulente specializzato in formazione e coaching sui temi di Lean-Agile Project Management e tecnologie Web, Mobile e Cloud. Co-fondatore della startup www.makeitapp.eu e CTO di Intre srl, aiuta le aziende ICT a creare nuovi prodotti e semplificare i loro processi, spostando l‘attenzione verso il valore per il…
Stefano Leli, appassionato di sviluppo software fin da bambino, è da sempre alla ricerca di nuovi spunti per migliorare il proprio lavoro. Nel 2003 sente casualmente parlare del manifesto agile e inizia titubante a praticare XP. Da quel momento il suo approccio allo sviluppo software è diventato una integrazione continua…
Articoli nella stessa serie
Ti potrebbe interessare anche