Quase toda descrição de vaga de PM diz algo como "defina a visão do produto", "trabalhe com stakeholders multifuncionais" e "seja o CEO do produto". Nenhuma dessas frases explica o que você vai fazer na segunda-feira de manhã.

Esse artigo explica. Sem eufemismo de JD.

A semana de um PM na prática

Não existe uma semana típica universal. Mas existem padrões que aparecem em quase todo contexto, independente do porte da empresa ou do estágio do produto.

Rituais de processo e engenharia

Na maior parte das semanas, um PM passa tempo em refinamento de backlog com o time de engenharia: entendendo o que vai entrar na próxima sprint, o que está bloqueado, e o que precisa de mais clareza técnica antes de poder ser estimado. Esse momento existe para garantir que o time nunca comece uma história sem informação suficiente para executá-la.

Planning, review e retrospectiva aparecem de forma recorrente em times que usam metodologias ágeis. Na review, o PM normalmente apresenta o que foi entregue para stakeholders e coleta feedback. Na retrospectiva, é o momento de ajustar o processo — e bons PMs participam ativamente em vez de tratar como reunião do time de engenharia.

Discovery e trabalho com usuários

Fora dos rituais, um PM saudável passa tempo em discovery: conversas com usuários, análise de métricas, revisão de pesquisas de UX, priorização baseada em evidência. A proporção de tempo dedicada a isso varia enormemente entre empresas — em algumas, discovery é estruturado e recorrente; em outras, acontece informalmente quando o PM percebe que está construindo sem entender o problema direito.

Escrita e comunicação interna

PRDs, briefs de produto, emails explicando decisões, documentos de contexto para stakeholders de negócio. PMs escrevem muito. E a qualidade da escrita reflete diretamente a qualidade do raciocínio — um PRD mal escrito normalmente indica um problema mal definido, não uma questão de texto.

PM vs PO: a diferença real

PM (product manager) e PO (product owner) são termos usados de formas diferentes em empresas diferentes. Qualquer pessoa que afirme que existe uma definição única e definitiva está ignorando como o mercado brasileiro funciona.

O que o Scrum diz sobre PO

PO, no sentido técnico que vem do framework Scrum, é o papel responsável por gerenciar o backlog e garantir que o time de desenvolvimento tenha clareza sobre o que construir. É um papel mais tático, mais próximo do time técnico, mais focado no "como vamos construir isso" do que no "por que vamos construir isso".

Como as empresas brasileiras usam os títulos

PM tende a carregar uma conotação mais estratégica: definir o que construir e por quê, com base em entendimento de mercado, usuário e negócio. Em muitas empresas brasileiras de médio porte, o mesmo profissional faz as duas coisas e recebe qualquer um dos dois títulos dependendo da cultura da empresa. Em empresas grandes ou com metodologia mais formal, às vezes são funções separadas com pessoas diferentes.

Na prática, quando você entra numa empresa como PM ou PO, a pergunta mais importante na entrevista é: "O que você espera concretamente desse papel nos primeiros noventa dias?" Os títulos mudam mais do que as responsabilidades, e saber o que se espera de você evita surpresas no primeiro mês.

O que é discovery — e por que desaparece quando o prazo aperta

Discovery é o processo de entender o problema antes de construir a solução. Em tese, todo PM concorda que isso é importante. Na prática, discovery é a primeira coisa que some quando o roadmap está atrasado.

Feature factory: o que acontece sem discovery

O resultado de pouco discovery é o que a indústria chama de "feature factory": um time que entrega funcionalidades constantemente mas não move métricas de negócio porque não entendeu o problema que estava tentando resolver. O time está ocupado. O produto não está melhorando.

Os sinais de uma feature factory são reconhecíveis: backlog crescendo mais rápido do que é priorizado, ausência de métricas de sucesso definidas antes do desenvolvimento começar, e stakeholders avaliando o time pelo número de funcionalidades entregues em vez do impacto gerado.

Como discovery acontece na prática

Fazer discovery não significa pesquisa qualitativa extensa em todo projeto. Às vezes são cinco conversas com usuários. Às vezes é olhar para os dados de comportamento e perguntar por que aquela métrica está assim. O que muda é a mentalidade: você está construindo porque entende o problema, não porque alguém pediu.

Discovery contínuo significa que você nunca para de aprender sobre seus usuários — independente de onde está no ciclo de entrega. É uma mentalidade, não uma fase. Para entender como estruturar esse processo na prática — quais técnicas usar, quando fazer discovery e como saber se está funcionando — veja o guia sobre como fazer discovery de produto que muda o que você constrói.

O papel do PM no delivery

No delivery, PM não é o gerente do projeto. Não é responsável por cronograma nem por garantir que todo mundo está fazendo o que precisa ser feito. Isso é responsabilidade do time como um todo, muitas vezes facilitada pelo Scrum Master ou pelo próprio time de engenharia.

O que o PM precisa fazer durante o desenvolvimento

O papel do PM no delivery é garantir clareza: que o time entende o problema que está resolvendo, que as histórias de usuário têm critérios de aceite precisos, e que quando surgir uma decisão técnica com implicação de produto o PM está disponível para decidir rápido — em minutos, não em dias.

PM que some durante o delivery e aparece só para revisar o que foi entregue cria ruído e atraso. O time de engenharia precisa de contexto para tomar boas decisões no meio do desenvolvimento, e o PM é quem tem esse contexto.

O mito do CEO do produto

"PM é o CEO do produto" é uma analogia que faz mais mal do que bem para quem está começando na área.

CEO tem autoridade formal. PM não tem. PM não manda em engenharia, não manda em design, não manda em dados. PM influencia, convence, alinha. Se você entra num papel de PM achando que vai dar ordens e as pessoas vão executar, vai ter problemas rápido — e vai entender por que essa analogia é tão equivocada.

O que PM tem em vez de autoridade

O que PM tem é contexto e convicção. Contexto sobre o usuário, o mercado e o negócio. Convicção sobre o que precisa ser feito e por quê. Quando esses dois elementos estão presentes, influência vem naturalmente. Quando faltam, o título não supre.

Essa é a habilidade central de um PM: construir convicção baseada em evidência e conseguir que outras pessoas compartilhem essa convicção sem precisar de autoridade formal. Nenhum framework ensina isso diretamente. Vem de prática, de feedback, e de observar PMs bons trabalhando de perto.

E se você está considerando entrar na área, o artigo sobre como fazer a transição para product manager cobre o que realmente separa quem consegue a primeira vaga de quem fica rodando em círculos.

Duas das relações mais importantes no dia a dia de um PM são com engenharia e com design. Para entender como construir uma parceria que funciona com o time de design, veja o artigo sobre como PM e designer trabalham bem juntos.

Se você quer entender o papel de produto na prática, além da teoria dos livros e das JDs, a comunidade mágica é o lugar onde PMs experientes e pessoas em transição discutem o que o trabalho realmente é.