Existe uma ilusão de que produto orientado a dados significa ter acesso a muitos dados. Na prática, significa ter poucas perguntas boas — e saber buscar as respostas com método.

PM que abre o Amplitude sem uma hipótese específica vai passar uma hora olhando para gráficos e sair sem ter aprendido nada que muda uma decisão. Para entender quais métricas de produto monitorar e o que cada uma está te dizendo sobre o comportamento do usuário, veja o guia completo de métricas.

Comece com a pergunta, não com o dado

Antes de abrir qualquer ferramenta de analytics, escreva a pergunta que você está tentando responder. "Por que a retenção D7 caiu 8 pontos percentuais nas últimas duas semanas?" é uma pergunta. "Como está a retenção?" não é.

Uma pergunta específica te diz quais dados você precisa, qual segmentação faz sentido, e como você vai saber se a resposta que encontrou é suficiente para tomar a decisão. Sem ela, você explora sem direção.

Análise de funil

Funil de conversão mostra onde os usuários param. Cada passo do funil — da chegada ao produto até a ação que você quer que realizem — pode ser medido. O que você está buscando são anomalias: onde a queda é desproporcional ao esperado?

Um funil com 60% de conversão do cadastro para o primeiro uso, 30% do primeiro uso para a segunda sessão, e 50% da segunda para a terceira sessão tem um problema óbvio: entre o primeiro uso e o segundo. Esse é o ponto de atrito que vale investigar primeiro.

Segmentação importa mais do que a média

Funil médio esconde comportamentos diferentes. Usuários que chegaram via busca orgânica se comportam diferente dos que vieram por indicação. Usuários de mobile se comportam diferente dos de desktop. Separar esses segmentos frequentemente revela que o "problema geral" é na verdade um problema específico de um grupo.

Antes de propor qualquer solução baseada em dados de funil, quebre o dado por pelo menos dois segmentos relevantes para o seu produto. A solução certa para usuários mobile pode ser diferente da solução certa para desktop.

Experimentos A/B: quando usar e quando não usar

Experimento A/B é o padrão ouro para validar que uma mudança causou um efeito — e não apenas que correlacionou com ele. Mas tem pré-requisitos que muita empresa ignora.

Volume de usuários suficiente para atingir significância estatística num tempo razoável. Se você tem 500 usuários por semana passando pelo ponto que quer testar, um experimento de pequeno efeito vai levar meses para ter resultado confiável. Nesse caso, pode ser mais rápido fazer uma mudança, observar, e estar ciente de que você tem menos certeza causal.

Hipótese clara sobre o que vai mudar e quanto. "Vamos testar um botão azul versus verde" sem hipótese sobre por que azul deveria converter mais é um experimento sem aprendizado possível além do resultado binário.

Quando dados enganam

Correlação não é causalidade. Usuários que completam o onboarding retêm mais — mas isso pode ser porque o onboarding é bom, ou pode ser porque os usuários que perseveram no onboarding são exatamente os mais motivados, e reteriam de qualquer jeito.

Survivorship bias em dados de retenção: quando você analisa usuários retidos, está analisando os que ficaram. O que te falta são os que saíram. Análise de churn — quem saiu, quando, em qual ponto do produto — é tão informativa quanto análise de retenção, e muito menos comum.

Dados qualitativos e dados quantitativos juntos

Dados quantitativos dizem o quê e quanto. Dados qualitativos dizem o porquê. Os dois são necessários para tomar boas decisões.

Uma queda no funil que você identificou nos dados te diz onde procurar. A entrevista com cinco usuários que pararam naquele ponto te diz o que estava acontecendo na cabeça deles. Com os dois, você tem diagnóstico suficiente para propor solução com confiança.

PM que só usa dados qualitativos corre o risco de generalizar a partir de casos atípicos. PM que só usa dados quantitativos não sabe o mecanismo por trás dos números. Os dois juntos são mais poderosos do que qualquer um sozinho.

Como comunicar decisões baseadas em dados

Stakeholders às vezes querem fazer algo que os dados contradizem. A forma mais eficaz de comunicar a contradição não é mostrar o dashboard — é construir a narrativa: "a métrica X mostra Y, o que indica Z. Quando tentamos algo semelhante no passado, o resultado foi W. Por isso, minha recomendação é..."

Dados numa apresentação sem narrativa são dados que as pessoas ignoram ou interpretam como querem. A narrativa é o trabalho do PM; os dados são o suporte.

Dados quantitativos te dizem onde o problema está. Para entender o porquê por trás dos números, o próximo passo é o dado qualitativo — aprenda como conduzir entrevistas com usuários que geram insumos acionáveis. E para entender como estruturar o processo de discovery que integra dados quantitativos e qualitativos de forma sustentável ao longo do tempo, veja o guia sobre como fazer discovery de produto.

Na comunidade mágica, temos sessões regulares onde PMs trazem problemas de produto reais e trabalham juntos em como usar dados para endereçá-los.