Product Owner per caso

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!

 

Oggi voglio raccontarvi di un argomento che mi sta particolarmente a cuore. Lo so, ho già scritto diversi post a riguardo ma in questo caso parliamo proprio di pratica: come si organizza operativamente una sessione di Impact Mapping.

Sto gestendo un progetto di crescita. E’ molto interessante ed allo stesso tempo anche complesso. Ho dalla mia due grandi vantaggi: il fatto di lavorare con focus esclusivo su questo obiettivo di business e un team con ottima seniority per poter fare end-2-end sulla nostra piattaforma.

Per me è stata l’occasione giusta per rispolverare questo strumento che amo molto e non impiego mai abbastanza.
Quando ho messo a fuoco che era il tool giusto per orientarmi nel mio progetto e ho cominciato a cercare istruzioni dettagliate su come gestire una sessione di Impact Mapping ho trovato in rete poche risorse concrete (questa è comunque la migliore base di partenza).
Da qui l’idea di condividere la mia esperienza.

L’occorrente

Se anche voi volete organizzarne una sessione di Impact Mapping avete bisogno di:

• una sala riunioni
• un tempo dedicato (considerate mezza giornata per partire)
• tavoli ampi (su cui elaborare l’artefatto)
• i partecipanti (ne parliamo più avanti)
• un facilitatore
• il libro o il sito di Adzic e mappe d’esempio
• materiale di supporto (fogli A1, post-it, pennarelli, ecc.)

Una parentesi d’obbligo sul giusto mindset, ovvero la predisposizione ad accogliere inizialmente tutte le idee come si fa nei brainstorming. Fa parte del processo partire da una fase di pensiero divergente per poi convergere successivamente sulle priorità. Quindi nessuna idea è sbagliata!

Setting della sessione

Il setting iniziale prevede 4 momenti:

• spiegazione dello strumento
• condivisione di mappe d’esempio
• chiarimento delle regole del gioco
• condivisione dell’obiettivo

E’ fondamentale introdurre lo strumento a tutti partecipanti.
In particolare vi invito a soffermarvi sugli impatti. Sono il cuore della mappa e spesso la parte più fraintesa da chi non ha già esperienza del tool.
Gli impatti vengono confusi con i deliverables mentre è importante chiarire che si tratta comportamenti; i comportamenti che vogliamo cambiare negli attori per raggiungere il nostro obiettivo.
I deliverables invece sono solo ipotesi: funzionalità che pensiamo possano produrre un impatto. Congetture da testare sul campo.

E’ utilissimo mostrare delle mappe d’esempio prima di cimentarsi a creare la propria. Quelle riportate nel libro di Gojko Adzic o sul sito vanno benissimo.

A chiusura dell’introduzione chiarite due “regole del gioco” fondamentali:

1. la finalità non è implementare l’intera mappa ma cercare il percorso più veloce per raggiungere l’obiettivo
2. il focus principale è la creazione di valore, non la delivery di funzionalità (= output). I deliverable hanno senso se e solo se producono un impatto. Se non lo fanno sono solo waste.

L’obiettivo

Un paragrafo a parte merita l’obiettivo.
E’ fondamentale che non ci siano ambiguità sull’obiettivo che state perseguendo.
Deve essere chiaro, condiviso da tutti i partecipanti e SMART (Specifico, Misurabile, Achievable ovvero raggiungibile, Rilevante e definito nel Tempo).

Se avete la sensazione che non sia così rimandate la sessione e chiarite prima questo punto.
L’obiettivo è il cuore dei vostri ragionamenti. Evitate di lavorare su qualcosa che si rivela poi essere sbagliato. Succede più frequentemente di quanto non immaginiate.
Idealmente dovreste arrivare alla sessione di Impact Mapping avendo esplicitato tutti i trade-off sottostanti all’obiettivo. Due domande possono venirvi in aiuto: Cosa siete disposti a mettere sul piatto per poterlo raggiungere? A quali condizioni rimane valido?

I partecipanti

Qui è importante la varietà di punti di vista.
Questo strumento fa leva sulla cosidetta “wisdom of crowd”, la saggezza della folla. E’ un tool collaborativo. Ecco perché è importante avere i vari interlocutori al tavolo: sales, prodotto, tecnologia, data analytics, ecc.
Maggiore è la varietà dei punti di vista e più articolata risulterà la mappa a livello di attori e impatti.

Se pensate che i partecipanti siano troppi (diciamo più di 8/10) ha senso suddividersi in più gruppi e lavorare separatamente. Il setting iniziale sarà comune, poi i partecipanti si divideranno per lavorare sulla mappa. L’importante è far fare allineamenti frequenti sui vari passaggi e prevedere una condivisione finale.

Una menzione speciale merita il facilitatore. Vi sconsiglio di avventurarvi in una sessione di Impact Mapping senza avere qualcuno che possa agevolare gli scambi durante il meeting, tenere i tempi e riportare la conversazione sui binari corretti quando necessario.
Pensare di prendere attivamente parte ai lavori e facilitare allo stesso tempo è  illusorio. Chi presidia il processo dovrebbe fare solo questa attività (e non è poco!).

La durata

Quanto tempo serve? Questa è una delle domande più frequenti…
In letteratura trovate indicazioni per una sessione di una giornata o mezza giornata.
Per l’esperienza che abbiamo avuto noi è veramente difficile superare lo scoglio delle 3 ore.
L’attenzione subisce un drastico calo e anche la qualità della produzione diminuisce vertiginosamente.

Questa è una proposta di agenda:

• 30 minuti per introdurre l’Impact Map
• 15-30 minuti per condividere l’obiettivo (a patto che abbiate fatto prima i compiti a casa)
• 90-120 minuti per una prima bozza
• 15 minuti di riepilogo

Il mio consiglio – nel caso di una mappa particolarmente ampia – è di suddividere il lavoro in più sessioni. Magari in un primo momento potete definire gli attori, individuare uno/due degli attori principali e concentrarvi sugli impatti che volete ottenere da questi soggetti.
Non abbiate timore di lasciare indietro qualcosa. Se iniziate a utilizzare l’Impact Map come strumento operativo pianificherete di certo più di una sessione nel corso del vostro progetto.

Pillole sul campo

Aggiungo qualche suggerimento distillato dalle lezioni sul campo.

Mappa di prova

Se è la prima volta che fate una sessione di questo tipo potrebbe esservi d’aiuto fare prima una mappa di prova per conto vostro, per capire gli attori che non possono mancare e supportare le giuste conversazioni al momento. Non deve emergere la “vostra” mappa; ciò che verrà fuori dalla sessione sarà di norma un quadro molto più ricco di quello che avete ipotizzato. Consideratela una sorta di traccia. Può essere di grande utilità se vedete che la conversazione si arena o se non ci si smuove da un singolo attore.

Impatti, impatti, impatti

Il cuore della mappa sono gli impatti. E’ li che dovete concentrarvi maggiormente. Definire come volete cambiare il comportamento degli attori. Se mettete a fuoco questo componente correttamente tutto sarà più facile.
Vi accorgerete di aver fatto un buon lavoro perché i comportamenti non cambieranno più di tanto nel tempo, mentre i deliverable sì (subiranno la prova dei fatti).

Livello di dettaglio

Questo è un altro punto che suscita molti dubbi. Quanto dev’essere dettagliata la mappa?
In realtà è un non problema.
La risposta giusta è: quanto basta per partire, per mettervi in condizione di validare le prime ipotesi con il team.
La mappa cambia nel tempo. Si adatta sulla base dei feedback che arrivano: i dati quantitativi, gli insight qualitativi. Capirete strada facendo il livello di dettaglio che vi serve in una determinata fase di progetto.

Nel nostro caso ad esempio siamo partiti definendo degli attori molto “macro”: gli utenti che ricercano voli e i clienti che hanno già acquistato un volo.
Adesso sentiamo la necessità di introdurre un nuovo livello di dettaglio utilizzando le personas… e – lo sappiamo già – potrebbe non essere anche questa la versione definitiva.

Non abbiate timore di sperimentare versioni diverse e ripensarla da capo.
E’ un lavoro mai finito.
Fate queste domande al team:

• per com’è adesso la mappa vi è utile nella vostra attività quotidiana?
• vi supporta o è d’ostacolo nel prendere decisioni operative?

Sulla base del feedback saprete se c’è bisogno di riorientare il tutto.
E’ una mappa in fondo. L’importante è che vi guidi a destinazione.