Come parla un PM di Google ai suoi clienti

Come parla un PM di Google ai suoi clienti

- di
Come parla un PM di Google ai suoi clienti

Vi siete mai chiesti cosa significa essere un PM di Google? E come parla un PM (di Google) ai suoi clienti? Avete idea di come sia impostato il lavoro quotidiano, come sono strutturati i team ma, soprattutto, qual è il percorso migliore per essere assunti nella Big Tech per eccellenza?

Lo abbiamo chiesto direttamente a Stefan Schnabl, Senior Product Manager di Google che, nell’episodio del nostro podcast dedicato, ha risposto esaustivamente a tutte le nostre domande.

Stefan è un product leader, coach e autore che attualmente ricopre il ruolo di Senior Product Manager a Google. Qui lavora da oltre 11 anni ed è a capo del team che si occupa dei prodotti in area “educational”: l’obiettivo è di diffondere la cultura tecnica attraverso la tecnologia. Stefan ha anche un suo blog, The Product Insider, dove raccoglie spunti, riflessioni e storie che ruotano intorno al mondo del product management.

In questo estratto del podcast, vi racconteremo:

Come parla un PM di Google ai suoi clienti

Dopo aver chiesto a Stefan come si diventa PM in Google e il suo primo giorno di lavoro, siamo passati al workflow usato dai PM dell’azienda per parlare ai suoi clienti. A Stefan abbiamo chiesto se lui, in quanto PM, utilizza qualche struttura flusso o processo specifico, in fasi diverse del ciclo di prodotto.

“Utilizziamo tutto ciò che rientra nella ricerca sull’esperienza utente. Ho un progetto di ricerca UX che applico con cognizione di causa. Internamente viene chiamata ‘ricerca rapida’, e credo che questo termine abbia un significato anche al di fuori di Google. Si tratta di un progetto molto leggero nato per creare un brief di ricerca basato su ipotesi, insieme a un processo che faciliti la raccolta di dati con i clienti in un contesto di interviste. Questo può essere fatto sia a distanza che di persona, e può includere o meno artefatti, a seconda della fase del ciclo di vita del prodotto in cui ci si trova. Quindi, in genere, è questo il metodo che scelgo perché è leggero e abbastanza flessibile, così da essere modificato. Ho anche scritto un post sul blog e l’ho pubblicato. Quindi è a disposizione di chi ne ha bisogno.

Ma quando faccio questo tipo di interviste ai clienti, la cosa fondamentale per me è che in Google abbiamo il lusso di avere a disposizione una tonnellata di risorse molto, molto talentuose, il che significa che queste risorse sono in grado di gestire, di far parte di queste conversazioni. Dunque, partecipano ingegneri, UX, in alcuni casi anche i project manager. In questo modo, lo scambio diretto di informazioni o la compilazione delle informazioni e la loro consegna a me ha cambiato le carte in tavola, soprattutto quando ci siamo imbarcati in nuovi spazi.

Perché in questo modo si ottiene il potere cerebrale di tutte queste persone. Portate con voi il vostro TL, il vostro tech lead direttamente dal cliente, a partire dalla descrizione del problema. Vedrete che è molto, molto più d’impatto di quanto non lo sia io che scrivo appunti e poi li condivido, che è prezioso naturalmente, ma lo è di più quando avete qualcosa che è ben compreso e avete solo bisogno di una prova che sia effettivamente di dimensioni legittime o legittimamente d’impatto. Ma per le cose che non conosciamo ancora, mi piacerebbe portare con me il team inter-funzionale di base a questi colloqui”.

Un lavoro di squadra

Dunque, è più simile a un gioco di squadra? Anziché ricevere tutte le specifiche per poi passarle al team di sviluppo, ci si abitua a lavorare insieme, anche nella fase di Discovery.

“La collaborazione completa da un capo all’altro è la cosa di maggior impatto: in questo modo si ha un TL che ha l’acume e le competenze tecniche, ma che comprende anche il problema dell’utente finale. Quindi le soluzioni saranno molto diverse. Avremo uno spazio dedicato alle diverse soluzioni: qui è ciò che il product manager ha descritto, questo è ciò che l’ingegnere ha costruito, e così via.

Ovviamente, se non si dispone di una gestione del prodotto, è proprio qui che le aziende finiscono nei guai. Quindi, mi confermate che c’è ancora l’idea che come PM si possano riassumere le cose e portarle al team e spiegarle, giusto?

Ma la cosa principale è che questo approccio cambia le carte in tavola. Per me ha cambiato le carte in tavola portare con me il team inter-funzionale e strutturare le sessioni in modo che siano focalizzate e guidate. Ed è qui che forse ora è un PM a dirigere. Io assumo il ruolo più importante. Definisco le linee guida per gli obiettivi e le priorità.

Stabilisco le linee guida di base, ma lascio che il team operi all’interno di tali linee guida, chiedendo di essere indipendente perché gli ingegneri devono comprendere il problema aziendale per creare effettivamente qualcosa che soddisfi le esigenze dell’utente finale. E se lo si traduce solo in termini generici, francamente è un sacco di lavoro, no? Bisogna scrivere molti dettagli per essere sicuri di non sbagliare. In secondo luogo, ci sono cose che gli ingegneri vedono e che io non vedrei necessariamente, e per questo è la soluzione migliore”.

L’aspetto più sottovalutato dell’essere PM

Da qui, ci colleghiamo a cosa significhi essere un PM: ma oltre agli aspetti positivi, qual è l’aspetto più sottovalutato dell’essere PM?

“Faccio molto coaching e le persone mi contattano spesso per diventare PM. E scrivo un blog, come sapete, il Product Insider, in cui rifletto molto su queste tematiche. Le persone pensano solo agli aspetti positivi, e credo che sia normale.

Le persone arrivano e guardano al ruolo e a tutto ciò che di straordinario è associato a questo ruolo, ma non si rendono conto di quanto sia solitario. Non c’è quasi mai un altro PM con cui si collabora strettamente. Hai un manager interessato alla tua crescita professionale, ma quando esci e vuoi costruire qualcosa all’interno di uno spazio, sei praticamente da solo. È altamente competitivo: si lotta per l’ambito, per le risorse, per chi ha il problema più grande, per esempio, e a volte è davvero estenuante, capisci? I momenti di successo sono piuttosto brevi.

Finiscono in fretta, sono di proprietà di tutti e le aspettative sono molto alte. Quindi, in altre parole, si tratta di un lavoro che si sente davvero, come quando – per esempio – le persone descrivono le sensazioni che provano gli atleti. Siete tutti insieme, vi allenate, ma alla fine della giornata siete là fuori a fare le vostre cose, a correre la vostra gara, e dovete affrontare le conseguenze dei risultati. E per certi versi si ha la sensazione che tutto dipenda da voi. E non è detto che sia sempre facile.

Ma è qualcosa che si vede. Di recente, ho partecipato a Zurigo a una conferenza sui product manager in cui c’erano solo PM. Ed è stato fantastico. Era un po’ come una seduta di terapia. Entravi lì e tutti quelli con cui parlavi avevano le tue stesse difficoltà. Ed è stato come dire: “Oh mio Dio, finalmente quello che dico ha un significato per qualcun altro”. Perché è chiaro che quando lo fai, nel tuo ambiente di lavoro, non ci sono molte occasioni in cui puoi avere del tempo a tuo agio senza alcuna pressione o competizione, in cui puoi davvero scambiare con un altro PM quello che stai passando e anche solo sentirti dire che, ‘ehi, quello che hai appena passato è normale e va bene così’. E questa è l’emozione che proverete.

E l’unica cosa che vorrei aggiungere è che l’abbinamento con un brand come Google non rende le cose più facili. Peggiora le cose. Non c’è quasi nessuno scenario vincente. Se fai bene, la gente si aspetta questo, no? E se sei un PM di Google, è ovvio che farai bene. Se fai male, c’è un moltiplicatore, perché hai fallito come parte di questo fantastico marchio chiamato Google, giusto?

Secondo me, ciò che le persone sbagliano è che confondono le cose più importanti (come il grande brand, il grande successo), con ciò che conta davvero come PM: le piccole cose. La cosa che mi entusiasma di più è quando costruiamo qualcosa che va bene per gli utenti. E quel momento in cui l’utente si siede e ottiene qualcosa che non pensava di ottenere, che non pensava fosse possibile, ma che lo aiuta. È il momento per cui si vive come PM, o almeno per cui vivo io come PM”.

Come parla un PM di Google ai suoi clienti

First Principle Thinking

Dunque, una solitudine del PM che a volte proviamo tutti o che abbiamo sperimentato almeno una volta: sì, hai molte persone con cui parlare e confrontarsi ogni giorno ma, in realtà, alla fine della giornata sei tu il proprietario del tuo risultato. Dunque, devi affrontare la realtà in ogni momento. A questo proposito, abbiamo chiesto a Stefan qual è stata la sua esperienza o l’insegnamento più grande come product guy?

“Questo è un aspetto che ovviamente passa attraverso l’iterazione. Quindi in questa fase, questa è la mia risposta, tra tre o quattro anni probabilmente avrò una risposta diversa. Il mio più grande insegnamento finora è stato quello che definirei la First Principle Thinking. È una cosa che mi ha sempre entusiasmato. So che ci sono persone là fuori che sono accreditate per l’eccellenza nei principi primi, nelle analisi, nel First Principle thinking. Elon Musk è una di queste persone, per esempio.

Quando si parla con Elon Musk del motivo per cui è entrato nell’industria automobilistica, lui vi dirà che è nel settore dell’energia e che è molto interessato a come rendere l’energia mobile e così via. E lo fa in un modo che è quasi fisico, quasi da fisica. Ho avuto un momento che ovviamente non era così, ma che mi ha comunque insegnato molto: mi è stato affidato un progetto di dimensioni spaventose e così esposto. E non sapevo proprio come sarebbe andata a finire.

E ora si tratta di qualcosa che è già stato realizzato. Si trattava dell’aggiornamento di Google Analytics da quello che viene chiamato Universal Analytics a Google Analytics 4: c’è una nuova versione di Google Analytics e questa versione utilizza funzionalità di tracciamento sottostanti diverse, un codice di tracciamento diverso rispetto alla vecchia versione. Quindi, il mio compito era essenzialmente quello di migrare tutti questi account, aiutare un milione di account a passare dalla vecchia alla nuova versione. E ciò che è stato davvero interessante in questo contesto è stata la prontezza di questi account. C’era una metrica che diceva: “La maggior parte di questi account sono già pronti per la migrazione”.

Quindi, la maggior parte del vostro lavoro consiste nel creare un processo che ci consenta di eseguire la migrazione e di aggiornare gli utenti, assicurandoci che ne siano consapevoli in tutte le fasi e così via. Così ho moltiplicato anche la minima possibilità di fallimento per l’esposizione e l’importanza di questo progetto, ma il rischio era ancora troppo alto perché potessi affidarmi solo a delle ipotesi. A questo punto mi sono trovato al livello 6 di PM, ovvero una sorta di PM senior di Google, per un paio d’anni e ho sentito la necessità, non perché non mi fidassi delle persone, ma solo perché volevo entrare e capire se tutti i prerequisiti erano soddisfatti.

Credo che la metrica dicesse qualcosa come l’80% del nostro fatturato – e questo è espresso in termini di entrate, quindi l’80% delle entrate che vengono eseguite attraverso AdWords, collegate a Google Analytics -, sarebbero state pronte per la migrazione, fondamentalmente.

Così sono entrato e ho analizzato le metriche e poi i dati. Ho esaminato i dati in tempo reale. Ho guardato i dati effettivi che arrivano da tutti questi account. E ho esaminato l’effettivo tracciamento sottostante che viene applicato ai dati, in modo da generare una sorta di primo livello minimo di informazioni. Una cosa che è apparsa molto chiara è che il modo in cui è stata definita la metrica non ha tenuto conto delle esigenze della configurazione, cioè è stato fatto in un modo che non si traducesse nel modo in cui pensiamo agli account di Google Analytics e ai dati in essi contenuti. È stato creato per esprimere il punto di partenza di un account.

In pratica, un account ha iniziato ad applicare questo tipo di tracciamento, ma non ha ancora finito. Non si trattava quindi di una metrica che misurava la completezza, ma di una metrica che misurava l’inizio, o il passo iniziale che i clienti facevano. Abbiamo quindi spostato la definizione della metrica, dicendo: “Ok, aver iniziato non è sufficiente per il nostro caso, abbiamo bisogno di completezza nella definizione della metrica”. E quindi la percentuale si è spostata da 80 a 0,03″.

Pazzesco, no?

“È stato pazzesco. Già. E, guardate, è stato divertente perché tutti coloro che sono stati coinvolti in questo progetto hanno richiesto la chiarezza della spiegazione a partire dal livello più basso, arrivando fino in cima, spiegando i passaggi intermedi in modo che a ogni punto di rottura si potesse tradurre ciò che sarebbe stato necessario per passare al livello successivo.

E questo è stato aggirato perché la definizione delle metriche era ambigua. Così, una volta risolta la definizione delle metriche, abbiamo evidenziato chiaramente queste milestone e abbiamo detto: “Ecco la milestone di cui abbiamo bisogno e a questa milestone abbiamo questa percentuale. La pietra miliare che pensavate di avere è all’80, ma non è utile per noi”. Ed è stato molto interessante vederlo.

Naturalmente si possono provare tutti i tipi di emozioni, ma la storia principale che ci si vuole raccontare è che non saremmo riusciti a far sì che nessun utente avesse successo con un processo che avremmo concepito noi. Quindi, in questo scenario, abbiamo risparmiato un sacco di dolore, sia per l’azienda che per i clienti. E, poi, abbiamo avuto chiarezza nell’articolare azioni concrete che erano molto diverse da quelle che pensavamo fossero necessarie.

A questo punto, non si trattava più di un processo. È diventata un’azione che ci richiedeva di abilitare e supportare meglio i clienti. Ed è quello che abbiamo fatto. E così l’aggiornamento è ora completo o in pieno svolgimento. E le cose funzionano molto bene”.

Riascolta l’intera puntata per approfondire l’intervista a Stefan Schnabl, Senior Product Manager di Google e iscriviti alla newsletter di Product Heroes per non perderti neanche un nostro contenuto!

Facci sapere nei commenti tuoi dubbi o richieste, siamo qui per risponderti.

Le slide sono disponibili per studenti ed ex studenti del Master in Product Management

Accedi a "Agile Starter Kit" Gratis

Iscriviti alla newsletter e accedi ad Agile Starter Kit: la cartella che contiene oltre 70 pagine su Agile, Scrum / Kanban, Organizzazione Team, User Story, Backlog, e tutto ciò che ti serve per partire.

Scarica il post sulle alternative a Scrum

Iscriviti alla newsletter e scarica gratuitamente il post "Agile Scrum: Alternative più flessibili e agili"