Métricas que todo PO precisa conhecer

Nível: Júnior | Duração estimada de leitura: 17 minutos | Categoria: Trilha Júnior — Módulo 2

Introdução

Existem dois tipos de PO quando o assunto é métricas.

O primeiro abre o dashboard toda semana, olha para os números, diz "cresceu" ou "caiu" e fecha. Tem uma sensação de controle — mas na verdade está navegando no escuro com os olhos abertos.

O segundo usa métricas como bússola: sabe exatamente o que cada número representa, por que está medindo aquilo, e o que vai fazer diferente dependendo do que os dados mostram. Cada lançamento tem uma hipótese. Cada hipótese tem uma métrica. Cada métrica tem um dono.

A diferença entre os dois não é acesso a ferramentas melhores. É clareza sobre o que medir e por quê.

Neste módulo você vai construir essa clareza — entender as métricas fundamentais de produto com profundidade suficiente para usá-las no dia a dia, não apenas citá-las em reunião.

Métricas de vaidade vs. métricas de produto

Antes de falar nas métricas certas, precisamos falar nas erradas — porque elas aparecem em todo dashboard corporativo e parecem razoáveis até você entender o que realmente representam.

Métricas de vaidade são números que crescem, ficam bem em apresentação para o board e não dizem nada sobre a saúde real do produto. Exemplos: número total de downloads desde o lançamento, quantidade de usuários cadastrados (sem distinção de quem usa de fato), pageviews totais do site, seguidores nas redes sociais, número de features lançadas no trimestre.

O problema não é que esses números sejam falsos. É que eles não revelam o comportamento que importa. Um aplicativo com 500 mil downloads e 3% de retenção no 30º dia tem um problema gravíssimo — mas o número de downloads sozinho faz parecer que está tudo indo bem. Um blog com 1 milhão de pageviews onde 90% dos visitantes saem em menos de 10 segundos tem um problema de produto, não de tráfego.

Métricas de produto medem comportamentos reais que indicam valor sendo entregue. Elas são difíceis de inflar artificialmente, respondem diretamente à pergunta "o produto está funcionando?" e mudam de verdade quando você faz algo certo — ou alertam quando algo foi feito errado.

A regra prática: se você consegue fazer um número crescer sem melhorar a experiência do usuário, ele provavelmente é uma métrica de vaidade.

As categorias de métricas que todo PO precisa dominar

O framework AARRR — criado pelo investidor americano Dave McClure e chamado de "Pirate Metrics" por conta da sigla — organiza as métricas de produto em cinco categorias que cobrem o ciclo completo do usuário: Aquisição, Ativação, Retenção, Receita e Indicação (Referral, em inglês). Cada categoria responde a uma pergunta diferente sobre a saúde do produto.

Aquisição — como os usuários chegam até você

Antes de qualquer coisa, o produto precisa ser encontrado. As métricas de aquisição medem o volume e, mais importante, a qualidade dos novos usuários que chegam.

CAC — Custo de Aquisição de Cliente

Em português simples: quanto de dinheiro a empresa gasta, em média, para trazer um novo cliente pagante. Se a empresa investiu R$ 100.000 em marketing em um mês e conquistou 200 novos clientes pagantes, o CAC é de R$ 500.

Por que isso importa para o PO? Porque se o CAC é muito alto em relação ao que o cliente gera de receita ao longo do tempo, o negócio não é sustentável — não importa quantas features você lance. O PO que entende o CAC consegue priorizar melhor: uma feature que melhora a conversão de cadastro gratuito para pago pode reduzir o CAC de forma significativa.

Taxa de conversão por canal

Cada canal que traz usuários — Google, Instagram, indicação de amigos, busca orgânica — converte de forma diferente. Taxa de conversão é o percentual de pessoas que chegam por aquele canal e viram usuários ativos.

Um canal pode trazer muito volume mas baixa conversão (usuários que chegam mas não ficam). Outro pode trazer pouco volume mas altíssima conversão. Entender essa diferença ajuda o PO a priorizar melhorias na jornada de entrada para os canais mais valiosos.

Ativação — o momento em que o usuário entende o valor

Ativação é o instante em que o usuário experimenta o valor central do produto pela primeira vez — o chamado "aha moment". Antes desse momento, o usuário ainda está avaliando se o produto vale o seu tempo. Depois dele, as chances de continuar usando aumentam drasticamente.

Taxa de ativação

É o percentual de usuários que chegam ao produto e completam a ação que define o aha moment. Se 1.000 usuários se cadastraram no mês e 300 completaram o aha moment, a taxa de ativação é de 30%.

Mas o que é o aha moment? Depende do produto. No Spotify, é ouvir a primeira música. No Slack, é trocar as primeiras mensagens com o time. Em um e-commerce, é completar a primeira compra. Em uma plataforma de aprendizado como o Backlogando, pode ser concluir o primeiro módulo de uma trilha.

Encontrar e otimizar esse momento é uma das alavancas de crescimento mais poderosas do produto. Uma melhoria de 10 pontos percentuais na taxa de ativação pode ter mais impacto no crescimento do que dobrar o investimento em aquisição.

TTV — Time to Value (Tempo para o Valor)

Quanto tempo leva desde o cadastro do usuário até ele experimentar o valor central? Um TTV alto — quando o usuário precisa passar por muitas etapas antes de sentir o benefício do produto — é um risco enorme. Cada passo a mais entre o cadastro e o aha moment é uma oportunidade de abandono.

Reduzir o TTV é frequentemente uma das prioridades mais valiosas do backlog, especialmente em produtos novos.

Completion rate do onboarding

O onboarding é o fluxo que guia o novo usuário pelos primeiros passos do produto. O completion rate mede quantos usuários completam esse fluxo do início ao fim. Se a maioria abandona na metade, existe uma etapa que está gerando fricção excessiva — e o discovery (módulo anterior) vai te ajudar a descobrir qual.

Retenção — o coração da saúde do produto

Se você pudesse acompanhar só uma categoria de métricas, seria esta. Retenção é a prova mais direta de que o produto tem valor real. Um produto que não retém usuários não tem product-market fit — tem um funil com um buraco no fundo. Você coloca usuários de cima e eles escorrem por baixo.

Retenção por coorte

Coorte é um grupo de usuários que chegou ao produto no mesmo período — por exemplo, "todos os usuários que se cadastraram em janeiro". A retenção por coorte mede qual percentual desse grupo continua usando o produto após 1 dia (D1), 7 dias (D7), 30 dias (D30), e assim por diante.

Por que analisar por coorte e não por total de usuários? Porque o total de usuários ativos pode crescer mesmo que a retenção esteja caindo — simplesmente porque a aquisição está cobrindo a saída. A análise por coorte revela a verdade sem essa distorção.

Como ler uma curva de retenção: ela começa em 100% (todos os usuários do grupo) e cai ao longo do tempo. O que importa é onde ela se estabiliza. Se cai para zero, ninguém ficou — o produto não tem valor sustentável. Se estabiliza em 20% no D30, significa que 20% dos usuários continuam voltando após um mês — e esse é o núcleo mais valioso do produto.

Churn Rate

Churn (pronuncia-se "tchern") é a taxa de cancelamento ou abandono. Em produtos SaaS (software pago por assinatura), é o percentual de clientes que cancelaram no período. Em apps, pode ser medido como o percentual de usuários que não voltaram após X dias.

Um churn de 5% ao mês parece pequeno, mas significa que em 12 meses você perdeu mais da metade da base. Reduzir churn tem impacto exponencial no crescimento — é matematicamente mais eficiente do que aumentar aquisição.

DAU/MAU Ratio

DAU significa Daily Active Users (usuários ativos diários) e MAU significa Monthly Active Users (usuários ativos mensais). O ratio entre os dois indica com que frequência os usuários retornam ao produto.

Se o produto tem 10.000 usuários ativos por mês mas apenas 1.000 por dia, o ratio é de 10% — a maioria usa raramente. Se tem 10.000 ativos por mês e 5.000 por dia, o ratio é de 50% — a maioria volta com frequência. Para produtos que dependem de uso diário (redes sociais, apps de produtividade), um ratio acima de 50% indica engajamento saudável.

Receita — o produto gera valor de negócio

Métricas de receita conectam o trabalho do produto ao resultado financeiro da empresa. O PO não é responsável pela estratégia de precificação — mas precisa entender essas métricas para tomar decisões de produto que impactem positivamente os números.

MRR — Monthly Recurring Revenue (Receita Recorrente Mensal)

Em produtos com assinatura (SaaS, plataformas de conteúdo, apps premium), o MRR é a soma de toda a receita que a empresa vai receber com certeza naquele mês, com base nos contratos e assinaturas ativas. É a métrica de saúde financeira mais importante para esse tipo de produto porque é previsível e recorrente — diferente de uma venda pontual.

Exemplo: se a plataforma tem 500 assinantes pagando R$ 50/mês, o MRR é R$ 25.000.

ARR — Annual Recurring Revenue (Receita Recorrente Anual)

É simplesmente o MRR multiplicado por 12. Usado como referência para avaliar o tamanho e crescimento de empresas de tecnologia. Quando uma startup diz que faturou "1 milhão de ARR", está dizendo que tem R$ 1 milhão em contratos anuais recorrentes.

LTV — Lifetime Value (Valor do Tempo de Vida do Cliente)

Quanto de receita um cliente gera para a empresa ao longo de todo o período em que permanece como cliente. Se um cliente paga R$ 100/mês e fica em média 24 meses antes de cancelar, o LTV é R$ 2.400.

O LTV precisa sempre ser avaliado em relação ao CAC. A relação saudável é: LTV deve ser pelo menos 3 vezes maior que o CAC. Se o LTV é R$ 2.400 e o CAC é R$ 800, a relação é de 3:1 — sustentável. Se o CAC for R$ 2.000 para um LTV de R$ 2.400, a conta não fecha.

ARPU — Average Revenue Per User (Receita Média por Usuário)

Divide a receita total pelo número de usuários ativos. Ajuda a entender quanto valor financeiro cada usuário gera em média e a comparar segmentos diferentes. Um PO pode usar o ARPU para priorizar features que atendem segmentos de maior valor.

ROI — Return on Investment (Retorno sobre Investimento)

O ROI mede o retorno obtido em relação ao investimento realizado. No contexto de produto, é a métrica que conecta cada decisão de backlog ao resultado financeiro — e a que mais convence stakeholders e liderança quando bem calculada.

A fórmula é: (Ganho obtido − Custo do investimento) ÷ Custo do investimento × 100

Se uma feature custou R$ 50.000 em esforço de desenvolvimento e gerou R$ 200.000 em receita adicional no trimestre, o ROI é de 300%.

Mas no produto, o ganho raramente é só receita direta. Ele pode vir de formas diferentes:

• Ganho por aumento de receita: feature que aumenta conversão ou ticket médio
• Ganho por redução de custo: automação que reduz atendimentos no SAC
• Ganho por retenção: redução do churn tem valor financeiro direto — cada cliente retido é LTV preservado
• Ganho por eficiência operacional: feature que economiza horas do time interno tem valor calculável

O PO que sabe estimar o ROI esperado de uma entrega tem um argumento muito mais sólido para priorização do que o que usa apenas intuição. "Esta feature tem ROI estimado de 180% em 6 meses com base na redução de 30% no volume de tickets de suporte" é completamente diferente de "o cliente pediu".

Atenção aos custos que muita gente esquece: além do desenvolvimento, considere custo de manutenção futura, suporte da nova funcionalidade, infraestrutura adicional e o custo de oportunidade — o que você deixou de construir para priorizar isso.

Expansão de receita

É o crescimento de receita vindo de clientes que já existem, via upsell (plano mais caro) ou cross-sell (produto adicional). Um produto com expansão de receita saudável cresce mesmo sem aumentar a base de clientes — porque entrega tanto valor que os clientes investem mais. É um dos indicadores mais fortes de product-market fit.

Indicação — quando o produto cresce por si mesmo

NPS — Net Promoter Score (Índice de Promotores Líquidos)

O NPS é uma pesquisa simples com uma única pergunta: "Em uma escala de 0 a 10, qual a probabilidade de você recomendar este produto para um amigo ou colega?"

Os respondentes se dividem em três grupos. Quem responde 9 ou 10 são os Promotores — usuários satisfeitos que ativamente recomendam o produto. Quem responde 7 ou 8 são os Neutros — satisfeitos mas sem entusiasmo. Quem responde de 0 a 6 são os Detratores — insatisfeitos que podem falar mal do produto.

O cálculo é: NPS = % de Promotores − % de Detratores

O resultado vai de −100 a +100. Acima de 0 é considerado positivo. Acima de 50 é excelente. Acima de 70 é excepcional. O NPS varia muito por setor — uma empresa de software B2B com NPS de 40 pode estar muito bem, enquanto esse mesmo número seria mediano para um produto de consumo.

O NPS sozinho não explica nada — o que importa é o comentário qualitativo que acompanha a nota. Por que o Detrator deu 3? Por que o Promotor deu 10? Esses comentários são insumo direto para o backlog.

Taxa de indicação orgânica e K-factor

A taxa de indicação mede quantos novos usuários chegam por recomendação de usuários existentes. O K-factor (ou coeficiente viral) quantifica isso: se cada usuário traz em média 0,5 novos usuários, o K-factor é 0,5. Se cada usuário traz mais de 1 novo usuário, o produto tem crescimento viral — cresce por si mesmo, sem investimento adicional em aquisição.

North Star Metric: a única métrica que une o time

Com tantas métricas disponíveis, existe o risco de o time ficar olhando para muitos números sem clareza sobre o que realmente importa. A North Star Metric — em português, Métrica Estrela Guia — resolve esse problema.

É a métrica única que melhor captura o valor central entregue ao usuário e que, quando cresce de forma sustentável, indica que o produto está no caminho certo. Ela não é uma métrica de receita — é uma métrica de comportamento do usuário que prediz o crescimento de receita.

Exemplos de empresas reais:

• Spotify: tempo de escuta por usuário por dia
• Airbnb: noites reservadas
• WhatsApp: mensagens enviadas por dia
• LinkedIn: profissionais com pelo menos 5 conexões ativas

Perceba que nenhuma dessas métricas é receita ou número de usuários cadastrados. Todas medem o momento em que o usuário está extraindo valor real do produto.

Como definir a North Star do seu produto: identifique o momento de valor central — o que o usuário faz quando o produto está funcionando perfeitamente para ele. Encontre a métrica que mede a frequência ou intensidade desse momento. Valide que essa métrica tem correlação com retenção e receita.

Como definir métricas antes de cada entrega

Um dos hábitos mais importantes do PO júnior é definir a métrica de sucesso de uma feature antes de ela ser desenvolvida — não depois, não durante. Antes.

Por quê? Porque definir a métrica depois da entrega é racionalizar o resultado, não medir o impacto. Você inconscientemente vai escolher a métrica que conta a história mais favorável.

O processo em cinco passos:

1. Defina a hipótese: "Acreditamos que ao implementar [feature X], vamos observar [mudança Y] na [métrica Z]."

2. Estabeleça o baseline: Qual é o valor atual da métrica antes da entrega? Sem baseline, você não sabe se o resultado foi bom ou ruim. Se a taxa de ativação está em 25% hoje e sobe para 30% depois do lançamento, você gerou 5 pontos percentuais de melhoria. Sem saber o 25%, o 30% não significa nada.

3. Determine o critério de sucesso: Qual variação da métrica indica que a hipótese foi confirmada? Seja específico: "crescimento de 10% na taxa de ativação nos primeiros 30 dias após o lançamento."

4. Defina o período de avaliação: Quando você vai olhar os dados? Imediatamente após o lançamento, em 2 semanas, em 1 mês? Defina isso antes — senão você vai olhar quando os dados parecerem mais convenientes.

5. Planeje o que fazer se a hipótese for refutada: Isso é tão importante quanto planejar o sucesso. Se não funcionou como esperado, o que você aprende e o que faz diferente?

Esse processo transforma cada entrega em um experimento com aprendizado garantido — independente do resultado.

Ferramentas de analytics que o PO deve conhecer

Você não precisa configurar as ferramentas — isso é trabalho do time de dados ou de engenharia. Mas precisa saber o que cada uma faz para pedir as métricas certas e interpretar os relatórios corretamente.

Google Analytics 4 (GA4): A ferramenta mais utilizada para analisar o comportamento de usuários em sites e aplicativos. Permite ver de onde os usuários vêm, o que fazem dentro do produto, onde abandonam e como convertem. É gratuita até determinado volume e indispensável para qualquer produto com presença digital.

Mixpanel: Especializado em entender o comportamento de usuários que já estão dentro do produto — não apenas como chegaram, mas o que fazem, quais caminhos percorrem, onde travam e onde voltam. Excelente para análise de funil (sequência de ações do usuário) e de coorte (comparar grupos de usuários ao longo do tempo).

Amplitude: Concorrente direto do Mixpanel, com foco em análise de produto. Tem uma camada gratuita generosa e é muito usado por times de produto de empresas de médio porte que querem começar a fazer análise de dados mais sofisticada sem custo inicial.

Hotjar e Microsoft Clarity: Registram gravações das sessões dos usuários e geram mapas de calor — imagens que mostram onde as pessoas clicam, onde passam o mouse e onde param de rolar a página. São ferramentas poderosas para entender o comportamento visual sem precisar de entrevista. O Clarity é completamente gratuito.

Metabase e Looker Studio: Ferramentas de BI (Business Intelligence) que permitem criar dashboards customizados conectados diretamente ao banco de dados da empresa. Úteis quando os dados importantes do produto estão em fontes internas que as ferramentas de analytics padrão não conseguem acessar.

Os erros mais comuns de POs com métricas

Medir tudo sem priorizar nada

Dashboard com 40 métricas não é inteligência de produto — é ruído. Quando tudo parece importante, a atenção se dilui e nenhuma métrica realmente guia decisão. Escolha de 3 a 5 métricas centrais para o momento atual do produto e foque nelas.

Confundir correlação com causalidade

"A retenção subiu 15% depois que lançamos a feature X" não prova que a feature X causou a melhora. Pode ter sido uma mudança sazonal, uma campanha de marketing simultânea ou uma mudança no perfil dos usuários que chegaram naquele período. Correlação significa que dois números se movem juntos. Causalidade significa que um causa o outro — e isso exige análise mais cuidadosa, idealmente com um teste A/B.

Olhar médias sem olhar distribuições

A média de tempo de sessão pode ser 5 minutos, mas se metade dos usuários fica 30 segundos e a outra metade fica 10 minutos, a média de 5 minutos não representa ninguém. Sempre pergunte: como esse número se distribui entre os diferentes segmentos de usuários? O comportamento médio frequentemente esconde comportamentos extremos muito mais reveladores.

Não compartilhar as métricas com o time

Métricas que só o PO vê não mudam o comportamento do time. Quando o desenvolvedor que implementou uma feature vê que ela gerou 20% de aumento na ativação, ele entende o impacto real do trabalho dele. Isso muda profundamente a forma como ele pensa no próximo item do backlog — de executor para co-criador de valor.

Agir em cima de dados sem significância estatística

Um pico de 2 dias não é tendência. Uma variação de 3% com 200 usuários não é um sinal confiável — pode ser apenas variação aleatória. Aprenda o básico de significância estatística para não tomar decisões precipitadas com amostras pequenas ou períodos curtos demais para gerar conclusões sólidas.

Usar métricas para confirmar decisões já tomadas

"Vamos lançar a feature X. Agora encontrem os dados que justificam." Isso é o inverso do processo correto e um dos comportamentos mais prejudiciais que um PO pode ter. Dados devem informar decisões antes de serem tomadas — não justificá-las retroativamente.

Certificações e onde estudar

Livros fundamentais:

• Lean Analytics — Alistair Croll e Benjamin Yoskovitz: A referência mais completa sobre métricas para produtos digitais. Explica quais métricas importam em cada estágio do produto — desde pré-lançamento até escala — com exemplos reais de empresas conhecidas. Leitura obrigatória para todo PO júnior que quer ir além do dashboard.
• Measure What Matters — John Doerr: Focado em OKRs (que aprofundamos no Módulo 6 desta trilha), mas com excelente fundamentação sobre como conectar métricas ao que realmente importa estrategicamente. O autor foi um dos primeiros investidores do Google e do Spotify.

Cursos e recursos online:

• Google Analytics Academy (skillshop.google.com): Cursos gratuitos e certificações oficiais do Google para GA4. Se o seu produto usa Google Analytics — e a maioria usa — esse é o primeiro investimento de tempo que você deve fazer.
• Mixpanel University: Conteúdo gratuito e certificação do próprio Mixpanel. Vale especialmente se a empresa onde você trabalha já usa a ferramenta.
• Reforge — Product Analytics: O programa mais denso sobre analytics de produto disponível hoje. É pago e seletivo, mas é a referência absoluta para POs que querem se tornar especialistas em dados de produto.

Certificações relevantes:

• Google Analytics Certification (GA4): Gratuita, reconhecida pelo mercado e exigida em muitas vagas de produto. Vale o investimento de tempo para fazer logo no início da carreira.
• Amplitude Analytics Certification: Para quem usa Amplitude no dia a dia — demonstra domínio de uma das ferramentas mais adotadas em times de produto modernos.

Conclusão

Métricas não são relatório para stakeholder. São a linguagem do produto.

Um PO que sabe ler métricas sabe quando algo está funcionando antes que o CEO perceba, sabe onde o produto está falhando antes que o usuário reclame, e sabe quais apostas priorizar com base em evidências — não em intuição ou na voz mais alta da sala.

O próximo passo não é memorizar todas as siglas deste módulo. É escolher as três métricas mais relevantes para o produto em que você trabalha hoje, entender o baseline atual de cada uma e definir como elas vão guiar a próxima decisão de priorização.

Métricas que você não usa para agir são dados que você coleta sem aprender nada.

No próximo módulo, vamos falar sobre cerimônias Scrum — mas agora com o olhar do PO júnior que já entende o produto em profundidade: como conduzir planning, review e retrospectiva de forma que gere aprendizado real, não só processo.

Até lá.