Product Management: por que a disciplina que separa startups de unicórnios ainda é mal compreendida

O que um Product Manager realmente faz

Spoiler: não é criar User Stories nem entrar em planning. Product Manager é o profissional responsável por resolver o problema certo, da forma certa, no menor tempo possível. Isso exige domínio em três dimensões: entendimento profundo do usuário, visão estratégica do negócio e capacidade de influenciar sem autoridade formal.

A armadilha mais comum em empresas brasileiras é transformar o PM em um proxy do cliente. Ele coleta requisitos, transforma em backlog e entrega para engenharia. Nessa configuração, o PM é essencialmente um tradutor de pedidos. Funciona até você perceber que sua equipe está construindo um produto que nenhum usuário pediu.

As quatro dimensões do trabalho de produto

O framework que melhor representa o trabalho real do PM é o Opportunity Assessment, proposto por Marty Cagan. Ele parte de quatro perguntas:

Um PM que entrega uma feature sem passar por essas quatro lentes está acumulando dívida de produto. Feature útil mas impossível de manter? Dívida técnica. Feature desejada mas que ninguém sabe usar? Dívida de usabilidade. Feature bonita mas que não move métricas? Dívida estratégica.

Product Discovery: onde a maioria falha

Discovery é a fase mais negligenciada nas empresas de tecnologia. O motivo é simples: não produz artefatos visíveis. Roadmap, sprint, demo todo mundo vê. Research, experimentação, validação de hipóteses não aparecem em nenhuma retrospectiva.

O resultado é previsível: equipes de engenharia brilhantes, com alta capacidade de execução, construindo produtos que ninguém usa. O fenômeno tem nome: Feature Factory.

"Você não sabe o que seus usuários precisam até observar o que eles fazem, não o que eles dizem." Marty Cagan

A disciplina de discovery exige rituais específicos:

• Entrevistas de contexto: observar usuários no ambiente natural, não em sala de aula.
• Shadowing: acompanhar o fluxo real de trabalho por horas, não por minutos.
• Jobs to be Done: focar na progressão do usuário em direção a um objetivo, não em funcionalidades.
• Testes de conceito: validar antes de construir, com protótipos de papel ou mocks clicáveis.
• Experimentação: rodar A/B tests pequenos antes de commit de engenharia.

Diagrama do ciclo de vida de um Product Manager: Descobrir, Definir, Desenvolver, Entregar, Medir

flowchart TD
    A[Descobrir] --> B[Definir]
    B --> C[Desenvolver]
    C --> D[Entregar]
    D --> E[Medir]
    E -->|Feedback| A

O diagrama acima mostra o ciclo completo. Note que Medir conecta de volta a Descobrir. Esse feedback loop é o que diferencia produto iterativo de projeto sequencial. Sem ele, você está especulando.

Priorização: frameworks e a armadilha do scoring

Quando o backlog cresce, a tentação é criar uma planilha de scoring com 47 critérios de priorização. Raramente isso funciona. Por quê? Porque priorização de produto é fundamentalmente sobre tradeoffs, não sobre pontuação.

Três frameworks que resistem ao teste de produção:

RICE

Score = (Reach × Impact × Confidence) / Effort

Simples, exige calibração inicial, mas funciona para equipes aprendendo a pensar em termos de impacto. O erro mais comum é tratar Reach, Impact e Confidence como variáveis independentes quando na prática são correlacionadas.

Value vs. Complexity

Plotar cada iniciativa em um quadrante 2x2: alto valor, baixa complexidade vai para o topo da fila. Baixo valor, alta complexidade é eliminada. A discussão sobre posicionamento no quadrante é o verdadeiro valor do framework, não a posição em si.

Must / Should / Could / Won't

MoSCoW. Funciona bem para alinhamento com stakeholders porque é difícil de argumentar contra. "Essa feature é Should ou Could?" é uma pergunta que expõe premissas rapidamente.

A regra de ouro: o melhor framework de priorização é aquele que sua equipe realmente usa e entende o rationale por trás. Uma matriz de priorização sofisticada que ninguém consulta é pior que uma lista simples com datas de validade.

Métricas: o que medir e por que a maioria das dashboards está errada

Métricas de produto existem para uma coisa: informar decisões. Qualquer métrica que não leva a uma ação é ruído.

A armadilha comum é o Vanity Metrics: pageviews, usuários cadastrados, downloads. Números que sobem e fazem o executivo dormir feliz, mas não indicam se o produto está melhorando.

Métricas que realmente importam dependem do estágio do produto:

"Se você não consegue medir, você não consegue melhorar. Mas se você medir a coisa errada, você vai melhorar a coisa errada." Peter Drucker

Como configurar OKRs que não viram KPI theater

OKRs se tornaram uma piada em muitas empresas porque foram implementados como cascata de metas, não como instrumento de alinhamento e aprendizado. A diferença:

Objective: Aumentar conversão
Key Result 1: Aumentar conversão de 2% para 3%
Key Result 2: Reduzir churn de 5% para 3%


Objective: Descobrir o que impede ativação
Key Result 1: 5 entrevistas com usuários que abandonaram no checkout
Key Result 2: Testar 3 hipóteses de fricção com A/B
Key Result 3: Documentar aprendizados e propor ação para Q2

O segundo formato é desconfortável porque não garante resultado. É exatamente por isso que funciona. OKRs ambíguos demais viram marketing. OKRs com metas garantidas viram trabalho braçal. O ponto é manter tensão criativa.

O que separa startups de unicórnios

Volto à provocação inicial: a diferença entre empresas que crescem e empresas que queimam dinheiro construindo features não está no framework de priorização ou na sofisticação das métricas. Está em uma única decisão: investir em discovery antes de investir em delivery.

Equipes de alto desempenho fazem discovery constantemente, mesmo quando estão no meio de um sprint de entrega. Elas tratam o roadmap como hipóteses, não compromissos. E elas sabem que o trabalho mais importante do PM acontece antes de qualquer linha de código ser escrita.

Se sua equipe de engenharia está sempre ocupada e seu produto não está crescendo, o problema não é velocidade de execução. É que ninguém está descobrindo o que construir.

Sua equipe de produto está descobrindo problemas ou apenas executando requests? Vamos conversar por 30 minutos sobre como estruturar a disciplina na sua empresa, sem compromisso.

Fale com um especialista da Eficify