Pensare e testare il prodotto – intervento all’Agile Experience Conference

Recentemente ho preso parte all’Agile Experience Conference organizzata dagli amici di Agile for Italy. Si tratta di incontri live caratterizzati da un taglio pratico e dalla formula intervento iniziale più intervista da parte dei peer.
Giovedì 18 febbraio ho parlato di come “Pensare e testare il prodotto” in compagnia di Roberto Lunazzi, Lorenzo Cassulo e Deborah Ghisolfi.
Abbiamo approfondito quali tecniche usare per creare un prodotto amato dai nostri clienti, quali metriche e quali difficoltà si incontrano.

Qui trovate la registrazione:

Ed ecco a voi una traccia del mio intervento.

Le precondizioni di un buon progetto

Dobbiamo fare una premessa prima di affrontare il momento della discovery di prodotto.
E’ necessario fare un setting quando affrontate progetti di questo tipo per comprendere:

  • chi saranno gli interlocutori (il cliente finale, l’acquirente, lo sponsor in azienda, il responsabile della decisioni finale e chi può influenzare il progetto).
    E’ fondamentale riuscire a mappare tutti questi attori per partire con il piede giusto;
  • qual è esattamente l’obiettivo.
    Quando si fanno attività di questo tipo c’è sempre un’aspettativa da parte dell’azienda, che siano obiettivi di ricavi, quote di mercato piuttosto o volumi di vendita.
    È opportuno fare tante domande prima di iniziare e capire bene quali sono le regole del gioco perché gli obiettivi si possono portare a casa in molti modi e noi dobbiamo capire quali sono i trade-off percorribili.

Prima di tutto vi voglio proporre una distinzione tra prodotti totalmente nuovi e prodotti esistenti che devono essere fatti evolvere, ottimizzati, ecc.
Perché questo? Perché nei due casi abbiamo a disposizione strumenti diversi.

Creare prodotti, ma di che tipo?

Nuovi prodotti

Stiamo parlando di una situazione in cui non abbiamo dati a disposizione di prima mano.
Il prodotto non è presente in azienda; stiamo creando qualcosa di nuovo con cui non ci siamo ancora confrontati.

Cosa faccio di solito io?

Analisi

Faccio un’analisi: cerco gli stessi prodotti o soluzioni simili sul mercato e li studio (se posso li utilizzo direttamente, altrimenti cerco qualcuno che ne abbia esperienza, cerco materiale online, help o video, commenti, ratings).
Queste sono tutte informazioni utili per cominciare a farmi un’idea di questa tipologia di prodotti:
– come sono fatti
– che caratteristiche hanno
– quali sono i loro punti di forza
– eventuali punti deboli.

Personas

L’altro passo che faccio immediatamente è andare a capire chi sarà il mio pubblico.
Dedico tempo alla costruzione delle personas primarie che coincidono con i miei utilizzatori.
Si dice che i PO sono la voce del cliente in azienda ma se questa voce non la ascoltiamo mai dal vivo non stiamo facendo il nostro lavoro, ci stiamo perdendo una grande opportunità.

Con le personas voglio capire quale sarà il mio segmento di pubblico, non solo da un punto di vista socio-demografico.
Qui ho bisogno di scavare in profondità:
– che tipo di bisogni ha?
– quali preoccupazioni?
– cosa vuole ottenere?
– cosa è importante per queste persone?
– che cosa li motiva e li ispira?

Devo riuscire a costruire un profilo a tutto tondo per potermi mettere nei loro panni e verificare che il nuovo prodotto risponda alle sue necessità.

Impact Mapping

Negli anni uno strumento che mi è venuto molto in aiuto nella creazione di nuovi prodotti è l’impact mapping.
E’ una tecnica di pianificazione strategica che ci aiuta a costruire la mappa mentale del progetto:
– qual è esattamente l’obiettivo che vogliamo ottenere
– quali sono gli attori in gioco (e qui tornano in gioco le personas ma non solo)
– quali sono gli impatti che vogliamo produrre ovvero i cambiamenti nel comportamento degli attori
– quali attività (ovvero funzionalità o caratteristiche del prodotto potrebbero aiutarci ad ottenerli).

Per costruire questa mappa si fanno sessioni collaborative, più persone con diversi ruoli e competenze. Maggiore è la varietà e meglio è.

Sessioni collaborative di discovery

Come dico sempre il prodotto è un gioco di squadra, non è qualcosa che fate chiusi da soli dentro il vostro ufficio. Avete bisogno di un confronto continuo nella fase di discovery.

Ecco perché consiglio di sfruttare il più possibile per la creazione di nuovi prodotti le sessioni collaborative di co-creazione: facciamo brainstorming, ad esempio lift-off di progetto o – se ne avete la possibilità – potete proporre degli innovation days o degli hackathon dove diversi team cross-funzionali elaborano idee, le migliori vengono votate e si può arrivare a generare un prototipo dell’idea.

Tutti questi eventi hanno un enorme vantaggio perché portano le persone a bordo, fanno comprendere la sfida e consentono di generare tantissime idee così da selezionare le migliori.

Migliorare prodotti esistenti

Dati ed esperienze di prima mano

Qui possiamo utilizzare tutto quello che abbiamo detto prima ma abbiamo altre frecce al nostro arco. Esistono già degli utenti del nostro prodotto, abbiamo dati di acquisto e di utilizzo.
Sfruttiamo al massimo questi mezzi!
Andiamo a parlare con acquirenti e utilizzatori, intervistiamoli (i dati quantitativi non vi bastano per capire i fenomeni, dovete capire il perché), guardiamo gli analytics, dati di vendita e utilizzo, le registrazioni di sessioni utente, le domande che arrivano all’assistenza clienti o vengono fatte ai commerciali, sondaggi, analisi della customer journey.

Io di solito parto da interviste interne all’azienda per farmi un’idea dei problemi principali, monitoro l’utilizzo e poi vado a fare interviste qualitative.

Interviste JBTD

Potete utilizzare il framework JBTD con cui cercate di capire a quale scopo serve il prodotto o il servizio, sia da un punto di vista più funzionale (è il cosiddetto lavoro primario), sia da un punto di vista emotivo e sociale (come il prodotto fa sentire il cliente, come viene percepito dagli altri).
Perché sono importanti? Perché se non capiamo sulla base di che cosa un utente sceglie il nostro prodotto, quali sono i suoi parametri principali o creiamo una soluzione che non vuole nessuno (e magari questo problema non l’avete con un restyling o un replatforming) o riempiamo il prodotto di funzionalità inutili che non ne aumentano il valore, bensì lo diminuiscono.

Utilizzando anche solo alcuni di questi strumenti avrete raccolto una marea di informazioni su cosa funziona e cosa no, avrete moltissimi spunti su cosa aggredire per primo e avrete generato un backlog di attività.

Pronti per lo sviluppo? No, testiamo l’idea di business

A me piace l’idea di testare l’idea di business (non stiamo parlando di testare il prodotto finito); stiamo parlando di compiere un giro completo prima ancora di partire con un singola riga di codice.
E’ un approccio che è diventato sempre più mainstream negli ultimi anni. Da Lean Startup in avanti è conosciutissimo.

Experiment Map

Qui ci vengono in aiuto una serie di strumenti: ad esempio potete utilizzare un semplicissimo canvas, quello della experiment map. Identificate quali sono le assunzioni più rischiose che stanno dietro alla vostra soluzione, chiarite il risultato che vorreste ottenere e poi costruite un esperimento (il più semplice e meno costoso possibile) per verificare la vostra idea.
Non serve avere il prodotto finito, basta abbozzarlo!

Minimum Viable Product

Ci rifacciamo al concetto di MVP, Minimum Viable Product, una delle idee più bistrattate e meno comprese.
Quando parlo di MVP mi viene sempre in mente l’esempio di Zappos che nel 1999 ha testato l’assunzione più rischiosa che stava dietro alla sua idea di business con un concierge MVP.
Tenete conto che l’e-commerce non era il fenomeno che è adesso. Il founder doveva capire se le persone sarebbero state disposte a comprare qualcosa online – le scarpe – senza poterlo provare.
Ha costruito un negozio finto, un front-end vetrina senza che ci fossero tutti i processi dietro. Ogni volta che qualcuno cliccava sul pulsante “Compra” andava fisicamente a comprare il paio di scarpe in negozio.

Design Sprint

Negli anni gli strumenti sono diventati sempre più sofisticati: pensate al design sprint inventato da Google Venture. In 5 giorni riducete i rischi del lancio sul mercato di un nuovo prodotto o servizio. Partite dalla definizione del problema, fate brainstorming delle possibili soluzioni, scegliete la più promettente, costruite un prototipo e lo validate con potenziali utenti.
Questo non vi fa solo risparmiare tempo e denaro, vi fa risparmiare la creazione di waste.

Conclusioni

In sintesi abbiamo tanti strumenti a disposizione.
Non esiste lo strumento perfetto o un unico strumento per un problema.
Provateli, testateli e cercate quello che più vi risuona, con cui vi trovate bene.

Ma la cosa importante non sono gli strumenti in sé.
Quando penso alla creazione di un nuovo prodotto per me è determinante l’approccio che è fatto di questi ingredienti principali: ascolto, lavoro di squadra, confronto con la realtà (uscite dagli uffici!), utilizzo di dati e sapere di non sapere.
Tutto è ancora da imparare!

IAD 2019: la mia intervista con AgileForItaly

In occasione degli Italian Agile Days che si sono tenuti a Modena l’8 e il 9 Novembre 2019 ho avuto il piacere di fare quattro chiacchiere sul tema Impact Mapping con gli amici di AgileForItaly.

Li conosco da tempo e ammiro il gran lavoro che Tiziano, Pierpaolo e Davide  stanno facendo per diffondere in modo chiaro e divertente le tematiche Agili in Italia.
Ci accomuna la medesima passione e la voglia di non prenderci troppo sul serio ;)

Nell’intervista parliamo di temi che ho già avuto modo di approfondire in altri post:

Qui in particolare ci siamo soffermati su come applicare l’Impact Map ai progetti growth, come produrla in modo collaborativo all’interno del team di lavoro, come darne visibilità in azienda e ogni quanto aggiornarla. Ho aggiunto anche qualche trucchetto su come partire da 0.

Ecco qui l’audio.
Buon ascolto!

E se ancora non lo conoscete vi consiglio di dare quanto prima un occhio al sito di AgileForItaly. Troverete tante risorse interessanti.

Impact Map: utilizzi pratici

Slide di esempio sul funnel di vendita

Non torno a raccontarvi la teoria dell’Impact Mapping, quella l’abbiamo ampiamente approfondita in questo post.
Abbiamo anche parlato di come organizzare praticamente una sessione.
Adesso voglio concentrarmi su cosa succede una volta che la vostra Impact Map è bella e pronta. Dopo tanto lavoro vediamo come metterla a frutto.
Vi do qualche spunto ma sono certa che vi verranno in mente molti altri utilizzi pratici.

Questo è ciò che abbiamo fatto nel mio team.
Non volevamo renderlo un semplice esercizio di stile, volevamo testare il tool sul campo e vedere fino a che punto saremmo riusciti a renderlo un reale strumento di condivisione.
Per questo abbiamo iniziato a presentare l’Impact Map nei contesti più disparati e a comunicarla ai vari livelli dell’organizzazione.

Epiche nel backlog

Gli impatti – o meglio le diverse combinazioni attori / impatti – sono stati inseriti come epiche nel Product Backlog.
In alternativa potreste utilizzarli come temi, che sarebbe un’impostazione ancora più corretta dal momento che i temi hanno carattere più generale e non si esauriscono.
In questo modo abbiamo inquadrato ogni item del backlog in una visione più generale. Questo ci ha consentito di dare maggiore contesto ad ogni attività e far crescere questo tipo di consapevolezza anche nel team.

Valore atteso in demo

Abbiamo introdotto dei riferimenti agli impatti nelle slide delle demo.
Ogni incremento di prodotto o A/B test veniva presentato esplicitando l’ipotesi sottostante: l’impatto che pensavamo di ottenere attraverso l’introduzione di quella specifica feature con tanto di metriche (=KPI).
In questo modo intendevamo trasmettere al pubblico della demo le finalità che guidavano le singole attività di sviluppo. Indirettamente stavamo comunicando anche il  framework di lavoro.

Priorità di lavorazione

Questo è stato un utilizzo molto concreto. Nel nostro team mancava il ruolo dello UX designer.  Abbiamo dovuto condividere questa risorsa con altri team. Coordinarsi in questa situazione non è né facile né ottimale.
La condivisione dell’Impact Map con le persone che collaboravano al progetto (ux research, designer, data analyst, altri team, ecc.) ci ha aiutato a rendere chiare le ragioni delle priorità di lavorazione.
Lo sviluppo è diventato più fluido e le dipendenze che inizialmente creavano ritardi sono diventate molto meno frequenti.

Allineamento con gli stakeholder

Tra tutti questo è forse l’utilizzo che ho trovato più vantaggioso in assoluto.
In questo caso l’Impact Map è stata un prezioso strumento di allineamento nella gestione delle aspettative degli stakeholder e nella raccolta dei feedback da parte del senior management.
L’accento sugli attori e sugli impatti ci ha consentito di mantenere la conversazione ad un livello strategico, di mantenerci aperti ad esplorare varie opportunità ed evitare cadute quali richieste di specifiche funzionalità.

Corrispondenze con il funnel

Infine – dato che il nostro progetto era focalizzato nello specifico sull’incremento dei volumi di vendita di una determinata tipologia di prodotti (quella che nelle immagini è indicata con XXX per riservatezza) – abbiamo trovato un’interessante corrispondenza tra gli impatti definiti per le due tipologie di clienti principali e i vari step del funnel di vendita o del cosidetto “funnel dei pirati” se utilizzate un approccio vicino al Growth Hacking.
E’ quello che vedete nell’immagine principale del post.

Questo è tutto da parte mia.
Se avete voglia di condividere qualche altro utilizzo pratico che avete in mente o che avete sperimentato sono tutta orecchie.
Alla prossima!