Data-driven: perché è fondamentale nel product management

Cosa significa data-driven? E cosa significa, soprattutto, adottare un approccio data-driven quando si gestisce un prodotto?

Tutti amano i dati, tutti ne parlano e tutti desiderano una strategia data-driven nella gestione del prodotto. Ma quanti riescono per davvero nell’intento?

Per cominciare, vorrei mostrarvi tre casi d’insuccesso che ho vissuto e che possono servire come benchmark:

1. Travolti dalla nostra quotidianità, non abbiamo abbastanza tempo da dedicare a raccogliere e incrociare i dati dalla ‘giungla’ di servizi disponibili;
2. Il management ha ancora un approccio “opinion-driven”, di quelli che conoscono già gli utenti, il mercato e tutti i perché dei trend;
3. Il “vorrei ma non posso”, ovvero non sappiamo da dove iniziare e quando lo sappiamo, non sappiamo che farcene.

Il terzo caso è, a mio parere, quello più interessante.

Vi sarà capitato di leggere tanti articoli sulle metriche fondamentali per il product management; ce ne hanno parlato ai corsi di formazione e alle varie conferenze, ma quando si tratta del nostro prodotto qualcosa si inceppa. Churn, PES, Adoption, Stickiness, MRR sono tutti esempi validi che ciascuno di noi potrebbe usare e che potremmo estrarre in maniera molto semplice anche attraverso diversi tool, ma una volta che li abbiamo, come li leggiamo? Ma soprattutto, come reagiamo?

Come adottare una strategia data-driven partendo dai problemi

L’errore che spesso facciamo è pensare di voler visualizzare una metrica perché ci risolverà un problema. Il mio suggerimento per un approccio data-driven di successo è fare l’esatto opposto, dimenticando per un attimo dati, metriche e grafici.

Data-driven, l’approccio al prodotto: partire dai problemi

Il miglior modo per capire quali sono gli obiettivi che vogliamo darci è partire dagli aspetti che vogliamo migliorare, quelli su cui il prodotto deve fare ‘un bel passo avanti’.

• Usabilità del prodotto
• Troppi bug
• Grosso effort in fase di supporto al cliente

Sono tutti problemi comuni di cui non imbarazzarsi. In questi casi, una fase di “terapia di gruppo” è quello che serve.

Condividere e confrontarsi sui problemi individuati

Per “terapia di gruppo” intendo un meeting vero e proprio tra tutti gli stakeholder coinvolti nel processo, dove la trasparenza è essenziale, e ciascuna delle persone presenti al tavolo condivide le problematiche e gli aspetti migliorabili del prodotto a beneficio del gruppo (e dell’utente finale naturalmente).

Coinvolgere figure diverse e non solo di prodotto in senso stretto – come UX, SME e magari anche Customer Success – è la chiave di svolta: la sensibilità di questi ruoli rispetto alle problematiche del prodotto aiuterà ad avere una visione più ampia ed equilibrata possibile.

How Might We questions: per definire meglio i problemi

Più semplicemente, mettere per iscritto i modi in cui si possono affrontare i problemi individuati, sarà la strada per definire i nostri goal.

La mia metodologia preferita è il cosiddetto How Might We, un metodo usato dal Design Thinking (ma condivisibile anche in altri ambiti), utile per cambiare la prospettiva di una sfida e ideare collaborativamente delle soluzioni.

La formula è molto semplice.

HOW: suggerisce di ragionare sul come risolvere un problema di cui non abbiamo soluzione certa e di esplorare i differenti scenari prima di saltare a facili conclusioni;

MIGHT: enfatizza il concetto della probabilità della risoluzione, permettendo a tutti di collaborare senza giudicare;

WE: ricorda che stiamo lavorando come un collettivo e possiamo arrivare alla soluzione sono con il lavoro di gruppo.

Facciamo un esempio su questo problema riscontrato: “Le chiamate di supporto tecnico sono elevate!”.

👎 How might we evitare che i clienti continuino a chiamare?

👍 How might we migliorare la formazione dei nostri clienti affinché siano più confidenti?

Una volta fatto, senza accorgercene, abbiamo definito i nostri goal! La parte finale della how might we sarà la nostra via da seguire.

Si, ma come?

Attuare un piano d’azione

Una volta che abbiamo fatto autoanalisi sugli aspetti da migliorare e abbiamo ipotizzato come affrontarli, abbiamo ottenuto i nostri goal. Per arrivare alle metriche utili ci manca però ancora qualche passaggio. Prima di tutto dobbiamo individuare quali sono le azioni compiute dai nostri utenti per alimentare quel goal. Ad esempio: se il nostro goal è migliorare l’engagement di una App, l’azione principale compiuta dall’utente è l’interazione stessa, lo scroll di un feed, la condivisione di un contenuto e così via.

Capite dunque, quali sono le azioni che gli utenti possono compiere, chiediamoci prima se sono misurabili ed eventualmente come. Si tratta di una fase molto delicata del processo: non è un errore se arriviamo a questo punto e capiamo che non ci sono metriche a supporto o non sappiamo come valutarle.

Nel primo caso potremmo aver individuato dei problemi di processo collaterali. Non era nello scope dell’attività, ma è comunque utilissimo stanarli. Segniamoli nel nostro backlog personale di miglioramenti! Se non sapessimo valutare il dato in prima battuta, niente paura! È normalissimo: è la nostra prima volta e abbiamo prima di tutto bisogno di una base-line di dati con cui poterlo confrontare e dire se sta migliorando oppure no.

Se invece abbiamo tutte le carte in regola, definiamo quali sono le metriche che vogliamo controllare e quando il valore che rileviamo è interpretabile come buono o come cattivo. Ad esempio, possiamo monitorare il tempo di utilizzo dell’App, ma anche il tempo di caricamento delle varie sezioni, la percentuale di utilizzo delle feature, i punti di uscita dello user journey.

Fatto questo non ci resta che reagire, ovvero decidere quali iniziative abbiamo intenzione di mettere in campo a fronte del risultato della metrica. Potrebbe essere un’iniziativa di conquista, nel caso in cui il dato sia negativo, o potrebbe esserlo di protezione, se vogliamo difendere un buon valore ottenuto.

Se ci accorgessimo, per esempio, che una particolare feature non performa, potremmo rivedere il posizionamento della funzionalità nella navigazione, oppure introdurre delle guide in-App che spieghino come utilizzarla di più o come raggiungerla rapidamente.

Arrivati a questo punto, avremo un piano di azione completo che parte dai punti di miglioramento del nostro prodotto e arriva fino a come vogliamo migliorarli, ma sempre passando dai dati e non dalle opinioni. 

Prendere decisioni data-driven: rischi e consigli

La prima volta che ho provato questo esercizio in azienda non è stata certamente un: “buona la prima”. L’errore principale che ho fatto è stato quello di dare per scontato che tutto fosse comprensibile esattamente come l’avevo immaginato, e andasse quindi tutto liscio. Ammetto che i fuori programma sono sempre in agguato, per cui mi sento di condividere tre rischi e consigli su come rendere tutto più efficace.

1️⃣Focalizzarsi sugli utenti

La fase di terapia di gruppo può portare in alcuni casi fuori tema, è importante non farsi deviare dai problemi di processo aziendali relativi al prodotto, ma focalizzarsi sempre sull’utente finale.
In questo tipo di esercizio, meglio avere un facilitatore super partes, che permetta il confronto, ma che tenga le fila (e il tempo).

2️⃣Un processo iterativo

Il piano di azione diventa inizialmente un vero e proprio progetto che qualcuno deve prendere in carico, definire la timeline e avere dei momenti di show&tell di quanto fatto e raccolto. Da quel momento in poi diventa un processo iterativo, dove i problemi, le iniziative e le metriche stesse non sono scolpite sulla pietra, ma si adatteranno nel corso del tempo.

3️⃣Essere più ambiziosi

L’evoluzione naturale dell’esercizio è di aumentare il focus delle sfide che si vogliono affrontare, è normale iniziare con problemi molto comuni come l’usabilità o l’adozione di una nuova feature. E’ importante non staticizzare la propria visione, ma guardare anche all’innovazione del prodotto, all’ottimizzazione della segmentazione dei nostri clienti, al modello di prezzo e a tutto quello che vi porta a differenziarvi e a generare più valore 🚀

E voi, avete vissuto qualche situazione simile? Cosa ha funzionato e cosa non ha funzionato?
Condividete pure le vostre lesson learned nei commenti ✍🏻! Sarò contento di leggerle e di confrontarmi con voi.

Se siete ancora curiosi, e i dati non vi spaventano…

Date un’occhiata alla Live con Sara Tortoli sul canale YouTube – se non vi siete ancora iscritti, è arrivato il momento di farlo 😉 – dedicata al tema delle Metriche di prodotto che vi riporto qui di seguito.

Guarda ora Andrea Ruggeri, Product Lead @Lightricks: Metriche di Prodotto: cosa sono e come sceglierle

Se volete capirci meglio, potete leggere altri articoli su cosa sono le metriche e perché utilizzarle e cosa misurare. Nella sezione Metriche e KPI, trovate tutti i post dedicati alle metriche di prodotto!

Ti piacerebbe approfondire il tema dei dati e delle metriche all’interno di un contesto più ampio e di un percorso formativo di gestione del prodotto a 360°? Dai un occhio al Master in Product Management 🎓 in partenza.