Dovrebbero Esistere gli Eroi nel Product Management?

Leggi la Trascrizione:

Stiamo provando a trascrivere i nostri podcast con un software automatico. Perdonate eventuali errori di battitura, il bot non è corretto al 100%.

Hannah Clark: Prima di iniziare, vorrei chiarire esattamente cosa intendo per eroi nel product management. Non sto parlando di thought leader come Marty Cagan o Lenny Rachitski, sto parlando di TE. Parlo di quella persona su cui il tuo team di prodotto fa affidamento per salvare la situazione quando qualcosa va storto. Parlo dell’eroe che si occupa di mille cose, ma mai con un mantello. Parlo del motivo per cui non riesci a lavorare meno di 50 ore a settimana eppure senti di non aver fatto progressi rispetto alla settimana precedente.

E se ti riconosci in questa descrizione, buone notizie—l’ospite di oggi è Clement Kao, fondatore di Product Teacher. Avendo formato product manager in ogni contesto, da startup agli esordi a Fortune 500, ha visto tantissime dinamiche nei team di prodotto, inclusi casi che richiedevano veramente un “salvataggio”.

Stiamo per discutere perché essere l’eroe in un team di prodotto può essere un pericolo di per sé. E se ti ritrovi in ciò che diciamo, resta fino alla fine per scoprire come ottenere la forza “superumana” per cambiare davvero le cose. Partiamo subito.

Bentornati a Product Manager Podcast. Oggi sono seduta con Clement Kao. È il fondatore di Product Teacher.

Clement, grazie mille per essere con noi oggi.

Clement Kao: Sì, grazie davvero per avermi invitato.

Hannah Clark: Come sempre, partiamo dall’inizio. Potresti raccontarci qualcosa sul tuo percorso e su cosa ti ha spinto a fondare Product Teacher?

Clement Kao: Ottima domanda. In realtà all’inizio non ho lavorato subito nel product management dopo la laurea.

Inizialmente ho lavorato come consulente manageriale. Poi, in quel ruolo, sono diventato per caso un ricercatore UX. Da lì sono poi passato ad analista dati. E successivamente, sempre un po’ per caso, sono diventato product manager. Ho quindi un background molto atipico. Andando avanti con la mia carriera come product manager, iniziando come associate PM alla base della scala, poi PM, poi senior PM, group PM, fino a principal product manager.

Una cosa che ho notato è che tante altre persone affrontano difficoltà simili alle mie. In pratica, spesso non hai a disposizione le risorse giuste. Come si affronta un determinato problema? Come si supera uno specifico sbaglio? Cosa significano tutti questi termini e perché sono importanti?

Così, man mano che diventavo più senior come individual contributor, mi sono chiesto: come posso avere il massimo impatto possibile? Ho realizzato che il mio impatto più grande non era continuare a fare product per un’azienda, ma aiutare centinaia, se non migliaia, di altri product manager ad avere successo quando iniziano. Perché il passaggio può essere molto confuso, e poi seguirli nella loro crescita. Così ho deciso di fondare Product Teacher. Product Teacher ha aiutato più di 7.000 product manager ad avere successo sul lavoro, sia quando entrano per la prima volta in questo mondo, sia ottenendo promozioni, sia come head of product nel definire la strategia e processi chiari per tutti i team.

È stato un viaggio estremamente gratificante.

Hannah Clark: Bello. Sembra anche la parte più intenzionale del tuo percorso e non solo la...

Clement Kao: Sì, è l’unica cosa che non ho fatto per caso. Esatto.

Hannah Clark: Oggi esploreremo il concetto di eroismo nel product management, verso cui tu hai generalmente una posizione critica. Che cosa significa esattamente in questo contesto e come si manifesta secondo te nelle organizzazioni che hai seguito?

Clement Kao: Ottima domanda davvero. Da chiarire: non dico che l’eroismo sia totalmente negativo. Uno degli aspetti chiave del product management è che la responsabilità ricade su di te.

Sta a te assicurarti che il prodotto abbia successo, anche “sporcandoti le mani” quando serve. Che si tratti di non avere qualcuno per il QA e di dover testare le cose prima della produzione, o di aiutare se il designer è malato e c’è bisogno di sbloccare gli sviluppatori.

O se i clienti non comprendono una parte del prodotto e devi occuparti delle operations per assicurarti che le cose girino. Serve disponibilità. Ma il problema che vedo spesso è se l’eroismo diventa la modalità standard, invece che l’eccezione quando accadono imprevisti importanti.

Per essere chiari: un product manager deve saper intervenire quando serve, ma non può essere sempre la persona che fa tutto. Capita spesso che, definendo un PM come “eroe”, gli si facciano svolgere tante funzioni a scapito dei colleghi per far funzionare il prodotto. Così però il resto dell’organizzazione si indebolisce. C’è chi non fa il dovuto sul marketing di prodotto, chi manca su analisi, customer success o vendite.

Molte attività diventano meno solide e replicabili se tutto grava su una sola persona. E se quel product manager si ammala, va in ferie o lascia l’azienda, il team va in crisi.

In sintesi: sì, i PM dovrebbero saper intervenire all’occorrenza. Ma se succede ogni giorno o ogni settimana, probabilmente c’è qualcosa di più profondo da affrontare.

Hannah Clark: Possiamo immaginare le conseguenze logiche quando un PM si trova costantemente in questa posizione. Perché, secondo te, continuano ad esserci così tanti product manager in questa situazione?

Clement Kao: Domanda fantastica. Credo che spesso i product manager restino in questa posizione perché il mondo del lavoro è cambiato e tutti devono gestire tante cose in modo trasversale.

Prima magari un designer UX si occupava solo di una iniziativa. Ora può seguire cinque prodotti. Anche l’analista di business ora copre tanti team diversi.

Quindi, per via di questa trasversalità, è meno chiaro chi debba occuparsi di cosa. Quando le cose vanno male, non è chiaro chi debba intervenire, quindi di default tocca al PM.

Se fosse più chiaro che, in caso di X, si occupa Tizio, il PM non dovrebbe intervenire ogni volta. Ma con la crescita di startup tech, team piccoli e autonomi, spesso non ci sono linee guida su chi fa cosa.

Ogni volta che c’è incertezza, tocca al PM. E se lo fa una volta soltanto, poi diventa la norma: “Lo ha già fatto bene, facciamolo fare sempre a lui/lei.” Così ho visto product manager assumersi analytic, ricerche di mercato, conversazioni con i clienti, vendite e altro, all’infinito.

Ecco perché credo che questa dinamica sia diventata così diffusa nell’ultimo decennio.

Hannah Clark: Ci sono segnali o “red flag” che possono indicare fin da subito che un’organizzazione non protegge i suoi PM dal trovarsi nella posizione dell’eroe o non è pronta dal punto di vista dei processi?

Clement Kao: Sì, ottima domanda. Uno dei modi per rendersene conto è proprio osservare la frequenza con cui “devi” intervenire. Una volta capita, è normale. Ma se succede con regolarità—ogni mese, ogni rilascio, o ad ogni bug—è segnale di un pattern da indagare. Se capita due volte di fila, è ora di affrontare la questione.

Un’organizzazione attenta ai “retrospective” o che introduce questi momenti, dovrebbe chiedersi: cosa è andato storto? Se dopo il primo retro il problema si ripete, il retro successivo dovrebbe chiedersi: perché c’è un pattern? Così ci si accorge se i PM si occupano regolarmente di cose fuori ambito—non è il modello desiderato.

Hannah Clark: Parlare dei retrospective sembra quasi il “rimedio poco sexy” a questo problema…

Clement Kao: Verissimo. È proprio poco sexy.

Hannah Clark: Purtroppo. Qual è il processo per condurre un retro efficace che coinvolga tutti nel cambiamento necessario?

Clement Kao: È fondamentale che il retro sia “blameless”, senza cercare colpe, concentrandosi sul sistema più che sulle persone. Facciamo un esempio: c’è un cliente enterprise esasperato dall’esperienza prodotto. Un PM, che sa programmare, vede che gli altri ingegneri sono troppo occupati e realizza direttamente lui la “copy change” e la deploya.

Serve comunque un retro. Ma non deve partire con “L’ingegnere era troppo occupato, quindi ci ho pensato io”. Evitiamo il dito puntato.

Piuttosto: perché la segnalazione di questo cliente, fatta sei mesi fa, non è stata presa in carico subito? Perché abbiamo aspettato che fosse sul punto di annullare il contratto per intervenire?

Guardiamo la prospettiva del sistema: se ricapitasse, come potremmo comportarci meglio come PROCESSO e non come singoli?

Un esempio calzante negli ultimi tempi viene dal mondo del controllo del traffico aereo. Quando succede un incidente, anche se c’era un controllore presente, non è (quasi mai) tutta colpa sua. Ci sono una serie di fattori a monte e a valle. Non vogliamo un singolo punto di fallimento, vogliamo un sistema molto più robusto.

Quindi il retro deve essere: affrontiamo insieme questo, senza puntare il dito. Domandiamoci: cosa è andato storto nel sistema? Come possiamo migliorarlo per tutti la prossima volta? Così costruiamo un ambiente dove tutti possano supportarsi e nessuno, per default, si ritrova a dover essere l’eroe che “mergea” il codice o ferma un churn da solo. Se salvi il cliente una volta va bene, ma se ogni volta serve il PM, occorre ripensare tutto.

Hannah Clark: Ha senso. Doversi ingegnare a risolvere il problema, partendo dall’analisi, per trovare la soluzione. Dal tuo lavoro coi team di prodotto, hai visto aziende risolvere efficacemente questa situazione? Raccontaci qualcosa.

Clement Kao: Sì, ti racconto prima una storia personale. Mi è successo di occupami di tutte le attività di product ops quando non avrei dovuto. Una volta per un prodotto B2B SaaS di cui mi occupavo, avevamo lanciato una nuova verticale. Perché avevo già fatto ricerca clienti, conoscevo tutti i punti dolenti, scrivevo i release notes, preparavo guide... insomma, per i primi tre clienti andava bene. Ma arrivati a 70, non avevo alzato la mano ai 10 o 15 clienti dicendo “non è più il mio compito gestire ogni demo e formazione”.

Il mio pensiero era “sono il product manager, il successo dipende da me, lo faccio io”. Ma così toglievo opportunità a colleghi come customer success o product marketing, che invece avrebbero dovuto prendersi l’intero processo e anche una visione più ampia dei clienti. Per esempio, avremmo dovuto fare documentazione più completa, video, cose standardizzate.

Sono stato fortunato ad avere un manager fantastico: mi ha detto “Ti vedo sopraffatto e fai cose fuori dal tuo ruolo. Sì, la responsabilità è tua, ma così non costruiamo un sistema robusto per il futuro. Quando passeremo da 70 a 140 clienti, come pensi di fare?”

A quel punto abbiamo coinvolto tutti e spiegato: non stiamo dando più lavoro, ma più ownership. Dare spazio agli altri significa liberarli e responsabilizzarli, non scaricare un peso.

Due aspetti chiave di successo: 1) L’appoggio dei leader di prodotto, che dicono “queste cose NON sono responsabilità tua”. 2) Il framing: non è “ti do altri incarichi noiosi”, ma “ti diamo il controllo end to end di un processo, stiamo togliendo un’ingiustizia”.

Poi—verifica periodica, passaggio graduale (può servire un contatto ogni settimana/all’inizio). Non si butta la palla dall’altra parte, ma si fa insieme la transizione, valorizzando anche nuove idee di chi prende in mano il processo.

Hannah Clark: Se hai un esempio simile più recente, che aiuti a illustrare altri aspetti di questo tema...

Clement Kao: Sì, te ne racconto uno in corso. Sto seguendo una grande organizzazione dove il team prodotto è relativamente nuovo. Tutti arrivavano dal team “solution architecture”: in passato producevano soluzioni custom per ogni cliente. Ora l’obiettivo è standardizzare e costruire un prodotto scalabile.

Così alcuni solution architect sono stati messi nel nuovo team prodotto, per riorganizzare tutto verso le tecnologie riutilizzabili. Però, per via del background, finivano a fare ancora solution architecture durante ogni deployment, invece di concentrarsi solo sul core prodotto. Questo generava sovrapposizione di ruoli, un po’ di incertezza, e demotivazione nei solution architect che si sentivano esautorati.

Abbiamo impostato allora la separazione chiara: il PM si occupa del prodotto core, il solution architect della configurazione per il cliente. Questo passaggio ha richiesto qualche incontro, ma ha funzionato proprio perché sono stati aperti nel ricevere feedback. Meglio risolverlo subito, dopo meno di un anno, che dopo 3 anni e problemi radicati.

Così ora il product manager è responsabile del prodotto, i solution architect della soluzione specifica. Questo permette di lavorare a scalare, responsabilizzare tutti, e permette ai solution architect di mantenere il proprio ruolo e sviluppo.

Hannah Clark: Parlando di mindset e maturità organizzativa: quando un’organizzazione cresce, anche le responsabilità si complicano e la mole di lavoro può sopraffare. È difficile uscire dalla sensazione di essere costantemente “sommersi”, specie se già c’è atrofia. Come si trova la motivazione e si agisce per uscire da lì? E cosa possono aspettarsi al di là del tunnel chi si impegna a cambiare?

Clement Kao: Sì, domanda fondamentale. Per rispondere, parto dal basso: la prima cosa è riconoscere che si è davvero sommersi, spesso senza nemmeno rendersene conto. A volte lavori 70-80 ore e non ti fermi mai a riflettere sul perché. È utile allora prendersi 10 minuti a inizio o fine settimana per chiedersi: sto davvero facendo product, sto portando valore?

Se ti accorgi di occuparsi di mansioni che non sono core, puoi iniziare ad attivarti—ma serve anche il supporto del proprio manager. Spesso non sanno che stai spendendo tempo su task secondarie. Se glielo mostri (“spendo 10 ore a settimana su X che non dovrei”), può aiutare, perché anche i tuoi metric sono i loro. Non dà fastidio, anzi, è nell’interesse di tutti, perché così puoi tornare sui tuoi obiettivi e contribuire in modo più efficace.

Idealmente porta una lista: “queste attività dovrebbero stare su altri team perché porterebbero più valore/scalabilità”. Così puoi avviare con loro una redistribuzione più consapevole. Poi transizione graduale, momenti di confronto, fino al completo passaggio (che va monitorato all’inizio).

Cosa c’è in fondo al tunnel? Ritrovi il tempo per fare davvero product: conoscere i clienti, lavorare creativamente con design e sviluppo, sviluppare strategie di posizionamento, raggiungere nuovi segmenti e così via. Avrai la mente più libera, più energia per il lavoro fondamentale, e potrai crescere davvero.

Un consiglio in più, spesso trascurato dai PM: tendono a mettere sempre gli altri al primo posto e a trascurare il proprio tempo di auto-valutazione o strategia. Personalmente, un trucco che mi ha aiutato molto è “spezzare me stesso in due”. Da una parte Clement il PM che esegue; dall’altra “Richard”, il leader che esige un piano di sostenibilità. Blocco in agenda tempo per “Richard”, e così non posso trascurare l’aspetto strategico. Anche solo fingere che ci sia un “altro” stakeholder aiuta a darsi priorità.

Il PM deve ricordare che è lui stesso uno stakeholder fondamentale e non può trascurarsi. Questo approccio aiuta anche a redistribuire compiti e ad affrontare temi di crescita.

Hannah Clark: Amo i metodi anticonvenzionali, soprattutto se aiutano a dare valore a sé stessi e al contributo che si dà al team. È straordinario come la cosa più “eroica” che puoi fare in un’organizzazione sia aiutare gli altri a crescere, e di riflesso, crescere tu stesso.

Clement, grazie davvero di essere stato con noi, è stato davvero un piacere e i tuoi spunti sono sempre preziosi. Dove possono trovarti online?

Clement Kao: Ottima domanda. Mi trovate su LinkedIn: credo di essere l’unico Clement Kao. Altrimenti productteacher.com, tutto attaccato, senza trattini. È lì che passo il tempo per aiutare altri product manager ad avere successo.

Hannah Clark: Ottimo, ci vediamo lì.

Clement Kao: Grazie, è stato un piacere.

Hannah Clark: Grazie per averci ascoltato! Per altri insights, guide pratiche e recensioni di tool, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altre conversazioni come questa iscrivendoti a The CPO Club, ovunque ascolti i podcast.