Além do dashboard: o que aprendi sobre dados sem ter background analítico

Escrito por: Giovana Nobrega Costa

Antes de trabalhar com dados, eu trabalhava com coisas que dava para tocar. Sou formada em engenharia de manufatura e, antes de migrar para analytics, trabalhei na Embraer por cerca de quatro anos como Engenheira de Desenvolvimento de Processos no time de Estratégia de Manufatura. Eu não tinha nenhuma experiência analítica prática que valesse mencionar: nada de anos escrevendo queries, nenhuma experiência construindo modelos e datasets, e nenhum hábito de pensar um negócio a partir das suas métricas.

Então, quando entrei em uma fintech conhecida por tomar decisões com base em dados, já direto como Senior Business Analyst, eu tinha quase certeza de onde teria dificuldade. Esperava que o lado técnico fosse a grande barreira. As pessoas ao meu redor pareciam fluentes em SQL e Scala, e eu imaginava que a distância entre nós era medida em linhas de código.

Eu estava errada. Não porque a parte técnica fosse trivial, mas porque ela acabou não sendo a parte difícil.

Recentemente, compartilhei essa história em um workshop sobre como desmistificar o uso de dados em gestão de produto. Este post é a versão escrita da parte mais pessoal dele: o que realmente mudou para mim quando passei a trabalhar com dados, e o que eu gostaria de ter sabido antes.

A lacuna que eu esperava

Quando você vem de uma área fora de dados, é fácil enxergar analytics como um clube técnico. O ingresso parece ser dominar as ferramentas: escrever queries que cruzam as tabelas certas, atualizar datasets conforme os bancos de dados mudam, construir dashboards de monitoramento ou montar decks que destacam os principais números e gráficos. Vistas de fora, essas tarefas podem parecer o trabalho inteiro, porque são a parte mais visível dele.

Na prática, essa parte veio mais rápido do que eu esperava. Além dos excelentes materiais de treinamento internos, o apoio da minha buddy (uma colega do Nubank designada para me ajudar nas primeiras semanas) foi inestimável. Ela criou exercícios com dados reais para responder perguntas como “Quantos clientes usaram o Produto X nos últimos 30 dias?”; eu resolvia esses exercícios tanto em SQL quanto em Scala, as duas linguagens que eu precisava aprender para o meu dia a dia. Essa abordagem mão na massa me ajudou a ganhar fluência nas duas em poucas semanas. Não foi sem esforço, mas era algo aprendível, e seguia um caminho que eu reconhecia: você trava, pesquisa ou pergunta para alguém, e na próxima vez fica um pouco mais rápido. E, naquela época, a gente nem tinha ferramentas de IA para ajudar a debugar o código ainda mais rápido.

Essa é a primeira coisa que eu diria para qualquer pessoa que esteja olhando para uma posição em dados a partir de produto, crédito, operações ou qualquer outra área, com o mesmo medo que eu tinha. As ferramentas são reais e importam. Mas elas são uma habilidade que se constrói, e raramente são o que separa uma boa análise de uma análise fraca.

A lacuna que eu realmente tinha

O que levou mais tempo foi algo que nenhum exercício de SQL ou Scala testa: o “so what”, o famoso “e daí?”.

Eu conseguia puxar os dados. Conseguia montar a tabela, calcular a métrica e colocá-la em um gráfico. Conseguia até criar um deck bonito e organizado. Mas chegava o momento em que alguém olhava para o que eu tinha produzido, e as perguntas de verdade começavam. O que isso significa? O que devemos fazer a respeito? Por que isso importa para o negócio?

Essas perguntas fundamentais surgiram quando criei um dos meus primeiros dashboards, no início do rollout do débito automático. Os dados estavam disponíveis e os gráficos estavam prontos, mas eu ainda precisava de tempo para entender como os clientes usavam o produto e construir contexto de negócio suficiente para identificar e responder às perguntas mais relevantes. Enfrentei o mesmo desafio ao montar uma apresentação resumindo a performance do produto.

Minha gestora me orientou e me deu feedbacks construtivos que me ajudaram a identificar pontos de melhoria. Um feedback de que me lembro como se fosse ontem foi: “Gaste menos tempo formatando dashboards e apresentações, e mais tempo entendendo o ‘so what’ – vá além de simplesmente descrever o que os gráficos mostram”. Em outras palavras, eu precisava focar primeiro no que os números estavam me dizendo e em como transformá-los em insights úteis, antes de fazer os ajustes finais. Usei esse feedback como norte para continuar desenvolvendo e afiando minhas habilidades analíticas de forma mais ampla.

Essa foi a verdadeira virada para mim. Dados, sozinhos, não movem um negócio. Um número descreve algo que aconteceu. Ele só se torna útil quando alguém o interpreta e transforma essa interpretação em uma decisão. Se eu paro no número, fiz a parte do trabalho que é mais fácil de ver e pulei a parte que realmente importa.

Um dashboard bonito não é uma resposta

Como apontado no feedback que minha gestora me deu, existe uma versão específica dessa armadilha em que é fácil cair: o dashboard.

Dashboards são úteis. Eles tornam a informação acessível, poupam as pessoas de fazer a mesma pergunta toda semana, e construir um bem desenhado é gratificante. Mas um dashboard é uma forma de mostrar dados, não uma conclusão sobre eles. Ele pode ser limpo, interativo e cheio de filtros, e ainda assim deixar quem o olha com a mesma pergunta de antes: e aí, o que eu devo fazer?

Como um dashboard parece pronto, é fácil confundi-lo com uma resposta. O esforço é visível, a qualidade visual é alta e dá a sensação de entrega. Mas se a pessoa que precisava tomar uma decisão ainda tem que descobrir o que os números significam, o trabalho só saiu da minha mesa e foi para a dela.

Vista por essa lente, a primeira pergunta em qualquer análise não é qual gráfico construir. É qual decisão a análise precisa apoiar, e o que alguém precisaria saber para tomá-la.

Dados, análise, recomendação

Hoje, penso em analytics como uma corrente com três elos:

dados → análise → recomendação

Os dados são a matéria-prima: o que aconteceu, quanto, quando e com quem. A análise é a interpretação: por que aconteceu, o que está diferente do que esperávamos, o que parece estar impulsionando a mudança. A recomendação é o posicionamento: diante do que estamos vendo, é isto que eu acho que devemos fazer, pelos motivos X, Y e Z, e é isto que esperaríamos que mudasse se fizermos.

A maior parte do esforço que as pessoas associam ao trabalho com dados está no primeiro elo. A maior parte do valor está nos outros dois. É tentador, principalmente quando você é nova na área e ainda está provando que dá conta das ferramentas, tratar a recomendação como opcional, quase como se fosse trabalho de outra pessoa. Não é. Uma análise sem recomendação entrega a parte mais difícil do raciocínio para quem a lê, e essa pessoa geralmente tem menos contexto do que quem fez a análise.

Essa distinção importa porque muda o que significa “pronto”. Uma query que roda não está pronta. Uma métrica correta não está pronta. O trabalho está pronto quando alguém consegue tomar uma decisão melhor por causa dele.

Por que isso importa em gestão de produto

Conversas sobre dados em gestão de produto costumam começar pelas ferramentas: quais métricas acompanhar, quais dashboards construir, quais experimentos rodar. Essas perguntas são importantes. Mas as decisões de um time de produto dependem menos de quantos dados ele tem e mais de alguém transformar esses dados em uma recomendação clara, que o time possa discutir, questionar e colocar em prática.

Essa é a parte que, para mim, precisa ser desmistificada. Usar bem os dados em produto não tem a ver com ser a pessoa mais técnica da sala. Tem a ver com chegar rápido ao “so what” e comunicá-lo com clareza, com a análise por trás para sustentar a conversa.

A análise que construímos vai depender muito da fase do produto. Para um produto novo prestes a começar um rollout gradual com uma pequena amostra de clientes, a prioridade pode ser monitorar performance e estabilidade: o produto está estável? Estão acontecendo erros inesperados, e eles estão afetando os clientes?

Responder a essas perguntas exige dados, mas a análise também deve levar a uma recomendação clara. Por exemplo, se o produto está estável e performando como esperado, poderíamos recomendar ampliar o rollout depois de revisar as principais métricas de estabilidade e confirmar que elas atendem às expectativas.

Por trás de todo lançamento de produto, uma série de perguntas “so what?” baseadas em dados orienta decisões importantes. É comum coletar dados por meio de experimentação direta com clientes, para entender o comportamento real deles em vez de depender de suposições.

O papel de business analyst abrange todo o processo, desde o desenho do teste até a interpretação dos resultados e a recomendação de um caminho a seguir. Para mais detalhes sobre experimentação e exemplos de cases de produto, confira este vídeo.

Assista aqui.

O que eu diria para quem está começando de onde eu comecei

Olhando para trás, o medo que eu tinha antes de entrar estava apontado para o lugar errado. Gastei energia me preocupando com a parte que acabou sendo aprendível e cheguei menos preparada para a parte que realmente define o trabalho. A lacuna técnica se fecha com prática. A lacuna do “so what” só se fecha quando você passa a tratar a recomendação como parte do trabalho.

Então, se você está vindo de fora da área de dados, aprenda as ferramentas, mas não pare por aí. Antes de construir qualquer coisa, escreva a pergunta. Quando tiver o número, pergunte o que ele significa. Quando souber o que ele significa, diga o que você faria.

Um dashboard bonito não é uma resposta. A resposta é o que você recomenda fazer com o que ele mostra.