3 Estruturas de um Time de Produto - Vida de Produto
Escalar uma equipe de produto bem-sucedida exige mais do que contratar novos gerentes de produto (e não tem estruturas de um time de produto pré definidas). Você precisa considerar a visão macro – como todos os indivíduos da sua equipe trabalharão juntos? e como você pode ajudá-los a operar de forma eficiente e sem fricção?
É aqui que a importância de saber como estruturar seu time de produto. Dar à sua equipe pelo menos alguma estrutura à medida que você expande ajudará a garantir que sua organização divida funções e habilidades da maneira mais eficaz possível. Nesse artigo vou listar as 3 estruturas de time um de produto mais comuns
Mesmo que atualmente sua empresa tenha apenas um gerente de produtos, você ainda deve ter uma estrutura em mente para quando for a hora de escalar você esteja pronto.Existem várias maneiras de estruturar equipes de produtos que já funcionaram para outras empresas. Neste artigo, discutiremos várias delas, além de como escolher a melhor estrutura para as necessidades da sua empresa.
3 maneiras de estruturar seu time de produtos
1. Um gerente de produto por produto (ou feature)
2. Os gerentes de produto são divididas de acordo com suas habilidades
3. Os gerentes de produto trabalham com uma equipe multifuncional
Por que sua equipe de produtos não deve se reportar à engenharia
Conclusão: você precisa reestruturar seu time de produtos
Essa é uma das maneiras mais diretas de desenvolver uma equipe de produtos. Cada produto ou feature (se as features individuais forem grandes e complexas o suficiente) obtém seu próprio gerente de produto.
Sob essa estrutura, um gerente de produto será responsável por todos os aspectos estratégicos de um determinado produto. Isso pode incluir pesquisa de mercado, previsão, orçamento, priorização de features, trabalho com as equipes de marketing e vendas em mensagens e, é claro, a supervisão do desenvolvimento de produtos.
Dentro dessa estrutura, você ainda terá outras decisões a tomar. Por exemplo:
Quantos desenvolvedores e designers você atribuirá a cada gerente de produto (em outras palavras, a cada produto ou feature principal)?
Quanta autonomia esses PMs terão? Eles precisarão executar todo o trabalho de um executivo ou você permitirá que eles divulguem seu trabalho diretamente no mercado?
Onde esses PMs se reportarão? O chefe de marketing? Você criará uma posição de produto de nível sênior, como um diretor de produto ou vice-presidente de produto?
Em minha experiência conversando com muitas empresas que estruturaram suas equipes de produtos dessa maneira, o arranjo mais bem-sucedido é criar uma organização de produtos autônoma liderada por um vice-presidente de produto ou diretor de produto.
Importante: Apesar de poder ter um gerente de produto por feature, você NÃO quer um "time de feature", mas sim um time de produto!!
Sob essa estrutura de time de produtos, você aproveitará os diferentes conjuntos de habilidades de seus gerentes de produtos em vários produtos.
Alguns exemplos de como essa relação iria funcionar:
Um gerente de produto pode liderar a pesquisa de mercado e o desenvolvimento de conhecimentos sobre as personas dos usuários em toda a sua linha de produtos.
Outro PM será o responsavel de fazer o orçamento de todo o portfólio e trabalhará com a equipe de desenvolvimento na alocação de recursos e cronogramas para todos os produtos.
Como isso pode ser na prática? Um modelo é criar uma equipe de produtos equilibrada, composta por um gerente de produtos comerciais, um gerente técnico de produtos, um design de produtos e um gerente de produtos de growth.
Vantagem: Essa estrutura de time de produtos pode funcionar bem para algumas empresas, porque elas podem desenvolver altos níveis de conhecimento em varios disciplinas e em muitos aspectos de seus produtos e mercado.
Desvantagem: No entanto, um risco de usar esse modelo, é que se um gerente de produto for embora, toda a equipe poderá ficar sem o conhecimento de domínio que o PM tinha. Isso pode acabar prejudicando todos os produtos, até que a empresa consiga substituir a experiência do gerente de projetos.
O melhor exemplo que vi dessa estrutura de equipe de produtos é o squad popularizado pelo Spotify. Até escrevi sobre como o modelo de squad do Spotify poderia ajudar a melhorar seu desenvolvimento.
Esse tipo de equipe de produto é multifuncional, o que significa que cada equipe consiste em um pequeno grupo de desenvolvedores e um dono do produto (PO). Essa equipe trabalhará em uma área funcional específica da linha de produtos – o que significa que: eles desenvolverão conhecimentos que podem atender a vários produtos, em todo o portfólio de produtos da empresa.
Essas características podem ser aplicadas a diferentes tipos de times de produtos. Mas o que diferencia o modelo de squad é que cada um deles tem autonomia para lançar seu trabalho no mercado. Não é necessária a aprovação da superiores (ou outros stakeholders). Sem burocracia. O squad desenvolve um novo código, o testa até que a equipe esteja satisfeita e o envia ao produto ativo.
Você pode encontrar outro exemplo desse modelo na estrutura de equipe "duas pizzas" da Amazon. O objetivo da Amazon é manter suas equipes internas enxutas e capazes de se mover rapidamente. O nome vem da ideia de que nenhuma equipe deve ser tão grande a ponto de que duas pizzas não seria o suficiente para alimentar a todos em uma reunião ou evento social.
Com a Amazon, esse modelo de duas pizzas se aplica a todas as equipes internas, não apenas ao gerenciamento de produtos. E essas equipes não são nem de perto, tão autônomas quanto os squads do Spotify. Muitas vezes, eles ainda precisam obter aprovação de um superior antes de seguir adiante com uma ideia.
Mas os princípios gerais permanecem os mesmos: mantenha suas equipes o menor possível, com as habilidades e recursos necessários para realizar o trabalho.
Isso acontece frequentemente (é um erro bem comum) em empresas onde os fundadores e executivos são engenheiros. Como essas empresas geralmente são focadas em engenheiros, instintivamente colocam o gerenciamento de produtos em engenharia. E na maioria dos casos, isso é um grande erro.
Colocar o gerenciamento de produtos no time de engenharia é um erro
Certamente, muitos engenheiros que se tornaram empreendedores construíram empresas de sucesso. Um dos motivos do sucesso é que eles entenderam o valor da tensão entre a engenharia e o gerenciamento de produtos. Esse entendimento garante que o produto se beneficie de diferentes pontos de vistas, vindos de equipes que estejam defendendo o que acreditam ser o melhor para a empresa.
Mas uma empresa orientada para a engenharia – acima, digamos, do marketing – corre o risco de se tornar muito introspectiva. Essa empresa pode por exemplo, se concentrar na elegância técnica do seu produto, em vez de saber se esse produto pode atingir um ajuste no mercado.
Como qualquer empresa ágil sabe, o objetivo não é acertar o produto na primeira tentativa. O objetivo é divulgar algo, aprender o que seus usuários gostam e melhorar o produto.
O mesmo vale para estruturar sua equipe de produtos. Não se preocupe em encontrar o modelo perfeito logo de cara. Como descobriu a empresa de gerenciamento de mídia social Buffer, sua primeira estrutura de equipe de produto pode não funcionar. (O mesmo vale para o seu segundo e talvez até o terceiro.) De fato, o Buffer mudou sua estrutura quatro vezes!
Portanto, esteja preparado para que a estrutura da sua equipe de produtos mude à medida que suas necessidades evoluem com o tempo. Mas por enquanto, com base no tamanho, na cultura, no portfólio de produtos e em outros fatores da sua empresa, pense nas 3 estruturas de times de produto acima e escolha a que achar mais apropriada para seu momento. Se funcionar, ótimo. Mas se não der, tudo bem. Sua próxima abordagem será melhor (O importante é sempre tentar construir um time melhor e de alta perfomance a cada dia)
Dica final: quando for montar seu time de produto, a parte mais importante é encontrar os melhores colaboradores. Existem muitas medidas para qualificar bons profissionais, mas a que eu mais me chama a atenção (e considero muito importante), é NÃO contratar mercenarios! Ficou curioso? Escrevi um artigo a respeito (Confia em mim, é muito importante você não ter esse tipo de profissional no seu time)