Esse é um assunto MUITO batido. Mesmo. Há mais discussões sobre as diferenças entre Product Owner e Product Manager que gente na rua 25 de Março em São Paulo. Muito dessa confusão, é que ninguém fala das responsabilidades que cada personagem exerce. Outro ponto, é que ninguém diz que esses dois caras são, na verdade, a mesma pessoa. Ou pelo menos deveriam ser (na minha opinião, claro).

De onde surgiu o Product Owner?

Product Owner é um personagem originado do Scrum e só quando ele virou um framework para desenvolvimento de software. E ao contrário do que você pode pensar, o Scrum não foi criado por Ken Schwaber e Jeff Sutherland, mas o termo Scrum, além do seu formato de trabalho foi originalmente introduzido em 1986 por Hirotaka Takeuchi e Ikujiro Nonaka em um artigo bem longo e sensacional publicado no HBR chamado The New New Product Development Game.

Até então, o Scrum ainda não fora usado para desenvolver software, o que só foi acontecer em 1995, aí sim, com o Ken Schwaber e Jeff Sutherland. Até então, o Hirotaka e o Ikujiro estavam aplicando e estudando esse formato em empresas do Japão e dos Estados Unidos que faziam produtos, que não eram essencialmente software. As primeiras empresas que aplicaram o Scrum em sua essência, foram a Fuji-Xerox, Honda e Canon… Nesse contexto, os times multifuncionais o Hirotaka e o Ikujiro se referem, são formados por pessoas que fazem a fabricação, desenho do hardware produto, manufatura, verificação do design, desenvolvimento de software, inspeção, produção, etc…

Agenda de desenvolvimento de produto da Fuji — Fonte:https://hbr.org/1986/01/the-new-new-product-development-game

Se você fica orgulhoso quando seu time multifuncional tem Designer, Front, Back, QA e Mobile, imagina um time que vai projetar e produzir um carro.

The Honda City project team, whose members’ average age was 27, had these > instructions from management: to develop “the kind of car that the youth segment would like to drive.” An engineer said, “It’s incredible how the company called in young engineers like ourselves to design a car with a totally new concept and gave us the freedom to do it our way."

Se você ler o artigo do Hirotaka o Ikujiro, você vai ver que o processo de trabalho que eles descreveram não perdeu quase nenhuma característica quando comparado com o Scrum que conhecemos hoje para desenvolvimento de software. Acontece, quando o Jeff e o Ken trouxeram o framework para o desenvolvimento de software, eles mudaram um bocado a estrutura para se adequar à nossa realidade.

Comparando as responsabilidades do Product Owner e do Product Manager

Em desenvolvimento de software, sofremos de alguns grandes problemas. Dois deles seriam:

  • A mudança de prioridade e escopo;
  • Requisitos e materiais para iniciar o desenvolvimento;

Esses dois problemas acabam minando a velocidade e a produtividade do time. Antigamente o time de desenvolvedores lidavam diretamente com os Stakeholders e outras áreas da empresa como atendimento, por exemplo. Então, as demandas podiam vir de todos os lados. Como o time de desenvolvimento consegue decidir se vai fazer uma tarefa que o Diretor Comercial pediu para conseguir ganhar Milhões, ou por um bug que está afetando milhares de usuários?

Além disso, geralmente todas essas demandas vinham sem detalhes suficientes para que os devs pudessem estimar o esforço técnico. Geralmente o atendimento não consegue extrair do usuário informações suficientes para dar ao time mais detalhes do problema, e os stakeholders são pragmáticos demais, preferindo falar um “Quero isso pronto para amanhã” do que explicar realmente a dor e o objetivo que deve ser alcançado.

Nesse cenário, não há espaços para inovação do produto ou solução para débitos técnicos, e geralmente o processo é totalmente waterfall e projetizado, baseado em deadlines, SLAs e etc…

Então, nesse contexto horroroso, o Product Owner surge como um centralizador, responsável por priorizar e organizar as demandas do time, que nós chamamos hoje de Backlog. O Guia oficial do Scrum especifica detalhadamente quais as responsabilidades de um Product Owner:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

Você leu em algum nessa lista as responsabilidades abaixo? Só pra citar algumas:

  • Identificação das necessidades do mercado e do negócio;
  • Pesquisa e análise de Benchmark;
  • Unir visão da empresa com a visão da área de produto;
  • Criar estratégia do produto e direciona-la para cumprir com as necessidades da empresa e do usuário;
  • Definir, acompanhar e comunicar métricas de sucesso do produto;
  • Compreender profundamente o negócio e o mercado de atuação;
  • Compreender profundamente o usuário, conhecendo suas necessidades, a fim de identificar oportunidades para o produto;
  • Definir e planejar novas features do produto de acordo com as necessidades do usuário e do negócio;

Se seu time tem um Product Manager que faz apenas as coisas da primeira lista, na verdade seu time tem apenas um Product Owner e outro alguém está sendo o Product Manager. Isso não é necessariamente errado, e vou tentar explicar isso em seguida.

O que é ser um Product Manager?

Geralmente o PM deve ter vindo da área de Negócio, Design ou Tecnologia… Mas ele pode ter vindo de outra área totalmente diferente dessas, como Marketing, por exemplo. Essa responsabilidade é relativamente nova aqui no Brasil e em outras partes do mundo, por isso é certo afirmar (ainda) que ninguém nasce Product Manager (e também Product Onwer).

A principal característica de um PM é ser multidisciplinar. Há um diagrama muito usado que coloca o PM na intersecção entre Business, Design e Desenvolvimento para ilustrar a multidisciplinaridade do PM.

Infelizmente esse diagrama é muito simplista, pois poderia haver mais áreas ali, por exemplo:

  • O PM precisa entender um pouco de Marketing, principalmente lançar seu produto/feature. Há também o conhecimento de aquisição, dependendo das responsabilidades que você tem na empresa;
  • O PM precisa entender bastante de Agile, já que ele exerce também as responsabilidades descritas de um Product Owner.
  • O PM precisa entender sobre atendimento ou fluxo de atendimento dos usuários, dado que ele vai precisar selecionar o que está mais doendo nos usuários, conseguindo priorizar qual solução ele vai pensar primeiro de acordo com número de usuários impactados, ciclo de ocorrência, churn, perda de receita e etc…
  • O PM precisa saber um pouco sobre dados, já que ele vai lidar com os times de BI, Data Science e assim por diante. Existem uma série de métricas de produtos que o PM poderá fazer correlações para entender melhor o comportamento do usuário, afim de melhorar a retenção e engajamento do produto;

Provavelmente você deve ter pensado em algumas áreas que poderiam ser citadas como compliance, segurança, risco, fraude, comercial, etc… Tudo vai depender do mercado em que você está atuando.

O Roman Pichler tem um artigo muito legal onde ele mostra que a gestão de produtos digitais é uma disciplina multifacetada. Nesse caso, ele sugere que o gestor de produtos deve ter um perfil T. Se você nunca ouviu falar sobre o Perfil T, dá uma lida no Handbook para novos funcionários da Valve ou nesse texto xexelento na Wikipedia.

O mercado está criando níveis e isso é ruim

Agora é muito comum ver empresas criando níveis: onde PMs lideram POs, exatamente por causa dessa separação de responsabilidades.

Essa é uma solução que funciona, mas não é a ideal, na minha opinião, exatamente por que a pessoa que exerce a responsabilidade de PO precisa ter contato com os outros pilares que fazem os PMs serem PMs.

Algumas empresas esperam que um PM possa cuidar de vários produtos, com vários POs embaixo. Eu não acho que um PM faria um bom trabalho em vários produtos ao mesmo tempo quando penso em todas as responsabilidades que um PM tem. Principalmente se os produtos envolverem vertentes ou verticais diferentes.

O Joaquim Torres, grande mestre de produtos digitais, explica e esse artigo as intersecções que podem ter nas responsabilidades de BA (Business Analyst), Product Owners e Product Managers. Ele é bem claro quando diz que o Product Manager pode gerir pessoas exercendo funções de BAs ou POs, contudo, o PM ganharia uma responsabilidade a mais: gestão de pessoas.

Caso haja em uma empresa, além dos PMs, pessoas exercendo função de BA e/ou PO, > é possível colocar os PMs como gestores dos BAs e/ou POs. Contudo, isso cria uma carga extra para o PM que, além de gerir o produto, terá que se preocupar com gestão de pessoas. — Joaquim Torres

Esse é um ponto muito importante, dado que gestão de pessoas é um assunto complexo e dá trabalho. Alguns desdenham da quantidade de trabalho que dá gerir pessoas, mesmo que sejam poucas, mas há responsabilidades de horário, carreira, produtividade, relacionamento, mentoria, coaching e etc, que não são fáceis de lidar, mesmo com um time diminuto de 2 ou 3 pessoas.

Concluindo

O nome Product Owner se tornou tão, mas tão pejorativo que é comum que pessoas não gostem dessa responsabilidade por ficar muito no tático. Mas entenda que essa é só uma das responsabilidades de um Product Manager. Se alguém julga ser um Product Manager e só exerce a versão “agile” da responsabilidade, você é um PO, então, provavelmente, seu time está órfão de um PM. Não apenas seu time, mas seus usuários e talvez seus stakeholders.

Referências dos links no artigo: