A anomalia PO PM
Estado ou qualidade do que é anômalo; anormalidade, irregularidade
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 por que 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
- estado ou qualidade do que é anômalo; anormalidade, irregularidade.
- 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.
