Sempre que falamos de gestão de produtos, a discussão sobre os papéis de Product Owner (PO), Product Manager (PM) e Gerente de Projetos (GP) ressurge. Muito se fala sobre as vantagens da separação deles. Mas pouco se fala sobre o custo, a sobreposição e o caos que isso pode gerar quando colocamos em funcionamento. O problema é que temos muitas pessoas direcionando o produto.
Há poucas empresas que fazem isso e um número infinitamente menor faz com sucesso e muita gente publicando no LinkedIn como é bom ter esses papéis separados para gerir o produto. Neste artigo tratei uma definição de cada um deles, suas origens e os problemas de colocar todos eles para atuar simultaneamente. Não falarei sobre vantagens porque, insisto, tenho a impressão de que nas redes sociais profissionais já tem muita gente falando sobre isso, embora, na prática e nos treinamentos, essa bipartição/tripartição de responsabilidades seja frequentemente alvo de reclamações.
Panorama dos papéis
Primeiro, vamos ver o que é cada um desses papéis para depois discutirmos os desafios de mantê-los em um time. Vou começar pelo Product Owner e pelo Gerente de Projetos, cuja literatura institucional define exatamente seu papel. Os subtítulos dessa seção são o nome mais comumente utilizado, sua sigla e a tradução que você também pode encontrar.
Product Owner (PO) – Dono do Produto
Aqui, reproduzo quase literalmente o que está no Guia do Scrum 2020. Segundo o guia, o Product Owner é responsável por maximizar o valor do produto desenvolvido pelo Scrum Team (lembrando que ele faz parte desse time). Para isso, deve gerenciar o Product Backlog, o que inclui:
- Definir e comunicar a meta do produto;
- Criar e detalhar os itens do backlog;
- Ordenar os itens por prioridade;
- Garantir que o backlog seja transparente, visível e compreensível.
O PO pode delegar essas atividades, mas continua sendo o responsável final. Suas decisões devem ser respeitadas por toda a organização e se refletem na ordem do backlog e no incremento apresentado na revisão da sprint.
Importante: o PO é uma única pessoa, não um grupo, embora possa representar os interesses de vários stakeholders. Alterações no backlog só ocorrem com a aprovação do PO.
Gerente de Projetos (GP) – Project Management
Aqui tento reproduzir de forma resumida o que está no 7ª edição do PMBOK (p.4)
“O Gerente de Projetos (GP) é a pessoa designada pela organização executora para liderar a equipe do projeto, responsável por alcançar os objetivos do projeto. Os gerentes de projeto desempenham uma variedade de funções, como facilitar o trabalho da equipe do projeto para alcançar os resultados e gerenciar os processos para entregar os resultados pretendidos”
É muito importante dizer que há algum tempo, o PMBOK não concentra as atribuições em uma única pessoa visto que, dependendo do projeto, seria impossível fazê-lo devido à sobrecarga de funções. Além disso, é perceptível que elas necessitam de áreas do conhecimento distintas. Sendo assim, elas podem ser distribuídas em diversas pessoas de um time, ser desempenhadas por pessoas pontualmente alocadas ou, em casos simples, ser desempenhadas por uma única pessoa.
- Supervisão e Coordenação: Liderar o planejamento, monitoramento e controle do projeto, além de apoiar o alinhamento estratégico, segurança e bem-estar da equipe.
- Objetivos e Feedback Atuais: contribui com perspectivas, insights e orientações claras de clientes.
- Facilitação e Apoio: Promover a colaboração, ajuda na tomada de decisões, resolução de conflitos e apoio à equipe.
- Orientação e Insight Comerciais: Direcionar o projeto com base em valor de negócio, risco e prioridade.
- Fornecer Recursos e Orientações: representar a alta gestão, remover obstáculos, defender o projeto e garantir os recursos e decisões necessárias.
- Governança: Assegurar que o projeto mantenha alinhamento com os objetivos estratégicos e monitorar a entrega de resultados ao longo do tempo.
Product Manager (PM) – Gerente do Produto
Ao contrário dos outros dois, o Product Manager não possui uma definição institucional. Diversos autores fazem suas definições. Utilizarei aqui um resumo do que o Marty Cagan apresenta no livro “Inspirado: Como Criar Produtos De Tecnologia Que Os Clientes Amam”.
Segundo Cagan, o Product Manager tem como função principal descobrir e entregar um produto que seja valioso para o negócio, utilizável pelos clientes e factível tecnicamente. Ele é o responsável por garantir que o time esteja resolvendo os problemas certos para os clientes certos, de forma alinhada com os objetivos estratégicos da empresa. Embora não seja o chefe de ninguém, ele deve ser o “CEO do produto”. Outras funções dele são:
- avaliar continuamente oportunidades de produto,
- estabelecer uma direção clara para o time,
- priorizar funcionalidades com base em impacto e viabilidade,
- garantir uma forte colaboração entre design, engenharia, marketing e demais áreas do negócio.
- compartilhar conhecimento com o time,
- promover alinhamento entre stakeholders e
- atuar como ponte entre as necessidades do cliente e as restrições da empresa.
Cagan destaca que essa pessoa deve ter um profundo conhecimento em 4 áreas: profundo conhecimento do cliente, profundo conhecimento dos dados, profundo conhecimento do seu negócio e profundo conhecimento do seu mercado e indústria. Além de ser uma pessoa inteligente, criativa e persistente.
Onde o problema entre os papéis nasce
Uma vez que já sabemos o que esses papéis são (ou deveriam ser), vamos ver possíveis fontes que fazem com que a multiplicidade deles apareça em um time ou uma empresa. Essa não é uma lista exaustiva, são apenas alguns fatos que acabam dando início ao problema.
Nenhum dos instrumentos definem como deve ser feito
Existe uma gama enorme de possibilidades de implantação dessas funções. Enquanto os livros definem de forma abrangente e abstrata o que eles fazem, nenhum detalha como eles fazem. Isso se deve ao fato de que cada empresa, cada contexto e cada mercado tem restrições e possibilidades próprias. Se algum documento tentar detalhar cada possibilidade ele seria maior do que as enciclopédias Barsa.
Infelizmente, isso abre para uma margem de interpretações diferentes. Muitas das veesperando que tudo funcionzes as pessoas criam restrições onde não existem e descrições que mantém tudo muito abstrato.
Falta de autorização
Já vimos algumas vezes as empresas criarem o papel do Product Owner, porém faltam-lhe acessos. Por exemplo, ele pode alterar o Product Backlog, mas não pode excluir uma história sem antes pedir autorização para alguém. Como a empresa possuía muitos product owners e esse agente autorizador tinha outras prioridades, criaram um papel de “Product Manager” para fazer a autorização. Como seria inadequado deixá-lo fazendo apenas isso, atribuíram novas responsabilidades genéricas para ele: “ter visão estratégica”, “alinhar demandas no longo prazo”. Frases e palavras que caem bem em um Business Bingo (jargões de negócio abstratos), mas que, não significam nada.
Falta de conhecimento
Quero trazer aqui uma frase de impacto do Marty Cagan:
“A verdade é que o gerente de produto precisa estar entre os maiores talentos na empresa.”
Segundo o autor, as pessoas de produtos devem ser os tops dos tops da empresa, visto que elas devem dominar um espectro amplo que vai desde análise de dados, projeção de cenários até facilitação de times. Não é pouca coisa.
Eu não iria tão longe. Obviamente, ter os tops dos tops seria excelente, porém nem sempre factível. Além do que acredito que as pessoas possam aumentar o conhecimento ao longo do tempo. Entretanto, atentando para o problema, quando temos muitas pessoas de produto em níveis iniciais, fatalmente faltará o conhecimento necessário sobre o cliente, produto, mercado etc. Nisso, as empresas acabam colocando um intermediário para suprir a falta de conhecimento. Nesse momento começam as sobreposições e abstrações desnecessárias.
Excesso de Controle
Muitas empresas possuem muitos controles. São dezenas de documentos, procedimentos, apresentações e indicadores que devem ser informados continuamente. Para isso, acabam criando uma hierarquia de papéis onde um gere o backlog, outro faz um Gráfico Gantt e outro conversa com o cliente.
Hype
Você vai em palestras e falam sobre as maravilhas dos papéis, você abre suas redes sociais e é a mesma situação. “Todos estão adotando” e não queremos ficar de fora do modismo. Então, temos que ter uma hierarquia deles. Terminamos com um empilhamento de papéis que gera confusão.
Rebranding de cargos e resquícios evolucionários
Às vezes, a empresa quer parecer moderna. O cargo era “Gerente de Projetos”, virou “Product Owner” porque “estamos fazendo ágil agora”. Fazem um simples ‘dê-para’, esperando que tudo funcione, mas não funciona.
Consultorias vendem, empresas compram
Consultorias adoram vender frameworks com nomes bonitos: dual-track agile, squad com PO+PM, tribo com chapter lead e feature lead. A promessa é sempre de mais clareza e mais valor. Infelizmente, implementa-se o cargo, mas não o contexto. Não há estratégia clara, nem autonomia real. O PM vira um “powerpoint manager”, o PO um “gestor de demandas” e o GP continua comandando o trem com base na data da entrega.
Quais os problemas que essa multiplicidade de papéis traz
Já vimos as origens da adoção de múltiplos papéis, agora vamos detalhar o problema que isso pode trazer a um time.
Intercessão de Responsabilidade
O primeiro problema é mais fácil de perceber é que há uma intercessão de responsabilidades nesses papéis. As fontes que estamos utilizando aqui dizem de uma forma ou de outra que eles devem:
- Definir um objetivo para o produto, metas e quais problemas o produto resolverá ou qual oportunidade ele aproveitará.
- Definir o escopo do projeto / produto
- Ser o responsável pelas decisões e direcionamento do produto.
- Comunicar e alinhar expectativas com time, cliente, gestores e demais stakeholders.
- Acompanhar o desenvolvimento
A essência desses papéis revela uma ampla sobreposição de funções e responsabilidades. Eventualmente um pisará no pé do outro. Imagine que você contrate três pessoas. Uma é uma excelente PO, outra é uma excelente PM e outra uma excelente GP. A partir daí, você precisa administrar o caos, pois se cada pessoa excelente fizer um excelente trabalho, elas irão fazer e desfazer o trabalho uma das outras. Isso infelizmente não tem uma solução prática, pois está no fundamento deles.
Utilizarei outra frase do livro do Martin Cagan:
“Em empresas de produto, é crucial que o Product Manager também seja o Product Owner.
Time com excesso de líderes
Eu tenho uma grande amiga que sempre me disse: “Cachorro com dois donos ou come demais ou morre de fome”. Depois que eu passei a ter um cachorro percebi que é verdade. Com um bom botafoguense não fico chateado com a comparação *, mas peço que você não se sinta mal pela frase de efeito. É apenas para fins de impacto mesmo. Entretanto imagine o seu time tendo que responder ao
- Product Owner
- Product Manager
- Gerente de Projeto
- Gerente Funcional
- Gerente do gerente funcional
- Líder Técnico
- Líder de UX
É muito cacique para pouco índio. O time ficará indo de um lado para o outro sem saber quem é a pessoa que realmente está a frente do projeto / produto.
* Uma das alcunhas da torcida do Botafogo é: cachorrada.
Diluição de Responsabilidade (Accountability)
Nome interessante e que costuma entrar no Bingo Business, mas realmente se torna um problema. Como a gestão do produto está com duas ou três pessoas, quem é o responsável real por ela. Com quem o time fala em caso de dúvida? Quem pode ser cobrado do quê?
Estive em um time que eles tinham uma planilha de assuntos e quem deveria tratar cada um deles. Imagine-se, como cliente, tentando obter uma informação e tendo que esperar alguém achar um assunto em uma planilha para você. O problema piora se você imaginar que um assunto, obviamente, terá impacto em outro assunto e o conhecimento fica todo diluído. O cliente fica tendo que repetir a mesma história várias vezes para várias pessoas.
E quem é o responsável para resolver isso? Depende, esse assunto é tratado pelo PO segundo a célula A5, mas se você quiser incluir também tal informação então terá que falar com o GP de acordo com a célula H9.
Falta de skin in the game (Arriscar a própria pele) *
Já que a responsabilidade está diluída, isso torna mais fácil com que as pessoas não tenham o “skin in the game”. Quando dá algum problema, você fatalmente ouvirá: “isso não era comigo”, “isso é responsabilidade do fulano (outro papel)”, “era até a minha responsabilidade, mas na situação X, isso fica com beltrano (outro papel)”.
* Nassim Nicholas Taleb escreveu o livro: Skin in the game (Arriscando a própria pele, em português). Ele fala sobre a pessoa ter algo pessoal em risco, seja financeiro, reputacional ou profissional, quando se toma uma decisão ou assume um compromisso. Isso cria um alinhamento de interesses e responsabilidades entre o decisor e o resultado da decisão.
Falta de confiança dos stakeholders
Já que ninguém é o responsável por “marcar o gol”, com quem os stakeholders falam quando precisam de algo? Se você é redirecionado o tempo todo para falar com pessoas diferentes, sobre um assunto, fatalmente perderá confiança nesse time / empresa.
Mudanças artificiais nas funções
Outro fato que costuma acontecer, para tentar reduzir as interseções é reduzir as responsabilidades. Surgem então frases como: “O Product Owner analisa o escopo de curto prazo e o Product Manager de médio/longo prazo”. Ou então algo como o “Product Manager cuida do product backlog e o Gerente de Projeto liga a estratégia da empresa”. “Papel X gere o backlog e Papel Y cuida de prazos, cronograma”
Perceba que na prática são atividades e responsabilidades inseparáveis. As restrições são artificialmente implementadas para justificar a existência e tentar manter a convivência entre múltiplos papéis. É muito, muito difícil de funcionar, principalmente se você escalar bons profissionais.
Síndrome da validação infinita (decisão ping-pong)
Quando há mais de uma figura com autoridade sobre o produto, qualquer decisão polêmica passa a ser empurrada de um papel para outro. Você escuta: “Preciso ver com o PO.”, “A gente já viu com o PM?” ou ainda, “O GP assinou isso?”. Essa validação em cadeia vira um ciclo vicioso de aprovações, gerando lentidão, frustração e baixa accountability. Como tudo que é ruim sempre pode piorar, isso é agravado quando os papéis estão em níveis diferentes da organização e há medo político de decidir.
Não “sujam a mão de graxa”
Este é um ponto especialmente delicado. Em um time temos diversos papéis que não estão propriamente trabalhando na construção do produto: os três aqui já mencionados, gestores, Scrum Masters, Coaches, entre outros. Eles são muitíssimo importantes, como bem diz Jeff Sutherland, criador do Scrum, um bom Scrum Master fará o time render 8x mais do que um time sem nenhum. Atualmente atuo como gestor e não creio ser irrelevante para meus times. Entretanto, não descarto o fato de que eu mesmo não sou a força motriz dos meus times. Se contratassem mais dois de mim, nós não ficaríamos nem mais eficientes e provavelmente perderíamos eficácia também.
Ter um acúmulo de papéis que não estão diretamente envolvidos na construção é muito prejudicial, pois uma hora, alguém fará a pergunta: “Por que estamos pagando mesmo Fulano e Beltrano por funções que são muito similares?”. O resultado nós vimos há bem pouco tempo com a retração econômica de 2021-2023. Criou-se um termo mais suave para disfarçar a realidade: layoff. No fundo, trata-se da velha e conhecida demissão.
Enquanto as grandes empresas estão financeiramente bem, há pouca preocupação com a sobreposição de papéis, mas na primeira fechada de tempo, começa a caça às bruxas, layoff e muita gente com o círculo verde #opentowork no LinkedIn.
Conclusão
O discurso é bonito: PO cuida do valor, PM da visão e GP da execução. Mas, na prática, a divisão de papéis é feita sem clareza nem contexto o que torna tudo em uma fábrica de desalinhamento. Multiplicam-se reuniões, conflitos de autoridade, decisões em looping e responsabilidades difusas. E o produto? Acaba ficando em segundo plano.
Se você puder opinar ou decidir, prefira escolher uma única pessoa para fazer esse papel de produteiro / produteira. Dê a ela o nome que for adequado, o poder necessário para desempenhar a função e o conhecimento que ela precisar. Um feijão com arroz bem feito é muito melhor do que uma sequência de pratos desconjuntados, insossos e visualmente desprovidos de beleza.
Ponto extra: IA é ferramenta e não identidade
Novas buzzwords surgem: AI Product Manager, AI Product Owner e similares. Títulos como saiba a diferença entre o Product Ower e o AI Product Owner. NÃO CONFUNDA FERRAMENTA COM IDENTIDADE! Criar esses papéis é o equivalente a ter cargos como Excel Product Manager, Jira Product Owner, MS Project-Project Manager, PowerPoint PM. Não faz sentido.
A Inteligência Artificial é uma bela ferramenta para o produteiro / produteira, mas não faz parte da identidade dele / dela. Se você ocupa esse papel, você é O responsável pelo projeto, produto ou serviço. A IA te ajuda, mas a responsabilidade é sua. Não existe a possibilidade de delegação para uma ferramenta.
Outros artigos sobre o tema
Quer saber mais sobre papéis na criação de projetos, produtos e serviços, dá uma olhada nesses artigos:
Product Owner
Product Owner: quem é e o que faz
Saiba quais são as responsabilidades do Product Owner
CSPO: como obter e por que ele é importante para a carreira de Product Owner?
Os sete arquétipos de um Product Owner
Product Manager
Qual é a diferença entre Product Manager e Product Owner?
Group Product Manager X Product Manager
Service Request Manager
O Product Owner do Scrum e o Service Request Manager do Kanban
Scrum Master
Scrum Master de verdade: quem são, o que fazem e o que deveriam fazer
Advanced Scrum Master: O próximo passo na sua carreira!
Desenvolvedores
Quem é o Time de Desenvolvimento do Scrum?
As disfunções do Time de Desenvolvimento – Parte 1
As disfunções do Time – Parte II – Problemas que podemos evitar
