Valore per i clienti e impatto commerciale del prodotto

Product owner, ti sei mai chiesto qual è l’impatto commerciale del tuo prodotto?

C’è una citazione di Marty Cagan che ultimamente ritrovo spesso nelle mie letture online:

“lo scopo dei team di prodotto è servire i clienti creando prodotti che i clienti amano, lavorando tuttavia per l’azienda”

Cosa intende dire esattamente Cagan con questa frase?
Vuole sottolineare il fatto che come responsabili del prodotto non ci muoviamo all’interno di un silos; siamo focalizzati sul valore per il cliente finale ma abbiamo la nostra parte di responsabilità sull’impatto commerciale del prodotto e sul conto economico dell’azienda.

Mentre riflettevo sulle implicazioni di questo messaggio mi sono imbattuta su Mind The Product in un intervento del Chief Product Officer di Talabat Yi-Wei Ang – dal titolo “Driving commercial impact for product teams”.
L’ho trovato molto interessante e ve lo riassumo qui di seguito.
E’ proprio incentrato sul fatto che la figura del product practitioner si trova oggi di fronte all’ennesima evoluzione.

Perché essere customer-obsessed non basta…

Come figure di prodotto – product owner, product manager, designer ed esperti UX – siamo spesso sbilanciati verso la prima parte dell’affermazione di Cagan: amiamo creare prodotti amati dai clienti.

Noi siamo quelli che nel giro degli ultimi 10 anni sono passati – per chi lavora in questo ambito da più tempo – dalle pianificazioni annuali di sviluppo dei prodotti e da lunghi documenti di requisiti redatti upfront ad essere i customer-advocates, la voce del cliente all’interno dell’azienda.

Diciamoci la verità: abbiamo un bias verso la creazione di prodotti che abbiano valore per i nostri clienti ma se spendiamo il 90% del nostro tempo su questo aspetto nei processi di discovery e delivery, quanto ci dedichiamo al successo commerciale?

Secondo Yi-Wei Ang è giunta l’ora di ribilanciare i nostri sforzi perché il ruolo del prodotto sta cambiando. Ciò che ci è richiesto oggi è di continuare a creare prodotti amati dai clienti ma che allo stesso tempo siano in grado di far crescere il business, che abbiano un impatto tangibile sulla bottom line (proprio quell’ultima riga del rendiconto finanziario che mostra l’utile o la perdita netti di un’azienda).

E’ ora di abbattere un altro silos…

A pensarci bene questo aspetto è spesso alla base della frizione o dell’incomprensione che si crea tra il team sales e quello di prodotto.

Vi è mai capitata questa situazione?
Il team sales sollecita il prodotto a sviluppare certe funzionalità richieste espressamente dai clienti con lo scopo, ad esempio, di diminuire il churn o tasso di abbandono. Il team di prodotto crea delle soluzioni senza un adeguato lavoro di discovery sul problema e alla fine le nuove feature rimangono inutilizzate senza raggiungere lo scopo iniziale.
E’ una dinamica alquanto frequente.
Evidentemente qualcosa è andato storto nella relazione tra i due.

Se vogliamo raddrizzare questa situazione il CPO di Talabat ci invita a farci carico dei risultati di business oltre che degli outcome di prodotto.
Lavorando a stretto contatto con il team business possiamo massimizzare i risultati per l’azienda nel senso più ampio.

Questo pensiero mi trova assolutamente d’accordo.
Ho sperimentato più volte che per essere davvero efficace nel mio lavoro con gli stakeholder devo essere in grado di mostrare al business l’impatto che sono in grado di produrre sulla bottom-line.
Il mio amministratore delegato, per quanto attento ai bisogni della clientela e consapevole delle metriche di prodotto, finisce comunque per misurare ogni risultato in termini di ricavi e riduzione dei costi. Non c’è niente di male, è il suo focus principale in fin dei conti.

Quantificare l’impatto commerciale del prodotto

Le vendite non sono altro rispetto al prodotto; il prodotto non serve il business, il prodotto è il business.
Se pensate che il prezzo, il costo di acquisizione dei nuovi clienti e il lifetime value siano aspetti che vi riguardano solo marginalmente come product owner state sbagliando strada e rischiate di perdere la migliore occasione per dare rilevanza al vostro ruolo in azienda.

Le decisioni business e di prodotto sono per lo più profondamente intrecciate.
Ang scherza sul fatto che anche se siamo diventati bravissimi ad utilizzare il business model canvas di Osterwalder ci sono alcuni aspetti di questo template che tendiamo con maggior frequenza a tralasciare.
Siamo super-concentrati sulla value proposition, le attività e le risorse chiave ma non approfondiamo altrettanto il prezzo, i canali utilizzati per il go-to-market, la struttura dei costi e delle revenue.

Quindi stiamo davvero dicendo che il Product Owner deve diventare anche un esperto degli aspetti finanziari del prodotto? Dobbiamo andare a coprire l’ennesimo ambito nel nostro ruolo?
La risposta è – come nelle ricette di cucina – “quanto basta”.
Dobbiamo conoscere e comprendere questi aspetti quanto basta per prendere le giuste decisioni.
La buona notizia è che non è necessario fare tutto da soli…

Co-creare con il business

Come possiamo portare l’organizzazione di business e quella di prodotto più vicine in modo da rafforzarle entrambe?
Il suggerimento che da Ang è semplice ed efficace: impariamo a co-creare con il business.

I product owner sono ormai abituati da tempo a considerare la relazione con i designer e con gli sviluppatori la chiave dell’attività di progettazione e sviluppo prodotto.
E’ una relazione che abbiamo creato all’interno dei framework agili e che oggi non mettiamo in discussione perché ne conosciamo il valore.

L’invito che ci viene fatto adesso è di estendere questa relazione di fiducia introducendo nel trio un quarto componente: il business.
Il business partner a quel punto si immerge con noi nella discovery, nella delivery e nella validazione.
L’approccio sperimentale che portiamo nella realizzazione del prodotto non si limita più alla prototipazione, ai test di usabilità o agli A/B test, ma si estende anche a validare le assunzioni di business sul pricing, i segmenti di clientela, le strategie go-to-market e molto altro.

Conoscere l’impatto economico del prodotto

In questa evoluzione della figura di prodotto Ang ci suggerisce di partire da una serie di domande a cui dare risposta:

  • Come fa i soldi il nostro prodotto?
  • Quali sono i costi associati alla linea di prodotto?
  • Quanto costa acquisire nuovi clienti?
  • Quanto costa far funzionare l’intera catena del valore?
  • Quali sono le assunzioni che il business sta facendo?

Quando diventiamo consapevoli degli economic drivers e dell’intero processo che va dall’acquisizione del cliente alle revenue la nostra capacità di influenzare l’evoluzione del prodotto e di creare storie potenti intorno al suo perché si fa esponenziale.

Nel mio caso so che questo passaggio non è stato facile da digerire; ho fatto resistenza per più tempo di quanto avrei dovuto.
Pensavo che essere misurata nel mio ruolo di responsabile di prodotto su metriche di business non fosse del tutto appropriato perché non sono aspetti che controllo direttamente; ho capito che questa è una visione parziale.
In realtà ho scoperto che l’essere legata proprio a obiettivi di business mi da la possibilità di esercitare grande influenza su quelle metriche e di dialogare con il management al livello in cui vengono prese le decisioni.

Quindi product owner non temere di affrontare nel tuo percorso l’ennesimo viaggio di scoperta. Entra nelle dinamiche del P&L; fatti aiutare dalla tua controparte business ed esplorate insieme come poter creare un impatto commerciale del prodotto senza precedenti.

Comunicare con gli stakeholder è un must

Se mi chiedessero di elencare le 5 cose più importanti che ho imparato in anni di lavoro nel Prodotto uno degli aspetti che menzionerei sarebbe sicuramente comunicare con gli stakeholder.
Non ribadirò mai abbastanza l’importanza di questa pratica.
E per stakeholder intendo proprio tutti gli stakeholder, interni ed esterni così come li abbiamo definiti quando parlavamo di mappatura.

Diciamo che abbiamo fatto i compiti a casa, ci siamo presi il tempo di intervistare le persone che a vario titolo sono interessate o influenzate dalla realizzazione del nostro prodotto, abbiamo compreso il loro punto di vista e le loro aspettative e quindi abbiamo gettato le basi per una relazione efficace.

Adesso si tratta di passare alla fase successiva, all’atto: ciò che ti serve è una strategia di comunicazione con i tuoi stakeholder.

Perché serve un piano di comunicazione

Partiamo da un presupposto: più è grande l’organizzazione di cui fai parte e più persone saranno influenzate dal tuo prodotto.
Se parli con ognuno degli interessati dovendo ripetere sempre le stesse informazioni perdi un sacco di tempo e rischi di non ricordare esattamente cosa hai detto a chi.
Ecco perché serve un piano.

Non è tanto importante quale tipo di formalizzazione decidi di adottare, ciò che conta davvero è che tu abbia chiaro:

  1. chi ha bisogno di quali informazioni
  2. quando ne hanno bisogno
  3. quanto frequentemente si aspettano di essere aggiornati
  4. come preferiscono ricevere le informazioni
  5. in generale come puoi massimizzare efficienza e chiarezza

Diciamo che se hai condotto un’attività di mappatura degli stakeholder e li hai intervistati dovresti avere chiari i primi 4 punti.

Essere intenzionali e consistenti

Questa è la chiave della comunicazione con gli stakeholder: essere intenzionali.
Decidere a priori quando avverranno i meeting, quali comunicazioni potranno passare semplicemente via mail e in quali occasioni sarà invece necessario allinearsi con il supporto di presentazioni.

Il migliore approccio che potete avere è creare un piano (condiviso possibilmente) e verificare mano a mano come sta funzionando. Non è necessario che sia perfetto, buono quanto basta è più che sufficiente.
Potreste scoprire in corso d’opera che l’idea iniziale non funziona come vi aspettavate. Non c’è problema: prendete dei feedback, modificate il piano di comunicazione testando i cambiamenti e reiterate il ciclo.

… ebbene sì, stiamo sempre parlando del metodo Lean Start-Up

Ad esempio vi potrebbe capitare che quanto ha funzionato ad inizio progetto si rivela meno efficace con il passare del tempo. Questo può essere dovuto al fatto che le informazioni da passare in fase di discovery sono molto diverse da quelle rilevanti durante la delivery e anche gli interlocutori potrebbero essere differenti.
Prendete nota della cosa e adattate il piano di comunicazione.

Ciò che dovete preservare a tutti costi è non il piano in sé ma l’approccio: essere intenzionali e consistenti. Avere chiara la finalità degli incontri (sono puramente informativi o servono a prendere decisioni?), prioritizzare le informazioni (soprattutto quelle più critiche) e capire cosa dev’essere riportato, quando e come.

Stiamo sempre raccontando storie

Poco tempo fa ascoltavo su Mind the Product un’intervista al CPO di Zoopla, David Wascha. L’intervistatrice domandava quali sono le skill più importanti nella gestione degli stakeholder e lui ha parlato di storytelling e ripetizione.

Tutte le volte che comunichiamo il nostro prodotto, ciò che stiamo realizzando e in quali attività è impegnato il team di sviluppo stiamo creando una narrativa su ciò che facciamo per l’organizzazione.
E’ importante essere consapevoli di questo aspetto: stiamo raccontando storie.

E come in qualsiasi storia che si rispetti è necessario rispettare un plot.
Nella narrativa in questione non possono mancare:

  • WHO (a chi stiamo risolvendo un problema)
  • WHAT (quale problema stiamo risolvendo)
  • WHY (perché è importante o di valore, in particolare per il cliente finale).

Chiediamoci sempre la motivazione della storia che stiamo creando, cosa vogliamo ottenere, se ciò che raccontiamo è al livello giusto, se ci siamo presi il tempo di supportarla con dati reali, se oltre ai dati abbiamo anche la possibilità di sostanziarla con citazioni degli utenti raccolte durante le interviste.

Il nostro storytelling di prodotto racconta dove siamo oggi, dove saremo e ciò che vogliamo ottenere.

Se ci pensate è proprio questa la scaletta di una review di prodotto:

  • riepilogo degli obiettivi e degli aspetti fondanti del progetto
  • lo stato dell’arte attuale
  • le attività che ci apprestiamo a fare nelle prossime iterazioni
  • gli impatti, i rischi e le eventuali decisioni da prendere

Ripetere, ripetere, ripetere… ed evitare di omettere le cattive notizie

Il secondo aspetto menzionato da David Wascha è la ripetizione.
“Le storie vanno ripetute. È fondamentale. Non devi essere soddisfatto fino a quando tutti sanno cosa state facendo. Lo ripeti anche 100 volte fino a quando non lo fanno anche gli altri.”

Riportare lo stato dell’arte di un progetto agli stakeholder è un processo continuo ed un’opportunità di allineamento continuo.
Ecco perché non ha ha senso “nascondere la polvere sotto il tappeto”.
Per quanto sia normale preferire riportare buone notizie, nascondere quelle brutte non le fa andare via e più tardi vengono sollevate peggiore è il rischio.

Avete presente quando slittano le date di una release di prodotto?
Questo è un grande classico!
Si vedono in anticipo i segnali che indicano qualche aspetto problematico ma si pensa di poter recuperare in corso d’opera e troppo tardi viene comunicato che non c’è possibilità di rispettare la deadline. E negli eventuali SAL di progetto è sempre stato comunicato che tutto procedeva secondo i piani…
Questo non fa che provocare la frustrazione in tutti gli stakeholder e una perdita di fiducia non solo sul progetto in questione ma anche su tutti quelli che verranno in futuro.

Ne vale la pena? Direi proprio di no. Meglio sollevare il rischio da subito!
Se i problemi che prefigurate oggi rientreranno non avrete impatti sul rilascio del prodotto, se non sarà così avrete tutto il tempo di valutare le opzioni disponibili e decidere come muoversi.
In più gli stakeholder apprezzeranno il fatto di sentirsi parte attiva del processo, sapranno che non nascondete loro informazioni e creerete i presupposti per una relazione di fiducia.

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!