Embora seja um assunto meio batido na comunidade de produto, a diferença entre essas duas funções ainda gera muitos problemas na área de produto. Quem atua como Product Manager ou Product Owner ainda sofre muito com a falta de organização nessas definições.
Recentemente participei de muitas discussões sobre esse assunto com colegas de trabalho e quando a gente sente que a estrutura pode estar afetando a qualidade do produto precisamos levantar a bandeira vermelha.
Criar um ambiente onde as pessoas tenham condições de usar sua curiosidade e criatividade para resolver (de fato) problemas de usuários é fundamental para o sucesso do produto.
A ideia aqui é fomentar o assunto para que você consiga puxar dentro da sua empresa uma thread e falar abertamente sobre isso. Converse com seus pares e seus líderes se você percebe que a cultura de produto precisa ser melhorada. Você pode ser o agente transformador, busque mudar essa realidade, pois além de melhorar o cenário da sua empresa (e consequentemente do seu produto), você vai estar ajudando a subir o nível da nossa comunidade.
Nesse artigo, trago um visão quantitativa e qualitativa com base em um pequeno questionário aplicado à comunidade de produto entre os dias 08 e 12 de janeiro de 2021.
Você pode querer entender melhor sobre qual é o escopo do(a) gerente de produto e qual é a diferença entre PM e PO antes de seguir a leitura.
Qual é a visão do mercado sobre a diferença entre PM e PO?
A pesquisa aplicada na comunidade buscou principalmente identificar qual é o cenário hoje dentro das empresas e o que as pessoas de produto acham deste ambiente. Foram reunidas 150 respostas e muitos insights.
Quem participou?
A pesquisa foi aberta a todos os profissionais que estão ou estiveram envolvidos no desenvolvimento de produtos. Os participantes são de empresas de diferentes tamanhos e modelos de negócio. No gráfico abaixo é apresentado o número de participantes por tamanho da organização. Um pouco mais de um terço dos respondentes atuam em empresas de grande porte (com mais de 1500 colaboradores).
Qual foi o objetivo da pesquisa?
O objetivo principal foi saber o que cada um dos participantes pensa sobre o ambiente em que está inserido em relação a estrutura de gestão de produtos e levantar quais são os problemas mais comuns dentro das organizações.
Embora a tendência de mercado hoje seja concentrar as funções estratégicas e táticas no product manager, ainda existem muitos lugares em que continuam utilizando PM e PO na mesma squad, mas uma tendência nunca consegue ser efetiva em todos os lugares.
Em que cenário os participantes estão inseridos?
Vamos aos resultados!
- Dos 150 participantes, 59 atuam em times onde PM e PO dividem as tarefas relacionadas à gestão de produto;
- 85 pessoas trabalham em times onde somente uma pessoa atua na gestão de produto. Um ponto importante a ser destacado aqui é que o nome do cargo é a primeira grande confusão que encontramos. Muitas empresas contratam Product Owners e concentram nesta pessoa atividades de cunho estratégico, sendo que neste caso o nome mais apropriado para o cargo seria de Product Manager. Essa distorção pode ser o primeiro sinal de que a cultura de produto da empresa precisa ser revista.
- A faixa determinada como indefinido, com 6 participantes, inclui empresas que estão em fase de estruturação de times, ou pessoas que estão passando por período de transição de carreira.
O que os participantes acham mais benéfico para o produto?
Ao questionar os participantes sobre o que eles acham ideal para o seu time na situação atual – o time possuir funções distintas para PM e PO ou o PM exercer também o papel de PO – temos um resultado muito equilibrado:
É tentador responder “depende” para esta pergunta, porque é lógico que tem uma série de argumentos que podem ser usados para justificar uma opção à outra: modelo de negócio, tamanho do produto, maturidade do time, disponibilidade de PMs e por aí vai. Mas a intenção aqui foi fazer o participante refletir sobre o que sente considerando o seu time de hoje.
Ao analisar com um olhar um pouco mais crítico, uma surpresa boa: há mais pessoas satisfeitas com a configuração atual do seus times do que insatisfeitas.
- Times em que existem PM e PO: das 59 pessoas que atuam em times que possuem as duas posições, a maior parte (35, que equivale a 59%) concorda que esta é a estrutura ideal para seu time, contra 24 (41%) que acham que seus times deveriam ter apenas um responsável por gerir o produto.
- Times em que existe somente o PM: das 85 pessoas que atuam em times que possuem somente uma cadeira de gestão do produto, a maior parte (49 que equivale a 58%) concordam que esta é a estrutura ideal para o seu time, contra 36 (42%) que acham que seus times deveriam ter PM e PO (lembrando que aqui estão sendo consideradas aquelas distorções de nome de cargo, em que POs que são responsáveis pela estratégia de produto deveriam ser chamados de PM).
Quais problemas ficaram evidentes?
Agora é a hora de tentar entender o porquê das preferências, afinal o conhecimento empírico é resultado da nossa própria interação com o ambiente. Ao vivenciar o dia a dia num time de produto, começamos a perceber práticas e procedimentos que interferem negativamente no resultado final, e é neste momento que conseguimos muitas vezes identificar os pontos fracos da nossa estrutura e as oportunidades de melhoria.
Baseando-se em artigos, livros e discussões na comunidades de produto, listamos para cada tipo de estrutura (PM e PM+PO) os problemas que encontramos em cada modelo e convidamos os respondentes a apontar quais eles achavam que eram realmente problemas. Além disso, os respondentes puderam indicar problemas que não estavam na lista.
Problemas que surgem quando existe somente o Product Manager na gestão do produto
Para as pessoas que acham ser mais eficiente existir 2 posições (PM e PO) na gestão do produto, considerando seu time atual, foi perguntado quais dentre os 6 motivos listados abaixo elas consideravam serem problemas decorrentes de uma única pessoa atuar na gestão do produto.
O último item acabou sendo adicionado por sugestão dos próprios respondentes e, como houve recorrência, está sendo considerado na estatística.
No gráfico abaixo temos 77% dos adeptos de times com PM + PO, dizendo que o maior problema é o time de desenvolvimento não receber apoio do PM por falta de tempo e, em segundo lugar, 42% dos respondentes apontaram a redução do backlog como um problema para este cenário.
A seguir, vamos aprofundar o assunto nos dois temas mais apontados como potenciais problemas:
Falta de tempo para apoiar o time de desenvolvimento
A verdade nesse ponto é que quando a gente se depara com a lista de responsabilidades de um PM/PO dá um certo desespero.
Analisando o escopo de um product manager e um Product Owner, temos o seguinte conjunto de tarefas:
Não precisa pensar muito para perceber que é difícil lidar com tudo isso sozinho, mas podemos contornar de algumas formas. Claro que as hipóteses listadas aqui não se aplicam a todos os time, mas não custa fazer um exercício e avaliar se a sua equipe sofre de algum desses males:
- Reduzir tamanho do time: você consegue alimentar seu time com duas pizzas? Seguindo Jeff Bezos, se não conseguir o time está muito grande, e isso aumenta proporcionalmente o trabalho envolvido na gestão do produto. Quanto mais pessoas você precisa orientar, menos tempo vai ter para se dedicar às outras tarefas. O que vemos na prática é que as empresas até iniciam com times pequenos, mas à medida que as coisas vão atrasando e novas necessidades vão surgindo, o time vai aumentando sem controle. Manter um padrão de tamanho de times ajuda a estancar a quantidade de trabalho e é saudável para todos;
- Reduzir os domínios do time: quando temos o conceito de squad/tribo ou sinônimos, é natural que cada squad fique responsável por determinados domínios do produto. Dependendo da quantidade de demandas e complexidade dos domínios concentrados num mesmo time, é inviável que o PM consiga fazer a gestão com qualidade. Normalmente o próprio time levanta esse tipo de problema, principalmente em empresas onde todos têm voz. Fique atento se os domínios do seu time estiverem acima do que o time suporta. Considerando o tamanho e maturidade do time, vale a pena rever essa divisão.
- Delegar responsabilidades ao time: Muitas das tarefas atribuídas ao Product Owner podem ser delegadas ao próprio time. Você já parou pra pensar que até mesmo o tech lead pode escrever user stories? Já imaginou como vai ser bom para os DEVs consumir US definidas por alguém que fala a língua deles? Além disso, a prática pode antecipar soluções de eventuais problemas técnicos, uma vez que o tech lead precisa garantir que entendeu a necessidade precocemente ao desenvolvimento.
- Facilitar o processo: O Scrum prevê uma série de procedimentos e cerimônias que tomam parte do tempo do time, e elas são todas muito importantes caso o time enxergue valor nessas cerimônias. A proposta aqui é avaliar se a energia e tempo envolvidos estão mesmo dando retorno. Avalie a frequência e a carga horária empregada nesses momentos. Quanto mais maduro o time e mais abertura e iniciativa as pessoas tiverem para dar feedbacks diretos, menos cerimônias precisam ser feitas.
Redução de backlog por falta de tempo
O segundo problema mais aclamado também é uma consequência da “falta de tempo” do product manager. O time vai entregar menos funcionalidades no fim de uma iteração porque o PM não deu conta de gerir o que habitualmente o PO colocava na esteira. Mas isso é mesmo um problema?
Entregar um caminhão de funcionalidades não quer dizer que você está entregando valor ao usuário. Mas o fato é que, em grande parte das empresas, ainda existe a mentalidade de que os bons times entregam muito. É preciso ter cautela e focar em entregar valor, e não em entregar mais números – e isso você só vai saber caprichando no discovery.
Considerando as boas práticas de discovery, o PM deve envolver o design e a engenharia (pode ser o tech lead ou um outro dev mais experiente). Então não é porque o backlog diminui que o time vai ficar sem trabalho. Se o PM reduziu o backlog porque precisa dedicar parte do seu tempo ao discovery, ele deve levar alguém do time junto. Segundo Marty Cagan, é um grande erro não envolver os engenheiros na fase de discovery. Historicamente, as soluções mais inovadoras geralmente partem do time de engenharia (no artigo Customer Inspired Technology Enabled, ele traz exemplos práticos disso).
O ideal é o time de engenharia e de product management estarem envolvidos tanto com tarefas de discovery como com tarefas de delivery, logicamente que não na mesma proporção, mas precisa existir essa via de mão dupla.
Então, diminuir o seu backlog para focar mais no discovery, é uma solução para diminuir as tarefas do PM, que beneficia também o time e consequentemente o produto. Lembrando que tudo sempre deve estar alinhado às estratégias e visão da organização.
Mas como nem tudo é tão fácil, todas essas possibilidades de contorno podem não ser viáveis na sua equipe. Quando temos times imaturos, por exemplo, dificilmente será possível diminuir as retrospectivas e nesses casos a estrutura de PM + PO pode ser a mais indicada.
Problemas que surgem quando existem Product Manager e Product Owner atuando na gestão do produto
Para o grupo que apoia a concentração do papel do PO na posição de product manager, foram listados os 5 problemas que ocorrem quando coexistem PM e PO na mesma squad.
No gráfico abaixo temos 51% dos adeptos a esta configuração, dizendo que o maior problema é “o pedágio PO/PM torna a comunicação truncada, o time demora tempo demais para receber feedbacks”.
Em segundo lugar, 38% das pessoas acreditam que “a falta de acesso ao cliente dificulta que o time realize validações e testes”. Também vamos falar sobre o terceiro ponto, que também teve um resultado expressivo (36%), e fala sobre a dificuldade de contagiar o time com o propósito do produto.
Comunicação truncada PM x PO
A estrutura de times que admite a coexistência de PM e PO surgiu essencialmente para blindar o PM e prover tempo para que ele atue em outras tarefas que não estão diretamente ligadas ao delivery. Logo, é bem comum que nesta estrutura o PM seja um cara distante do time. Não que o time não possa acessá-lo, ou que ele não esteja disposto a ajudar alguém. Mas a própria estrutura não prioriza a relação de camaradagem e a formação de laços. O time sempre vai se sentir mais à vontade com o PO. É ele que vai ser indagado quando a dúvida surgir, mas nem sempre o PO terá a melhor resposta de bate pronto, então ele terá que consultar o gerente e depois esclarecer as dúvidas do time. Mas, você conhece aquela brincadeira do telefone sem fio? Por melhor que seja o PO, ele não vai conseguir transmitir a mensagem com a mesma riqueza de detalhes que a pessoa que possui maior contato com o usuário.
Então, se o seu time possui as duas posições (PM e PO) lembre-se que ainda é responsabilidade do PM garantir que o time conseguirá entender as necessidades do usuário! Embora o PO esteja engajado neste propósito, ele vai AJUDAR o time neste processo, mas não GARANTIR. Preocupe-se em se certificar de que todos no time se sentem à vontade para buscar orientação com o gerente de produto.
Nada é mais importante do que o sucesso do seu produto. De nada adianta você buscar novas necessidades no mercado se não tiver certeza de que o que está sendo feito, está sendo feito de forma inovadora. Gestão de tempo e comunicação são imprescindíveis neste papel, e se não conseguir organizar o tempo para acompanhar sua obra de perto, esse serviço não é para você.
Falta de acesso ao cliente
Melissa Perri diz, em seu artigo Product Manager vs. Product Owner, que quando iniciou palestras sobre gerenciamento de produto em uma empresa que utilizava o framework SAFe, ouviu a seguinte indagação: “Você está nos ensinando a falar com os usuários, mas eu sou um Product Owner. O gerente de produtos que deve conversar com todos os usuários e nos dizer quais são os requisitos do produto. Passo todo o meu tempo escrevendo histórias de usuários a partir delas e trabalhando com a equipe para entregar a solução. Estou confuso.” E foi aí que ela começou a questionar a coexistência de PMs e POs.
Mas, independente de quem tenha acesso ao cliente, seja PM ou PO, essa pessoa deve ser responsável por puxar o time de engenharia (nem que seja representado pelo tech lead) para as reuniões de discovery. Como já falei aqui em cima, você perde muito se não fizer isso.
Dificuldade de contagiar o time pelo propósito
O fato é que para conseguir a inovação que tanto buscamos nos nossos produtos, um bom PM precisa estar alinhado e engajado com o time de engenharia e designer, independentemente do tamanho da empresa ou do modelo de negócio. Se o PM não for aquele cara que evangeliza o time em torno da visão do produto, os resultados serão produtos que não atendem e não tem aderência do usuário final.
Escute o seu time
E aí identificou alguma dessas situações no seu time? A verdade é que por ser tão recente a área de gestão de produtos, ainda estamos todos descobrindo e aprendendo a melhor forma de desenvolver os processos. O resultado dessa pesquisa mostra que a unificação das funções de PO e PM, embora seja uma tendência, ainda está longe de ser realidade em grande parte dos times e organizações.
Outro ponto é que 40% dos respondentes demonstraram insatisfação em relação à estrutura atual de seus times. Eu acredito que muitos de vocês tenham força e capacidade para sugerir mudanças que melhorem as possibilidades das suas equipes, afinal, insanidade é continuar fazendo as mesmas coisas e esperar resultados diferentes, certo?
Quer saber mais sobre a gestão de produtos digitais?
Se quer entrar na área de produto e se tornar um Product Manager preparado(a) para enfrentar o mercado, baixe a ementa do curso referência em produto no país e aprenda com 17 instrutores de empresas como OLX, Nubank, Booking.com, iFood, Creditas, Grupo ZAP, entre outras grandes tech companies brasileiras.
