Por que nossos Product Owners viraram Product Managers (e qual a diferença)

Quando decidimos que os Product Owners mudariam de papel dentro do time de produto e passariam a ser Product Managers, nem mesmo a troca do nome foi instantânea — e ainda hoje alguém às vezes se descuida e me chama de P.O.! Rótulos à parte, foi uma mudança profunda que até hoje está causando um impacto muito positivo em nossa maneira de desenvolver produto.

Vale ressaltar que em algumas empresas, esses papéis coexistem: o Product Manager define Visão e Roadmap, o Product Owner define estórias de usuário. O PM olha mais para fora (clientes, mercado etc.) e o foco do PO é para dentro (time, entrega). No nosso caso, porém, ambas as responsabilidades passaram a se concentrar no Product Manager. Vou explicar como:

O contexto e a importância do Product Owner

Quando o Scrum introduziu o papel de Product Owner, resolveu uma série de problemas causados pela quantidade de informações, requisitos e interferências que um time de desenvolvimento pode sofrer quando não existe uma interface única que represente a figura do cliente.

No contexto do Scrum, o Product Owner é o cliente, e ao time de desenvolvimento, não importa quantas pessoas diferentes estão dando inputs ao PO, nem se esses inputs são contraditórios, se as pessoas estão mudando de ideia ou se há necessidades que não estão sendo atendidas. Uma vez escrita e priorizada a estória de usuário pelo PO, é papel do time se organizar para realizar aquela entrega.

É também papel do PO participar de todas as cerimônias do time e estar 100% disponível para orientar e tirar dúvidas quanto ao caminho a ser seguido no desenvolvimento.

Por muito tempo, este papel fez sentido e cumpria com as necessidades do nosso time de produto. Até que as coisas começaram a mudar.

Os times especialistas

Conforme o produto começou a crescer e escalar, começamos a precisar de times especialistas em cada frente de atuação. Os times foram reorganizados para serem multidisciplinares — produto, design, desenvolvimento, qualidade — e cada especialidade se tornou um chapter:

Se você reparar bem na primeira linha, ali de cabelos brancos, estão os… Product Owners! Pois bem, o modelo que serviu de inspiração para nossa reorganização foi o do Spotify e essa imagem é como eles explicam a estrutura.

No entanto, quando ainda estávamos planejando a transição, percebemos que o produto ficaria carente de uma visão mais ampla. No modelo anterior, nosso Head de Produto era também o responsável pelo olhar de negócios, do mercado e das dores do cliente, trazendo para os POs os Épicos (ou Features) a serem estudados e quebrados em estórias de usuário. Com a mudança, percebemos que a estrutura de um único profissional olhando para os Épicos e o Roadmap simplesmente não iria escalar.

Além da parte de Engenharia de Software, era necessário também que cada time pudesse, por conta própria:

1. Evoluir seus conhecimentos do Negócio — tanto Marketing Digital no geral, quanto a especialidade do time;
2. Identificar, entender e desenvolver Empatia pelos problemas dos clientes;
3. Ter uma visão ampla de Mercado, Tendências e Oportunidades;
4. Trabalhar próximo às demais áreas da empresa (Marketing, Vendas, Customer Success etc.) em intercâmbio de ideias e informações; e principalmente
5. Desenvolver um Roadmap e revisá-lo sempre que oportuno, garantindo uma Visão de longo prazo dos caminhos que aquela vertical do produto deve seguir.

Esses papéis, agora mais externos do que internos, acrescentaram toda uma camada estratégica ao profissional que antes era o Product Owner, dedicado mais à camada tática e em alguns casos, até operacional. São responsabilidades que estão diretamente ligadas à figura do Product Manager, ou Gerente de Produto, e passou a fazer muito mais sentido denominar assim esses profissionais.

A mudança de nome não foi apenas uma mudança de nome: marcou também as novas responsabilidades do profissional de produto e serviu como um “divisor de águas”.

O Product Manager no time

Com a especialização, os times deixaram de ser times de software e passaram a ser times de produto, cada um passando a ter autonomia, como se fosse uma “mini start-up”: investigando, testando, validando e criando por conta própria, em alinhamento com a estratégia geral do RD Station, que continua sendo definida pelo Head da área, em conjunto com o CEO e com os heads de algumas áreas.

Na estrutura do time como start-up, a divisão de responsabilidades e a relação entre o Product Manager e o Tech Leader é a mesma que existe entre um CEO e um CTO. Ainda que tudo seja conversado e decidido em conjunto, é responsabilidade do primeiro definir o que fazer e para onde ir, enquanto ao segundo cabe a também difícil definição de como fazer para chegar lá.

Apesar dessa divisão, uma importante atribuição do PO foi mantida pelo PM nesta nova estrutura: ainda é ele que recebe as entregas do time, ao final de cada Sprint. Portanto ainda cabe ao PM definir, nas reuniões de planejamento, qual o DoD (definition of done) de cada pacote de trabalho. Por outro lado, tarefas do PM que estão relacionadas diretamente ao time, como Roadmap e Visão de Produto, também são entregues ao time em cerimônia similar, o que garante maior envolvimento do time com as etapas anteriores à escrita de estórias de usuário e desenvolvimento de solução.

Novos desafios, novas soluções

Quando assumimos essas novas responsabilidades, nossos dias não passaram a ter 48 horas, portanto tivemos que nos dividir entre os papéis! O papel do Product Owner continuou sendo importante, mas teve que ser feito em menos tempo e como era de se esperar, alguns alertas se acenderam. Decidi compartilhar dois deles neste post:

1. Suporte ao time

O primeiro foi que o profissional de Produto não estava mais 100% do tempo com o time. Se antes era possível tirar uma dúvida de imediato, com a mudança, os desenvolvedores agora podiam se encontrar bloqueados no andamento de uma tarefa, sem saber qual caminho seguir.

Vale ressaltar que, com a especialização do time, todos tiveram que estudar mais a fundo os conceitos e dificuldades de sua temática, mas ainda assim, dúvidas e impedimentos relativos ao Produto e à solução continuam surgindo no dia-a-dia e continua sendo responsabilidade do PM ter um entendimento mais profundo do cliente e do negócio.

A saída para isso foi investir em alinhamento e autonomia. Nas interações com o time, especialmente nas fases iniciais de estudo e planejamento, o Product Manager precisa “contar a história do Épico” de maneira mais detalhada, geralmente no momento de apresentar o Press Release. Isso garante maior alinhamento e consequentemente, dá ao time autonomia e segurança para tomar pequenas decisões de produto e solução, removendo por conta própria alguns impedimentos. Em outras palavras, o time fica mais ágil, respondendo prontamente a mudanças e novas descobertas.

2. Interações com o cliente

Outro desafio foi a quantidade de interações dos Product Managers com clientes. Em nosso Kanban de Produto, há uma fase importantíssima chamada Estudo do Problema. Essa fase é totalmente investigativa e envolve dados quantitativos, conversas com profissionais de outras áreas da RD e entrevistas com clientes. Posteriormente, há uma outra fase, de experimentação e validação da hipótese, geralmente por um MVP, que muitas vezes fica disponível para um grupo de clientes que comparamos com um grupo de controle. Mais para o final, temos a fase de Lançamento, que novamente envolve contato com o cliente.

Tente imaginar 10 times diferentes entrevistando clientes, executando experimentos, lançando novas features etc. Além de aborrecer o cliente com o excesso de interações, cada hora partindo de uma pessoa diferente, foi se tornando cada vez mais difícil formar grupos de experimentação e controle que não tivessem alguma sobreposição com grupos formados por experimentações de outros times.

A solução para esse problema veio de dois papéis que hoje estão na área de Marketing: o Product Marketing e o Customer Marketing. Entre outras coisas, esses dois papéis dividem responsabilidades relativas a interações com os clientes, convites para Alpha tests, estratégias de lançamento etc., evitando excesso de e-mails e conversas. Em um post futuro, podemos aprofundar como isso tem sido para nós!

Saldo final

Como todo Gerente de Produto, sou apaixonado por problemas a serem resolvidos. A possibilidade de um olhar mais panorâmico, bem como a aproximação com clientes e outras áreas da empresa, me permitem estudar muito mais a fundo cada problema e não só criar os Épicos, como também desenvolver uma Visão de Produto e traduzi-la em um Roadmap que conte uma história e que faça sentido ao longo do tempo.

Além disso, com os Gerentes de Produto exercendo seus papéis de dentro do time, todos no time ganharam em visão de produto no médio e longo prazo. Alguns desenvolvedores se engajaram no processo de estudo, investigação e solução, o que tem agregado bastante. As interações com os Designers também ficaram muito ricas e essa troca tem sido de grande valor em todas as etapas do Kanban.

Esse processo de transição trouxe algumas dores e novos desafios, mas até agora o saldo é totalmente positivo e tenho certeza que “subimos um nível” em nossa maneira de pensar e desenvolver produto.

Quer fazer parte dessa evolução? Temos vagas para Product Manager e para estágio na área.

Originalmente publicado em: http://shipit.resultadosdigitais.com.br/blog/product-owners-viraram-managers/