Nella gestione del prodotto, è facile ritrovarsi a indossare il mantello dell’eroe. Ma se il vero percorso verso il successo e l’impatto andasse oltre il fascino di essere il salvatore di riferimento per il team?
In questo episodio, Hannah Clark è affiancata da Clement Kao—fondatore di Product Teacher—per approfondire le sfumature dell’eroismo nella gestione del prodotto ed esplorare strategie per responsabilizzare i team di prodotto in modo più sostenibile.
Punti salienti dell’intervista
- Il percorso di Clement dalla Management Console a Product Teacher [00:54]
- Il background di Clement è non convenzionale: inizia come consulente manageriale, poi diventa ricercatore UX, analista dati e infine product manager.
- Ha notato che molti altri affrontavano difficoltà simili nella gestione del prodotto, mancando di risorse e orientamento.
- Man mano che avanzava nella sua carriera, Clement si è reso conto di poter avere un impatto maggiore aiutando altri product manager ad avere successo.
- Questo lo ha portato a fondare Product Teacher, con l’obiettivo di supportare i product manager in tutte le fasi della loro carriera, dai principianti ai professionisti senior.
- Product Teacher ha supportato oltre 7.000 product manager in ambiti come l’ingresso nel settore, la crescita professionale e lo sviluppo di strategie e processi di prodotto.
- Ridefinire l’eroismo nella gestione del prodotto [02:44]
- Clement chiarisce che l’eroismo nella gestione del prodotto non è necessariamente negativo; dipende dalla frequenza e dal contesto in cui viene applicato.
- Ci si aspetta che i product manager prendano l’iniziativa e risolvano problemi quando serve, ma affidarsi troppo spesso all’eroismo può causare problemi.
- Un’eccessiva dipendenza dall’eroismo può portare gli altri membri del team a trascurare le proprie responsabilità, danneggiando l’organizzazione.
- Quando un product manager diventa l’unico eroe, si indeboliscono altre aree dell’organizzazione, rendendola dipendente da una sola persona.
- Ci dovrebbe essere equilibrio, con i product manager che intervengono solo quando è realmente necessario, non come routine quotidiana o settimanale.
- Se è richiesta spesso l’eroismo, ciò indica problematiche più profonde all’interno dell’organizzazione che vanno affrontate.
I product manager dovrebbero essere pronti ad intervenire quando necessario. Tuttavia, se questo diventa un evento frequente, potrebbero esserci problemi di fondo che richiedono attenzione.
Clement Kao
- Perché i Product Manager Finiscono per Ricoprire Troppi Ruoli [04:54]
- Clement spiega che molti product manager si ritrovano in posizioni da "eroe" a causa dei cambiamenti nella struttura del lavoro nel tempo.
- La cross-matrixizzazione delle responsabilità è diventata comune, con persone che supportano più iniziative o team contemporaneamente.
- La mancanza di chiarezza su chi dovrebbe occuparsi di compiti specifici porta a far ricadere tali compiti di default sul product manager.
- Le startup e i team più piccoli spesso mancano di linee guida chiare sulla distribuzione delle attività, portando i product manager ad assumersi varie responsabilità.
- Quando un product manager gestisce con successo un compito, si crea un ciclo auto-rinforzante per cui ci si aspetta che continui a farlo.
- Esempi includono product manager che si occupano indefinitamente di analisi, ricerche di mercato, discussioni con clienti o conversazioni di vendita.
- La tendenza si è intensificata nell'ultimo decennio, con i product manager sovraccaricati a causa della loro competenza percepita in vari ambiti.
- Identificazione e Risoluzione delle Debolezze Organizzative [06:58]
- Clement suggerisce che frequenti episodi in cui i product manager devono essere "eroi" possono indicare carenze organizzative.
- Azioni eroiche occasionali sono attese, ma se il modello si ripete spesso ciò suggerisce problematiche più profonde.
- Le organizzazioni che danno valore alle retrospettive dovrebbero utilizzarle per analizzare i problemi e prevenire ricorrenze.
- Se problemi simili si presentano ripetutamente, è fondamentale affrontare le cause alla radice per evitare che i product manager si trovino regolarmente a occuparsi di compiti fuori dal loro ambito.
- Retrospettive regolari dovrebbero aiutare a identificare e correggere i pattern di sovraccarico dei product manager o di assegnazione di compiti che non spettano loro.
- Retrospettive Efficaci: Uno Strumento per il Cambiamento Organizzativo [08:07]
- Clement sottolinea l'importanza delle retrospettive prive di colpe per affrontare questioni sistemiche.
- Sostiene la necessità di concentrarsi sul sistema, non sulle persone, durante le retrospettive.
- Utilizzando un esempio dal controllo del traffico aereo, illustra come i fallimenti raramente siano colpa di una sola persona ma piuttosto il risultato di problemi di sistema.
- Le retrospettive devono puntare a migliorare il sistema per prevenire i problemi invece che attribuire colpe.
- L'atteggiamento durante le retrospettive deve essere collaborativo, concentrandosi su come migliorare il sistema per tutti.
- L'obiettivo deve essere il miglioramento continuo, assicurando che il carico dei problemi non gravi sempre e solo sul product manager.
Un aspetto importante nella conduzione di una retrospettiva è garantire che rimanga priva di colpe, concentrandosi sul sistema e non sulle persone.
Clement Kao
- Casi Studio Personali e Organizzativi sulla Chiarezza dei Ruoli [11:15]
- Clement condivide una storia personale su un periodo in cui ha assunto troppe responsabilità operative di prodotto, ostacolando la crescita del team.
- Inizialmente pensava fosse suo dovere, come product manager, assicurare il successo del prodotto, ma in seguito si è reso conto che stava indebolendo i colleghi non delegando i compiti.
- Il suo manager è intervenuto e lo ha aiutato a riconoscere la necessità di delegare responsabilità ad altri membri del team per garantire la scalabilità e il successo a lungo termine.
- Fattori chiave per una risoluzione efficace hanno incluso il sostegno della leadership, il ripensamento delle responsabilità come opportunità di ownership e incontri regolari per garantire una transizione graduale.
- L'esperienza ha insegnato a Clement l'importanza di condividere le responsabilità e responsabilizzare i colleghi nella gestione autonoma dei propri compiti.
- Clement condivide anche un caso studio recente da una grande organizzazione dove il team di prodotto è passato dall’architettura di soluzioni al product management.
- Inizialmente, il team, costituito in gran parte da ex solution architects, faceva fatica a distinguere i propri ruoli, portando a sovrapposizioni e confusione.
- Il team di prodotto ha assunto involontariamente compiti da solution architect, ostacolando la scalabilità e il successo a lungo termine.
- Attraverso diversi confronti e discussioni, il team ha riallineato i ruoli, chiarendo che i product manager si concentrano sulla core product development mentre i solution architect si occupano delle soluzioni specifiche per i clienti.
- L’apertura del team ai feedback e la volontà di ridefinire fin da subito le relazioni hanno contribuito al loro successo.
- Questo approccio proattivo ha prevenuto problematiche a lungo termine e assicurato che ogni membro si occupasse di compiti rilevanti per il proprio ruolo, favorendo scalabilità ed efficienza.
- Clement condivide una storia personale su un periodo in cui ha assunto troppe responsabilità operative di prodotto, ostacolando la crescita del team.
- Mindset e Maturità: Navigare la Crescita Organizzativa [21:46]
- Rifletti regolarmente sul carico di lavoro personale per identificare attività che non sono in linea con le responsabilità core di prodotto. Riconosci le sensazioni di sovraccarico o frustrazione, che possono indicare disallineamenti nelle aspettative di ruolo.
- Informa il tuo manager sulle attività che consumano tempo e che non sono legate alle responsabilità fondamentali di prodotto. Presenta dati sulla suddivisione del tempo e sulle ragioni dello squilibrio di carico lavorativo. I manager traggono beneficio dalla consapevolezza di tali disallineamenti perché li aiuta a raggiungere efficacemente i metric del team.
- Collabora con il manager per identificare attività più adatte ad altri team. Comunica perché certi compiti dovrebbero essere trasferiti e come ciò contribuisce alla scalabilità organizzativa. Avvia conversazioni con i team rilevanti per facilitare il trasferimento delle responsabilità.
- Garantisci una transizione fluida dei compiti ai team appropriati. Fornisci il contesto necessario e supporto alle nuove squadre che assumono le responsabilità. Fai check-in regolari per assicurare l’integrazione e affrontare eventuali criticità.
- Ottieni un focus più pulito sulle responsabilità core di prodotto, ottenendo risultati più incisivi. Acquisisci tempo extra per ingaggiare profondamente clienti, design, ingegneria e strategie di business. Sperimenta maggiore chiarezza mentale e produttività delegando efficacemente i compiti non-core.
- Dedica tempo specificatamente alla strategia e alla pianificazione della sostenibilità del carico di lavoro. Adotta un approccio a due "personas", dove una è destinata all’esecuzione concreta delle attività e l’altra ad analizzare e pianificare. Riconosci l’importanza dei bisogni personali degli stakeholder per guidare pratiche di product management efficaci.
Conosci il Nostro Ospite
Clement Kao è il fondatore di Product Teacher, un’azienda di formazione sul product management che accelera il talento nel prodotto tramite workshop aziendali, video-corsi on-demand e executive coaching. Prima di fondare Product Teacher, Clement ha lanciato più di 10 prodotti multimilionari come group product manager in diverse aziende, guidando exit di successo per miliardi di dollari complessivi. I suoi articoli sono stati pubblicati su Amplitude, Mixpanel, Gainsight e altre principali testate del settore.
Una cosa che spesso i product manager dimenticano è che loro stessi sono stakeholder critici e non possono trascurare questo aspetto mentre svolgono il loro ruolo.
Clement Kao
Risorse da questa puntata:
- Iscriviti alla newsletter The CPO Club
- Collegati con Clement su LinkedIn
- Dai un’occhiata a Product Teacher
Articoli e podcast correlati:
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.
