Non sono certo l’unico a essersi chiesto cosa esattamente faccia un product manager. Approfondendo, ho capito che responsabilità e competenze del product manager cambiano a seconda delle aziende, dei team, dei prodotti. Il che genera una gran confusione e può rapidamente debilitare chi soffre di sindrome dell’impostore (eccomi!). Non a caso ho passato i primi mesi della mia carriera a tener nota di tutte le caratteristiche che mi mancavano rispetto a chi già svolgeva il lavoro. Il problema: ciascuno di loro sembrava avere competenze e aree di responsabilità diverse.
Buone notizie: probabilmente c’è il prodotto che fa per te
Oggi mi piace pensare a questa situazione in termini di opportunità. Mi sono chiesto:
- Come distinguere le caratteristiche e competenze centrali da quelle accessorie o specifiche di certi prodotti e domini?
- Qual è il giusto livello da raggiungere per ciascuna di queste competenze? Come posso arrivarci se ancora ho delle mancanze?
- Soprattutto: cosa mi piace fare e cosa mi riesce bene? Posso sfruttare questo fatto per diventare quel particolare tipo di product manager?
Ho lavorato a stretto contatto con una collega durante la sua transizione da una posizione commerciale a product manager. Ho visto nel suo percorso il dispiegarsi di queste possibilità. La sua iniziale titubanza nell’affrontare temi tecnici ha lasciato man mano spazio alla sicurezza derivante dalle sue eccellenti capacità strategiche, commerciali, analitiche e di gestione degli stakeholder. E nel tempo ha lavorato quanto bastava per solidificare le nozioni tecniche necessarie.
Perché ha funzionato? Primo, perché lavora sul prodotto giusto – un prodotto il cui sviluppo richiede un bilanciamento di competenze che si riflette bene sul suo. Secondo, perché lavora nel team giusto – un team dove, ad esempio, la sua principale controparte tecnica ha un eccellente senso per le necessità del prodotto ed è dunque altamente affidabile. Terzo, perché ha riflettuto su questi argomenti, dedicando poi tempo nell’approfondire ciò che andava approfondito (e compensare ciò che andava compensato).
Ok… da dove inizio?
La risposta breve è: dal capire le potenziali aree di responsabilità. La miglior risorsa che ho trovato per riassumere quali siano queste aree è il framework creato da Julia Nechaieva sul suo sito PM Daisy. Qui viene suggerito che un PM possa essere potenzialmente responsabile per un numero variabile di queste aree:
- User / customer research: test di funzionalità, survey, focus panel, report di mercato, interviste agli utenti.
- Artefatti: gestione o scrittura di PRD, user story, documentazione della visione o strategia di prodotto, roadmap.
- Engineering: sviluppo del codice in produzione, sviluppo di prototipi, design dell’architettura del sistema.
- UX: creare prototipi, mock-up, design, elementi grafici, wireframe.
- Analisi dei dati: analisi dei KPI, proiezioni, gestione e analisi degli A/B test.
- Project management: gestione delle risorse, definizione dei processi.
- Marketing: strategia di go-to-market, gestione delle campagne, creazione dei briefing per i creativi.
- Vendite e partnership: business development, ricerca e sviluppo di accordi commerciali.
- Business e finanza: responsabilità per la P&L, gestione della performance finanziaria.
- Gestione personale: gestione diretta di sottoposti, assunzioni, sviluppo del personale.
Il modello proposto suggerisce inoltre che, per ciascuna area, vi possano essere quattro tipi diversi di coinvolgimento:
- Il PM si occupa in prima persona dell’area (ad esempio, in Engineering, parte delle sue responsabilità includono la scrittura di codice per la realizzazione di prototipi)
- Pur non occupandosene in prima persona, il PM ha a disposizione all’interno del proprio team le risorse che si occupano dell’area
- Il PM ha a disposizione risorse esterne (aziendali o non) che si occupano dell’area
- L’area non rientra tra le responsabilità del PM
I primi tre livelli di coinvolgimento non sono mutualmente esclusivi. Nel mio caso, ad esempio, sono direttamente coinvolto nell’area business quando si tratta di stimare il potenziale commerciale di un’iniziativa; al contempo posso poggiare su un’area del nostro team che si occupa di esplorare opportunità commerciali con altre aree dell’azienda; infine, quando necessario posso utilizzare risorse esterne al team per analisi specifiche.
E sì, può darsi che alcune aree esulino completamente da ciò che viene richiesto al PM: nel mio caso, Marketing e Vendite sono completamente al di fuori delle mie responsabilità (un gran sollievo, considerato il mio scarso interesse al riguardo!).
Il sito permette di visualizzare la propria configurazione e suggerisce di ripetere l’esercizio periodicamente per vedere come questa cambia a seconda dell’azienda, del prodotto, del team. Qui la mia “margherita”:
Dalle responsabilità alle competenze
Le responsabilità del product manager di una piccola startup coprono probabilmente tutti gli ambiti descritti precedentemente: è inoltre presumibile che la PM abbia scarso supporto interno o esterno, e debba occuparsi direttamente di quasi tutti questi aspetti pur non essendo esperto in tutti. Per prendere un caso diametralmente opposto, posso immaginare che la technical product manager di prodotti interni a Google abbia un ambito di responsabilità più limitato, un numero di aree dove il coinvolgimento diretto sia richiesto con un alto livello di esperienza, e diverse altre aree su cui può contare su abbondante supporto sia esterno sia interno.
Comprendere le aree di responsabilità e stimare il tipo di supporto che ci si può aspettare sono i prerequisiti per capire le competenze che sarà necessario sviluppare o rafforzare.
Ad esempio, nella mia attuale posizione mi sono trovato da subito a competere per le risorse interne di data analytics. Occupandomi di prodotti interni, spesso queste risorse si sono dimostrate scarse in quanto focalizzate sulle analisi per i prodotti rivolti al cliente. Inoltre, molti dei dati su cui poggiano i miei prodotti non sono facilmente estraibili dalle fonti classiche (Google Analytics, ad esempio) e richiedono una certa conoscenza delle API interne per essere estratti e manipolati.
Per quanto partissi da una buona conoscenza in analisi dei dati, ho capito che sarebbe stato fondamentale rafforzare alcune delle mie competenze più tecniche, e raffinare la mia abilità nel saper comunicare i risultati delle mie analisi (in quanto diverse da quelle a cui gli altri PM sono abituati).
Posso immaginare un ottimo PM che non abbia queste stesse competenze di analisi dei dati? Certo! Ne conosco parecchi, ben più bravi di me nel loro lavoro. Potrebbero svolgere il mio stesso ruolo senza acquisire queste competenze? Forse, ma avrebbero bisogno di strategie per compensare queste mancanze.
Stesso nome, lavoro differente
Una cosa accomuna musica, whisky e product management: ce n’è per tutti i gusti. Il giorno in cui mi sono spostato su un nuovo prodotto ha rappresentato il momento in cui ho distintamente compreso di aver intrapreso la carriera giusta. Un prodotto, naturalmente, non solo più adatto alle mie potenzialità e aree di forza: anche più in linea con il modo in cui voglio spendere il mio tempo.
Un momento di riflessione come quello facilitato dalla PM Daisy permette di capire quali sono le aree da sviluppare per poter svolgere bene il lavoro attuale. Al contempo, può essere un eccellente strumento per valutare la soddisfazione con tale lavoro, e dove ci si può immaginare nel futuro.
La variabilità di responsabilità e competenze non deve spaventare. Altro non rappresenta che un ulteriore elemento di riflessione per chi approccia la carriera da product manager, e un’opportunità per chi pensa che i propri talenti e interessi non siano ancora sfruttati al meglio.
