Perché tengo un corso sul product management alla Harvard Business School, mi viene spesso chiesto “Qual è il ruolo di un product manager? Il ruolo del product manager (PM) è spesso definito come il “CEO del prodotto”. Non sono d’accordo perché, come sottolinea Martin Eriksson, “I product manager semplicemente non hanno alcuna autorità diretta sulla maggior parte delle cose necessarie per rendere i loro prodotti di successo – dalla ricerca degli utenti e dei dati attraverso il design e lo sviluppo al marketing, alle vendite e al supporto”. I PM non sono il CEO del prodotto, e i loro ruoli variano ampiamente a seconda di una serie di fattori. Quindi, cosa dovreste considerare se state pensando di perseguire un ruolo di PM?
Gli aspiranti PM dovrebbero considerare tre fattori principali quando valutano un ruolo: le competenze di base, l’intelligenza emotiva (EQ) e l’idoneità dell’azienda. I migliori PM con cui ho lavorato hanno padroneggiato le competenze di base, hanno un alto QE, e lavorano per l’azienda giusta per loro. Oltre a spedire nuove funzionalità con cadenza regolare e a mantenere la pace tra l’ingegneria e il team di progettazione, i migliori PM creano prodotti con una forte adozione da parte degli utenti che hanno una crescita esponenziale delle entrate e forse addirittura sconvolgono un settore.
Competenze fondamentali
Ci sono competenze fondamentali che ogni PM deve avere – molte delle quali possono iniziare in classe – ma la maggior parte si sviluppa con l’esperienza, buoni modelli di ruolo e mentoring. Alcuni esempi di queste competenze includono:
- conduzione di interviste ai clienti e test degli utenti
- esecuzione di sprint di progettazione
- prioritarizzazione delle caratteristiche e pianificazione della road map
- l’arte dell’allocazione delle risorse (non è una scienza!)
- effettuare valutazioni di mercato
- tradurre i requisiti da business a tecnici, e viceversa
- prezzare e modellare le entrate
- definire e tracciare le metriche di successo
Queste competenze di base sono la base per qualsiasi PM, e i migliori PM affinano queste abilità nel corso di anni di definizione, spedizione e iterazione dei prodotti. Questi PM eccellono nel riflettere su dove ognuna di queste competenze ha contribuito al successo o al fallimento dei loro prodotti e nell’aggiustare continuamente il loro approccio in base al feedback dei clienti.
Intelligenza emotiva
Un buon PM può conoscere le cose da fare e da non fare in un colloquio con i clienti, ma i migliori PM hanno la capacità di entrare in empatia con i clienti in quel colloquio, sono sintonizzati sul loro linguaggio del corpo e sulle loro emozioni, e possono astutamente scoprire i punti di sofferenza che il prodotto o la funzionalità affronteranno. Un PM con un alto QE ha forti relazioni all’interno della sua organizzazione e un senso acuto di come navigare tra gli ostacoli interni ed esterni per spedire un grande prodotto. Ecco uno sguardo più approfondito su come i quattro tratti chiave dell’IE, come definiti da Daniel Goleman, si riferiscono al ruolo di PM:
Gestione delle relazioni. Probabilmente una delle caratteristiche più importanti di un grande PM è la sua capacità di gestione delle relazioni. Formando connessioni autentiche e affidabili con gli stakeholder interni ed esterni, i migliori PM ispirano le persone e le aiutano a raggiungere il loro pieno potenziale. La gestione delle relazioni è anche vitale per negoziare con successo, risolvere i conflitti e lavorare con gli altri verso un obiettivo condiviso, che è particolarmente impegnativo quando un PM ha il compito di bilanciare le esigenze dei clienti, i team di ingegneri con risorse limitate e gli obiettivi di reddito dell’azienda. Relazioni autentiche e di fiducia all’interno di un’organizzazione possono portare ad un maggiore supporto quando sono necessari ulteriori finanziamenti per un prodotto o quando un ingegnere deve essere convinto ad includere una rapida correzione di un bug nel prossimo sprint. Al di fuori di un’organizzazione, queste abilità potrebbero incoraggiare i clienti esistenti a testare una nuova funzionalità per un feedback iniziale o per convincere un cliente target a provare l’MVP di un prodotto ancora in modalità stealth. Queste abilità relazionali possono anche essere ciò che fa la differenza tra avere clienti irritati a causa di un bug introdotto nel prodotto e quelli che dicono, “Non preoccuparti, sappiamo che lo sistemerai!”
Autoconsapevolezza. I PM devono essere consapevoli di sé stessi per rimanere obiettivi ed evitare di proiettare le proprie preferenze sugli utenti dei loro prodotti. Se un PM è innamorato di una caratteristica perché questa affronta i propri punti critici – i PM sono spesso super-utenti dei prodotti di cui sono responsabili – potrebbero indurre un utente a dire che anche loro la amano, solo per compiacere il PM (“false positive feature validation”). Se non è consapevole, un PM può spingere a dare la priorità ad una caratteristica che ha concepito anche quando tutte le interviste con i clienti e le prove sono contro di essa. Questa mancanza di autoconsapevolezza potrebbe far deragliare priorità più importanti o danneggiare il rapporto del PM con gli ingegneri, che potrebbero perdere la fiducia nel loro PM quando la caratteristica non viene prontamente adottata dagli utenti.
Self-management. Essere un PM può essere incredibilmente stressante. Il CEO vuole una cosa, il team di ingegneri un’altra, e i clienti hanno le loro opinioni sulle priorità delle funzionalità. Gestire scadenze strette, obiettivi di entrate, richieste del mercato, conflitti di priorità e vincoli di risorse tutto in una volta non è per i deboli di cuore. Se un PM non riesce a mantenere le proprie emozioni e la calma sotto pressione, può perdere rapidamente la fiducia di tutti i suoi elettori. I migliori PM sanno come spingere con forza sulle giuste priorità, con urgenza ma senza trasmettere un senso di panico o di stress. Questi PM sanno anche quando prendere fiato e allontanarsi per riorganizzarsi.
La consapevolezza sociale. Secondo Goleman, le competenze associate all’essere socialmente consapevoli sono l’empatia, la consapevolezza organizzativa e il servizio. I PM devono capire le emozioni e le preoccupazioni dei clienti riguardo al loro prodotto tanto quanto capiscono le preoccupazioni del team di vendita su come vendere quel prodotto, o del team di supporto su come supportarlo, o del team di ingegneria su come costruirlo. I PM devono avere una profonda comprensione di come opera l’organizzazione e devono costruire un capitale sociale per influenzare il successo del loro prodotto, dall’ottenere budget e personale per assicurarsi un ingegnere di punta per lavorare sul loro prodotto. Infine, la consapevolezza sociale assicura che i migliori PM servano i loro clienti con un prodotto che si rivolge al loro lavoro da fare, che è in definitiva ciò che guida il product-market fit.
(Leggi di più su ciò che Paul Jackson ha da dire su EQ e PM qui. E qui c’è un’intervista con Sam Lessin, ex VP del product management di Facebook, che dice di non aver “mai allenato con successo l’empatia”)
Company Fit
Se i migliori PM hanno competenze chiave ben sviluppate e un’alta IE, significa che sono destinati al successo indipendentemente da dove lavorano? Non necessariamente. Infatti, prendere queste abilità e caratteristiche di personalità e applicarle all’azienda giusta è ciò che alla fine garantirà il successo.
Devo ancora vedere una descrizione standard del lavoro per un product manager, perché ogni ruolo è in definitiva definito dalle dimensioni, dal tipo di prodotto, dalla fase, dal settore e anche dalla cultura dell’azienda. Se possiedi le competenze di base e l’alta IE necessarie per essere un PM di successo, il prossimo passo è quello di scoprire chi sta assumendo e cosa sta veramente cercando.
Queste sono alcune delle aree chiave in cui le aziende differiscono in ciò che vogliono da un PM:
Capacità tecniche. Il tipo di prodotto, chi lo usa e il tipo di azienda determinano quanto tecnico deve essere un PM. Per esempio, Google richiede ai PM di superare un test di abilità tecnica indipendentemente dal prodotto su cui lavoreranno. Se l’azienda sta costruendo un CRM SaaS, ci possono essere più requisiti intorno all’esperienza con il go-to-market e i cicli di vita dei clienti che intorno a come il prodotto è costruito. Al contrario, se si tratta di un prodotto di scienza dei dati con algoritmi di apprendimento automatico e API, il ruolo può richiedere molta più profondità tecnica per capire non solo come costruire il prodotto ma anche come parlare in modo credibile con i clienti che lo useranno. Detto questo, avere una comprensione tecnica di base di ciò che è sotto il cofano e la padronanza degli strumenti che i PM utilizzano è sicuramente importante per il ruolo, ovunque esso sia. Colin Lernell ha più da dire su queste competenze necessarie qui. Se sei un aspirante PM e sei preoccupato di non avere le competenze tecnologiche di base per il ruolo, potresti prendere in considerazione la possibilità di seguire corsi online come il rinomato corso di Introduzione all’Informatica (CS50) offerto dall’Università di Harvard o uno dei tanti corsi di introduzione e tecnologia avanzata offerti da The Flatiron School.
Filosofia aziendale sul PM. Ogni azienda ha una filosofia diversa sul processo di sviluppo del prodotto e su come i PM si inseriscono in tale processo. Qui sotto ci sono i tre tipi più comuni, con pro e contro:
- Il PM guida l’ingegneria. Questo è un approccio “buttato oltre il muro”, dove i PM raccolgono i requisiti, scrivono la quintessenza del documento dei requisiti del prodotto e lo passano all’ingegneria per definire i requisiti tecnici. Le organizzazioni contemporanee possono fare questo processo in un modo più agile e collaborativo, ma l’aspettativa è che i PM conoscano meglio ciò di cui i clienti hanno bisogno e che l’ingegneria sia lì per servire.
- Pro: L’ingegneria può concentrarsi sulla codifica senza molte distrazioni; questo tende a funzionare bene per i negozi di sviluppo Waterfall con lunghi cicli di vita.
- Con: Gli ingegneri perdono di vista il quadro generale e non sviluppano empatia per i clienti, il che può portare ad una scarsa esperienza utente. Spesso ci sono tensioni malsane quando il debito tecnico e il lavoro di “idraulica” devono avere la priorità sui requisiti del cliente.
- L’ingegneria guida il prodotto. Le aziende di prodotto più tecnicamente orientate (cloud, big data, networking) tendono ad essere guidate dall’ingegneria, dove gli ingegneri fanno progredire la scienza nel loro dominio e i PM convalidano le soluzioni o creano punti di accesso front-end (UI, API) per attingere a questa nuova tecnologia. Ci può essere un rapporto di collaborazione e un ciclo di feedback tra clienti, PM e ingegneria, ma tipicamente i PM sono al servizio dell’ingegneria in queste aziende.
- Pro: La tecnologia innovativa può offrire ai clienti cose di cui non sapevano nemmeno di aver bisogno. VMotion di VMware è stato un grande esempio di questo. Un ingegnere ha pensato che sarebbe stato bello farlo, un PM ha capito come monetizzarlo, ed è diventato un game changer da un miliardo di dollari per l’azienda.
- Con: Gli ingegneri inseguono la novità luccicante, sovra-architettano la soluzione, o iterano all’infinito, cercando la perfezione prima di ottenere il feedback del cliente. L’input del PM sulle priorità è ignorato, che a volte include i bisogni più elementari dei clienti.
- La partnership PM-ingegneria. In questi casi, c’è un forte yin-yang tra PM e ingegneria, con la scoperta congiunta, il processo decisionale e la responsabilità condivisa. Gli ingegneri si uniscono ai PM nei colloqui con i clienti, e i PM sono nelle riunioni di sprint per aiutare a sbloccare i compiti o chiarire i requisiti. Ma i due ruoli rispettano la linea dove uno inizia e l’altro finisce. I PM capiscono cosa viene codificato ma non dicono agli ingegneri come codificare, e gli ingegneri hanno empatia per i bisogni dei clienti ma lasciano la priorità ai PM.
- Pro: Un processo di prioritizzazione semplificato che valorizza il debito tecnico e i progetti idraulici; migliori processi di design che portano ad un’esperienza utente più positiva; team più performanti con una migliore velocità del prodotto, qualità e, tipicamente, clienti più felici.
- Con: L’innovazione rivoluzionaria può non essere approvata; il time-to-market può sembrare in ritardo (anche se direi che ciò che viene rilasciato è molto meglio allineato con le esigenze dei clienti e più probabile che sia scalabile con successo).
Sono chiaramente prevenuto a favore del terzo tipo di filosofia sul PM (come lo è il venture capitalist Fred Wilson), poiché ho sperimentato tutti e tre e ho trovato che lo yin-yang è più efficace. Ma questo non significa che gli altri siano particolarmente cattivi – dipende davvero dal tipo di prodotto che stai costruendo, dalla fase dell’azienda e da altro. Indipendentemente da ciò, quando si considera un ruolo di PM, la filosofia del PM nell’azienda potrebbe essere il fattore decisivo per l’idoneità al ruolo.
Fase dell’azienda. Il ruolo del PM in una startup è molto più probabile che sia responsabile di “tutte le cose”, mentre in un’azienda matura il suo ruolo sarà più chiaramente definito. (Il libro Product Leadership di Banfield, Eriksson e Walkingshaw ha una sezione che ha molti più dettagli su questo argomento)
- Startup. Oltre alla scoperta, definizione e spedizione, i PM possono anche essere responsabili del prezzo, del marketing, del supporto e potenzialmente anche delle vendite del prodotto. Questi PM prosperano in un ambiente scrappy e sono a loro agio con l’ambiguità e i frequenti cambiamenti di direzione mentre l’azienda lavora verso il product-market fit e impara ad operare su scala.
- Pro: I PM sono probabilmente più coinvolti nella strategia dell’azienda, si espongono alla leadership senior e al consiglio di amministrazione, sono in grado di correre più rischi e hanno un impatto maggiore. Hanno anche più influenza e autorità sulle risorse dell’azienda.
- Con: Di solito c’è poca o nessuna mentorship, modelli di ruolo o best practice all’interno dell’azienda. I budget sono tipicamente limitati, e i PM potrebbero non avere l’esperienza necessaria per avere successo in alcune delle cose che sono incaricati di fare.
- Azienda matura. Il PM può avere uno scopo più ristretto e avere colleghi che gestiscono i prezzi, le strategie di go-to-market e così via. Ed è probabile che facciano parte di un team più grande di product manager.
- Pro: I PM hanno più probabilità di avere mentori e modelli di ruolo, così come standard di sviluppo e best practice. La stretta associazione con un team di ingegneri può creare relazioni forti nel tempo, il che è ottimo per l’impatto a lungo termine e la crescita della carriera. E se il prodotto è adatto al mercato, c’è una base di clienti consolidata e una performance di base su cui lavorare, invece di tirare a indovinare fino a quando non si ottiene il risultato giusto.
- Con: I PM hanno meno esposizione alla strategia aziendale e sono solo una delle tante voci del cliente. Possono “perdersi” nel sistema e avere a che fare con più politica e budget ristretti.
Founder/CTO/CEO relationship with PM. Specialmente nelle aziende in fase iniziale, è importante sapere quanto il fondatore/CEO/CTO è coinvolto nel processo di produzione. Se sono profondamente coinvolti, il ruolo del PM può giocare più un ruolo di supporto, per dare corpo alle loro idee o convalidare i concetti con i clienti, piuttosto che concepire e guidare le proprie idee. Questo può essere molto divertente per alcuni PM che amano collaborare con i fondatori e i dirigenti di livello C e collaborare all’evoluzione del prodotto. Ma per altri PM, può essere molto frustrante se preferiscono prendere più proprietà della direzione del prodotto. Può anche essere impegnativo se i fondatori più tecnici o i C-levels preferiscono lavorare direttamente con gli ingegneri. Questo può lasciare i PM fuori dal giro o sminuiti (a volte involontariamente), causando non solo frustrazioni personali ma anche ritardi. Quando prendete in considerazione un ruolo di PM che può lavorare a stretto contatto con il team di leadership fondatore, assicuratevi di scoprire le loro aspettative sulla funzione di PM e decidete se questo è il giusto abbinamento con i vostri interessi.
Ci sono, naturalmente, molti altri fattori da considerare per qualsiasi ruolo, come il tipo di prodotto che state costruendo (B2B, B2C, industria), le persone con cui lavorerete, la cultura aziendale complessiva (diversa, inclusiva, orari di lavoro flessibili, cultura remota), e, naturalmente, la compensazione e i benefici. Ci sono anche molti articoli sull’assunzione di product manager per avere una prospettiva su ciò che i responsabili delle assunzioni stanno cercando – raccomando in particolare il pezzo del mio amico Ken Norton “How to Hire a Product Manager”. Comunque, se ti stai sforzando di essere un grande product manager, considera tutto quanto sopra prima di firmare il tuo prossimo lavoro. Sviluppare le competenze di base sarà un’attività continua per tutta la tua carriera, e sfruttare l’IE ti garantirà un’esperienza più positiva. Ma dove si lavora, come si lavora, e con chi si lavora e per chi si lavora determinerà in definitiva il vostro successo a lungo termine.
Una versione di questo articolo è apparsa per la prima volta sul sito dell’autore.