Product Oversee

Opinião: a anomalia PO PM

Estado ou qualidade do que é anômalo; anormalidade, irregularidade

Imagem de destaque de Opinião: a anomalia PO PM

No pergunte para o Oversee, a pergunta mais votada foi a seguinte:

Eu vou aproveitar que essa pergunta fala sobre a eterna discussão entre Product Owners e Product Managers para deixar aqui a minha opinião sobre o porque ter esses dois papéis é uma anomalia e no final vou responder essa pergunta.

Uma pitada de história e definições

Apesar da história da gestão de produto se datar de 1931 com Neil H. McElroy e a famosa Procter & Gamble (P&G), a carreira de Product Manager como conhecemos hoje começou a se popularizar de fato em 2010, muito forte com o movimento lean startup nos EUA e com a chegada do primeiro Scrum Guide, também em 2010, onde se viu a primeira descrição sobre o papel de uma Product Owner (PO), em tradução livre:

A PO é a única pessoa responsável por gerenciar e controlar o Backlog de Produto. Essa é a pessoa oficialmente responsável pelo valor do trabalho realizado. Essa pessoa mantém o Backlog de Produto e garante que ele está visível para todos. Todos sabem quais itens têm as maiores prioridades, então todos sabem a ordem em que os itens serão resolvidos.

A PO é uma pessoa, não um comitê. Comitês podem existir para aconselhar e influenciar essa pessoa, mas qualquer pessoa ou grupo de pessoas que querem que a prioridade de um item mude, precisa convencer a PO. As empresas têm muitas maneiras de definir prioridades e requisitos. Essas práticas serão influenciadas pelo Scrum no passar do tempo, particularmente através das reuniões de Sprint Reviews.

Para que a PO tenha sucesso, todos na empresa precisam respeitar as suas decisões. Ninguém tem a permissão de dizer para os times trabalharem em diferentes prioridades, e os times não tem permissão de escutar quem diz algo diferente disso. As decisões da PO são visíveis no conteúdo e na priorização do Backlog de Produto. Essa visibilidade precisa que a PO dê o seu melhor para acontecer, e faz com que o papel da PO seja ao mesmo tempo necessário e recompensado.

Comparando com a versão mais atual do guia do Scrum:

O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. A forma como isso é feito pode variar amplamente entre organizações, Scrum Teams e indivíduos.

O Product Owner também é responsável pelo gerenciamento eficaz do Product Backlog, que inclui:

  • Desenvolver e comunicar explicitamente a meta do produto;
  • Criar e comunicar claramente os itens do Product Backlog;
  • Ordenar os itens do Product Backlog; e,
  • Garantir que o Product Backlog seja transparente, visível e compreensível.

O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros. Independentemente disso, o Product Owner ainda é o responsável.

Para que os Product Owners tenham sucesso, toda a organização deve respeitar suas decisões. Essas decisões são visíveis no conteúdo e na ordem do Product Backlog e por meio do incremento inspecionável na revisão da sprint.

O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar as necessidades de muitos stakeholders no Product Backlog. Aqueles que desejam alterar o Product Backlog podem fazê-lo tentando convencer o Product Owner.

É muito visível como a versão mais atual tem mais flexibilidade em relação ao papel da PO, onde tira um pouco o peso da exclusividade da PO ser detentora de todos os poderes. Agora algo que não mudou mesmo depois de 20 anos é que a PO é responsável pelo valor que o produto entrega.

Quando olhamos para a definição de Product Manager, temos o seguinte

Uma gestora de produto é um cargo que é responsável pelo desenvolvimento de produtos para uma empresa, prática essa conhecida como gestão de produto. Gestoras de produto detém a estratégia de negócio por trás de um produto, especificam seus requisitos funcionais, e geralmente gerenciam o lançamento de funcionalidades.

Wikipedia

Ou para os amantes do Marty Cagan

Uma gestora de produto combina negócio, tecnologia e design para descobrir um produto que gera valor, que é possível de ser feito e que é usável.

Marty Cagan

Eu não sei vocês, mas eu não conheci gestão de produto através de Product Managers, eu conheci através de Product Owners e na empresa que eu trabalhava, as POs faziam exatamente o mesmo papel que as Product Managers de outras empresas, simplesmente tinham o nome diferente. Nem Scrum a gente usava.

Tirando essa parte de que a Product Owner e a Product Manager mandam no produto, definem suas regras e tomam as decisões sozinhas que é uma visão bastante ultrapassada, o que sobra das definições de diferente entre esses dois cargos é a parte tática, o resto é praticamente igual. E é exatamente aí que eu acho que existe uma anomalia.

Anomalia

substantivo feminino

  1. estado ou qualidade do que é anômalo; anormalidade, irregularidade.
  2. qualquer irregularidade ou anormalidade (de um corpo, objeto, fenômeno, estrutura, formação etc.).

É um problema estrutural

Mais que entrar numa seara sobre se é papel ou se é cargo como a Melissa Perri sempre faz

na minha visão, na grande maioria das empresas, PO e PM fazem a mesma coisa, que é de fato gerar o tal do valor. A maneira como o valor é gerado é que muda de empresa para empresa. Tem empresas que POs são mais estratégicas e tem empresas que PMs são mais executoras e vice versa.

Talvez o que a Melissa falou sobre PO ser um papel do Scrum funcione bem para o contexto americano, mas aqui no Brasil, ainda mal se tem uma boa definição sobre gestão de produto e das responsabilidades da PM, basta olhar as descrições das vagas no Linkedin. Então no final, é uma questão de nomenclatura e definição de responsabilidades do cargo. Não acho que seja uma questão de PO ser melhor do que PM e vice versa. É indefinido ainda, essa é a verdade.

Agora, algo que eu realmente considero uma anomalia nas empresas é ter PM e PO ao mesmo tempo. Para mim, é um problema estrutural e da organização de produto. Se você tem que ter uma PO para ficar no tático do delivery, só recebendo o que precisa ser feito da PM, como diria a Melissa, a empresa deve estar presa na armadilha de entregas.

Eu digo preso na armadilha das entregas, porque o que eu ouço muito como argumento para ter esses dois cargos nas empresas é que a PM não tem tempo para gerenciar o estratégico e o tático ao mesmo tempo, então precisa da PO para fazer o tático. Se a PM tem que criar e gerenciar 384758347 por semana, isso no geral significa, que escolhas não estão sendo feitas e que provavelmente ou não se tem estratégia ou a estratégia é muito fraca.

E isso é de fato um problema estrutural, de como as coisas são cobradas na empresa. Na verdade, o que deveria ser feito é tentar reduzir ao máximo a quantidade de itens que são colocados no produto buscando o maior retorno possível. Mais código no ar, mais código para manter, mais débito técnico para pagar, mais complexidade para o usuário usar, mais custo operacional.

Então seja PO ou PM, o importante no final das contas é definir as responsabilidades que essa pessoa terá. Se na sua empresa tem os dois cargos, minha sugestão é tentar ajustar a estratégia e dividir os times de uma forma que seja possível atingi-la sem que se crie anomalias na estrutura da organização de produto.

Na minha empresa mudaram o cargo de todos os POs para PMs, mas continuamos sendo babá de feature de stakeholder. Isso é normal? Devo fugir?

Eu vejo com bons olhos a empresa mudar o cargo de PO para PM, se ela estiver realmente com a intenção de uma mudança estrutural também na maneira de trabalho. Eu mesmo fiz isso na Vindi e tenho visto que tem sido um movimento natural das empresas.

Mudar no geral é lento e tem dor envolvida, ainda mais se a empresa já for grande. Quanto maior, mais complexas são as mudanças em nível cultural e estrutural. Na Vindi, conscientemente mudei o nome de PO para PM para começar a demonstrar para a empresa que tínhamos a intenção de realizar mudanças na forma como trabalhávamos, mas eu e as então Product Managers, tínhamos consciência que não seria algo fácil e que levaria tempo. Mudar o nome foi só o primeiro passo.

O que eu faria é conversar com a liderança para entender a real intenção em se ter mudado o nome para conseguir tomar uma decisão de continuar ou não na empresa. E se a liderança realmente tiver a intenção de realizar as mudanças estruturais, colocar força junto em todas as oportunidades de evangelizar e educar a empresa para gestão de produto. Agora, se a mudança foi só para se adequar aos termos da moda, os mesmos problemas vão de fato continuar existindo e aí vai de cada um entender se vale ou não ficar aonde está ou partir para novos desafios.

Referências

Scrum Guides Scrum Guide V1 The History of Product Management



Um apoio do Patrocinador - awari

Aprenda as habilidades mais requisitadas pelo mercado, receba mentoria de profissionais referência em suas áreas de atuação e conte com a ajuda de profissionais especializados para conquistar uma vaga em sua nova área.