Deverá Haver Heróis na Gestão de Produto?

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoe quaisquer erros tipográficos, pois o robô não está correto a 100% do tempo.

Hannah Clark: Antes de começarmos, quero esclarecer exatamente o que quero dizer com heróis na gestão de produto. Não estou a falar de líderes de opinião como Marty Cagan ou Lenny Rachitski; estou a falar de SI. Estou a falar da pessoa em quem a sua equipa de produto se apoia para salvar o dia quando algo se incendeia. Estou a falar do herói que usa muitos chapéus, mas nunca uma capa. Estou a falar da razão pela qual parece não conseguir trabalhar menos de 50 horas por semana e, ainda assim, sente que não está mais adiantado do que estava na semana anterior.

E, se isso lhe soa familiar, temos boas notícias — o convidado de hoje é Clement Kao, fundador da Product Teacher. Tendo orientado gestores de produto em todos os tipos de ambientes, desde startups em fase inicial até empresas da Fortune 500, já viu muitas dinâmicas de equipas de produto, incluindo muitas que precisavam de ser seriamente resgatadas.

Estamos prestes a discutir porque ser o herói de uma equipa de produto é, por si só, um perigo. E, se isto lhe diz alguma coisa, fique connosco até ao fim para descobrir como obter a força sobre-humana necessária para finalmente mudar as coisas. Vamos começar.

Bem-vindo de volta ao Podcast do Gestor de Produto. Hoje estou com Clement Kao. Ele é o fundador da Product Teacher.

Clement, muito obrigada por se juntar a nós hoje.

Clement Kao: Sim. Muito obrigado pelo convite.

Hannah Clark: Vamos começar como começamos sempre. Pode falar-nos um pouco sobre o seu percurso e sobre o que o levou a fundar a Product Teacher?

Clement Kao: Sim, excelente pergunta. Na verdade, quando terminei a universidade, não comecei na gestão de produto.

Comecei como uma consola de gestão. Depois, como consola de gestão, tornei-me acidentalmente investigador de UX. A partir daí, tornei-me acidentalmente analista de dados. E depois disso, tornei-me acidentalmente gestor de produto. Portanto, tenho um percurso muito pouco tradicional. À medida que continuava a progredir na minha carreira como gestor de produto, comecei como gestor de produto associado, na base da hierarquia, depois passei a gestor de produto, gestor de produto sénior, gestor de grupo de produto e gestor principal de produto.

Uma das coisas que reparei foi que havia muitas outras pessoas a debaterem-se da mesma forma que eu. Basicamente, não tinham necessariamente os recursos certos à mão. Como se resolve este problema específico? Como se ultrapassa este erro específico? O que significam todos estes termos diferentes e porque são importantes?

Por isso, uma das coisas que comecei a perguntar a mim próprio, à medida que me tornava cada vez mais sénior na minha carreira como colaborador individual em gestão de produto, foi: como posso causar o maior impacto possível? E comecei a perceber que causar o maior impacto não significava necessariamente continuar a fazer gestão de produto dentro de uma empresa. Na verdade, significava ajudar centenas, ou até milhares, de outros gestores de produto a serem bem-sucedidos quando se tornam gestores de produto pela primeira vez.

Porque essa pode ser uma transição muito confusa, e depois ajudá-los a progredir na carreira. Foi por isso que decidi fundar a Product Teacher. A Product Teacher já ajudou mais de 7000 gestores de produto a serem verdadeiramente bem-sucedidos no trabalho, quer estejam a entrar em produto pela primeira vez, quer estejam a ser promovidos, quer estejam, como responsáveis de produto, a definir a estratégia de produto e a garantir que temos processos realmente claros para todos os nossos colegas, entre outras coisas.

Tem sido uma jornada incrivelmente gratificante.

Hannah Clark: Muito bem. E parece que esta foi a parte mais intencional do seu percurso profissional, e não a…

Clement Kao: Sim. Foi a única coisa que não fiz por acidente. Sim, sim.

Hannah Clark: Hoje vamos explorar a ideia de heroísmo na gestão de produto, à qual parece opor-se um pouco. Para sermos claros, o que significa isso neste contexto e como vê essa situação manifestar-se nas organizações com que trabalhou?

Clement Kao: Sim, excelente pergunta. Há algo que é importante esclarecer: não estou a dizer que o heroísmo seja totalmente negativo. Uma das características fundamentais de ser gestor de produto é que a responsabilidade final é sua.

É da sua responsabilidade garantir que o produto é bem-sucedido e, sabe, está disposto a arregaçar as mangas para fazer o que for necessário. Quer seja porque não temos uma pessoa de garantia de qualidade e precisamos subitamente de garantir que tudo é devidamente testado antes de entrar em produção; quer seja porque o nosso designer está doente e precisamos realmente de fazer avançar as coisas para desbloquear os nossos engenheiros.

Quer seja porque os nossos clientes estão a ter dificuldades em compreender uma parte do produto e precisa de assumir o papel de operações de produto para o implementar e garantir que as pessoas são bem-sucedidas. Seja o que for, o gestor de produto tem de ser capaz de intervir. Mas o problema fundamental que vejo muitas vezes no heroísmo na gestão de produto surge quando este é tratado como algo que se deve fazer o tempo todo, em vez de algo que só se deve fazer quando surge uma exceção muito, muito específica.

Para sermos claros, um gestor de produto deve, sim, ser capaz de intervir e fazer com que as coisas aconteçam quando necessário, mas não deve ser a pessoa que faz tudo o tempo todo. Muitas vezes, quando as pessoas dizem: “Este gestor de produto é um verdadeiro herói”, o que está realmente a acontecer é que essa pessoa está a retirar muitas das funções profissionais a outros colegas para fazer o produto funcionar.

Isso faz com que o resto da organização atrofie. Há pessoas que deixam de fazer necessariamente o que é preciso do ponto de vista do marketing de produto, da análise de produto, do sucesso do cliente ou das vendas ao cliente.

Todas estas áreas começam a tornar-se muito menos fortes e muito menos repetíveis quando se depende de uma única pessoa para fazer tudo. Já vi isto acontecer à minha volta. Quando esse gestor de produto adoece, vai de férias ou sai da organização, toda a gente fica numa situação muito complicada.

O que quero esclarecer é que, naturalmente, os gestores de produto devem estar dispostos a assumir responsabilidades quando surge uma necessidade. Mas, se essa necessidade surge diariamente ou semanalmente, provavelmente existe algo mais profundo que precisa de ser resolvido.

Hannah Clark: Sim, e penso que conseguimos imaginar algumas das consequências lógicas de um gestor de produto estar sempre nessa posição. Mas porque acha que ainda existem tantos gestores de produto nessa situação?

Clement Kao: Excelente pergunta. Penso que, muitas vezes, os gestores de produto continuam nessa posição porque a forma como o trabalho mudou ao longo do tempo significa que todos têm de conseguir lidar transversalmente com muitas coisas diferentes o tempo todo.

No passado, poder-se-ia dizer: “Bem, tem um designer de UX e ele está apenas concentrado numa iniciativa.” Agora vemos que essa pessoa pode estar a apoiar cinco produtos. Pode haver alguém que deveria concentrar-se num conjunto central de iniciativas e que agora apoia sete equipas diferentes.

Por causa desta colaboração transversal, torna-se muito menos claro quem deve assumir a responsabilidade. Quando as coisas correm mal, não é claro quem deve intervir. E, como não é claro, por defeito o gestor de produto tem de intervir.

Se houver mais clareza — “Quando este tipo de coisa acontece, é esta a pessoa que deve tratar dela” — então o gestor de produto não precisa de intervir. Mas, com o crescimento das startups tecnológicas e de equipas muito mais pequenas e autónomas, por vezes não existem orientações claras sobre quem deve fazer o quê.

Assim, sempre que pensamos: “Não temos a certeza de quem deve fazer isto”, passa a ser responsabilidade do gestor de produto. E, assim que o faz uma vez, cria-se quase um ciclo de autorreforço: “O gestor de produto já fez isto antes e fê-lo muito bem. Foi muito melhor do que eu teria feito. Então porque não o deixamos fazer novamente da próxima vez?”

É por isso que vejo esta situação a acontecer cada vez mais na última década.

Hannah Clark: Diria que existem sinais ou indícios precoces de que uma organização não fez o trabalho necessário para proteger adequadamente os seus gestores de produto de terem de ser os heróis, ou de que simplesmente não se preparou do ponto de vista dos processos?

Clement Kao: Uma forma de pensar nisso é que se reconhece quando acontece. Se precisar de intervir uma vez, tudo bem; isso é totalmente esperado. Mas, se notar que está a intervir com bastante frequência — quase todos os meses, sempre que lançamos algo, sempre que há um erro —, então existe um padrão.

Se acontecer duas vezes, se o mesmo tipo de situação ocorrer duas vezes seguidas, provavelmente é preciso ter uma conversa mais profunda. Se está numa organização que valoriza retrospetivas, deve utilizá-las para discutir: “Porque é que este problema aconteceu?”

Idealmente, se fizer isso da primeira vez, o problema não deverá repetir-se. Se acontecer uma segunda vez, a retrospetiva deve incluir a pergunta: “Porque existe este padrão?” Isso deverá ajudar a identificar que as pessoas de produto estão a fazer coisas fora do âmbito das suas responsabilidades regularmente, o que não queremos.

Hannah Clark: Quando se trata de realizar estas retrospetivas, percebo que esta parece ser uma solução pouco apelativa para um problema deste tipo.

Clement Kao: É muito pouco apelativa. Sim.

Hannah Clark: Infelizmente. Que processo deve utilizar um gestor de produto para realizar uma retrospetiva realmente adequada, que consiga envolver todos na implementação das mudanças necessárias para resolver uma situação destas?

Clement Kao: Uma das coisas realmente importantes é garantir que a retrospetiva não atribui culpas e que falamos sobre o sistema, não sobre as pessoas. Não queremos que a retrospetiva comece com: “Este engenheiro estava tão ocupado que não conseguiu fazer isto e, por isso, tive de o fazer.”

Em vez disso, deve começar com algo como: “Porque é que, quando este cliente levantou o problema há seis meses, não prestámos mais atenção? Porque esperámos até ele ficar muito frustrado e estar prestes a cancelar o contrato para o gestor de produto intervir?”

É preciso afastar-nos da culpa individual e perguntar: “Se esta situação voltasse a acontecer, o que poderíamos ter feito melhor enquanto sistema e enquanto processo?”

O mais importante é a mentalidade: estamos a passar por isto juntos. Não estamos a apontar dedos nem a dizer que uma pessoa específica é culpada e que a sua carreira está em risco. Vamos auditar o sistema. O que correu mal no sistema? Como podemos torná-lo um pouco melhor para todos nós da próxima vez?

Isto pode ser extremamente poderoso para garantir que temos as pessoas de apoio e os processos de suporte adequados, em vez de ser sempre o gestor de produto a integrar código ou a impedir que um cliente abandone a empresa.

Hannah Clark: Faz sentido. É necessário fazer uma espécie de engenharia inversa do problema e encontrar a solução a partir desse ponto de partida. No seu trabalho com equipas de produto, já viu pessoalmente alguma organização resolver com sucesso um problema destes?

Clement Kao: Sim. Vou começar por contar uma história sobre mim. A certa altura, acabei por ser a pessoa responsável por fazer todo o trabalho de operações de produto, quando não deveria ter sido.

Num dos produtos que geria numa empresa de software B2B, estávamos a lançar um produto totalmente novo, adjacente ao nosso produto existente. Como eu tinha feito toda a investigação junto dos clientes, compreendia os seus problemas e era responsável por garantir que tínhamos as notas de lançamento, as gravações e tudo o que fosse necessário para que os clientes tivessem sucesso na configuração e utilização do produto.

Isso funcionava quando tínhamos apenas três clientes. Mas, quando chegámos ao cliente número 70, percebi que tinha cometido um erro: não tinha levantado a mão muito mais cedo, talvez junto do décimo ou do décimo quinto cliente, para dizer: “O meu trabalho não é fazer todas as demonstrações e todas as formações para todos os clientes. Isso deve ser responsabilidade de outra pessoa.”

Na altura, pensei: “É o meu trabalho. Sou gestor de produto e tenho de garantir que o produto é bem-sucedido, aconteça o que acontecer.” Não percebi que estava a retirar uma oportunidade às pessoas do sucesso do cliente ou do marketing de produto para terem uma visão completa do que os clientes estavam a ver e para melhorarem essa experiência.

Com as melhores intenções, estava a prejudicar os meus colegas. Não lhes estava a dar a oportunidade de assumirem algo de ponta a ponta. Por isso, quando alguém dizia: “Clement, estou a trazer um novo cliente para este produto que gere. Não sei como configurar isto”, eu explicava tudo individualmente.

Na realidade, alguém deveria ser responsável por uma documentação mais abrangente, por vídeos, capturas de ecrã, perguntas de qualificação e um processo de entrada para o momento de integração de um cliente.

Tive a sorte de trabalhar com um diretor de produto extraordinário. Ele disse-me: “Clement, parece que estás um pouco sobrecarregado e estás a fazer coisas que tecnicamente não são da tua responsabilidade.” Eu respondi: “Sim, mas a responsabilidade final é minha.”

Ele disse: “Isso é verdade, mas o que estás a fazer impede-nos de criar um sistema robusto para apoiar os clientes a longo prazo. Conseguiste apoiar-nos de um a dez clientes, mas estás no limite com 70 e queremos duplicar para 140 no próximo ano. Como vais fazer isso?”

Foi uma observação justa. A partir daí, reunimos todas as partes envolvidas e discutimos quem deveria assumir cada responsabilidade. Não se tratava de atribuir mais trabalho a alguém, mas de lhe dar mais autonomia e a possibilidade de controlar todo o processo de ponta a ponta.

Uma das coisas fundamentais foi ter o apoio das lideranças de gestão de produto. Se a equipa de liderança disser simplesmente: “Vai lá fazer isso”, é muito difícil transferir a responsabilidade para quem realmente deve assumi-la.

A segunda parte foi a forma de apresentar a mudança. Não se trata de dizer: “Estamos a dar-vos mais trabalho e este trabalho não é divertido.” Trata-se de dizer: “Queremos dar-vos mais responsabilidade. Queremos que possam controlar todo este processo. Estávamos injustamente a retirar-vos essa oportunidade.”

Depois, é necessário fazer acompanhamento regular. No início, talvez seja preciso reunir todas as semanas ou de duas em duas semanas: “Como está a correr? Que informação preciso de transferir? O que eu fazia no passado e que agora passará a ser feito por vocês?”

O que não queremos é simplesmente atirar o trabalho para o outro lado e esperar que as pessoas saibam imediatamente o que fazer. Somos todos colegas de equipa e estamos a fazer uma transição. É importante garantir que compreendemos o que acontecia antes e decidir como queremos incorporar isso no futuro.

Hannah Clark: Se tiver outro exemplo, talvez mais recente, que enquadre esta situação, gostaria de o ouvir. Gosto muito da forma como apresenta isto como uma devolução de autonomia à equipa e uma partilha da carga de trabalho.

Clement Kao: Tenho um caso muito recente. Estou a trabalhar com uma organização de grande dimensão onde a equipa de produto é relativamente nova. Muitos dos seus membros trabalhavam anteriormente quase como arquitetos de soluções.

A organização tinha uma equipa de TI que criava soluções personalizadas para cada cliente, por isso não havia um produto escalável. A liderança decidiu criar uma equipa de produto porque percebeu que as soluções personalizadas tinham muitas semelhanças e que era necessário construir um produto robusto e escalável.

Alguns membros da equipa de arquitetura de soluções passaram para a área de produto e começaram a analisar como transformar tudo numa tecnologia escalável, em vez de continuarem a criar soluções individuais.

No entanto, devido à sua experiência anterior, a equipa de produto continuava a fazer trabalho de arquitetura de soluções. Quando estavam a definir uma solução de produto, os arquitetos de soluções, que eram os seus clientes internos e trabalhavam diretamente com os clientes, acabavam por perguntar: “O que estou eu a fazer?”

A equipa de produto estava a fazer simultaneamente arquitetura de soluções e gestão de produto. Foi necessário explicar que o gestor de produto deve concentrar-se na construção de uma plataforma robusta e que o arquiteto de soluções deve adaptar essa plataforma às necessidades específicas de cada cliente.

Desta forma, afastamo-nos de uma relação individual entre um gestor de produto e um cliente, que não é escalável, e passamos para um modelo de um para muitos. Um gestor de produto gere o núcleo do produto e cada arquiteto de soluções pode estabelecer uma relação individual com os clientes.

Foi necessário ter várias conversas com toda a equipa. É importante reconhecer que todos querem fazer um bom trabalho, mas também é necessário recordar que, se retirarmos aos arquitetos de soluções a capacidade de encontrar soluções para os clientes, não teremos tempo para construir a base tecnológica que permitirá a toda a equipa trabalhar mais depressa no futuro.

A equipa percebeu rapidamente a mensagem e redefiniu a relação. Foi ótimo identificar o problema quando a equipa tinha menos de um ano, em vez de esperar três anos até a situação ficar cristalizada e depois ter de reequilibrar tudo.

O gestor de produto é responsável pelo produto e os arquitetos de soluções são responsáveis pelas soluções. O gestor de produto não precisa de ser o herói em cada implementação para cada cliente.

Hannah Clark: Quero falar um pouco mais sobre essa ideia de mentalidades, mas também sobre a maturidade de uma organização e o impacto que isso tem na forma como as coisas funcionam. À medida que uma organização amadurece, as funções e os processos tornam-se mais complexos e a sobrecarga instala-se. Podemos ficar presos numa situação que parece insustentável, mas também parece ser a única forma possível de trabalhar.

Para alguém que já está numa situação destas, que inadvertidamente contribuiu para a atrofia da organização e se sente sobrecarregado com responsabilidades que tecnicamente não lhe pertencem, que luz ao fundo do túnel pode esperar se fizer o trabalho necessário para se libertar? E como pode defender-se numa organização que está nessa fase?

Clement Kao: Para começar, é necessário reconhecer que está sobrecarregado de uma forma que não tinha escolhido. Muitas vezes essa perceção nem sequer acontece porque está demasiado ocupado. Está a trabalhar 70 ou 80 horas por semana e não tem tempo para pensar: “Isto não parece gestão de produto.”

É muito útil reservar dez minutos no início ou no fim da semana para refletir: “Como me sinto em relação ao trabalho que estou a fazer? O que estou a fazer é realmente produto? Estou a influenciar as métricas que deveria influenciar? Há coisas que estou a fazer que não representam um valor elevado, mas que, por alguma razão, parecem ser da minha responsabilidade?”

Essa reflexão pode ajudá-lo a reconhecer a situação. Talvez pensasse que o seu trabalho era compreender o problema do cliente, trabalhar com design e engenharia para criar uma solução e colaborar com a empresa para a lançar. Se agora está a fazer muitas outras coisas, precisa de perceber o que se passa.

Depois, é importante obter o apoio do seu responsável. Muitas vezes, os responsáveis não sabem que está a fazer todo esse trabalho, não por culpa própria, mas porque têm as suas próprias métricas, gerem várias pessoas e têm outras responsabilidades.

Quando lhes disser: “Passo dez horas por semana a fazer isto”, é provável que respondam: “Porquê? Gostava que me tivesses dito mais cedo, porque isso não é da tua responsabilidade.” Ao mostrar que está a gastar tempo em atividades que não estão alinhadas com as suas métricas nem com as do seu responsável, está a ajudá-lo a ser mais eficaz.

Depois de estarem alinhados, podem trabalhar com outras equipas para identificar o que lhes pertence. Pode estar a fazer desenhos de UX e esquemas quando existe uma equipa de design, ou consultas SQL pontuais quando existe uma equipa de análise. Essa equipa pode criar um painel que automatize o processo e beneficie toda a organização.

Quando começa a transferir responsabilidades, deve fazer verificações frequentes e reduzi-las gradualmente. É importante garantir que as outras pessoas se sentem preparadas, compreendem o contexto e têm as condições necessárias para serem bem-sucedidas.

No fim do processo, terá muito mais tempo — o tempo que deveria ter tido desde o início — para se dedicar ao trabalho central de produto: compreender os clientes, colaborar criativamente com design e engenharia, criar soluções agradáveis e escaláveis e gerar valor a longo prazo.

Terá também mais disponibilidade para trabalhar com a empresa na estratégia de posicionamento e entrada no mercado, perceber como se diferenciar, garantir o sucesso dos clientes e identificar novos segmentos.

Sei que é difícil, porque passei por isso. Mas é muito valioso. Consegui criar produtos com um impacto muito maior e compreender os meus clientes de forma muito mais profunda, porque finalmente tinha tempo para me envolver.

Outra sugestão importante é não se desvalorizar. Os gestores de produto querem muitas vezes que as outras pessoas sejam bem-sucedidas e acabam por se colocar em segundo plano. Em vez de reservar dez minutos para pensar na semana e decidir o que pode delegar, usam esse tempo para criar um plano de lançamento ou limpar a documentação de engenharia.

Uma técnica que achei extremamente útil foi dividir-me em duas pessoas. Existe o Clement gestor de produto, que executa o trabalho, mas também existe uma outra persona: o líder de produto. Esse líder exige que, na semana seguinte, eu tenha um plano para trabalhar de forma sustentável.

No meu caso, o meu segundo nome é Richard. Por isso, dizia: “O Richard, executivo de produto, espera que na próxima semana tenhas um plano para trabalhar de forma mais escalável.” Isso obrigou-me a reservar tempo para rever o plano e garantir que estava a fazer progressos.

Foi muito útil deixar de pensar que estou sempre a executar e reconhecer que também sou responsável pela estratégia. Sou igualmente uma parte interessada e não posso negligenciar as minhas próprias necessidades enquanto gestor de produto.

Hannah Clark: Adoro uma técnica pouco convencional, especialmente uma que nos permite tornar explícito o nosso próprio valor e o nosso contributo para a equipa. É incrível pensar que a coisa mais heroica que podemos fazer numa organização é capacitar as outras pessoas e, por consequência, também a nós próprios.

Clement, muito obrigada por se juntar a nós. Foi fantástico. Aprecio sempre as suas perspetivas e penso que tem muito para oferecer nesta área. Onde é que as pessoas podem acompanhá-lo online?

Clement Kao: Podem encontrar-me no LinkedIn. Penso que sou provavelmente o único Clement Kao. Também podem visitar productteacher.com. Sem espaços nem hífenes. É sobretudo aí que estou e onde ajudo outras pessoas de produto a serem bem-sucedidas.

Hannah Clark: Excelente. Encontramo-nos por lá.

Clement Kao: Obrigado pelo convite.

Hannah Clark: Obrigada por nos ouvirem. Para obter mais perspetivas, guias práticos e análises de ferramentas, subscreva a nossa newsletter em theproductmanager.com/subscribe. Pode ouvir mais conversas como esta subscrevendo o The CPO Club, onde quer que ouça os seus podcasts.