Why vs What & How: facciamoci le giuste domande

In questo articolo voglio parlarti di uno dei classici problemi che affligge il Product Manager: il dare il più importanza al “cosa” fare e al “come” farlo rispetto al “perché” e al contesto.

Ti parlerò di un vero episodio di vita – lavorativa – vissuta, dal quale ho capito quanto sia importante chiarirsi le idee sul perchè sto facendo quella cosa.

Vedremo assieme il why e il contesto contrapposti al what e al how e trarremo infine delle conclusioni.

• Introduzione
• “Tutto chiaro!” – sbagliato!
• Il “what” e il “how”
• “Why” e Product Lifecycle
• Contesto, Why e collaborazione intra-team
• Conclusione

Introduzione

Ci siamo passati tutti. Garantito! Ti sarà sicuramente successo di approcciarti a costruire un Prodotto Digitale chiedendoti esclusivamente “Cosa c’è da fare” e di procedere dritto come un treno verso lo sviluppo del tuo Prodotto. Quindi ti sarà sicuramente successo di lanciare prodotti incompleti, o di lanciarli in ritardo, o che rispondessero in modo incompleto al need dei tuoi utenti. 

A me è capitato di farlo e di lanciare un prodotto in discreto ritardo rispetto alla Roadmap. Ma cosa è successo in quel caso? Ho sottovalutato l’importanza del chiedermi “Perché lo sto facendo?” e delle informazioni di contesto, che ho imparato essere fondamentali per guidare un Product Manager. 

Mi dirai che c’è la ricerca, che ci sono le discussioni con gli stakeholder – che aiutano a chiarire ed approfondire il need che il tuo Prodotto Digitale soddisferà (insieme, appunto alla ricerca) – che ci sono gli OKR – che chiariscono la direzione da prendere a livello aziendale.

Il punto è che ricerca, OKR e discussioni con gli stakeholder sono ingredienti necessari ma non sufficienti per realizzare un Prodotto Digitale: se non sono “conditi” dalla risposta a due domande:

• perchè lo sto facendo?
• qual è il contesto in cui mi sto muovendo?

come Product Manager faremo molta fatica, dall’attività più strategica a quella più operativa.

Vediamo, appunto, perché.

“Tutto chiaro!” – sbagliato!

Di recente sono stato incaricato di lanciare uno dei Prodotti Digitali di cui mi occupo in uno dei Paesi in cui opera TheFork – l’azienda per cui mi occupo di gestire i Prodotti di Pagamento, sia per il mercato B2B (i ristoranti) che per quello B2C (gli utenti finali che prenotano pasti dal sito web e dall’app). 

L’obiettivo era quello di lanciare uno dei Prodotti di Pagamento per i ristoranti. Conoscendo il Prodotto, e sapendo grosso modo cosa fare, ho proseguito con la programmazione degli Sprint assieme al Team Scrum di cui faccio parte.

A poche settimane dalla data di lancio programmata, uno degli stakeholder locali mi ha chiesto di scrivere una guida. È proprio mentre si scrive una guida che vengono a galla errori come quello che mi sono accorto di aver commesso in questo caso: mi ero accorto di non aver incluso, negli sviluppi, una funzionalità banale ma imprescindibile per il corretto funzionamento del Prodotto che stavo per lanciare. 

Quindi?

Quindi, risultato finale: ritardo sull’execution di 3 settimane e conseguente ritardo nella commercializzazione del Prodotto.

Cosa ho imparato da questo errore? 

• Che non mi sono chiesto “perché”. O meglio, me lo sono chiesto quando era ormai troppo tardi. Avere chiaro il why di quello che facciamo come Product Manager, il “dove vogliamo arrivare”, e il raccogliere più informazioni possibili relative al contesto sono azioni fondamentali nella costruzione di un Prodotto Digitale (e domande da porsi ben prima della realizzazione di una guida!). 

• Che why e contesto sono elementi quasi più importanti del “cosa voglio fare” o del “come”. E lo sono sia nella fase che precede l’implementazione (nel mio caso sarebbe stato fondamentale!), che nelle fasi di scaling e miglioramento del prodotto a regime. 

Il “what” e il “l’how”

Ma quindi dobbiamo passare il nostro tempo a filosofeggiare sul perché stiamo costruendo un Prodotto Digitale? 

No, non sto dicendo questo: sto dicendo che non bisogna affrettarsi a “fare le cose”. Quando si fa Prodotto si tende a definire “cosa vogliamo fare” fra le prime cose (es. “Lanciare il Prodotto X, implementare il social login, etc.). Si tende a farsi prendere dall’euforia e ad abbozzare i primi wireframe, e a lanciarsi il prima possibile nella fase di sviluppo.

Il che non è sbagliato di per sé, ma è facile intuire come senza gli elementi di contesto e la spiegazione del perché lo stiamo facendo, rischiamo di commettere errori (più o meno gravi, vedi sopra!). E non c’è ricerca o OKR che tenga: ci deve essere chiaro sia cosa fare che perché lo stiamo facendo. Lo so che sembra ripetitivo, ma deve diventare un mantra (e alla fine di questo articolo, fidati, lo sarà.

Prendi il mio caso, ad esempio: mi era chiarissimo cosa dovessi fare. Avevo già in mente flussi, wireframe, addirittura l’interfaccia. Ma se mi fosse stato chiarissimo anche il “perché” (o, meglio, se mi fosse stato chiaro ben prima) non avrei ritardato il lancio del mio Prodotto di 3 settimane.

“Why” e Product Lifecycle

Ma cosa si intende per “fasi le giuste domande”, “chiedersi il perchè”, “approfondire il contesto”? Dalla mia esperienza, significa aver raccolto – tramite la ricerca, attraverso gli OKR aziendali / di Dipartimento / di Team, dagli stakeholder – tutti quegli elementi di contesto di base che ci permetteranno di muoverci e districarci autonomamente e con poche informazioni nelle nostre attività da Product Manager. 

E quindi, come Product Manager, quando dovremmo farlo, esattamente? In quali fasi del ciclo di vita del Prodotto? La risposta é semplice… sempre! Contesto e il perché delle cose sono elementi da avere sempre chiari in mente per muoversi e “fare le cose”:

• in fase di concept
• in fase di pianificazione dello sviluppo
• dopo aver lanciato un Prodotto, quando se ne cura l’evoluzione.

Lo Sprint Planning

Non sempre, poi, un Product Manager ha le idee chiare su come prioritizzare il proprio backlog. 

Può succedere di trovarsi ad uno Sprint Planning e di non sapere quali attività svolgere prima e quali dopo. Quando capita, contesto e perché vengono in aiuto: bisogna solo individuarli, con l’aiuto dei dati, degli stakeholder, del mercato. 

Durante questo periodo di lavoro da casa, a causa dell’emergenza Covid19, mi è capitato di pianificare uno Sprint dando minor priorità ad una funzionalità per i ristoratori rispetto ad una funzionalità per gli utenti finali – banalmente perché i ristoranti sono chiusi e quella funzionalità poteva aspettare. 

In questo caso, il contesto esterno mi ha dato le risposte di cui avevo bisogno per fare – correttamente – il mio lavoro. È un esempio banale, ma che permette di capire in maniera molto facile quanto siano potenti queste due parole per un Product Manager.

Il Backlog Grooming

Sono domande molto importanti anche durante il Backlog Grooming – il processo di revisione e modifica giornaliera che il Team di Sviluppo apporta quotidianamente al proprio Backlog. Servono per rispondere alle domande che gli sviluppatori possono porre al Product Manager. Serve al Product Manager per chiedersi se tutto il Team ha tutti gli elementi di cui ha bisogno per procedere come se, nell’arco temporale del proprio Sprint, il Product Manager non esistesse. E serve al Product Manager per ottenere un Backlog in salute, parlante, con tutti i dettagli che servono per rendere il Team produttivo in qualsiasi momento.

Contesto, “why” e collaborazione intra-team

Contesto e perché sono due elementi molto importanti anche in un altro aspetto fondamentale della vita del Product Manager all’interno di un’azienda. Dalla piccola start-up, alla scale-up in crescita, alla grande azienda, ogni Product Manager deve interagire, collaborare ed ottenere collaborazione sia all’interno del proprio Team di Sviluppo che con altri Product Manager e i relativi Team di sviluppo. 

Dare contesto e spiegare il perché si ha bisogno di collaborazione è fondamentale per offrire ma anche per ottenere collaborazione fra i Team: se non spieghiamo bene ai nostri colleghi il contesto in cui stiamo operando, non otterremo collaborazione e non saremo produttivi, né noi con il nostro Team, né loro con il proprio. 

Ma se spiegare il perché potrebbe essere relativamente semplice, forse é più complesso spiegare il contesto ai fini di ottenere collaborazione fra Team: in quest’ottica, gli OKR sono di grande aiuto, sia quelli di Team che quelli aziendali, perché danno un contesto inequivocabile e, laddove necessario, aiutano a far prioritizzare una determinata attività al Team con cui ci si è interfacciati. 

Quindi: OKR, elementi di contesto, e “perché delle cose” aiutano sia a collaborare all’interno del proprio Team – per gestire il Backlog, per capire perché stiamo facendo un determinato sviluppo, per capire quale problema stiamo andando a risolvere – sia fra il proprio Team e gli altri Team, con l’obiettivo finale di produrre tutti insieme maggior impatto e valore aziendale. E per capire meglio il cosa e il come dobbiamo “fare le cose”.

Conclusione

In conclusione, chiedersi perché, raccogliere elementi di contesto e ripetersi le risposte a questi due interrogativi 

• è molto importante nella vita di tutti i giorni del Product Manager
• aiuta a prendere decisioni difficili in contesti di assenza/scarsità di informazioni
• aiuta a collaborare fra team e all’interno del tuo stesso team. 

Sono due strumenti, due elementi di guida che possono servire più di qualsiasi framework a chiarirci le idee e farci fare il nostro lavoro al meglio e realizzare Prodotti che rispondono appropriatamente (e per tempo!) al need per cui li abbiamo creati o migliorati. Non è semplice, lo so, ma ci si arriva: è un esercizio da fare quotidianamente e reiterare finché non sarà diventato parte del nostro mindset. 

Il non farlo, però, può portarci a fare errori anche abbastanza grossolani (vedi sopra, parte II), o a farci perdere di vista i problemi da risolvere o l’obiettivo finale da perseguire.

E tu? Hai mai adottato questo metodo? Quali altri ne conosci? Sarei molto curioso di approfondire le tue esperienze, quindi se hai feedback o dei suggerimenti o vuoi semplicemente condividere il tuo punto di vista in merito a questo argomento, fallo pure nei commenti! (Ovviamente, chiedendoti prima il perché e spiegandomi bene il contesto 😉)