Você não precisa saber todos os termos para trabalhar com produto. Mas alguns são tão centrais que aparecem em toda reunião, toda entrevista, toda discussão de estratégia. Não saber o que eles significam de verdade causa ruído real — especialmente em entrevistas, onde usar um termo sem conseguir explicar o conceito por trás é pior do que não usar o termo.

Esse guia cobre os que mais aparecem e explica o que cada um significa na prática, não no glossário.

Discovery e delivery

Discovery é o processo de entender o problema antes de construir a solução. Delivery é o processo de construir. São os dois grandes modos de trabalho de qualquer time de produto. Para ver como esses dois modos se encaixam na rotina real de um PM, veja o artigo sobre o que faz um product manager no dia a dia.

Por que discovery desaparece quando o prazo aperta

Numa empresa saudável, discovery e delivery acontecem em paralelo: enquanto o time entrega uma funcionalidade, o PM já está entendendo os próximos problemas a resolver. O erro comum é tratar discovery como uma fase separada que termina antes do desenvolvimento começar.

Na prática, quando alguém diz "precisamos fazer mais discovery", está dizendo que o time está construindo coisas sem evidência suficiente de que elas resolvem um problema real. Discovery contínuo significa que você nunca para de aprender sobre seus usuários — independente de onde está no ciclo de entrega.

O que é feature factory e como reconhecer

Feature factory é o estado em que um time de produto fica quando passa a maior parte do tempo entregando funcionalidades sem validar se elas resolvem problemas reais. O time está ocupado. O produto não está melhorando.

Os sinais mais comuns: backlog que cresce 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 volume de entregas em vez do impacto gerado. Reconhecer esse padrão é uma habilidade importante — tanto para saber o que evitar quanto para saber o que perguntar numa entrevista sobre como a empresa trabalha.

Outcome vs output

Output é o que você entregou: uma funcionalidade, uma tela, um relatório. Outcome é o resultado desse output no comportamento do usuário ou nos números do negócio.

Por que a distinção importa na prática

Times que medem sucesso por output tendem a construir muito e mover pouco. "Entregamos doze funcionalidades no trimestre" não diz nada sobre se o produto está melhor. "Aumentamos retenção de trinta dias em oito pontos percentuais" diz.

Quando você descreve seu trabalho — em entrevistas, no LinkedIn, num portfólio — sempre que possível descreva pelo outcome. Não "implementei o onboarding de usuário novo". Mas "redesenhei o onboarding e isso reduziu o drop na ativação em 15%".

Essa distinção também aparece em discussões de roadmap. Quando alguém diz "vamos adicionar a feature X", a pergunta de produto é: qual outcome esperamos que essa feature gere? Se ninguém consegue responder com uma métrica específica, o item merece mais discovery antes de entrar no desenvolvimento.

North Star Metric

A North Star Metric (NSM) é a métrica que melhor representa o valor que o produto entrega para o usuário. É diferente de métrica de negócio (receita, usuários ativos) porque está centrada no usuário, não na empresa.

Exemplos reais de North Star Metric

Para o Spotify, uma North Star possível seria "minutos de música ouvida por usuário ativo". Para o Airbnb, "noites reservadas por hóspede ativo". Para o iFood, "pedidos entregues com avaliação acima de quatro por usuário ativo no mês".

Na prática, times usam a North Star como bússola para priorização: a funcionalidade que estamos considerando vai mover essa métrica? Se não, vale fazer agora? Essa pergunta, feita com consistência, é o que separa times que entregam impacto de times que entregam output.

O que significa escolher uma North Star

Não existe uma North Star certa para todo produto. O que existe é um processo de discussão sobre qual métrica melhor captura o valor entregue ao usuário — e esse processo em si é valioso porque força o time a alinhar o que "sucesso" significa.

OKR: objetivo e resultados-chave

OKR (Objectives and Key Results) é um framework de definição de metas. O Objective é qualitativo e direcional: "Tornar nosso onboarding o melhor da categoria". Os Key Results são quantitativos e mensuráveis: "Aumentar taxa de ativação no D1 de 40% para 55%" e "Reduzir tempo até primeiro valor percebido de sete para três dias".

O erro mais comum ao usar OKR

O erro mais comum é usar OKR como lista de tarefas. "Lançar feature X" não é um Key Result — é uma atividade. Key Result mede resultado, não atividade. Se você não consegue medir o Key Result sem executar uma tarefa específica, ele provavelmente está no nível errado.

Para PMs em entrevista, a pergunta clássica é: "Como você mediria o sucesso desse produto?" A resposta que impressiona conecta a métrica ao comportamento do usuário, não ao output de engenharia. Para aprofundar no uso de OKRs na prática — como escrever KRs que realmente guiam priorização e não viram burocracia — veja o guia sobre OKRs para product managers.

Épico, história de usuário e DoR

Um épico é um agrupamento grande de trabalho relacionado. Dentro de um épico, existem histórias de usuário: descrições de uma necessidade do ponto de vista de quem usa o produto.

O formato de história de usuário e por que importa

O formato clássico de história é "Como [tipo de usuário], quero [ação] para [benefício]". Esse formato existe por uma razão: força o time a pensar sempre no ponto de vista do usuário, não da empresa ou da tecnologia. Uma história bem escrita é verificável — você consegue, ao final do desenvolvimento, testar se o usuário consegue fazer aquela ação e obter aquele benefício.

DoR (Definition of Ready) é o conjunto de critérios que uma história precisa atender antes de entrar numa sprint. Serve para evitar que o time comece a trabalhar numa história com informações incompletas. Uma história está "pronta" quando o time tem clareza suficiente para estimar e executar sem precisar interromper constantemente para pedir mais contexto do PM.

Para entender como as métricas mencionadas aqui — ativação, retenção, NPS, North Star — funcionam na prática do produto, veja o artigo sobre métricas de produto que todo PM precisa entender.

Para aprofundar no vocabulário e na rotina de produto, a comunidade mágica tem hot seats quinzenais onde PMs discutem casos reais — é onde os termos ganham contexto prático, não só definição.