Come costruire fiducia nel tuo team di prodotto e ottenere il buy-in degli stakeholder

Leggi la trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Per favore, perdona eventuali errori di battitura poiché il bot non è corretto al 100% delle volte.

Hannah Clark: Lasciami inquadrare la situazione: sei in una sala riunioni con tutti i tuoi principali stakeholder. Guardi alla tua sinistra e vedi il Direttore Account che sta finendo una e-mail. Alla tua destra, il Responsabile dell'Ingegneria ha le braccia incrociate e osserva con sospetto la tua presentazione. Sei anche abbastanza sicuro che il Lead Product Designer stia giudicando il layout delle tue slide. In qualche modo, in qualche maniera, dovrai convincere tutte queste persone a muoversi nella stessa direzione. Ma prima di poterlo fare, è necessario che si fidino di te. Quindi, come puoi guadagnarti quella fiducia e ottenere il loro supporto?

Oggi sono con Noa Goldman, Lead Product Manager di DagsHub. La carriera di Noa è iniziata nello sviluppo software, quindi è stata da entrambe le parti—il che significa che sa quanto può essere difficile conquistare la fiducia nei team cross-funzionali e arrivare a una soluzione efficace per i problemi dei clienti. Noa ci ha raccontato la sua ricetta per conquistare gli stakeholder, costruire relazioni e rafforzare i risultati del team. Iniziamo subito.

Grazie mille, Noa, per essere con noi.

Noa Goldman: Grazie. Sono felice di essere qui. Grazie per l'invito.

Hannah Clark: Sì, siamo contenti di averti qui. Quindi Noa, hai un background nello sviluppo software, che sono sicura ti sia tornato utile in molti modi. Ma mi piacerebbe se potessi dirci qualcosa su come questo ha influenzato il tuo approccio al product management.

Noa Goldman: Certo. Sono stata una sviluppatrice full stack per otto anni. Parte di questa esperienza risale al mio servizio militare. Un'altra parte in piccole startup e grandi aziende. Poi ho fatto il passaggio per diventare product manager e la mia esperienza oggi è nel mondo degli strumenti per sviluppatori, dove mi ha aiutato molto il fatto di essere una sviluppatrice.

Mi ha influenzato molto, ovviamente, la prima cosa: ha sviluppato una forte abitudine a pensare all’utente e anche al buyer persona. So che molti product manager dicono che è fondamentale per loro e pensano costantemente all’utente e al buyer persona. Ma, dalla mia esperienza, spesso non è così.

Per me, essendo stata sviluppatrice e ora product manager di strumenti per sviluppatori, penso sempre sia all’utente che al buyer persona. Quindi, per esempio, se abbiamo una nuova funzionalità da rilasciare o magari un nuovo prodotto da lanciare, penso sempre a come mi sentirei io provando questa funzionalità.

Come si sentirebbe il mio collega riguardo a questa funzionalità? Come la utilizzeremmo? Quali sono i nostri parametri di valutazione? Questa è una cosa davvero importante che secondo me spesso viene trascurata. Quando si rilascia una funzionalità specifica, bisogna sempre pensare a come viene valutato l’utente, secondo quali parametri e se questa funzionalità o prodotto specifico aiuterà davvero l’utente a migliorare o lo aiuterà nelle valutazioni che riceve dal proprio management in quel determinato contesto.

Quindi sì, mi ha influenzato molto nell’abitudine al pensiero sulla persona utente, ma mi ha aiutato tanto anche riguardo al buyer persona. Perché, ancora, sento che questo buyer persona viene spesso trascurato nel processo di rilascio di nuove funzionalità e prodotti.

Quando cerchiamo di lanciare un nuovo prodotto penso sempre: ok, chi sono le persone coinvolte nel flusso di acquisto? Chi deve prendere questa decisione? Per esempio, penso a me stessa. Da sviluppatrice, sarei andata dal mio team lead con una nuova funzionalità o un nuovo prodotto dicendo: “Ehi, che bello”.

E quei team lead risponderebbero: “Perché dovrebbe aiutarci? Perché dovremmo pagare questa azienda?”. Quindi cerco sempre di pensare anche a quelle persone. È una parte molto importante per me essere una product manager, ma il mio background da sviluppatrice mi ha davvero aiutato. E penso che mi abbia influenzato molto anche sulle priorità.

Per ogni nuova funzionalità, non devo sempre andare a chiedere al team lead. Sento che questo processo può essere un po’ pesante per i team lead o per i lead R&D quando il product manager chiede costantemente quanto tempo servirà o quale sarà l’impegno richiesto. Quindi sento che questa è una cosa che posso fare da sola fino a un certo punto.

Questo mi ha aiutato molto. Ma penso che la cosa più importante che ho imparato dall’essere sviluppatrice sono le relazioni con gli altri sviluppatori. Perché so come mi sentivo io verso il product manager da sviluppatrice e come si sentivano i miei colleghi. E non è sempre piacevole, non sempre c’è accordo.

E quello che ne ho tratto è che voglio che gli sviluppatori con cui lavoro si sentano positivi rispetto a me e abbiano voglia di aiutarmi. So quanto siano importanti le relazioni e so, o almeno penso di sapere, come guadagnare la loro fiducia, cosa scegliere su cui discutere e cosa sia più o meno rilevante. E penso che questa consapevolezza dell’importanza della fiducia mi abbia aiutato molto, perché sono stata sviluppatrice all’inizio.

Hannah Clark: Vorrei approfondire questo aspetto: se un product manager ci sta ascoltando e vuole lavorare nel modo migliore con il proprio team di sviluppo, evitando risentimenti e tensioni, quali sono le migliori pratiche che dovrebbe tenere a mente per collaborare in modo efficace?

Noa Goldman: Sì, certo. Ovviamente ci sono molti conflitti a volte, può essere frustrante per entrambe le parti. Essendo stata da entrambe le parti, lo so molto bene. Penso che una delle cose più importanti sia sempre spiegare il perché, collegandoli al lato business.

Noi, come product manager, stando “nel mezzo”, parliamo costantemente con il marketing, il commerciale o l’alta direzione. Gli sviluppatori, invece, lo fanno raramente. Quando presenti qualcosa che vuoi sviluppare agli sviluppatori o ai team R&D, per te product manager è chiarissimo cosa vuoi, perché lo vuoi e come aiuterà l’azienda.

Ma gli sviluppatori che lo sentono per la prima volta non connetteranno necessariamente i punti. Quindi è importante spiegare il perché e collegarli al lato business. Per me, se qualcuno mi chiede di fare qualcosa, non sempre sono d’accordo se non capisco il motivo. Ma se mi viene spiegato il perché, qual è la ragione e come aiuterà l’azienda, probabilmente sarò più propensa ad accettare, o almeno ad aprire una conversazione. Penso sia una cosa fondamentale. E come product manager, il nostro lavoro dipende dagli altri.

Facciamo raramente cose come sviluppare una feature o occuparci del marketing. Dobbiamo sempre spiegare agli altri cosa vogliamo fare. Quindi spiegare il perché e collegare i punti lato business è fondamentale. Inoltre, è molto importante mostrare i dati. Se spieghi il perché e il lato business e come aiuterà l’azienda a crescere, devi supportare tutto con i dati corretti.

Sono sicura che la maggior parte dei product manager si definirebbe data driven. Ma in questi momenti specifici, quando lo presenti al team di sviluppo, è davvero importante essere guidati dai dati. Perché vuoi che si fidino di te, vuoi guadagnare la loro fiducia e vuoi che siano allineati. Questo è un altro aspetto fondamentale che direi.

Un’altra cosa che ho imparato nel tempo, anche se può sembrare strano, è semplicemente dare riconoscimenti. Come ho detto prima, gran parte del nostro lavoro dipende dagli altri. Quando qualcuno, come uno sviluppatore, è coinvolto e lavora duro su una funzionalità, è importante riconoscerlo e dirgli bravo, “Ottimo lavoro”, sia in privato che in un contesto più ampio, in modo che tutti lo sappiano.

Per me, quando qualcuno apprezza il mio lavoro, voglio fare bene, voglio continuare e aiutare. Quindi queste sono le cose che mi aiutano di più nella collaborazione col team di sviluppo.

Hannah Clark: Sì, credo che quello dei riconoscimenti sia un aspetto fondamentale in qualsiasi ruolo, ma spesso viene trascurato benché sia la cosa che può fare davvero la differenza in una collaborazione cross-funzionale.

A questo proposito, pensando alla collaborazione con team cross-funzionali oltre a quello di sviluppo, quali sono le migliori pratiche secondo te per garantire che lo sviluppo delle feature sia fluido e tutti siano allineati a prescindere dalla competenza tecnica?

Noa Goldman: Sì, ricordo una specifica funzionalità che mi ha davvero aiutato a creare la mia “ricetta” personale su come affrontare funzionalità a lungo termine che richiedono molto impegno e tempo. Era una funzionalità relativa all’onboarding in un’azienda dove ero product manager e siamo riusciti ad aumentare il tasso di conversione dal 15% al 90%.

È stato fantastico, ma anche un percorso molto lungo. Ero una PM junior, quindi lavorare con team cross-funzionali e con marketing, vendite e alta direzione era molto impegnativo. Ma è così che ho creato quella che oggi chiamo la mia personale “ricetta” su come affrontare queste situazioni. Il primo passo, ancora prima di presentare la nuova feature al team, è assicurarsi che la motivazione sia quella giusta e che sia davvero la cosa giusta da fare in quel momento, internamente.

Quindi, con me stessa, prima di presentare qualcosa agli altri, voglio essere sicura e certa che sto facendo la mossa giusta. Indipendentemente dalla grandezza dello sforzo, cerco sempre di capire se sto interpretando correttamente il contesto, se sto ascoltando le richieste di business e degli utenti, tenendo lista di richieste funzionalità, e osservando come gli utenti usano il prodotto.

Cerco di avere una mappatura di come stanno le cose in quel momento e di cosa sia importante per l’azienda. Quando arriva una richiesta grande, la prima cosa che faccio è confrontarla con questa mappa mentalmente e verifico che sia davvero la scelta vincente. Se sono convinta, procedo.

Dopo questa verifica interna, controllo di nuovo i dati. Metto in ordine i numeri, li ripasso e vedo se hanno senso, se questo grande sforzo porterà effettivamente il risultato auspicato.

In questo modo mi assicuro anche che non sia solo una mia “fissa” per una particolare funzionalità; sono i dati stessi che mi convincono che sia giusto. Quando sono completamente convinta, cerco il modo più chiaro per presentare tutto: punto a preparare una o due frasi che descrivano il problema e il motivo per cui è importante affrontarlo subito.

Queste frasi devono essere comprensibili sia dalla persona più tecnica in sala che da quella meno tecnica. Poiché il lavoro coinvolge team cross-funzionali, voglio che marketing, sales, management, team leader R&D capiscano bene la questione e il perché sia importante per il business.

Mi assicuro che la presentazione sia “a prova di bambino”, come si suol dire, poi uso i dati raccolti e li presento in modo chiaro. Può sembrare banale, ma presentare i dati bene è fondamentale: il verde indica positivo, il rosso negativo, usare i grafici giusti...

Sono dettagli che spesso vengono trascurati. Quindi faccio in modo che problema e dati a supporto siano illustrati chiaramente. Questo è il secondo step. Il terzo—può sembrare strano—nella mia “ricetta” si chiama Dividi e Conquista, che può avere una connotazione negativa ma non è affatto così.

Questo significa che, prima di presentare la feature a tutti i lead dei team cross-funzionali, cerco di avere delle one-to-one con ciascun responsabile. Ci vuole più tempo, ma ne vale la pena. Mi siedo individualmente col responsabile marketing, sales, R&D e chiunque sarà coinvolto nel processo.

Questo serve prima di tutto a farli sentire ascoltati e importanti. Come dicevo: se vuoi ottenere l’appoggio di qualcuno, deve sentirsi coinvolto e rilevante.

Questi incontri individuali mi preparano anche per la discussione plenaria, perché so già quali obiezioni emergeranno, sono preparata con le risposte e so cosa aspettarmi su ciascun commento riguardo la feature. Inoltre, questi scambi spesso portano ottime idee da integrare nella feature, aumentando anche l’engagement degli altri team.

In questo modo, secondo la mia esperienza, la maggioranza dei coinvolti è già favorevole quando si arriva alla riunione generale, perché si sentono parte del processo e ascoltati. Dopo questo c’è la riunione allargata: mettere tutti nella stessa stanza può far venire un po’ d’ansia, ma dovresti ormai essere preparato.

In sala, presenti lo stesso pitch già condiviso nei one-to-one—quelle due frasi semplici e i dati—e dato che li hai già ascoltati tutti singolarmente, ripeti la presentazione. A questo punto, il più delle volte tutti sono propensi o per lo meno aperti alla discussione. L’obiettivo qui è dare voce a chiunque e ottenere il consenso della maggioranza.

Non si ottiene quasi mai consenso totale, ma se tutti si sentono ascoltati almeno sono aperti all’idea. Dopo questo, la maggior parte sarà con te. I passi successivi sono quello che chiamo “prendere la scena”.

Dato che lo sviluppo è partito e tutti sono informati, assicurati di aggiornare costantemente il team, settimanalmente o mensilmente, oppure usando un meeting già esistente. Mi piace mostrare i cambiamenti visuali, dividere grandi implementazioni in piccole “quick win” per mantener vivo l’entusiasmo e la partecipazione. Visualizzare i successi o insuccessi con i dati.

Essere trasparenti sul processo e ascoltare nuovamente idee o feedback aiuta a mantenere tutti coinvolti e a portare avanti efficientemente la collaborazione cross-funzionale.

Hannah Clark: Un processo davvero chiaro e lineare! Sono curiosa però: che succede se la sala è divisa e non si raggiunge il consenso necessario per andare avanti con la feature? Come ti comporti in questi casi?

Noa Goldman: Ok, se sono sicura che sia la scelta giusta per l’azienda, cerco sempre di ricordare che alla fine tutti lavoriamo per lo stesso obiettivo. Quindi, di nuovo, cerco di dividere e convincere, spiegare il business e il perché, fare capire che siamo tutti nello stesso team.

E di solito funziona. Se ancora non basta, scelgo quali “battaglie” combattere. Per esempio, se qualcuno non è d’accordo, cerco di capire come convincerlo, magari concedendogli una propria feature, aiutandolo a portare avanti la propria agenda.

È tutta una questione di relazione: spesso se aiuti qualcuno, quella persona sarà più incline ad aiutarti. Si tratta di negoziare e far sì che tutti ottengano ciò che desiderano, alla fine.

Hannah Clark: Sì, ha senso. Cambiamo tema verso la prioritizzazione. Parlando di feature, la priorità è sempre una parte enorme. Hai dei segreti o metodi per la prioritizzazione delle feature?

Noa Goldman: Sì, ho la mia “stella polare”, che è il business. Tutto ciò che serve all’azienda per crescere è il mio punto di riferimento. Il mio lavoro è aiutare il business a crescere.

Non si tratta di ciò che amo io o che il mio team vorrebbe sviluppare, ma di quello che è utile per l’azienda. Tengo traccia di quello che chiedono gli utenti, delle richieste del business, del marketing e di cosa fa il mercato.

Per ogni feature che mi viene proposta, chiedo: questa è la cosa che adesso farà crescere di più l’azienda? Se la risposta è sì, passo alla domanda successiva: è la maniera più semplice per svilupparla?

In termini di priorità, scelgo quello che aiuta di più il business e che richiede meno sforzo del necessario. Sono queste le due domande chiave. Se sai rispondere, puoi priorizzare qualsiasi cosa.

Hannah Clark: Siamo quasi alla fine, ma chiudo con qualcosa di divertente. Ultimamente ho chiesto ai nostri ospiti di parlare di musica: che sia mentre lavori o nel tempo libero, c’è un artista o un album o genere che ti piace particolarmente in questo periodo?

Noa Goldman: Domanda divertente, sono proprio contenta! Ascolto musica praticamente sempre. Cerco di farlo mentre svolgo attività che non richiedono troppo pensiero, altrimenti mi confondo. L’artista principale che sto ascoltando è Paolo Nutini.

Non so se lo conosci, ma è fantastico. Ha appena pubblicato un disco che adoro, e il mio sogno sarebbe vederlo in concerto (anche se probabilmente non succederà mai), però ci lavorerò su!

Hannah Clark: Che bello! Non lo conoscevo, magari raccoglieremo una playlist “product manager” anche con i suggerimenti dei nostri ospiti.

Noa Goldman: Mi piacerebbe molto.

Hannah Clark: Ottimo, allora lo andrò a scoprire. Grazie ancora per essere stata con noi oggi, Noa. Apprezzo il tempo che ci hai dedicato e soprattutto la ricetta che ci hai lasciato, davvero pratica e utile per acquisire conoscenze reali e concrete. Grazie mille del tuo tempo.

Noa Goldman: Grazie, mi sono davvero divertita. Grazie a voi.

Hannah Clark: Grazie per averci ascoltato. Per altri approfondimenti, guide pratiche e recensioni di strumenti, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altre conversazioni come questa iscrivendoti a Product Manager su qualsiasi piattaforma di podcast.