Impact mapping per definire la strategia di prodotto

Impact mapping: una metodologia per passare dal “fare le cose” al “decidere quali cose fare” in base agli “impatti” che vogliamo generare

L’11 e il 12 marzo scorsi abbiamo fatto due giorni di workshop da remoto sull’impact mapping. Ci ha guidato l’agile coach Lorenzo Massacci che avevamo già conosciuto agli albori di Soisy, in una primissima sessione di Lego Serious Play. 

In questo post blog voglio raccontarvi in cosa consiste e a cosa serve la metodologia dell’impact mapping, come si è svolto il workshop e cosa abbiamo imparato.

Ma facciamo un piccolo passo indietro: quali erano i nostri obiettivi e perchè l’impact mapping per definire la strategia di prodotto?

Abbiamo ingaggiato Lorenzo perché il team tech a fine 2019 si era posto un obiettivo molto ambizioso, e cioè “Aumentare la delivery del team degli sviluppatori”. L’esigenza nasceva da una ragione più profonda: stavamo crescendo molto e data la crescita che ci aspettavamo, volevamo esser pronti, lato sviluppo, a seguire il crescere del business aumentando la delivery.

Nell’affrontare l’“aumento della delivery”, il primo passo è stato chiederci se volevamo aumentarne la quantità o la velocità (qui sotto trovate uno screen con cui Ciccio aprì la conversazione in Slack):

La conversazione successiva ha messo l’accento  su due necessità, entrambe molto importanti per il team di delivery:

1. diventare più bravi a rilasciare più velocemente le cose sulle quali stiamo lavorando (nello stesso tempo stavamo anche portando avanti un book club su Accelerate e il tema era particolarmente caldo)
2. diventare più bravi a identificare le cose giuste da rilasciare

Da qui l’idea di un workshop sull’impact mapping per indirizzare meglio la strategia di prodotto: è stato Francesco Tassi a proporlo, pensando esattamente all’attività in campo e all’obiettivo che si proponeva (aumentare la delivery).

Partendo dalla pipeline delle attività di prodotto nella nostra kanban, ha suggerito di mettere in correlazione l’obiettivo che si vuole raggiungere con le azioni che si pianificano e prioritizzano in kanban per ottenerlo. Aveva già avuto esperienza con l’impact mapping e riteneva che questa metodologia potesse aiutarci proprio a collegare le due cose (attività in corso rispetto agli obiettivi di business).

Ne abbiamo parlato con Lorenzo che, dopo un veloce giro di interviste per inquadrare la nostra situazione e le nostre necessità, ha progettato per noi un workshop mescolando impact mapping e lean value tree. 

Un approfondimento breve ma doveroso: cos’è l’impact mapping?

Non entrerò nel dettaglio di cosa sia l’impact mapping e vi rimando anzi a più autorevoli fonti per tutti gli approfondimenti del caso: per ora, è sufficiente sapere che è una una tecnica di pianificazione che aiuta a visualizzare le assunzioni, spesso implicite, che popolano le roadmap dei prodotti software.

Attraverso questa metodologia si vanno a creare mappe mentali per aiutare i team 

• a visualizzare meglio le strategie e le roadmap di prodotto; 
•  a spiegare come i risultati finali di una certa attività si collegano 
  • da un lato agli obiettivi di business interni a ogni singolo team 
  • e dall’altro alle esigenze esterne degli utenti che utilizzano un determinato prodotto;
• a generare opzioni e strade alternative per raggiungere un certo obiettivo.

Con impatto -dal libro Impact Mapping: making a big impact with software products and projects– si intende “un cambio di comportamento” di qualcuno (attori) che interagisce con il nostro prodotto. Come questi attori ci possono aiutare a raggiungere il nostro obiettivo? Come ci possono ostacolare? Che cosa stanno cercando di fare/ottenere/raggiungere?

L’impact mapping serve cioè a focalizzarsi su come possiamo aiutare i nostri utenti a raggiungere i loro scopi, più che sulla feature di turno. 

Chi ha partecipato all’impact mapping e perchè?

Solitamente l’impact mapping si svolge in sessioni live, con pareti bianche da popolare di post-it: per questo avevamo prenotato una sala nel nostro hub di Le Village a Milano, ma per esigenze di team prima (e di decreti restrittivi per la salute pubblica poi) abbiamo fatto l’intera due giorni da remoto.

Anche questa è stata una decisione presa in corso d’opera e discussa e condivisa dal team, come lo snap qui sotto di una conversazione su slack mi ha ricordato:

Qui Lorenzo -che ci ha coordinato e guidato- vi spiega cosa il remoto ha significato in termini di organizzazione e svolgimento del worskhop.

Lato presenze, parlando di roadmap di prodotto i product owner e alcuni dev erano imprescindibili. Poi ci siamo auto-organizzati come sempre, affinché all’evento ci fosse un “microcosmo” il più possibile rappresentativo dell’azienda: alla fine, oltre i PO erano presenti alcune persone del team tech appunto, il CEO (nel duplice ruolo di founder ma anche perché segue molte attività di partnership commerciali con e-commerce e gateway di pagamento), il nostro legal e io che seguo la comunicazione e il marketing.

In Soisy, infatti, non contano tanto i ruoli o i job titles e ogni incontro live, videocall o retrospettiva che sia, è ispirato ai principi della massima apertura e del valore che si pensa di portare. Ogni incontro è quindi sempre aperto a tutti e ognuno decide liberamente se partecipare o meno, anche in base all’interesse di ciascuno per un determinato argomento/attività. L’obiettivo è assecondare le passioni personali ma anche farci guidare dall’intelligenza collettiva, guardando a un problema da più prospettive e punti di vista.

Due giorni ad alto impatto: dalla teoria alla pratica!

Impact mapping giorno 1

Il primo giorno abbiamo fatto ice-breaking con lo strumento Miro (che non tutti noi del team conoscevamo), iniziando da un’attività di check-in: essendo tutti da remoto siamo andati a posizionarci sulla cartina dal posto in cui lavoravamo. Questo ci è servito più che altro a prender confidenza con lo strumento, a capire come spostarci sulla mappa (che da mentale era davvero reale e bisognava orientarsi), come creare post-it e commenti ai post-it.

Dopodichè la prima attività è stata riprendere la nostra vision e la mission (declinata in 6 macro-obiettivi di business) che avevamo già pronte; poi Lorenzo ci ha fatto esercitare nel definire “Cosa NON è Soisy” e quale “la cosa più importante che Soisy non è”.

È stato bellissimo -come ha testimoniato Pietro in un post Linkedin a fine giornata, snap sotto- vedere quanto siamo allineati nel definire chi e cosa NON siamo e non facciamo, perchè poi è anche a partire da questo che possiamo declinare meglio prodotti (e attività di prodotto) che siano rispondenti a questa forte visione e consapevolezza identitaria.

Posto che avevamo molto chiaro chi siamo e chi vogliamo essere e anche chi NON siamo, serviva un altro ingrediente: definire gli attori in gioco.

Secondo la metodologia dell’impact mapping, sono attori tutti quelli che influenzano, in modo diretto o indiretto, il risultato del nostro lavoro. Si va dagli utenti che usano il nostro software (investitori per investire, e-commerce per incassare e acquirenti per pagare a rate) a chi può ostacolare il raggiungimento dei nostri obiettivi, a coloro su cui noi vogliamo avere un impatto o quelli che possono influenzare in qualche modo quello che stiamo facendo.

Gli attori si possono catalogare in

• primari: gli utenti del prodotto, che possiamo identificare con le personas; qui abbiamo ripreso le varie value proposition canvas con cui nel tempo abbiamo mappato le esigenze dei nostri clienti, i loro pain e gain e le soluzioni con cui cercano di risolvere un certo problema (e ci siamo accorti che erano anche invecchiate nel frattempo e molti unsatisfied needs nel tempo li avevamo anche soddisfatti o erano cambiati 😉
• secondari: tutti gli attori dietro le quinte, che non sono direttamente utilizzatori del software ma hanno potere di influenzare il successo della nostra mission (ad esempio regulators, credit bureau,…).

Abbiamo quindi fatto un elenco di tutti gli attori secondari per Soisy, per poi andare a compilare, collettivamente, una stakeholder map: nel compilarla ci chiedevamo che tipo di relazione dovremmo tenere con loro, ragionando sull’asse del potere e dell’interesse.

Abbiamo fatto un’interessante discussione su questa mappa e sugli attori coinvolti, per poi tornare sui 6 obiettivi/goal della nostra mission: ci siamo divisi in gruppi (grazie a Zoom è possibile organizzare “stanze” virtuali, in cui i sottogruppi possono entrare e discutere, per poi, al timeout, tornare nella stanza principale) e per ogni obiettivo della mission abbiamo indagato

• gli attori coinvolti (users)
• la situazione corrente: breve descrizione dell’as is (current situation)
• cosa andrà a cambiare: breve descrizione del gap che andremo a colmare, di cosa succederà quando avremo raggiunto quell’obiettivo e cosa cambierà concretamente per gli utenti coinvolti (what is going to change).

In questa fase ho trovato particolarmente potente l’utilizzo di Miro: la fase di divergenza è sempre utile ed esplorativa per un team che fa dell’intelligenza collettiva uno dei suoi pilastri, ma è necessario anche convergere e uno strumento come Miro trovo ci abbia aiutato tanto: nello specifico i 3 sotto gruppi elaboravano e lavoravano a 2 goal ciascuno, si tornava nella “stanza principale” e si “attaccavano” i goal compilati nelle varie parti (users – current situation – what is going to change) sulla “parete virtuale” di Miro, e a questo punto ci prendevamo 5 minuti, in cui ciascuno poteva scrivere commenti sui vari post-it degli altri mini-gruppi.

Poi il mini-gruppo tornava nella sua stanza, rielaborava i feedback/commenti ricevuti e decideva quali accettare o meno rivedendo la proposta iniziale; si tornava nella stanza principale con una proposta “rivisitata” del goal alla luce dei commenti del team e bisognava esplicitare quali feedback erano stati accettati, e quali no e perchè.

L’ho trovato un modo davvero smart e veloce per passare dalla fase di divergenza a quella di convergenza in un lasso di tempo timeboxato e limitato.

Sempre guidati da Lorenzo, abbiamo scelto di approfondire, focalizzarci e lavorare sul primo dei nostri obiettivi e cioè “mantenere il vantaggio competitivo sul prodotto partner”.

Siamo passati attraverso una prima fase di divergenza in cui indagavamo:

1. le misure di successo, cioè come ci accorgiamo che ci stiamo avvicinando all’obiettivo. In questa fase cercavamo di elencare le metriche che pensiamo ci aiuteranno a capire se stiamo andando nella giusta direzione; se le attività messe in campo stanno portando i frutti desiderati o se stiamo sprecando energie. In questo Lorenzo ci ha aiutato molto con i suoi suggerimenti: secondo lui, infatti, una buona metrica è indipendente da quello che andiamo a fare e dall’attività/feature che mettiamo in campo per raggiungere quell’obiettivo, possiamo anche non fare una certa attività ma risolvere comunque il problema e i pain della current situation e la metrica deve continuare ad aver valore; spesso il problema, ci ha detto, è che ci immaginiamo già come realizzare un certo obiettivo, per cui finiamo col legare la misurazione del successo a quello che abbiamo fatto o non fatto, e non a quello che immaginiamo di ottenere come effetto. E ci ha suggerito anche una “prova del nove” per evitare di incorrere in questo errore: è importante chiedersi sempre “ma se realizzo l’obiettivo che mi son dato -nel nostro caso se manteniamo il vantaggio competitivo…- senza scrivere codice o far nulla, ma solo perchè ho avuto una certa intuizione, va bene lo stesso?”. Solo se la risposta sarà positiva siamo sulla strada giusta, perché avremo raggiunto l’obiettivo anche se l’ambito è variato rispetto alla visione iniziale; al contrario se avremmo realizzato tutte le funzionalità previste in backlog senza che l’obiettivo di business sia stato raggiunto, il fallimento è dietro l’angolo e la concretizzazione della mission sarà sempre più lontana.
2. e poi abbiamo indagato le challenge e i rischi dell’obiettivo di mantenere il vantaggio competitivo, cioè quali crediamo siano le sfide e i rischi che prevediamo nel mettere la testa su quell’obiettivo.

Poi, attraverso un dot voting (i pallini colorati nel blocco Misura del Successo), abbiamo scelto le metriche che il gruppo riteneva più importanti. Ad esempio: dato l’obiettivo focus della discussione di voler mantenere il vantaggio competitivo sul prodotto partner, riteniamo che una buona metrica sarà quella di fare un confronto qualitativo attraverso mistery shopping su altri e-commerce presidiati dai nostri competitor.

Questi esercizi alla fine del 1° giorno ci hanno aiutato a visualizzare meglio come colmare il gap tra situazione attuale e quella desiderata. Dovevamo fare lo sforzo di pensare “abbiamo raggiunto questo obiettivo, ok: e ora che effetto fa e come valutiamo se abbiamo fatto bene?”, mentalmente dovevamo colmare il gap e posizionarci laddove vogliamo arrivare, concentrandoci sull’effetto che avremmo innescato a obiettivo raggiunto, e non sulle singole azioni che ci avevano portato sin là.

Impact mapping giorno 2

Il secondo giorno abbiamo lavorato sulle cosiddette bet e impatti: siamo partiti dal nostro backlog e liste di attività per lo sviluppo prodotto, cose da fare, iniziative, insomma dalle attività in kanban.

Lorenzo ci ha spiegato che quando si generano liste di attività sullo sviluppo prodotto c’è sempre una motivazione sottesa, poi però quando si passa alla fase di sviluppo questa motivazione si perde, nel senso che si perde di vista il perché andiamo a realizzare una certa attività. È probabile che ciascuno che l’abbia in testa, ma è davvero importante concretizzarla e visualizzarla quella motivazione, affinché tutti siano allineati sul perché proprio quella attività è fondamentale per noi, sul perché stiam facendo quella e non altre attività e perché riteniamo che quella lì ci porterà dritti dritti a raggiungere un determinato obiettivo.

L’impact mapping è proprio un approccio orientato a far ragionare sugli impatti e si prefigge di mappare tutti gli impatti/bet per raggiungere un certo obiettivo.

Per capire meglio cosa fosse una bet/impatto, è tornata utile una spiegazione teorica: Lorenzo ha unito la metodologia dell’impact mapping teorizzata da Gojko Adzic a quella del Lean Value Tree (sotto due schemi riassuntivi): la prima teorizza che un determinato goal si raggiunge ragionando per actor, impact e deliverable, con l’accento appunto sugli IMPACT. La seconda punta invece sul concetto di BET, cioè di scommettere su diversi esperimenti per raggiungere poi i vari goal che realizzano la vision. 

Un approccio orientato all’impatto cerca quindi di evidenziare gli impatti/bet: “su quali impatti scommettiamo per raggiungere un certo obiettivo?”, come sintesi delle due teorie.

L’esercizio si è realizzato dunque nel partire dal backlog di attività (post-it gialli in basso a sinistra) fino a collegare ciascuna di esse a un obiettivo di business (i post it verdi a destra), passando per la redazione dei post-it blu nel mezzo, che erano i post-it degli impatti/bet, appunto.

Secondo Gojko Adzic, inventore dell’impact mapping, l’impatto altro non è che un cambiamento di comportamento dei nostri attori, e spesso sono ipotesi di cambiamento. In questo senso risulta utile scrivere i post-it blu sottolineando tali cambiamenti e dunque utilizzando verbi come “iniziare a…” o “smettere di…”, “fare più…” o “fare meno…”.

Si partiva dal post-it giallo dell’attività in kanban, ci chiedevamo “Lo facciamo perchè…”, pensando quale impatto e cambiamento di comportamento vogliamo generare, e scrivevamo il post it blu, che dovrebbe rappresentare il mezzo e l’ipotesi che ci permetterà di collegarci al post-it verde a destra, e quindi a realizzare un certo obiettivo.

Siamo quindi tornati all’obiettivo del “mantenere il vantaggio competitivo” su cui avevamo lavorato e ragionato in termini di misure di successo, challenge e rischi e abbiamo formulato una serie di bet/impatti su cui scommettere: una delle bet era, ad esempio, “Crediamo che se più clienti finalizzeranno l’acquisto, questo ci porterà a mantenere il vantaggio competitivo sul prodotto”. Descrivere questo impatto è ben diverso dal dire “Miglioriamo il funnel o facciamo tal modifica per migliorare il funnel”, che sono già soluzioni: la bet così formulata permette infatti di ricollegarci a livello profondo con gli obiettivi della mission.

L’ultimo passo è stato passare dalle bet alle singole iniziative: una volta inquadrata una certa attività su cui scommettiamo e che secondo noi genererà impatto e cambierà il comportamento degli utenti, a quel punto possiamo elencare le varie iniziative che ci porteranno a concretizzare quella bet.

In quest’ultima fase del workshop siamo entrati nel dettaglio di una singola bet, analizzandone:

• misure di successo
• challenge e rischi come per il goal
• e in più ci siamo chiesti quale fosse la più piccola cosa che potessimo fare (iniziativa, appunto) per capire se siamo sulla strada giusta; cosa fare per generare l’impatto/bet cui ambiamo e come capire che abbiamo finito (aver chiara in testa la cosiddetta “definition of done”).

Penso che un esempio come sempre valga più di mille parole: una delle iniziative messa sul tavol.. ops, sulla board condivisa di Miro, rispetto alla bet “Crediamo che se più clienti finalizzeranno l’acquisto, questo ci porterà a mantenere il vantaggio competitivo sul prodotto” è stata “ipotizziamo che non pagare interessi aumenterà la conversione”. Definition of done: “Tasso Zero implementato su più e-commerce possibili”. 

Una delle strade possibili per far finalizzare il funnel di pagamento rateale, potrebbe essere accordare ai clienti il tasso zero, che ha come assunto e ipotesi di fondo che il non pagare interessi rafforzi la volontà del cliente nel finalizzare il funnel della richiesta di pagamento rateale: ma questa è ovviamente un’ipotesi e scommessa, su cui il team potrà decidere di mettere o meno le energie. Ma esistono molte altre strade possibili (altre iniziative su cui abbiamo “scommesso”: facial recognition che ad oggi non abbiamo, pagamento rateale via carta mentre oggi è solo via IBAN, etc…), e poi con dot voting e altri metodi ogni team può scegliere quale mettere in campo e attualizzare, andando a disegnare una roadmap e strategia di prodotto che si basi appunto su impatti e cambiamenti di comportamento che vogliamo generare, e non su singole feature o azioni.

L’ultimo step dell’impact mapping mette tutti i deliverable e iniziative in relazione con gli impatti da produrre ma è anche il livello meno importante della mappa. Non è necessario infatti che sia fatto tutto dall’inizio alla fine; i deliverable sono opzioni ed esperimenti, mano a mano che verranno rilasciati saranno misurati gli impatti; si potrà decidere se proseguire nell’implementazione o dedicarsi ad altri obiettivi perchè magari l’impatto desiderato è già stato raggiunto con meno deliverable di quelli che pensavamo fossero necessari.

Per fare questo sarà importante chiederci sempre “qual è la più piccola cosa che possiamo fare per generare questo impatto e capire se siamo sulla strada giusta?” e “come capiamo che questa iniziativa messa in campo ha generato impatto?”; se l’impatto che ci eravamo prefissati è stato generato, possiamo passare ad altri impatti.

L’approccio che suggerisce il Lean Value Tree, inoltre, è quello di ragionare in termini di bet includendo persone di business, e poi le iniziative sono responsabilità del team di sviluppo. Questo aspetto non lo abbiamo approfondito e forse solo con applicazioni reali potremmo rendercene davvero conto.

Tutto bello, ma questa due giorni che impatto ha avuto in tutta l’organizzazione Soisy? Cosa è cambiato?

È presto per dirlo: i cambiamenti di comportamento -specie quelli di un’organizzazione- sono risultati di lungo periodo, e un metodo va prima digerito e interiorizzato.

Sicuramente mi “sentirei di scommettere” -passatemi il termine- su una cambio di prospettiva tra noi che abbiamo partecipato all’impact mapping: è fondamentale ragionare per bet e impatti, e portarli nel nostro lavoro quotidiano.

Ci stiamo organizzando per fare dei test di un paio di mesi nella kanban di prodotto (e in tutte le kanban per cui ci sentiremo pronti) per scrivere le card/attività introiettando il concetto di bet/impatto. Poi valuteremo se questo ci ha aiutato e come, e in caso positivo estenderemo la sfida al team, portandoli a bordo con pillole sull’impact mapping e sul metterci a disposizione -noi che abbiamo partecipato al workshop- nell’affiancare tutti nella redazione di card e attività tenendo conto appunto del concetto di “impatto da generare”.

E cosa mi porto a casa io?

Se l’estensione della metodologia all’intero team è lontana almeno di un paio di mesi visto il test in corso, posso però condividere alcune riflessioni su cosa ha cambiato in me il workshop. 

Io faccio comunicazione e non specificamente prodotto e forse l’applicabilità è limitata, ma sono uscita da quei due giorni piena di energie e idee nuove, ma soprattutto forte di una consapevolezza: non son tanto le singole idee che mi porteranno ad aiutare Soisy a raggiungere certi obiettivi di business, quanto più esplicitare queste idee sotto forma di “perchè vogliamo testare queste idee e fare queste card e non altre attività?” o “Quali cambiamenti vogliamo generare?”. 

Ho sempre pensato che sono le domande, e non le risposte, a fare la differenza e credo che queste domande orientate a impatti e cambiamenti da generare possano aiutarmi nel disegnare prodotti (di comunicazione, nel mio caso) che possano creare valore maggiore.

E se provo ad andare oltre il mio naso e il mio ruolo, se lo applico al prodotto insomma, è potentissimo come ragionamento: chiedersi qual è il cambiamento che vogliamo portare nel mondo e come questo mondo cambierà se facciamo la feature X al posto della funzionalità Y, è una rivoluzione copernicana nell’approcciare il prodotto.

Ragionare su impatti e goal è difficile, certamente, sono discussioni che di solito non si fanno, e chiedersi a posteriori se ho ottenuto quell’impatto e se ho fatto o devo creare altre iniziative, trovo che potrà aiutarci sempre più a focalizzare meglio le nostre energie e a prendere decisioni migliori. Di prodotto, e non solo.

Giorgia, Marketing e comunicazione

PS: se hai curiosità e domande su questo “esperimento” che abbiamo fatto in Soisy o vuoi raccontarci come hai usato l’impact mapping nella tua azienda, il box commenti è tutto tuo: mi piacerebbe si popolasse di domande ma anche di link ed esperienze con cui poterci noi stessi confrontare e da cui imparare 🤗