O Que É Product Manager

O que você realmente faz quando ninguém está olhando

Product manager é um cargo que parece simples na descrição mas que na prática é uma série de decisões ruins com dados incompletos. O título varia entre empresas, algumas chamam de gerente de produto, outros de head de produto, e em startups pequenas literalmente todo mundo faz tudo junto. O core do trabalho é decidir o que construir, para quem, e por quê, mas a parte que ninguém conta nas descrições de vaga é que 60% do tempo você passa convencendo pessoas de que a decisão foi boa. Na minha experiência, o papel se divide em três camadas. A camada estratégica é onde você define a direção do produto, o que significa coisas como priorizar entre manter features existentes versus desenvolver novas funcionalidades. A camada tática envolve traduzir essa direção em user stories, especificações e roadmaps que o time de engenharia consegue executar. A camada operacional é o trabalho sujo de remover bloqueios, coordenar entre times e garantir que nada quebre quando for para produção. Um exemplo concreto. Trabalhei em uma plataforma de e-commerce onde tínhamos que escolher entre melhorar o sistema de recomendações ou refazer o checkout. Os dados de engenharia puxavam para o checkout porque o ticket médio caía muito nos abandonos. Eu puxava para as recomendações porque a retenção trimestral tinha caído 18%. A solução foi rodar um A/B test controlado no checkout primeiro, identificar que o problema principal era o campo de Cupom que travava em 30% dos casos, e depois realocar a equipe de recomendações para trabalhar em parallel. Isso economizou cerca de três semanas de delay que teríamos se tivesse ido para um ou outro sozinho.

Ferramentas que funcionam e as que são perda de tempo

Jira e Linear são osmais comuns para gestão de backlog. Eu uso Linear porque permite configurar workflows customizados sem precisar de permissão do time de DevOps, o que economiza reuniões de alinhamento que nunca decidem nada. Para documentação, Notion ainda é o padrão da indústria, mas se você tem mais de cinco produtos simultâneos, considere migrar para Confluence ou até ferramentas mais leves como Craft. A diferença é que Notion tende a criar arquivos órfãos que ninguém atualiza há meses. Firebase Remote Config e LaunchDarkly são essenciais para feature flags. Sem feature flags, você não consegue fazer releases gradativos nem rollback rápido. Um release sem feature flag é um tiro no escuro. Ferramentas de analytics como Mixpanel ou Amplitude são obrigatórias, mas o erro mais comum que vejo é times que coletam métricas demais e analisam de menos. Configure apenas quatro a cinco métricas de norte estrela e ignore o resto.

O que ninguém te conta sobre o cargo

Product manager precisa ter empatia com usuários e com engenharia ao mesmo tempo, e essas duas empatias frequentemente conflitam. Usuários querem features novas. Engenharia quer refatorar código legado. O trabalho do PM é encontrar o ponto onde ambas as necessidades se encontram, o que muitas vezes significa dizer não para ambas as partes. É uma posição socialmente desgastante porque você é o único responsável pela decisão e o único culpado quando dá errado. Outra coisa contraintuitiva: quanto mais senior você fica, menos product management operacional você faz. Em nível júnior, você escreve user stories e acompanha sprints. Em nível pleno, você começa a definir strategy de produto. Em nível director ou VP, o trabalho é quase inteiramente sobre people management e alinhamento estratégico com outras áreas. Se você gosta de executar e não de gerir pessoas, talvez product ownership seja mais adequado do que product management puro.

Pontos cegos que custam caro

O maior erro de PMs iniciantes é focar em output em vez de outcome. Entregar uma feature no prazo não é um sucesso. O sucesso é a feature gerar o resultado esperado. Eu já vi times celebrarem sprints completos que não moviam nenhuma métrica de negócio. Isso acontece quando o roadmap é feito baseado em pedidos de stakeholders e não em hipóteses validáveis. Outro problema comum é a armadilha do Sunk Cost. Produto que não está funcionando continua recebendo investimento porque "já gastamos tanto". A regra prática que eu adotei é: se um produto não atinge 40% da métrica de sucesso em três meses, seja um sunset planejado ou uma pivot completa. Quanto mais tempo você espera, maior é o custo de correção. Um case específico que enfrentei: tínhamos um produto interno de gestão de estoques que os usuários alegavam ser essencial. Coletamos feedback por três meses e descobrimos que 73% dos usuários usavam planilhas paralelas porque o sistema não suportava o fluxo real de trabalho. A decisão foi sunsetear o produto e construir um novo baseado nas planilhas. O custo foi alto, mas continuar mantendo o sistema legado custaria pelo menos o triplo em desenvolvimento ocioso.

Como começar sem formatura específica

A área não exige formação em TI. Pessoas de diversas áreas — administração, design, psicologia, engenharia — conseguem transicionar bem desde que desenvolvam raciocínio analítico e capacidade de comunicação técnica. Cursos de produtos digitais da Escola de Product Management ou do Product School são sólidos para começar. Mas o mais importante é praticar com produtos reais, mesmo que seja analisando um app que você usa no dia a dia e tentando identificar problemas de UX que poderiam ser resolvidos. Leitura recomendada: "Inspired" de Marty Cagan para foundations, "Continuous Discovery Habits" de Teresa Torres para metodologias práticas, e "Escaping the Build Trap" de Melissa Perri para entender a diferença entre output e outcome. Nenhum desses livros é perfeito, mas juntos cobrem cerca de 80% do que você precisará nos primeiros dois anos.