Este artigo é uma tradução adaptada de “Hiring a Head of Product“, escrito por Richard Mironov. Por ser um conteúdo de alto valor, consideramos uma boa ideia traduzi-lo para ajudar a comunidade brasileira de Produto a evoluir. Boa leitura!
Nas últimas três décadas, passei por 10 empregos em tempo integral e lidei com 180 clientes de consultoria, liderei equipes de produto 18 vezes (principalmente como Vice-Presidente Interino) e ajudei outras 12 empresas a contratar seus Heads de Produto. Esse pode ser o recorde para qualquer pessoa que não seja profissional de pesquisa. Nesse tempo, observei alguns padrões para fazer uma boa seleção de Heads de Produto e vim compartilhar quais são eles.
Alguns problemas que surgem frequentemente são:
- As equipes executivas não sabem o que Heads de Produto fazem, ou querem alguém que “torne o desenvolvimento mais eficiente”;
- Não valorizam a experiência na gestão de equipes de Produto. Em vez disso, elas dão muito peso às habilidades técnicas ou ao segmento de mercado que a pessoa vem;
- Cada departamento quer contratar de acordo com a própria régua. Os executivos de Vendas querem mais Heads de Produto para Vendas; os executivos de Desenvolvimento querem mais Heads de Produto de Engenharia; as equipes de Marketing querem uma pessoa de Marketing… Nenhum candidato passa em todos os times.
Vamos investigar isso mais a fundo.
O que compreende um título?
Primeiro, vejo que os títulos e funções em Produto variam muito entre as empresas: não há consenso mesmo dentro de um segmento. Então, nosso primeiro desafio é como denominar esse papel. Vamos definir uma pessoa “Head de Produto” como alguém que supervisiona diretamente uma equipe de Gerentes de Produto, cuidando também de contratação, atribuições, orientação e resolução de disputas de cross-product.
Na sua empresa, esses profissionais podem ser chamados de Chief Product Officer, VP Product, Director of Product Management ou Group Product Lead. Os Heads de Produto também podem gerenciar designers, Product Owners, Product Ops e Business Analysts, ou ainda, profissionais de Product Marketing.
Não estou incluindo funções que envolvem principalmente a gestão do desenvolvimento: VP de Engenharia, CTO, CIO, Diretor de Desenvolvimento, Gerente de Engenharia, Project Officer ou Líder de Transformação Agile. Se você estiver supervisionando 52 desenvolvedores e 4 Product Managers, sua atenção estará mais voltada para problemas de engenharia do que para problemas de Produto.
E muitos executivos nunca viram um bom gerenciamento de produtos. Eles vêm de grupos de serviços profissionais – que são todos realizados com base em contratos sob medida e gerenciamento de projetos. Ou empresas que não são de software – em que a TI é encarada como um centro de custos, em vez de ser o principal centro de lucro da empresa. Ou eles interpretam o fundador como um “crítico de produto de meio-período” – nesse caso, os desenvolvedores recebem ordens diretamente do CEO, sendo constantemente interrompidos e lidando com frequentes mudanças de prioridades. Ou eles passaram por transformações fracassadas de Waterfall para Agile – nesse caso, Product Owners trabalham em fábricas de recursos para implementar projetos fracos para executivos de negócios que não são técnicos.
Não admira que as pessoas estejam confusas, frustradas e não consigam encontrar a liderança de produto de que precisam. Gastamos nosso tempo discutindo sobre títulos ou remoendo falhas em toda a organização.
Experiência em liderança de Produto é essencial na hora de contratar um Head de Produto
Quando as empresas estão entrevistando candidatos para VPs de Vendas (também conhecidos como Chief Revenue Officer), elas buscam alguém com experiência prévia como vendedores e gestores de equipes de vendas.
Ao contratar um CFO (também conhecido como Head of Finance), as organizações perguntam sobre a experiência prévia no gerenciamento de fluxo de caixa, folha de pagamento e contas a receber. Os CFOs garantem que os funcionários sejam pagos e os executivos não descumpram a lei, então, pessoas sem experiência são contratações arriscadas.
Ao procurar um VP de Engenharia, as empresas querem alguém que construiu muitos softwares e gerenciou equipes de desenvolvimento. “Acho que criar softwares seria divertido” não é um forte argumento de venda.
Ao considerar as contratações de VPs de Marketing, as organizações olham para a experiência em posicionamento de marca, mensagens, funis de leads qualificados, engajamento nas redes sociais e estratégia de marketing. Os CMOs sabem que o marketing é mais do que redesenhar logotipos ou fazer testes A/B de e-mail.
No entanto, de alguma forma, esse pensamento se perde quando olhamos para as entrevistas e as descrições de cargos de Heads de Produto. Sempre falo sobre a necessidade de experiência em Produto para executivos da área. Exemplos de perguntas em entrevistas:
- Você já foi responsável por equipes de Gerentes de Produto? Quantas/há quanto tempo?
- Qual é o seu modelo de organização preferido para times de produto?
- Fale-me sobre produtos ou serviços que você gerenciou.
Sem uma estratégia de contratação clara e critérios específicos, os entrevistadores escolhem naturalmente os candidatos mais parecidos com eles. Os entrevistadores de vendas querem experiência em campo; os desenvolvedores fazem exercícios de codificação; as equipes de suporte se entusiasmam com os gerentes de produto que dizem que priorizam cada relatório de bug; o pessoal de finanças quer saber que podemos estimar o ROI em detalhes.
Essa situação pode ser evitada:
- Priorizando a experiência prévia em liderança de produto para avaliar os candidatos;
- Reduzindo a descrição do trabalho;
- Fazendo com que cada pessoa que participará da entrevista leia a descrição do trabalho;
- Designando a cada pessoa uma área para explorar com todos os candidatos.
Isso nos dá alguma base para comparação.
“Queremos um Head de Produto que impulsione a engenharia”
Muitos CEOs me dizem que a pessoa VP Product Management de alguma forma deve tornar o processo de desenvolvimento mais eficiente. Isso vem de um mal-entendido sobre como as pessoas de Produto e Engenharia trabalham juntas e de uma confusão entre “mais rápido” e o valor real para o cliente.
As equipes de Desenvolvimento não trabalham para o gerenciamento de produtos: elas se reportam a um Vice-Presidente de Engenharia ou outro executivo de desenvolvimento. E eles fazem a maioria das escolhas em relação a processos/ferramentas. (Os Gerentes de Produto podem ter opiniões fortes sobre Scrum vs. Kanban vs. XP; ou Jira vs. Asana vs. Pivotal Tracker; ou Selenium vs. LambdaTest vs. Ranorex; ou planning poker vs. snake sorts). Mas os desenvolvedores podem escolher. Nossas sugestões são apenas sugestões. Não podemos obrigar a equipe de engenharia a fazer o que pedimos, só podemos estimular o desejo de fazer algo.
A maior contribuição de Produto para a eficiência do desenvolvimento é reduzir as interrupções na sprint e diminuir a priorização de mais de 92% das solicitações que não são tão importantes quanto os 8% de demandas críticas que iremos resolver. Isso é contra-intuitivo para executivos de go-to-market, mas quanto mais sobrecarregamos o desenvolvimento, menos entregamos no final.
Cada compromisso inesperado com o cliente (“A BigCorp precisa de X e não será difícil, então vamos incluir essa demanda no contrato”) significa menos tempo para nossos projetos previamente acordados e menos dedicação dos nossos desenvolvedores. Metas estendidas podem motivar as equipes de Vendas, mas desanimar as equipes de Desenvolvimento.
Assim, os Gerentes de Produto aumentam a produtividade e a entrega, reduzindo quase todas as demandas surpresas. (Quem faz uma solicitação individual não tem a visão do todo, mas recebemos 10, 20 ou 50 novas solicitações por dia, cada uma de alguém que precisa que a sua demanda seja nossa nova prioridade número 1.)
E uma pessoa Head de Produto tem que aceitar as críticas do resto da equipe executiva, sabendo que cada time quer mais atenção da engenharia.
“Nosso produto é supercomplexo, então precisamos de uma pessoa especialista no assunto”
Eu ouço muito isso, desde produtos de machine learning a CRMs, sistemas de gerenciamento hospitalar, ferramentas de design, comércio eletrônico, aplicativos de namoro e segurança de rede. Mas quase nunca acredito nessa afirmação.
Percebo uma grande divisão entre produtos B2C e B2B e, consequentemente, entre os respectivos Gerentes de Produto. A maioria dos produtos B2C tem muitos usuários, ciclos de venda mais curtos/simples e nenhum cliente com poder de compra suficiente para nos manter reféns.
O comprador tende a ser o usuário e as histórias de valor não são submetidas à análise dos CFOs. Utilizando diferentes ferramentas e estratégias de negócios para produtos B2C versus produtos corporativos. Então, para empresas B2B, tenho a tendência de procurar pessoas com experiência em B2B.
Mas dentro disso, observo que Gerentes de Produto experientes podem aprender a maior parte do que precisam em um período de 1-2 meses.
- Os PMs de data warehouse podem acelerar a segurança da rede;
- O pessoal de CAD/CAM pode entender rapidamente os sistemas ERP;
- Especialistas em sistemas de contabilidade podem fazer a transição para RH/Sistemas de Rastreamento de Candidatos.
Como Head de Produto, talvez seja necessário estimular a equipe a sair do escritório (virtual). Esse primeiro mês não pode ser desperdiçado exclusivamente com análises internas ágeis ou em análises técnicas. Pelo menos metade do seu tempo precisa ser utilizado fazendo experimentações de mercados / usuários / concorrentes / pipelines de vendas / ROI do cliente e lucratividade da empresa / problemas de suporte / desafios de integração / ecossistemas.
Porque não importa o que pensemos, a menos que isso reflita o que realmente está acontecendo no mercado. Bons gerentes de produto confiam no mercado acima de seus preconceitos; bons Heads de Produto apostam no processo de continuous delivery do cliente.
Se o seu produto é tão complicado que Product Managers não conseguem aprendê-lo em 8 semanas, então você vai ter um enorme problema para que os clientes em potencial o entendam, comprem, usem e engajem.
Aqui está o que eu notei quando colocamos especialistas como Head de Produto:
- Eles se concentram em usuários avançados e em novos recursos complexos. Eles sabem como isso deve funcionar e já “foram o cliente”. Infelizmente, com isso, 95% do que os usuários reais experimentam se perde: integração difícil, fluxos de trabalho complicados, conhecimento presumido, mensagens inúteis ou pouco claras, exceto para outros especialistas. Muitas vezes, ouço culparem e envergonharem os usuários.
- Como eles são especialistas, há menos urgência em fazer descobertas e validações genuínas. Mercados mudam, concorrentes surgem, novos problemas aparecem, escolhas técnicas evoluem – o que nossos especialistas ignoram. Eles já sabem a resposta certa, então não há necessidade de confirmá-la. “Deixe-me explicar de novo por que os clientes realmente não querem o que estão pedindo.”
- Muitas vezes, especialistas vêm de uma experiência de usuário de longa duração. “Executei sistemas de análise de pacientes na Cleveland Clinic por 12 anos e sei o que os hospitais precisam”. Seu ponto de vista tende a ser antigo, rígido, ancorado em um pensamento único. Isso também prejudica uma habilidade central no gerenciamento de produtos: segmentar um mercado de maneira criativa para encontrar um segmento que precise do nosso produto.
Gerentes de Produto precisam ter sede de conhecimento e devem querer saber: o que há de novo acontecendo em todas as etapas, desde a necessidade do cliente até a ideação de um novo produto, as decisões técnicas, a geração de leads, a primeira venda e a reativação para um usuário que deu churn. E os Heads de Produto precisam se desafiar constantemente para atualizar suas observações.
“Priorização significa colocar nossa estratégia em uma planilha”
É raro encontrar uma empresa com uma estratégia específica e acionável que priorize o trabalho de produto. Às vezes, isso acontece porque as organizações adotam OKRs simplistas; às vezes, elas focam em muitos possíveis compradores e usuários; às vezes, as metas são apenas um acúmulo de objetivos departamentais que mistura de 60 itens de uma vez. A maioria não tem uma lista clara do que não fazer.
Diante de uma lista com 6 ou 13 ou 27 objetivos estratégicos, é muito difícil priorizar qualquer coisa. A maior parte do nosso backlog vai apoiar um objetivo ou outro. E cada departamento vai solicitar uma meta específica, relacionada aos seus objetivos.
E cada departamento quer todo o esforço do time de desenvolvimento. O suporte vive com bugs dos clientes o dia todo, portanto, espera todo o nosso esforço para corrigir problemas de P1/P2. As vendas são responsáveis pela nossa receita e assumem que 100% de cada sprint é para ajudar a fechar grandes negócios. O sucesso do cliente cuida de novas aquisições por meio do onboarding: portanto, nossos ciclos de engenharia deveriam ser dedicados à integração e à conversão de dados.
Os fundadores não-técnicos veem muita otimização incremental e pouca inovação. O Compliance quer manter nossos executivos dentro da lei, por isso considera os itens regulatórios como prioridade. A Engenharia sofre com problemas na arquitetura e ferramentas imperfeitas, então, quer colocar pelo menos 80% da nossa energia em refação.
Dá para notar que cada área tem um conjunto diferente de critérios, métricas, justificativas e histórias de valor. Esses elementos não são fáceis de comparar e nem de mudar no dia a dia, dependendo de quais clientes estão sendo considerados. Portanto, o processo envolve uma mistura de análise pura e logrolling interno. Nunca encontrei uma planilha que reflita tamanha complexidade.
O que significa que precisamos contratar Heads de Produto que tenham grandes habilidades de negociação, grande empatia e boas conexões. Manter a estratégia enquanto negocia com outros executivos (sem ser demitido) é uma habilidade sutil desenvolvida ao longo dos anos.
Além disso, precisamos que nosso Head de Produto capacite os Gerentes de Produto individualmente: cada um deve equilibrar interesses internos conflitantes enquanto entrega um produto vencedor e pelo qual muitos clientes pagarão. As pessoas que não são de Produto acham que isso é fácil; Heads de Produto experientes conseguem fazer com que o trabalho pareça simples.
Resumindo
Assim como esperamos que os executivos de vendas, de engenharia e de finanças tenham experiência em administrar organizações de vendas, engenharia e finanças, devemos contratar Head de Produto que tenha experiência em gerenciar equipes de produto.
Isso inclui o tempo de experiência como Gerente de Produto e a experiência em liderança: estratégia de portfólio, colaboração multifuncional, contratação/orientação de novos profissionais de produtos e EQ elevado para acalmar os executivos insatisfeitos. Melhor contratar alguém com experiência em Produto do que alguém que acha que o trabalho será moleza.
Conheça o Curso de Product Leadership
Já atua na área de Produto e deseja assumir cargos de liderança, gerir pessoas e influenciar diretamente na estratégia de produto da sua empresa? Ou ainda, já atua nessa função e quer seguir se qualificando na área? Então você precisa conhecer o Curso de Product Leadership!
O curso reúne um conteúdo aprofundado com mais de 25 horas de conteúdo gravado, feito para pessoas líderes ou seniores na área de Produto (mais de 3 anos de experiência).
Mais de 12 líderes renomados e com vasta experiência no mercado brasileiro compartilham seus aprendizados e cases, transmitindo as melhores práticas de gestão de pessoas e estratégia de Produto.
Bateu a curiosidade? Então acesse gratuitamente a ementa completa!
Leia também:
