O que aprendi depois de entregar uma análise certa para a pergunta errada
TL;DR
Recebi dados de um fornecedor externo para estimar a posição de mercado de uma base de clientes em determinado segmento. O fornecedor cobria cerca de 60% dos clientes — para os outros 40%, não havia referência externa disponível. A pergunta declarada era "qual é nossa posição nesse segmento?" e eu poderia ter respondido com uma média dos clientes cobertos aplicada ao restante. A pergunta que a decisão precisava era outra: com que nível de confiança o resultado poderia sustentar uma escolha estratégica? Essas são perguntas diferentes, e entender qual estava em jogo antes de começar mudou o que eu entreguei. Neste post, explico o gap entre as duas perguntas, as cinco verificações que faço antes de qualquer query, como reorientar quando percebo que comecei errado, e três situações para aplicar essa semana.
A análise e a pergunta que ela precisava responder
O pedido era estimar a posição de mercado de uma base de clientes em determinado segmento. Para isso, havia dados internos sobre o que cada cliente fazia conosco e dados de um fornecedor externo com informações sobre o mercado total. O processo parecia direto: cruzar as duas fontes, calcular a fração da atividade de cada cliente que acontecia internamente, agregar.
O problema apareceu quando comecei a trabalhar com os dados: o fornecedor cobria cerca de 60% dos clientes. Para os outros 40%, não havia correspondência externa disponível. A abordagem mais simples seria calcular a métrica sobre os cobertos e aplicar a média ao restante — isso responderia a pergunta declarada e geraria um número que caberia numa apresentação.
O que me freou foi perceber que a decisão para a qual a análise servia tinha uma natureza diferente da estimativa em si. A pergunta declarada era "qual é nossa posição?". A pergunta operacional — o que o stakeholder precisava para agir — era "com que nível de confiança podemos tomar decisões estratégicas com base nessa estimativa?" Uma média aplicada a 40% dos clientes sem nenhuma marcação de incerteza responderia a primeira e ignoraria a segunda inteiramente.
A resposta técnica foi usar bootstrap: reamostrei os clientes cobertos com reposição 10.000 vezes, calculei a métrica a cada iteração e construí um intervalo de confiança de 95% para a estimativa dos não-cobertos. O resultado final não foi "nossa posição é X%", mas "nossa posição está entre X% e Y% com 95% de confiança." O intervalo era amplo o suficiente para que os dois extremos implicassem prioridades distintas — e apresentar isso forçou uma conversa que um número único teria evitado: o que fazemos se estivermos no limite inferior? E se estivermos no superior?
Essa conversa era a decisão real. A análise que eu quase entregava teria respondido corretamente a pergunta declarada e deixado essa decisão sem insumo.
A diferença entre a pergunta que foi feita e a pergunta que precisa ser respondida
Quando alguém pede uma análise, o que chega até você é uma pergunta declarada.
"Por que o churn aumentou?"
"Qual o perfil dos usuários que mais convertem?"
"Como está a retenção no produto X?"
Cada uma tem uma resposta técnica razoável. O problema é que por trás de cada pergunta declarada existe uma pergunta operacional — a decisão que o stakeholder vai precisar tomar depois de ler o que você entregou.
Se o PM está com o roadmap do trimestre travado esperando uma justificativa para priorizar retenção, a pergunta operacional é "o que entra no sprint?" Responder "por que o churn aumentou" sem conectar os drivers aos itens de backlog é entregar a metade descritiva, sem a metade que serve a decisão.
Se a liderança precisa aprovar orçamento para uma iniciativa, a pergunta operacional é "qual o ROI esperado e com que nível de confiança posso defender esse número?" Uma análise comportamental de usuários, por mais bem feita que seja, não responde o que está em jogo para aquela aprovação.
O gap entre as duas perguntas é a razão mais comum pela qual análises tecnicamente sólidas ficam sem uso.
As cinco perguntas antes de qualquer query
Com o tempo, desenvolvi um conjunto de verificações que faço antes de escrever a primeira linha de SQL. Não é uma metodologia — é o resultado de análises que não geraram ação e de conversas sobre o que tinha faltado.
1. O que o stakeholder precisa fazer depois desta reunião?
A ação concreta que a pessoa vai tomar depois de ler a análise orienta tudo: o formato, o nível de detalhe, o que vai na abertura. Aprovar orçamento, decidir entre dois caminhos de produto, alinhar com a liderança — cada uma dessas ações implica um tipo diferente de análise. Se essa pergunta não tem resposta clara, vale um alinhamento de 15 minutos antes de começar.
2. Que decisão esta análise está servindo?
Toda análise serve uma decisão, mesmo que ninguém tenha explicitado isso. Se você não consegue nomear a decisão, vale perguntar diretamente: "Para que você vai usar isso quando eu entregar?" A pergunta raramente incomoda, e com frequência revela que o próprio stakeholder não tinha clareza sobre o que precisava.
3. Qual é o prazo real da decisão — não só da entrega?
"Preciso disso para a reunião de quinta" e "precisamos disso antes da revisão de roadmap no fim do mês" implicam granularidades muito diferentes. Uma análise rápida e direcionada entregue antes do momento de decisão costuma gerar mais impacto do que uma completa que chega depois. Saber o prazo da decisão — não só da tarefa — calibra o quanto detalhe faz sentido.
4. Quem mais está envolvido na decisão?
Se o PM vai apresentar sua análise para a liderança, você está preparando para dois públicos com modelos mentais diferentes. Saber isso antes muda o que você coloca na abertura e quais perguntas secundárias você antecipa. Uma análise feita só para o PM pode chegar à liderança sem o enquadramento necessário para gerar ação.
5. O que invalidaria esta análise para o stakeholder?
Existe alguma premissa que, se estiver errada, tornaria o resultado irrelevante? Um contexto externo que você não sabe? Uma decisão já tomada que a análise estaria contrariando? Perguntar isso antes evita chegar a uma reunião com doze slides para descobrir que o contexto mudou três dias antes.
Como reorientar quando você percebe que começou pela pergunta errada
Você está no meio de uma análise e percebe que a pergunta que está respondendo não é a que a decisão precisa. Isso acontece com regularidade — o pedido inicial era vago, o contexto mudou, ou você só entendeu a pergunta operacional depois de começar a trabalhar.
Antes de entregar: para a análise e alinha com o stakeholder. Pode ser uma mensagem curta: "Comecei a olhar para X, mas percebi que para a decisão que você precisa tomar pode ser mais útil Y. Posso seguir os dois caminhos, mas se tiver que priorizar um, qual faz mais sentido para o que você precisa em seguida?" Isso parece recuo. Na prática, demonstra que você está pensando na decisão — não só na tarefa — e é o tipo de comportamento que constrói confiança com stakeholders ao longo do tempo.
Depois de entregar: a análise anterior pode servir como contexto para a conversa seguinte. O que corrói confiança nessas situações geralmente não é ter começado pela pergunta errada — é continuar refinando uma análise que não serve à decisão sem perceber o problema. Nomear o gap diretamente funciona melhor do que ignorá-lo: "Na análise que entreguei, respondi [pergunta declarada]. Percebi que para [ação do stakeholder], pode ser mais útil olhar para [reorientação]. Posso trazer isso ainda essa semana."
Em ambos os cenários, o movimento de reorientar explicitamente tende a ser recebido melhor do que parece de dentro. Stakeholders raramente esperam perfeição na definição inicial. Esperam que o analista perceba quando está no caminho errado.
Três situações para aplicar essa semana
Antes da próxima análise que você vai começar: escreva em uma frase o que seu stakeholder vai precisar fazer depois de ver o que você vai entregar. Se você não conseguir completar a frase com uma ação concreta, o alinhamento vale antes de começar.
Antes da próxima análise que você vai apresentar: abra com a implicação para a decisão, não com a metodologia. Em vez de "hoje vou apresentar a análise de retenção do Q1", comece com o que a análise indica que deveria acontecer e por quê — e use o restante da apresentação para mostrar o que levou a isso.
Para uma análise que você já entregou e ficou parada: antes de refazê-la, pergunte qual era a decisão que aquela pessoa precisava tomar quando recebeu o que você trouxe. Com frequência a análise era tecnicamente sólida e respondia a pergunta declarada com precisão. A pergunta operacional estava em outro lugar.
Logo menos, vou ensinar isso para vocês!
O raciocínio que descrevi aqui — como identificar a decisão antes de começar, como verificar se a pergunta declarada é a operacional, como apresentar resultados de forma que o stakeholder consiga agir — é o que estou pensando em compartilhar, de uma forma diferenciada.
