Qual a diferença entre um Product Manager e um Product Owner?

A ideia deste artigo é justamente dar um pouco de luz a alguns temas bem polêmicos, especialmente dentro de grandes corporações que estão passando por transformações digitais e ágeis, algo cada vez mais comum hoje em dia por uma questão de sobrevivência.

No modelo tradicional, Product Managers fazem suas pesquisas de mercado e especificam suas Visões de Produto durante alguns meses até que o documento esteja pronto e seja encaminhado para o Escritório de Projetos (PMO) da empresa. O Escritório irá delegar a um Project Manager transformar a visão de produto em um projeto de software (geralmente usando MS Project ou similar) que uma vez que esteja construído será delegado a um time de desenvolvimento da área de TI, que regularmente terá de prestar reports ao Project Manager sobre o andamento do projeto que por sua vez reportará ao Product Manager. Ao término do desenvolvimento, o software será enviado para um Departamento de Qualidade (QA) para os testes e o resto da historia você já conhece, é o bom e velho waterfall. Ou nem tão bom assim…

Waterfall Product Development
Waterfall Product Development

No entanto, quando mudamos este paradigma e passamos a trabalhar com métodos ágeis, em especial o Scrum, o mais famoso deles, esse ciclo em cascata é rompido drasticamente, silos são destruídos e papéis são drasticamente modificados ou novos papéis são introduzidos. É o caso da extinção do Project Manager e o surgimento do Product Owner e do Scrum Master. Mas e o Product Manager? Ele deve também ser extinto nesse modelo de trabalho?

Sim e não.

Mas antes vamos entender o que é Gerenciamento de Produto (Product Management).

Gerenciamento de Produto ou Product Management

A disciplina de Gerenciamento de Produtos data da década de 1930. Gerenciar um produto é sobre fazer análise e pesquisa de mercado, descobrir product/market fit, inteligência competitiva, customer discovery, definição de requisitos de produto, desenvolvimento do dito-cujo (embora na prática isso seja terceirizado a outro setor ou empresa), go to market, estratégia de precificação (pricing), marketing inbound e outbound, treinamentos no uso do mesmo, revisões e até extinção do produto.

Ufa! É muita coisa!

A primeira coisa mais fácil de notar aqui é que não tem como uma única pessoa cuidar de tudo isso sozinha, certo? Sendo assim, se você acha que o Product Manager da sua empresa é um deus, você está errado. Geralmente Product Managers contam com uma equipe para lhes ajudar: profissionais de marketing, designers, desenvolvimento, pesquisadores e analistas.

Note também que o próprio papel de Product Manager só faz sentido em organizações com produtos maduros, que exijam uma governança mais organizada sobre todo o seu ciclo de vida. Ou seja, corporações. Dificilmente você vai ver um Product Manager, que é um orquestrador de todo o ciclo de vida de um produto, em pequenas empresas ou em startups.

E o Product Owner do Scrum, não seria ele um Product Manager com outro nome? Não faria ele as mesmas atividades que um Product Manager mas em uma empresa ágil?

Para responder a esta pergunta, vamos relembrar o conceito do Product Owner.

Product Owner ou Dono do Produto

O foco da criação do papel do PO, lá na década de 1990 pelos criadores do Scrum era tornar o time de desenvolvimento mais próximo do cliente, ou o contrário, tanto faz. O gap de comunicação do dono do problema até os desenvolvedores da solução era enorme, o que mais se via eram projetos entregues que não atendiam às necessidades reais dos usuários.

O PO nasceu como um representante máximo do cliente dentro do time de desenvolvimento, o porta-voz dos usuários do produto, o dono das prioridades e das regras de negócio para o time de desenvolvimento.

Segundo o Scrum Guide, o Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Time de Desenvolvimento. Ou seja, guiar o time para a construção do produto que trará o maior ROI possível. O próprio Scrum Guide deixa claro que os detalhes de como este indivíduo vai conseguir fazer isso varia enormemente de organização para organização.

O Scrum Guide finaliza a curta descrição deste importantíssimo papel se referindo a ele como o ‘manager’ do Product Backlog e que tão somente ele tem a palavra final sobre o mesmo, embora o PO possa ser o representante de um comitê maior que ele.

O foco do PO é o Product Backlog, segundo o Scrum. Talvez o nome mais correto seria Product Backlog Owner, mas soaria muito mal esse nome. O Product Backlog é a ferramenta do PO para maximizar o ROI de um produto desenvolvido por um Time de Desenvolvimento.

Só com essas informações, per se, já é possível notar uma diferença gritante entre os dois papéis, certo?

Product Owner e Product Manager
Product Owner e Product Manager

Product Management é algo mais estratégico, enquanto que Product Ownership é algo mais tático. Pra finalizar, o Product Development seria o operacional (responsabilidade do Development Team). O que responde basicamente a pergunta que iniciou esse artigo: qual a diferença entre Product Manager e Product Owner.

Product Manager ou Product Owner?

Claro, agile nunca foi e nunca será algo preto e branco, algo prescritivo como as metodologias tradicionais.

No passado acreditou-se que os Product Owners substituiriam os Product Managers. E até o fazem em empresas pequenas ou em times de produto que estão recém iniciando (trabalhei muito em startups, nelas o PO conversa direto com o CEO e pronto). Conforme a empresa cresce e seus produtos tornam-se mais e mais complexos e maduros, a necessidade de ter pessoas diferentes cuidando do estratégico e do tático de um produto torna-se indispensável até para garantir a sanidade desses profissionais.

Imagine um produto complexo como uma linha de financiamento bancária. Uma visão limitada poderia acreditar que basta desenvolver este recurso em um aplicativo e está tudo resolvido. No entanto, como eu bem sei pois trabalho em uma instituição bancária, isso envolve desde core banking, APIs, disponibilização em canais (mobile e internet banking, no mínimo), regulamentação do banco central, atendimento aos clientes no SAC, solução comercial para vendas, infraestrutura para suportar treinamento para a galera de backoffice, inclusão no site, conteúdo no blog e muito mais.

Desenvolver o software para este produto é apenas uma parte (obviamente muito importante) desta cadeia completa que envolve o gerenciamento deste produto. É o mesmo que acreditar que Engenharia de Software resume-se apenas a programar sistemas.

Mas o Product Owner não pode cuidar sozinho de todos os aspectos de um produto? E abaixo dele ter uma série de outros profissionais para ajudá-lo a gerenciar o produto como um todo?

Pode. Daí ele acabou de se tornar um Product Manager com outro nome e talvez ele não consiga cuidar da sua principal atribuição que é gerenciar o Product Backlog, maximizando a entrega de valor do time de desenvolvimento.

Note que desde que isso esteja claro e a empresa decida que este é o melhor modelo para se trabalhar, está ok. Apenas atente ao fato de que gerenciar um produto por completo é uma tarefa que exige muito mais senioridade e conhecimento de mercado do que se focar no aspecto tático de como guiar um time de desenvolvimento. Sem obviamente desmerecer esta atividade, mas são skills diferentes que são necessárias.

Mas este assunto, de como escalar e dividir o trabalho dos profissionais de produto de uma empresa é assunto para outro artigo. Para quem quiser se aprofundar recomendo este e este artigo da Ellen Gottesdiener, uma Agile Product Coach, especialista neste assunto.

Gostou do assunto? Quer aprender mais sobre métodos ágeis para construção de produtos? Conheça meu livro Scrum e Métodos Ágeis clicando no banner abaixo!

O que achou desse artigo?
[Total: 2 Média: 5]