Métricas de PM: resultado versus entrega, North Star e indicadores antecedentes (B2B SaaS)

Já participei do QBR em que o PM apresenta quatorze funcionalidades entregues no Q3. Novo fluxo de onboarding. Edição em massa. SAML. Três integrações. Dois novos dashboards. Paridade mobile para o pipeline de deals. O slide é uma linda matriz de checks verdes. Todo mundo balança a cabeça.

Então o CEO se inclina para frente e faz uma pergunta: "A retenção se moveu?"

Silêncio. O PM olha para o analista, que olha para o data engineer, que olha para o chão. Alguém finalmente diz: "Achamos que sim, mas a coorte ainda não está totalmente madura." O CEO escreve algo no caderno. A sala sabe.

Aquele PM não foi demitido. Aconteceu algo pior. Ele foi silenciosamente removido da próxima conversa de estratégia. Seis meses depois, o roadmap dele está sendo co-escrito por vendas, porque produto não consegue provar que o trabalho importa.

Esta é a lacuna entre entrega e resultado, e a maioria dos PMs cai no lado errado dela. Não porque sejam preguiçosos. Porque entrega é fotogênica e resultados não são.

O enquadramento de Cagan: entrega é o que você produz, resultado é o que muda

Marty Cagan vem batendo nessa tecla há quinze anos e a maioria de nós ainda erra.

Entrega é tudo o que você consegue ver num demo de sprint. Funcionalidades entregues. Tickets fechados. Story points consumidos. Releases tagueadas. É contável, semanal, e vive no Jira onde todo stakeholder pode ver.

Resultado é o que mudou no comportamento do cliente ou no desempenho do negócio por causa dessa entrega. A taxa de ativação foi de 38% para 51%. O NRR se manteve em 112% durante um aumento de preço. O tempo até o primeiro deal caiu de 9 dias para 4. As contas do pod do pipeline de deals agora fazem login 3,2 vezes por semana em vez de 1,8.

Entrega é um substantivo num slide. Resultado é um verbo na vida de um cliente.

Os PMs recorrem à entrega por um motivo: é a única coisa confiavelmente observável numa sexta-feira. Você entregou sete coisas neste sprint, aqui estão as sete coisas, aqui estão os screenshots. O resultado leva 30, 60, às vezes 90 dias para aparecer, e a cadeia causal é mais bagunçada ("a ativação se moveu por causa do novo fluxo, ou porque o Q3 é só um trimestre de alta intenção?"). Quando você está estressado e o deck vence na segunda, você recorre à coisa contável.

O detalhe: a coisa contável não é pelo que o seu CEO está te pagando. Ele está pagando por mudança de comportamento. Até o seu slide refletir isso, você é um gerente de entregas com um título mais bonito.

As 5 métricas de resultado que de fato se sustentam em B2B SaaS

Você não precisa de 47 métricas. Você precisa de cinco, definidas explicitamente, atualizadas semanal ou mensalmente conforme a cadência, e confiadas pelo financeiro.

1. Taxa de ativação. A porcentagem de novas contas que atingem o evento "aha" do seu produto em até N dias do signup. A parte difícil é definir o evento, não medi-lo. Para um CRM, "3 deals criados em até 14 dias" é um aha defensável. Significa que o cliente de fato moveu o pipeline dele para dentro. Para uma ferramenta de gestão de projetos, "5 tarefas criadas em 2 projetos com 1 responsável além do criador" funciona. Escolha o evento, anote-o, defenda-o por um trimestre antes de mudá-lo. Ativação abaixo de 40% em B2B SaaS é um vazamento. Acima de 60% é raro e vale proteger.

2. Retenção. Duas variações, e você precisa das duas. A gross revenue retention (GRR) mede o que você manteve das contas existentes antes de qualquer expansão. Tipicamente 85% a 92% é saudável em SaaS de mid-market, e qualquer coisa abaixo de 80% é um problema de churn. A retenção de logos mede a porcentagem de contas que você não perdeu, independentemente do tamanho do contrato. Acompanhe ambas por coorte (mês ou trimestre de signup) para você ver se as coortes novas são mais saudáveis que as antigas. Se a sua coorte do Q1 retém melhor que a do Q3, o time que entregou entre elas fez um trabalho de verdade.

3. Expansão. O NRR é o número de destaque. Pegue a receita de uma coorte de 12 meses atrás, olhe o que essa mesma coorte gera hoje (depois de churn e depois de expansão), divida. Acima de 110% em B2B SaaS é bom, acima de 120% é ótimo, acima de 130% significa que você achou algo que a maioria das empresas não achou. Combine-o com ARR de expansão por conta para você ver se o cliente médio está crescendo ou se você tem algumas baleias puxando a média para cima.

4. NPS ou CSAT. Defasado, direcional, útil como fio de alerta. O NPS fica defasado do comportamento real em 60 a 90 dias. Quando ele cai, o dano já foi feito no seu pipeline de churn. Não conduza com ele. Use-o para confirmar uma história que você já está vendo em retenção e expansão. Se o NPS cai 8 pontos e a retenção está bem, você tem um problema de percepção. Se o NPS cai 8 pontos e a retenção também cai, você tem um problema de produto e precisava saber disso mais cedo.

5. Receita por usuário (ou por conta). ARPU ou ARPA, acompanhado ao longo do tempo. O sinal mais limpo de que seu produto está ficando mais valioso para os clientes. Se a ativação está em alta, a retenção está em alta, mas o ARPU está estagnado, você construiu um tier gratuito mais grudento e pouco mais. Se o ARPU está subindo e a retenção se mantém, o produto está fazendo o que um produto deve fazer.

Essas cinco juntas cobrem a jornada do cliente pelo seu produto: ele começou a usar (ativação), ele ficou (retenção), ele cresceu (expansão), ele gostou o suficiente para recomendar (NPS) e ele gastou mais (ARPU). Qualquer coisa que você medir fora dessas cinco deveria estar a serviço de explicar uma delas.

A North Star: uma por pod, não uma por empresa

A Amplitude popularizou "a métrica North Star" como um único número em torno do qual uma empresa se organiza. Usuários ativos diários para um app de consumo. Noites reservadas para o Airbnb. Músicas tocadas para o Spotify.

Para B2B SaaS na Série A ou B, uma-por-empresa quebra. Um pod de CRM, um pod de billing e um pod de relatórios fazem trabalhos completamente diferentes. Forçá-los a compartilhar uma North Star a transforma numa métrica vaga em nível de empresa, como "contas ativas semanais", pela qual ninguém de fato se orienta.

A correção: uma North Star por pod. A única métrica que, se ela se mover, o seu pod fez o seu trabalho neste trimestre. Exemplos que vi funcionar:

Pod de ativação de CRM → % de novas contas com 3+ deals criados nos primeiros 14 dias
Pod de roteamento de leads → % de leads qualificados roteados a um rep em menos de 5 minutos
Pod de onboarding → % de contas que concluem a checklist de configuração em até 7 dias
Pod de relatórios → visualizadores ativos semanais de dashboard por conta pagante
Pod mobile → % de usuários ativos semanais que fazem login pelo mobile em qualquer semana dada

Cada uma é específica. Cada uma é um número. Cada uma pode ser movida pelo time que é dono dela sem discutir com outro time sobre atribuição. É esse o teste. Se dois pods podem ambos reivindicar crédito quando a métrica se move, não é uma North Star, é uma métrica de resultado em nível de empresa.

A North Star em nível de pod não é a North Star da empresa. A empresa ainda se importa com o NRR. Mas o pod se importa com a coisa antecedente que impulsiona o NRR para a jornada do cliente que ele é dono.

Indicadores antecedentes versus defasados: você não consegue conduzir com uma métrica que leva 90 dias

Toda métrica que nomeei até agora está em algum ponto do espectro de defasado a antecedente, e você precisa saber onde.

Indicadores defasados te dizem o que já aconteceu. O NPS fica defasado em 60 a 90 dias. A retenção fica defasada em um trimestre ou mais. O ARR de expansão fica defasado pelo ciclo de contrato. Quando essas se movem, o trabalho que as moveu foi feito dois trimestres atrás. Você não conduz com elas. Você faz autópsia com elas.

Indicadores antecedentes se movem semana a semana e preveem a métrica defasada. A taxa de ativação é um indicador antecedente da retenção (contas que ativaram retêm melhor, ponto final). A conclusão da checklist de configuração é um indicador antecedente da ativação. O tempo até o primeiro valor é um indicador antecedente da conclusão da configuração. O volume de tickets de suporte numa funcionalidade recém-lançada é um indicador antecedente de se aquela funcionalidade vai gerar churn ou grudar.

A regra que eu sigo: combine toda métrica defasada com um ou dois indicadores antecedentes em que você confie para prevê-la. Se a sua North Star é retenção e a única coisa que você mede é retenção, você está voando às cegas por 90 dias de cada vez. Se a sua North Star é retenção e você também acompanha a taxa de ativação semanalmente, você vai saber que tem um problema na semana 2 em vez da semana 14.

Para cada uma das cinco métricas de resultado, aqui estão os indicadores antecedentes que valem acompanhar:

Ativação → % de conclusão da checklist de configuração, tempo até a primeira ação-chave, % de contas com 2+ usuários na semana 1
Retenção → usuários ativos semanais por conta, amplitude de adoção de funcionalidades (quantas funcionalidades cada conta toca), volume de tickets de suporte por conta
Expansão → % de utilização de assentos, % de contas em 80%+ do limite do plano, solicitações de funcionalidades em recursos de tier premium
NPS → tempo de resposta de suporte, tempo até a resolução, % de tickets resolvidos no primeiro contato
ARPU → taxa de impressão-para-clique de prompts de upgrade, % de contas que bateram num paywall nos últimos 30 dias

Você não vai acompanhar todos esses. Você vai escolher um ou dois indicadores antecedentes por métrica de resultado, anotá-los e checá-los semanalmente. A disciplina importa mais do que as escolhas específicas.

Conectando a árvore de métricas

Uma árvore de métricas é o artefato visível que diz "é assim que o trabalho do nosso pod se conecta ao negócio". North Star no topo, 3 a 4 métricas de driver abaixo dela, indicadores antecedentes sob cada driver. Desenhada, o pod de ativação de CRM poderia ficar assim:

NORTH STAR: % of new accounts with 3+ deals created in 14 days
├── DRIVER 1: Setup checklist completion rate
│   ├── Leading: Time to first deal created
│   └── Leading: % of accounts inviting a 2nd user in week 1
├── DRIVER 2: Onboarding email engagement (open + CTA click)
│   ├── Leading: Day-3 email open rate
│   └── Leading: Day-7 reply rate to "stuck?" email
├── DRIVER 3: First-week support ticket volume
│   ├── Leading: % of tickets tagged "setup confusion"
│   └── Leading: Median time-to-resolution on setup tickets
└── DRIVER 4: % of accounts with sales-team intro call scheduled
    ├── Leading: Calendly link click rate from welcome email
    └── Leading: No-show rate on intro calls

Três coisas importam sobre esta árvore. Primeiro, todo driver alimenta a North Star com uma história causal clara (melhor conclusão de configuração → mais contas atingindo 3 deals em 14 dias). Segundo, cada indicador antecedente sob um driver é algo que você consegue puxar do seu ferramental amanhã sem um projeto de engenharia de dados. Terceiro, a coisa toda cabe em uma página.

Ferramental, por categoria:

Indicadores antecedentes (dados de eventos): Amplitude ou Mixpanel. A ferramenta de product analytics rastreia os eventos em nível de usuário que compõem seus indicadores antecedentes.
Métricas de resultado (dados de warehouse): Snowflake ou BigQuery para o warehouse, Looker ou Metabase para o dashboard. Métricas de resultado envolvem receita, contratos e joins em nível de cliente que não vivem na ferramenta de product analytics.
As próprias definições de métricas: um único documento do Notion, do qual o PM é dono, legível pela engenharia. Não uma página de wiki que fica desatualizada. Um documento vivo onde a definição do evento de ativação fica ao lado do SQL que a calcula. Se o seu time de eng não consegue achar a definição de ativação em 30 segundos, suas métricas não são reais.

O erro que vejo PMs juniores cometerem: construir esta árvore uma vez, apresentá-la num all-hands e nunca atualizá-la. A árvore deveria ser revisitada a cada trimestre. Métricas de driver que não movem a North Star são cortadas. Novos indicadores antecedentes são adicionados quando você os descobre.

O slide de QBR que se sustenta sob escrutínio

Um slide. Aqui está a estrutura:

PRODUCT QBR : Q3 : CRM ACTIVATION POD

NORTH STAR: % of new accounts with 3+ deals in 14 days
  Q2: 38%   →   Q3: 51%   (+13 pts)

DRIVER METRICS (Q-over-Q):
  • Setup checklist completion: 44% → 67%
  • Onboarding email CTA click: 12% → 19%
  • Week-1 support ticket volume per account: 1.8 → 1.1

LEADING INDICATORS THAT EXPLAIN WHY:
  • Time-to-first-deal: 6.2 days → 2.8 days
    (driven by new setup flow shipped wk 3 of Q3)
  • Day-7 active users per account: 1.4 → 2.1
    (invite-2nd-user prompt added wk 5)

BUSINESS CONTEXT:
  • NRR held at 112% (no Q-over-Q change)
  • Activation→retention correlation: activated accounts
    retain 89% vs 61% for non-activated cohort

É esse o slide inteiro. As funcionalidades entregues durante o trimestre (o novo fluxo de onboarding, o prompt de convite, a reescrita do e-mail) vão num apêndice. Elas são contexto, não a manchete.

A razão pela qual este slide sobrevive à pergunta do CEO é que ele responde a pergunta antes de ela ser feita. "O trabalho importou?" Sim. A ativação foi de 38% para 51%. Aqui estão os três drivers. Aqui está o indicador antecedente que prova que o novo fluxo a causou. E, aliás, a divisão de retenção de 89% versus 61% te diz por que a ativação é a coisa certa para se obcecar.

Se o seu VP consegue ler esse slide em 20 segundos e entrar na sala do CEO e recontar a história sem anotações, você acertou. Se ele precisa de você na sala para traduzir, o slide não está pronto.

A armadilha do "entregamos 14 funcionalidades" e como sair dela

Slides de contagem de funcionalidades parecem seguros. São contáveis. Provam que você estava ocupado. Dão crédito à engenharia, o que mantém o eng manager feliz. Eles parecem trabalho.

Eles também matam a credibilidade do PM num horizonte de 12 meses. Aqui está a conta: seu CEO foi a talvez 20 QBRs de PM na carreira dele. No terceiro, ele parou de perguntar "o que você entregou" e começou a perguntar "o que mudou para o cliente". Se seus slides continuam respondendo a primeira pergunta, você vai ser o PM cujo trabalho o CEO não consegue lembrar direito quando chegam as conversas de promoção.

Sair dela é um problema de uma conversa e um problema de execução de dois trimestres.

A conversa é com o seu VP, idealmente antes de o próximo trimestre começar. Ela soa assim: "Quero mudar como reportamos progresso no próximo trimestre. Aqui está a árvore de métricas do nosso pod. Aqui está o template de slide de QBR que vou usar. As funcionalidades que entregamos vão para um apêndice. Vou continuar reportando o que construímos, mas a manchete vai ser o que mudou para o cliente. Posso ter a sua leitura das definições de métricas antes de eu levar isto ao time?"

Duas coisas acontecem. Uma: seu VP recebe um rascunho de um PM melhor, e ele se lembra da conversa. Duas: você se compromete por escrito. Você não consegue silenciosamente voltar para slides de contagem de funcionalidades três semanas depois quando a árvore de métricas parecer difícil.

O problema de execução são os próximos 6 meses. O primeiro trimestre vai ser desconfortável. Você vai aparecer num QBR com um slide de resultado e um dos drivers vai estar estagnado ou em queda, e você vai ter que falar sobre isso em vez de se esconder atrás de 14 checks verdes. No segundo trimestre, você vai ter uma comparação trimestre a trimestre e a conversa fica mais fácil. No terceiro trimestre, o seu slide é o slide que os outros PMs silenciosamente fotografam antes dos próprios QBRs.

O que fazer esta semana

Não espere o próximo trimestre. Faça isto nos próximos 10 dias.

Escolha a North Star do seu pod. Uma frase, uma métrica. Se você não consegue fazer isso numa tarde, seu escopo é amplo demais e você tem um problema diferente.
Escreva as 3 métricas de driver abaixo dela. Cada uma com uma definição específica (não "engajamento", mas "% de usuários ativos semanais que concluem a ação-chave X").
Ache os 2 indicadores antecedentes por driver que você consegue puxar do Amplitude ou do Mixpanel amanhã. Se você não consegue puxá-los amanhã, seu ferramental tem uma lacuna que vale um ticket separado.
Coloque tudo num documento do Notion. Uma página. Árvore de métricas no topo, definições e queries de SQL abaixo.
Envie o documento ao seu gestor e peça uma rodada de contestação antes do próximo QBR. Não peça aprovação. Peça a única definição com a qual ele discordaria. O que quer que ele conteste é a métrica que o seu time de eng também tem mais chance de interpretar errado. Conserte antes do QBR, não durante.

O PM que reporta resultados, mesmo que imperfeitamente, vence o PM que reporta entregas perfeitamente. Reportar entrega é a escolha que parece mais segura e limita a carreira. Você pode continuar construindo o mesmo slide de contagem de funcionalidades por mais três anos e silenciosamente se ver derivar para fora da conversa de estratégia, ou você pode gastar dois trimestres desconfortáveis fazendo a mudança e compor confiança a partir dali.

Comece neste trimestre. A árvore de métricas não precisa ser perfeita. Ela só precisa existir.

Playbooks para Product Manager