Product Manager in FAANG: come si lavora in Facebook

La scorsa settimana Ben Erez ha condiviso un tweet sulla sua esperienza nella creazione e gestione di prodotti in Facebook.

Si è scatenato un putiferio. Molti hanno pensato che questa fosse un’ulteriore prova del fatto che i product manager non fanno niente. Altri (soprattutto PM di altre aziende) erano invece d’accordo. I PM di tutto il mondo hanno espresso il loro parere a riguardo.

John Cutler di Amplitude ha detto, una verità a riguardo: le persone sono state veloci nel giudicare senza avere alcun contesto.

Bene. Vorrei aggiungere un po’ di contesto e condividere con voi qual è il ruolo del Product Manager in FAANG (Facebook, in questo caso), quale tipo di rapporto abbiamo con gli Engineer e perché questo modello funziona per noi (e forse anche per il vostro team).

Product Manager in FAANG: Execution + Strategy

Da quando sono entrato a far parte di Facebook, sono stato PM in quattro team diversi e in aree diverse dell’azienda. Parlo di aree diametralmente opposte e responsabilità quotidiane differenti. Ciò che rimaneva costante era quello che ci si aspettava da me e il mio modo di lavorare con gli sviluppatori.

I product manager di Facebook sono responsabili per due outcome in particolare: great strategy e great execution. Un ex manager ha spiegato questo concetto in modo più interessante:

The role of a product manager is to figure out what game we’re playing and how we’re going to play it.

La strategy è la scelta del gioco che stiamo giocando. Si tratta quindi di trovare le aree su cui vale la pena investire e saper creare una vision inattaccabile. Una great strategy si collega ai bisogni in continua evoluzione degli utenti, segue la direzione del business e si basa su una serie di pillars che la fanno progredire.

L’execution è il modo in cui giochiamo la partita. Sono i processi quotidiani, le decisioni e le azioni che mettiamo in campo per progredire verso la nostra missione. L’execution è ciò a cui si riferiva il tweet di Ben prima, che vorrei approfondire.

A mio avviso, una buona execution si traduce in due grandi categorie di sub-task:

La definizione delle priorità, comprende il roadmapping, la stima dell’impatto e la scelta delle feature da implementare. Questa è una parte importante del mio ruolo ed è la parte di execution in cui passo la maggior parte del mio tempo.

L’altra parte è la gestione dei processi. Il processo è tutto ciò che è necessario fare per passare da un brief di prodotto all’outcome desiderato.

Un buon svolgimento di questi sub-task, può contribuire a creare un buon ritmo di execution. Ma se un PM dovesse occuparsi di tutte queste attività per ogni feature in cui è coinvolto, questo sarebbe un ruolo a tempo pieno.

Per i PM più giovani, questo è il ruolo a tempo pieno. Quando sono diventato PM, la maggior parte della mia giornata era dedicata a supportare un buon ritmo di execution del team. Si trattava di project management, Gantt charts, analisi dei risultati degli esperimenti e stesura di report settimanali. All’inizio ero più un “feature manager” che un product manager.

Ma dopo il mio primo ciclo di valutazione, ho imparato una cosa fondamentale: I PM sono responsabili degli outcome del team; gli input/attività non interessano. Per esempio:

• A nessuno interessa che abbiate costruito dei Gantt; a loro interessa che abbiate consegnato il progetto in tempo.
  
• Non interessa che abbiate organizzato riunioni, scritto e-mail ogni settimana o creato task; a loro interessa che il progetto abbia avuto un impatto una volta rilasciato.
  
• Non interessa che abbiate scritto query in SQL perché il vostro data scientist era in ferie; a loro interessa che i vostri obiettivi siano stati ragionevoli e soprattutto raggiunti.

Aver compreso questo, mi ha fatto smettere di definire il mio ruolo in base ai task che dovevo svolgere per concentrarmi invece sugli output di cui ero responsabile.

Sia chiaro: i PM sono responsabili al 100% dei risultati del proprio team. Se il vostro team non riesce a raggiungere gli obiettivi, la responsabilità è vostra. Cemre lo spiega bene:

Ma i risultati sono outcome; il come arrivare a generare quegli outcome sta alle decisioni che verranno prese dal vostro team. Il vostro obiettivo come PM dovrebbe essere quello di trovare la migliore combinazione di input/attività per massimizzare gli outcome del vostro team. Ray Dalio lo chiama pensiero sistematico.

Ciò significa che non è necessario svolgere tutte le attività legate all’execution. Infatti, l’unico modo per scalare il vostro ruolo/impatto nell’organizzazione è iniziare la meta-execution.

La Meta-Execution

La meta-execution consiste nell’execution attraverso gli altri. È così che i direttori di prodotto possono guidare un team di 200 persone senza scrivere ticket, fare revisioni di esperimenti o scrivere aggiornamenti settimanali.

La capacità di conferire ai leader del team una maggiore responsabilità è ciò che separa l’execution di un PM di un team di 5 sviluppatori a quella di un PM che guida un team di 40 Engineer.

La meta-execution consiste nel conferire ai leader del team una maggiore responsabilità (empowering leaders within your team to have more ownership). Questo permette al PM di concentrarsi su problemi che solo lui è in grado di risolvere.

Rivediamo l’elenco degli item di execution di cui sopra. Si potrebbe stilare un elenco di elementi che il PM è in grado di risolvere in modo unico. Il mio punto di vista sarebbe:

Quelli in cima all’elenco sono quelli che avranno sempre bisogno della vostra attenzione, mentre quelli in fondo possono essere delegati ad altri leader del vostro team.

La meta-execution ha bisogno di leader capaci di guidare una maggiore execution in modo autonomo. Una volta individuati questi leader, date loro la responsabilità e continuate a supportarli strada facendo.

In questo modo si arriverà ad avere parti significative dell’execution guidate da altri leader del team.

Un approccio di questo tipo garantisce supporto al team sulle aree in cui ha più bisogno e libera la vostra capacity, che potrete utilizzare nel definire la strategia a lungo termine per la vostra area di prodotto.

Punti chiave

• I PM sono responsabili degli outcome del team; gli input/dettagli/attività sono soggettivi. Il vostro obiettivo dovrebbe essere quello di trovare la migliore combinazione di input per massimizzare gli outcome del vostro team.
  
• Più si diventa PM senior, più si può avere un impatto sulla strategia. Per sfruttare la propria capacity senza che i risultati ne risentano è necessaria la meta-execution.
  
• Ma a prescindere dalle vostre capacità di delega, sarete sempre responsabili dell’execution.

Product Manager in FAANG: Team di prodotto empowered

Non c’è bisogno di guardare lontano per trovare critiche a questo metodo. Dal post di Ben:

Critiche come queste creano una visione contraddittoria tra prodotto e Engineering. Dicono che i PM hanno determinati compiti da svolgere e gli Engineer ne hanno altri.

Questa critica è valida solo quando i team non decidono cosa costruire. Se non decidete cosa costruire, l’unica cosa che conta è come consegnate il progetto che vi è stato assegnato.

Se il vostro team decide cosa costruire, allora l’outcome che generate sarà l’outcome per cui verrete giudicati, non “chi fa cosa”

Questo è ciò che Marty Cagan definisce come la differenza tra empowered team e non-empowered team.

Nella maggior parte delle aziende, i team tech esistono “per servire l’azienda”. Questa è molto spesso la frase letterale che si sente dire. Ma anche se non lo dicono esplicitamente, le diverse parti dell’azienda finiscono per guidare ciò che viene effettivamente costruito dai team tech.

Al contrario, nelle organizzazioni di prodotto forti, i team esistono per uno scopo molto diverso. Esistono “per servire i clienti”, in modo da soddisfare i business need.

Questo evidenzia perfettamente il contrasto. In Facebook, i team di prodotto decidono qual è la cosa migliore da costruire e sono responsabili dei risultati.

In questo modo, si fa spazio a una quantità significativa di lavoro sulla comprensione delle esigenze dei clienti, degli utenti, dell’azienda e del mercato per ciò che si sta costruendo. Per questo motivo, un PM che si concentra esclusivamente sull’execution è segno di un non-empowered team. Dare ha colto bene questo aspetto:

Se il tuo team è responsabile degli outcome, gli Engineer sono felici di guidare parti dell’execution se ciò consente al PM di trovare l’outcome più impattante da generare.

Quando gli Engineer vengono valutati in base all’impatto che generano (ad esempio, una crescita della DAU del +5%), preferiscono progetti che possano avere un impatto significativo. Se fossi al loro posto, preferirei che il mio PM dedicasse il tempo a trovare questi progetti piuttosto che a gestire le attività del progetto a cui sto lavorando.

Punti chiave

• Empowered product teams sono responsabili degli outcome, non degli input. È per questo che le persone assumono compiti al di fuori dei loro ruoli tradizionali (per sostenere gli outcome).
• In un team di prodotto empowered, tutti pensano al modo migliore per raggiungere l’outcome. Ciò può comportare la modifica degli input (ad esempio, gli Engineer guidano parti dell’execution, in modo che i PM possano identificare le aree giuste su cui concentrarsi).
• Il modo migliore per un PM di aiutare un Engineer è assicurarsi che stia lavorando al lavoro di maggiore impatto.

Product Manager in FAANG: il punto di vista degli Engineer

Entriamo in modo approfondito sulla prospettiva di un Engineer.

In un team di prodotto empowered, tutti gli Engineer pensano agli outcome del team. Partecipano alla definizione delle priorità, collaborano con partner cross-funzionali (es. design, data science) e vengono valutati in base all’impatto che generano, non alle righe di codice che scrivono.

Dominik Krejcik ha scritto un’eccellente descrizione di cosa significhi essere un tech lead in un team di prodotto empowered:

Essere tech lead in un team di prodotto empowered non è un ruolo puramente tecnico. Oltre ai tipici compiti sullo sviluppo, si fa parte del product trio manager/tech lead/product designer e si collabora alle decisioni sui prodotti

La collaborazione alle decisioni sui prodotti è possibile quando gli Engineer hanno la responsabilità di un’area. Un modo per accrescere la loro titolarità è quello di guidare parti significative dell’execution.

Comunicare i progressi, guidare la sperimentazione e guidare la gestione del progetto renderà l’Engineer il volto del prodotto e renderà necessaria la sua partecipazione alle decisioni importanti.

Ecco alcuni modi in cui ho visto Engineer e PM lavorare insieme per guidare l’execution:

• Creazione di roadmap: Il PM guida il processo (con il contributo di tutti) per individuare i progetti di maggiore impatto. Una volta definite le priorità e dato il via al progetto, gli Engineer sono responsabili della soluzione e tengono traccia dei progressi verso le tappe fondamentali.
• Comunicazione: Gli Engineer si occuperanno delle riunioni, della documentazione e della comunicazione generale per gli aspetti che stanno supportando. Gli Engineer più anziani guideranno i progressi delle aree più ampie. I PM si occuperanno delle riunioni, della documentazione e della gestione del progetto per l’intero team.
• Gestione del progetto: I PM creano la struttura di execution (es. riunioni ricorrenti, tracker del progetto, check-in delle milestone) e gli Engineer la guidano. Gli Engineer che guidano queste riunioni sono responsabili di segnalare i blocker e di supportarsi a vicenda per raggiungere gli obiettivi. Il PM si inserisce nelle parti dell’execution che può supportare al meglio.

Questi Engineer guidano l’execution per sviluppare competenze, essere coinvolti nelle decisioni di prodotto e guadagnare la capacità di affrontare problemi più labili.

Punti chiave

• Empowered Engineer vogliono collaborare alle decisioni sui prodotti. Guidare l’execution è un ottimo modo per lavorare sull’ownership e partecipare a decisioni importanti.
• I PM e gli Engineer devono collaborare per assicurarsi che l’execution sia ben gestita. Se ci sono lacune nel processo, il PM deve scovarle e risolverle.

Per fare il punto

Quando un team viene valutato in base agli outcome, adatta i propri input per ottenere il massimo impatto. Abbiamo parlato di Engineer che si assumono compiti di execution, ma ci sono molte altre varianti di questo concetto:

• Se un PM può avere l’attenzione di un tech lead per progettare un problema su larga scala, il PM dovrebbe partecipare.
• Se un designer può guidare la gestione del progetto per consentire a un PM di formalizzare una nuova partnership, il designer dovrebbe intervenire.
• Se i data science hanno bisogno del consenso della leadership per finalizzare i goal, i PM possono intervenire per guidare l’allineamento.

Questo perché il team di prodotto è, di fatto, un team. Non si tratta di una serie di ruoli solitari che siedono uno accanto all’altro.

Immaginate una squadra di calcio in cui gli attaccanti si rifiutano di giocare in difesa perché non è il loro ruolo. È questo il senso di alcune lamentele contenute nel post originale di Ben.

I product manager sono i leader di un team. Non perché abbiamo autorità, ma perché siamo responsabili degli outcome a lungo termine dei nostri team.

A volte, è nell’interesse dei nostri team che il PM faccia un passo indietro rispetto all’execution per lasciar crescere il team stesso, definire piani a lungo termine e assicurarsi che stiamo lavorando sugli elementi di massima priorità.

E voi, cosa ne pensate? Fatecelo sapere nei commenti!
Trovate l’articolo originale in lingua inglese di Will a questo link.