Checklist per la riunione di mappatura degli stakeholder

La settimana scorsa abbiamo parlato delle varie alternative che abbiamo a disposizione per mappare gli stakeholder di progetto.

Uno degli accorgimenti che con l’esperienza ho trovato più utili è effettuare l’attività di mappatura in gruppo, in particolare coinvolgendo i diretti interessati.

Come dicevamo la volta scorsa non prendersi il tempo per intervistare gli stakeholder è la cosa più rischiosa che possiamo fare quando stiamo partendo con una nuova iniziativa, ma anche non pianificare a priori come avverrà la comunicazione potrebbe crearvi un sacco di grattacapi e farvi perdere molto tempo quando ne avrete poco a disposizione.

Per questo motivo ad avvio di progetto è utile far convergere tutti gli interessati in una stanza e costruire insieme a loro la mappatura ed il framework di comunicazione che si desidera utilizzare.

Questa attività vi aiuta a comprendere ancora meglio le aspettative di ciascuno, a valutare la qualità delle relazioni tra gli interlocutori e a identificare potenziali aree di rischio o di frizione.

Quindi programmiamo l’ennesima riunione in agenda? 
Ebbene sì, ma facciamo in modo che sia veramente produttiva!

Per supportarvi in questo arduo compito ho raccolto in una checklist tutti i punti salienti a cui prestare attenzione per far sì che questo meeting sia un successo.

Qui trovate il pdf scaricabile.

Buon lavoro!

Gestione degli stakeholder: partiamo dalla mappatura

Diciamo la verità: spesso come persone di prodotto non siamo i responsabili diretti dei team con cui lavoriamo, non dettiamo gli obiettivi di business né scaliamo gli organigrammi nelle tradizionali posizioni di potere.

Quella che può apparire a volte come una posizione scomoda, da cui è faticoso coinvolgere le altre persone negli sforzi che stiamo tentando di portare avanti, è in realtà un’ottima palestra per esercitare uno strumento straordinario nella nostra “cassetta degli attrezzi”: l’abilità di influenzare gli altri (qui abbiamo parlato della differenza tra influenzare e manipolare).

Ma chi sono questi “altri”? Parliamo di loro, i famosi stakeholder.

La gestione proattiva degli stakeholder

Gli stakeholder sono coloro che possono influenzare o essere influenzati dalle nostre attività e – più in generale – da un’organizzazione, una strategia o un progetto.
Gli stakeholder sono tutte le persone che hanno un interesse di qualsiasi tipo nel prodotto che stiamo realizzando.

Se vogliamo capire come gestirli al meglio dobbiamo mettere in atto le medesime pratiche che utilizziamo con i clienti finali (il cliente finale peraltro è uno dei nostri stakeholder!).
Partiamo dall’ovvio: sono persone prima di tutto! E come tali hanno necessità e bisogni specifici, così come solide opinioni su ciò che vogliono ottenere e ciò che farebbero al nostro posto. E’ nostro compito prima di tutto farci un’idea di questi presupposti e indagare cos’è per loro di valore.

Se ritenete che gestire gli stakeholder sia una delle tante attività che “vi tocca” portare avanti senza magari troppo entusiasmo in mezzo alle mille cose da fare, provate a cambiare prospettiva: costoro possono essere delle risorse incredibili per il raggiungimento dei vostri obiettivi.
Hanno conoscenza dell’organizzazione, della materia e dei clienti, mezzi, relazioni, esperienza su procedure, policy e molto altro.
Capite perché investire in questa relazione può essere molto vantaggioso oltre che rivelarsi particolarmente efficace per i vostri progetti?

Mappatura degli stakeholder: 3 esempi

Da dove si parte allora?
Come sapete uno dei principi della mentalità agile è proprio la consapevolezza che nasce dall’atto di visualizzare le attività: andremo quindi a creare per prima cosa una mappa degli stakeholder.
Per fare questo potete utilizzare strumenti di qualsiasi tipo – sono sufficienti anche carta e matita – e avete a disposizione vari tipi di rappresentazione.
Oggi ne esploreremo 3 diverse insieme.

Mappa degli attori

La mappa degli attori è a tutti gli effetti una mappa mentale.
Vi suggerisco di partire dal team di lavoro che è il diretto interessato perché ha a che fare con la realizzazione del prodotto giornalmente; a partire da questo ci si estende mano a mano a tutte le varie funzioni con cui il team interagisce, dall’interno dell’azienda fino all’esterno.
Fare questa attività di mappatura in gruppo può aiutare a individuare soggetti non ovvii.

Credits Mind The Product

La mappa degli attori funziona bene anche per attori esterni.
Il principio è sempre lo stesso: partire dagli attori più vicini – le core personas – ed estendere la rappresentazione.

In generale una modalità che si rivela particolarmente efficace è creare la mappa direttamente con gli stakeholder.

Onion Map

La mappatura “a cipolla” vi offre un altro tipo di “colpo d’occhio”.

Credits Mind The Product


In questo caso posizionate gli stakeholder in cerchi concentrici sempre a partire dal team di lavoro che ricade nel centro. Potete suddividere gli “strati” della cipolla in vari spicchi corrispondenti alle differenti funzioni aziendali.
A questo punto inserite le varie persone tenendo presente che non tutti gli strati devono necessariamente contenere un nome.

La onion map vi dà la possibilità di individuare eventuali buchi nella rappresentazione o aree che contengono troppi interlocutori.

Anche in questo caso potete rivedere la mappatura con gli stakeholder stessi e chiedervi perché li avete inseriti in quella posizione? Sono d’accordo sulla collocazione?
Se vi sentite a disagio all’idea di condividere questo schema con i diretti interessati chiedetevi perché. Evidentemente c’è qualche aspetto che deve ancora essere risolto…

RACI

Infine un grande classico della mappatura degli stakeholder: la matrice RACI. Ricordo quando in una vita precedente studiavo questa tabella per la certificazione PMI.

RACI è un acronimo che sta per:

  • responsible – colui che fa il lavoro
  • accountable – chi detiene l’ownership del risultato finale del lavoro; è un soggetto che ha potere decisionale e di veto sul prodotto / progetto
  • consulted – in questo cluster sono spesso collocati moltissimi stakeholder; sono coloro che devono essere consultati prima che siano prese le decisioni
  • informed – quelli che devono essere mantenuti aggiornati; l’area dove sono sempre presenti più persone.

Nell’esempio dell’immagine potete vedere come la realizzazione del prodotto viene segmentata in attività e come i diversi soggetti giocano un ruolo differente nei vari task.
La matrice RACI può avere questo livello di dettaglio o fermarsi al grado più alto indicando una persona singola come responsible o accountable dell’intero progetto (così è come gestivamo le roadmap in lastminute.com).

Tenete anche presente che, indipendentemente dallo strumento utilizzato, la mappa degli stakeholder non è una rappresentazione statica: va tenuta aggiornata perché cambia nel tempo.
Uno stakeholder vitale all’inizio di un progetto potrebbe essere poco interessato in fase finale e viceversa.

Coinvolgere gli stakeholder dall’inizio del progetto

Qualsiasi tipo di mappatura decidiate di usare il punto chiave è capire chi sono gli stakeholder, a cosa tengono veramente e che tipo di coinvolgimento devono avere nel progetto.

Per comprendere cosa li spinge adottiamo sempre la solita procedura: dobbiamo parlare direttamente con loro, dobbiamo intervistarli per comprendere quali sono le loro aspettative nei confronti del progetto, cosa vogliono ottenere, qual è il loro contesto, le sfide che vedono.
E per essere davvero efficaci dobbiamo fare in modo che questa conversazione avvenga presto, all’inizio e non alla fine del progetto.
E’ davvero una regola di buonsenso: già solo sedersi ed avere una conversazione assieme fa una grande differenza. E’ il primo step di una gestione proattiva e moltissimi non lo fanno.

Chiudo con un piccolo suggerimento che potrebbe sembrare controintuitivo ma si è rivelato utile in diverse occasioni: partite con il proposito di empatizzare, ma non date per scontato che il vostro interlocutore abbia sempre un intento positivo nei confronti del vostro progetto / prodotto.

Esplorate la reciprocità cercando di trasmettere cosa potete fare voi per loro e rimanete in ascolto. Se scoprite che ci sono disallineamenti tra di voi potete utilizzare ciò che avete appreso sulle aspettative dell’interlocutore per ricondurre la discussione sul terreno comune degli obiettivi.

Non esiste una formula magica; si tratta di sperimentare e cercare la giusta misura.
Ogni giorno con prove ed errori crescerete nella capacità di influenzare.

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!