Luglio 4, 2022 - di Will Lawrence
La scorsa settimana Ben Erez ha condiviso un tweet sulla sua esperienza nella creazione e gestione di prodotti in Facebook.
In >1 year as a PM @ Facebook I've created zero tickets/tasks. We don't do sprints either.
— Ben Erez (@ViableBen) July 28, 2021
PMs here focus on vision, strategy & partnerships. Less on project management & tasks.
Engineers carry most of the project management responsibility & create their own tasks.
It's great.
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.
The comments on this LinkedIn post by @ViableBen are absolutely fascinating. https://t.co/UiISou9X9W
— John Cutler (@johncutlefish) August 1, 2021
Few attempt to explore context.
Attempt to define "works", "project management", "tasks", "strategy" and "vision".
Consider the broader incentives at FB, eng culture, etc. pic.twitter.com/TqyLWSHuSE
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).
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:
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:
this tweet from ben got quite misunderstood.
— cemre güngör (@gem_ray) July 30, 2021
pm's at facebook are held *very* accountable to outcomes.
if a project is failing because of poor execution, it's 100% on the pm to address it, whether they do it themselves or delegate it (successfully). https://t.co/PJUSXcrn5g
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 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.
Non c’è bisogno di guardare lontano per trovare critiche a questo metodo. Dal post di Ben:
«PMs here focus on pseudo work, while engineers do most of the actual work. It’s great» https://t.co/COmV5LO94w
— Vyacheslav Egorov (@mraleph) July 30, 2021
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:
The role of PMs varies depending on how much strategy is top down versus bottom up at a company. At many companies, senior leaders define strategy so the PM role is devising tactics and coordinating execution.
— Dare Obasanjo (@Carnage4Life) August 1, 2021
At Facebook strategy’s often expected to come from PMs not leadership https://t.co/XEhwMJbQQU
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.
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:
Questi Engineer guidano l’execution per sviluppare competenze, essere coinvolti nelle decisioni di prodotto e guadagnare la capacità di affrontare problemi più labili.
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:
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à.
Will è un Product Manager e autore di Product Life, una newsletter che semplifica il product management. In precedenza è stato a capo dei team di consumer payments and growth di Facebook e WhatsApp.
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management