Métricas de produto para time pequeno: o que olhar primeiro

Time pequeno costuma sofrer de um dos dois extremos. Ou não mede quase nada e decide por opinião, ou instala cinco ferramentas, cria vinte dashboards e continua decidindo por opinião, só que agora com gráficos de fundo.

O problema raramente é falta de dado. É falta de recorte. Um time enxuto não precisa acompanhar tudo que acontece no produto. Precisa enxergar cedo o suficiente aquilo que pode mudar uma decisão.

Antes da métrica, vem a decisão

Existe uma pergunta que elimina boa parte dos indicadores desnecessários: se esse número mudar, o que faremos diferente? Imagine que uma métrica suba 20%. Existe alguma decisão que isso provocaria? Agora imagine que ela caia 20%. O time faria alguma coisa diferente? Se a resposta for não nos dois cenários, provavelmente estamos diante de informação interessante, mas pouco acionável.

Isso não significa que todo dado precise gerar uma tarefa imediatamente. Alguns indicadores servem para acompanhar saúde, detectar mudança ou levantar hipóteses. O problema aparece quando o dashboard cresce sem que ninguém saiba por que cada número está ali.

Instrumentação também tem custo. Alguém precisa implementar o evento, validar, documentar, manter, interpretar e discutir. Cada nova métrica disputa atenção com as outras. Em time pequeno, atenção é um recurso tão escasso quanto desenvolvimento.

Métrica boa aponta para uma pergunta mais específica

“Temos 32 mil usuários cadastrados.” Pode ser uma informação importante para a empresa. Para produto, ainda diz pouco. Quantos chegaram recentemente? Quantos experimentaram a função principal? Quantos voltaram? Quantos abandonaram numa tarefa importante? Quantos pagam? Quantos ainda encontram valor meses depois? O total acumulado mistura comportamentos diferentes num número confortável.

Por isso métricas acionáveis normalmente ganham força quando têm algum tipo de comparação: entre etapas, entre períodos, entre coortes, entre segmentos, entre quem executou determinado comportamento e quem não executou. O objetivo não é simplesmente saber se o número está alto ou baixo. É conseguir formular uma pergunta sobre o que mudou.

Comece pelo caminho que produz valor

Em vez de começar escolhendo cinco métricas porque todo SaaS acompanha cinco métricas, comece pelo funcionamento do produto. Como alguém entra? O que precisa acontecer para experimentar valor? Que comportamento indica que o produto passou a fazer parte da rotina? Onde existe uma decisão de compra? O que caracteriza um cliente saudável meses depois? Essas perguntas normalmente levam a um conjunto pequeno de indicadores.

Ativação

Qual comportamento mostra que um novo usuário realmente começou a experimentar o produto? Não confunda cadastro com ativação. Criar conta é um evento do sistema. Ativação precisa representar algum avanço relevante para o usuário. Em uma ferramenta de analytics, pode ser visualizar a primeira análise com dados reais. Num produto colaborativo, talvez exija participação de outra pessoa. Num sistema financeiro, pode ser concluir com sucesso uma primeira operação importante. A definição depende do produto. O que importa é conseguir acompanhar quantas pessoas chegam a esse estado e quanto tempo levam.

Retenção

Depois de experimentar valor, as pessoas continuam voltando quando precisam do produto? Aqui, coortes costumam ser mais úteis do que uma taxa agregada. Agrupe usuários pela data ou período de entrada e acompanhe o comportamento ao longo do tempo. Isso permite comparar:

usuários que entraram depois da mudança de onboarding estão retendo melhor que os anteriores?

Agora a métrica começa a avaliar uma intervenção.

Uso das tarefas que sustentam valor

“Usuários ativos” é uma métrica perigosa quando ninguém consegue explicar o que significa estar ativo. Abrir o produto não é necessariamente valor. Pergunte quais tarefas justificam a existência dele: emitir uma cobrança, executar uma automação, criar um relatório, conciliar pagamentos, compartilhar um projeto. Depois acompanhe se essas tarefas continuam acontecendo e em quais segmentos.

A frequência esperada também depende do produto. Um sistema utilizado mensalmente não deveria ser julgado com a mesma régua de uma ferramenta operacional diária.

Conversão nas decisões importantes

Nem todo produto precisa acompanhar exatamente o mesmo funil, mas algumas transições merecem ser vistas separadamente: cadastro iniciado → cadastro concluído, trial iniciado → avaliação relevante, página de preços → checkout, checkout → pagamento, plano atual → upgrade. Transformar tudo em uma única “taxa de conversão” esconde onde existe o problema. Se poucas pessoas entram no checkout, a hipótese é uma. Se muitas entram e poucas concluem, é outra.

Receita ligada ao comportamento

Produto não existe separado do negócio. Para SaaS B2B, pode fazer sentido acompanhar expansão, contração e retenção de receita por coorte ou segmento. Mas o objetivo não deveria ser colocar MRR no dashboard de produto apenas porque é uma métrica importante para a empresa. A pergunta é: conseguimos relacionar mudanças de comportamento no produto com mudanças posteriores na receita? Essa ligação é muito mais útil.

Coortes ajudam a descobrir se o produto melhorou

Imagine que a retenção geral esteja em 65%. No trimestre seguinte continua em 65%. Parece que nada mudou. Só que, nesse intervalo, o time lançou um novo onboarding. Quando você separa por coorte, aparece outra história: usuários antigos continuam saindo no ritmo anterior, enquanto os que entraram depois da mudança estão retornando com mais frequência. A média agregada demora para mostrar isso porque mistura populações diferentes.

Coorte permite observar gerações do produto. Quem entrou antes da mudança viveu uma experiência. Quem entrou depois viveu outra. Essa comparação não prova automaticamente que a mudança causou a diferença, mas oferece um sinal muito mais útil para investigar. E não exige necessariamente uma infraestrutura sofisticada de BI. Uma tabela bem construída já resolve muitas perguntas.

Instrumente marcos, não cada clique

Quando um time decide “ficar mais data-driven”, é comum começar instrumentando tudo: button_clicked, modal_opened, tab_selected, page_viewed. Poucos meses depois existem centenas de eventos e ninguém sabe quais são confiáveis.

Instrumentação deveria começar pelas perguntas. Se queremos saber quantas pessoas concluíram a primeira configuração, precisamos dos eventos que representam essa progressão. Se queremos entender abandono num checkout, precisamos das etapas desse checkout. Um clique só merece virar evento quando aquele clique representa alguma coisa que o time realmente quer analisar.

Também vale adotar uma convenção simples: invoice_sent, report_created, integration_connected, ou equivalentes em português. O padrão exato importa menos do que a consistência. Nome de evento deveria descrever o que aconteceu, e as propriedades deveriam carregar o contexto necessário para análise: plano, origem, tipo de conta, método de pagamento, segmento. Não transforme toda propriedade disponível em tracking. Colete aquilo que tem uso claro.

Quando o número muda, talvez você ainda não saiba por quê

Imagine que a conclusão de uma tarefa caiu de 72% para 58%. O dado mostra que existe uma mudança. Ainda não explica o mecanismo. Pode ser uma alteração recente de interface, um bug, um perfil de tráfego diferente, uma nova regra de negócio. Talvez usuários estejam deliberadamente desistindo porque perceberam que a tarefa não serve para eles.

É aí que pesquisa com usuários, análise de suporte, logs e observação do fluxo entram. Quantitativo e qualitativo não disputam qual é “mais verdadeiro”. Eles ajudam a responder partes diferentes da investigação. O dashboard aponta onde existe algo para entender. O contexto ajuda o time a decidir o que testar.

Volume pequeno exige humildade

Times pequenos também precisam lidar com uma realidade: poucos usuários produzem números instáveis. Se 100 pessoas passam por um fluxo, uma mudança de 8 para 11 conversões transforma a taxa de 8% em 11%. Visualmente parece um salto considerável. Na prática, estamos falando de três pessoas. Isso não significa que a mudança não existe. Significa que ainda precisamos ter cuidado antes de atribuí-la à última feature lançada.

Não existe uma regra simples como “ignore mudanças menores que X%”. A confiança necessária depende do volume, da variabilidade, do tamanho do efeito e da decisão que será tomada. Uma mudança pequena que exige meses de desenvolvimento merece evidência mais forte. Um experimento barato e reversível pode justificar ação com menos certeza. Em times com baixo volume, períodos maiores, comparação de coortes e repetição do comportamento ajudam a evitar decisões baseadas em ruído.

E existe uma frase extremamente útil numa reunião de produto: ainda não temos dados suficientes para concluir. Isso também é análise.

Não use média automaticamente

Médias são úteis, mas podem esconder distribuições ruins. Imagine que o tempo médio para concluir uma configuração seja quatro minutos. Parece ótimo. Só que metade termina em dois minutos e um grupo menor passa quinze tentando descobrir uma etapa específica. O número médio sozinho esconde justamente os usuários que mais precisam de atenção.

Mediana, percentis e distribuição ajudam a enxergar esse tipo de comportamento. O mesmo vale para receita, uso, tempo de resposta e quantidade de tarefas. Não existe uma estatística universalmente melhor. Escolha aquela que representa melhor a pergunta.

O dashboard deveria apontar para o trabalho

Uma boa métrica tem ligação clara com a próxima investigação. Ativação abaixo do esperado pode mandar o time olhar como novos usuários progridem até conseguir operar o produto. Retenção piorando numa coorte pode levar à análise dos sinais que aparecem antes do churn. Abandono concentrado depois da escolha do método de pagamento manda abrir o checkout por etapa.

O número não entrega a solução. Ele direciona a próxima pergunta. Essa é uma diferença importante. Dashboards ruins tentam responder tudo. Dashboards bons ajudam o time a perceber onde precisa investigar agora.

Uma rotina simples é melhor que um painel perfeito

Métrica só entra no processo de decisão quando alguém olha para ela com frequência suficiente. Não precisa existir uma cerimônia enorme. Para alguns times, quinze minutos por semana bastam. O importante é abrir os mesmos indicadores e perguntar: o que mudou? É uma mudança real ou ainda temos pouco volume? Qual hipótese pode explicar? Precisamos investigar? Existe alguma ação?

Uma vez por mês, talvez faça sentido olhar coortes e tendências mais longas. Eventos sem uso podem ser revisados e eventualmente removidos. Definições também precisam ser revisitadas: se “ativação” deixou de representar o comportamento que gera valor, manter a mesma métrica apenas para preservar histórico pode ser tão ruim quanto trocar toda semana. Medição é infraestrutura de decisão, não decoração de dashboard.

O mínimo é aquilo que o time realmente usa

Um time pequeno não precisa de menos métricas porque é menos sofisticado. Precisa de menos métricas porque cada uma precisa ganhar espaço real na rotina. Talvez sejam cinco. Talvez três. Talvez sete. O número importa menos do que a ligação entre cada indicador e uma pergunta de produto.

Antes de adicionar mais um gráfico, vale repetir o teste do começo: se esse número subir, o que faremos diferente? E se cair? Quando ninguém consegue responder, talvez o problema não seja falta de analytics. Talvez o time esteja medindo algo que ainda não sabe para que serve.

Fontes

Kerry Rodden, Hilary Hutchinson e Xin Fu. “Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications”, Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI 2010, pp. 2395–2398. O trabalho apresenta o framework HEART e uma abordagem para conectar objetivos de experiência a sinais observáveis e métricas, princípio utilizado neste artigo para partir da decisão e da pergunta antes de escolher o indicador.