Muito além dos dados: o que faz um Business Analyst no Nubank

Escrito por: Nubank Editorial & Guilherme Lasinskas

No Nubank, Business Analysts conectam análise de dados a decisões de negócio. Internamente, o papel costuma ser descrito como o motor racional e o guardião do negócio dentro do squad. Na prática, isso significa trabalhar junto ao time para entender o que os dados realmente mostram, quais trade-offs existem em cada caminho e quais premissas estamos assumindo antes que qualquer funcionalidade seja priorizada, ajustada ou descontinuada.

Uma parte importante do trabalho é conseguir tomar (e acompanhar) decisões mesmo em cenários de incerteza, quando os dados não entregam uma resposta definitiva. Painéis, consultas e relatórios fazem parte da rotina, mas o principal entregável de uma pessoa BA não é um dashboard, e sim a clareza sobre qual decisão faz mais sentido e por quê.

No começo do meu segundo ano como Business Analyst no Nubank, recebi um pedido para investigar a queda de uma métrica. Abri as ferramentas, construí uma análise segmentada por canal e perfil de cliente e passei duas semanas mergulhando nos dados. Quando finalmente comparei o comportamento com o mesmo período do ano anterior, a resposta apareceu: a queda era sazonal. Acontecia em todo primeiro trimestre havia três anos, e eu poderia ter descoberto isso em uma hora.

E como é o dia a dia de um BA na prática?

Eu sou formado em Engenharia da Computação com especialização em Finanças e, como trabalho como BA em um squad multidisciplinar do Nu, fui convidado para contar tudo.

A manhã: reuniões do squad e perguntas antes de qualquer consulta

O Nubank opera em squads: times multidisciplinares autônomos responsáveis por uma área específica de produto e negócio. Meu dia normalmente começa com uma reunião rápida de 15 minutos com o PM (Product Manager, responsável por priorizar o que o time vai construir) e o tech lead (engenheiro responsável pelas decisões técnicas do squad).

Nesses alinhamentos, cada função contribui com uma perspectiva diferente. O tech lead avalia viabilidade técnica e impacto em sistemas. O PM traz o contexto de experiência do usuário e do roadmap do produto. Eu, como BA, analiso os dados para entender quais caminhos estão abertos e o que estamos abrindo mão em cada um deles.

Essa combinação de perspectivas é um dos mecanismos mais importantes de tomada de decisão aqui.

Já participei, por exemplo, de uma discussão sobre descontinuar uma funcionalidade com baixa adoção.. O tech lead sabia que remover aquela funcionalidade liberaria capacidade de engenharia, mas também exigiria uma migração de dados que ninguém havia considerado. O PM entendia que os usuários ativos daquela funcionalidade tinham um perfil de alto valor, e eu trouxe uma análise mostrando que a adoção estava crescendo em um segmento específico que o painel agregado não revelava.

Nenhuma dessas perspectivas, isoladamente, teria levado à melhor decisão. O tech lead sozinho provavelmente recomendaria remover a funcionalidade com base no custo de manutenção. O PM tenderia a mantê-la por causa do perfil de usuários, e a análise, sozinha, sugeriria esperar mais tempo.

Juntas, essas três lentes levaram o squad a ajustar a funcionalidade para o segmento em crescimento e desativá-la para os demais, uma alternativa que sequer existia antes da conversa. É assim que decisões multidisciplinares funcionam na prática: os pontos cegos de uma função são compensados pela visão das outras. Quanto mais complexa a decisão, mais essa complementaridade importa.

Dependendo do squad, essa dinâmica muda. Em squads de Crédito e Fraude, por exemplo, o trabalho do BA se cruza fortemente com cientistas de dados e engenheiros de machine learning. Enquanto essas pessoas desenvolvem modelos preditivos complexos, como scores de risco, o papel do BA é transformar a saída desses modelos em políticas reais de decisão.

Na prática, isso significa responder perguntas como: a partir de qual score devemos aprovar um cliente para equilibrar experiência e sustentabilidade do negócio? O modelo entrega a probabilidade e o BA define a régua de decisão.

Depois do alinhamento, começa o trabalho analítico. As ferramentas que mais uso no dia a dia incluem:

• Databricks / Spark: plataforma de processamento de dados em larga escala. A maior parte das análises exploratórias começa aqui, com consultas em SQL e Scala sobre conjuntos de dados com bilhões de registros.
• Ferramentas de BI (Business Intelligence, ou inteligência de negócio): painéis de monitoramento de métricas.
• Ferramentas de documentação: toda análise que embasa uma decisão de produto fica registrada em um histórico acessível ao squad.
• Inteligência artificial: usada para acelerar escrita de consultas, limpeza de dados e prototipação de análises.

Antes de abrir qualquer ferramenta para uma análise nova, costumo passar por um checklist rápido:

1. Esse padrão já apareceu no mesmo período do ano passado?
2. Existe algum fator externo conhecido que explique isso?
3. Qual decisão realmente vai mudar com o que eu encontrar?

A tarde: resolvendo um problema real

A tarde costuma ser meu bloco de foco: agenda fechada para trabalho analítico profundo.

No Nubank, BAs geralmente atuam em quatro frentes principais: desenvolvimento de  políticas de risco em Crédito, análises de conversão de campanhas em Marketing, escalabilidade operacional  ou maximização de engajamento em Produto. O caso abaixo ilustra um desafio clássico do dia a dia de um BA de Produto.

O problema

O squad lançou uma nova tela no app. A tela está em teste A/B, dividindo clientes em cinco grupos diferentes. Depois de algumas semanas, os dados preliminares mostram que dois desses grupos apresentam churn acima da média do grupo de controle.

A reação natural seria desativar a tela e realocar os engenheiros para o próximo item do roadmap.

O enquadramento antes de abrir qualquer ferramenta

Antes de mergulhar nos dados, estruturo quatro perguntas inspiradas em abordagens de análise orientada por hipóteses comuns em consultoria estratégica, adaptadas ao contexto de squads de produto:

Qual decisão vai ser tomada com esse resultado?

O squad está considerando desativar a tela e realocar capacidade de engenharia. É uma decisão concreta, com custos reversíveis e irreversíveis.

O que precisaria ser verdade para essa decisão mudar?

A tela precisaria apresentar retenção equivalente à média ou algum benefício secundário capaz de justificar o investimento contínuo.

Já tentamos responder isso antes?

Não há análise prévia documentada, apenas o painel de monitoramento semanal.

Qual é o dado mais simples que responde isso?

Retenção de grupo com teste de significância estatística, antes de qualquer modelo mais sofisticado

O que os dados mostram

Rodo então um teste de proporções (two-proportion z-test), comparando as taxas de churn de cada grupo de teste contra o controle.

Mesmo com amostras relevantes de clientes, os dois grupos com churn mais alto têm p-values de 0.12 e 0.23. O p-value mede a probabilidade de a diferença observada ter ocorrido por acaso. Quanto menor, mais confiável a conclusão. Valores abaixo de 0.05 costumam ser considerados significativos.

Os resultados encontrados indicam que a diferença observada ainda é compatível com variação aleatória. Ou seja: não existe evidência suficiente para concluir que a nova tela causa cancelamento.

Ao olhar métricas secundárias, esses mesmos grupos mostram um aumento no engajamento com outras áreas do app. Clientes expostos à tela passam a explorar funcionalidades que antes não utilizavam (p < 0.01, com relevância estatística).

Na prática, a nova tela está funcionando como ponto de entrada para outras experiências do produto, mesmo nos grupos que inicialmente pareciam problemáticos.

O impacto

Duas horas de análise estruturada transformam uma decisão binária (“desativar ou não”) em uma discussão mais sofisticada sobre o que se ganha e o que se perde em cada cenário.

O squad decide manter a tela ativa, ajustar o conteúdo exibido para os grupos com churn mais alto e estabelecer uma nova revisão em 30 dias, agora com critérios claros de sucesso.

Sem esse enquadramento, o custo estimado seria de três a quatro sprints de engenharia reconstruindo algo que, na prática, já estava funcionando.

Documentação de decisões

A última etapa do processo analítico é documentar toda decisão não-trivial em um documento com os dados, premissas e trade-offs envolvidos.

Sem documentação, o squad perde o contexto rapidamente. Meses depois, ninguém consegue explicar por que uma funcionalidade foi descontinuada, e alguém acaba recomeçando a mesma análise do zero para responder a uma pergunta que já havia sido resolvida antes.

Nossa cultura analítica: rituais e aprendizado contínuo

O que mais diferencia o ambiente analítico do Nubank, na minha experiência, é a combinação entre escala de dados e uma cultura que trata decisões orientadas por evidência como padrão operacional.

A iteração contínua centrada no usuário, que deu origem a produtos como o Modo Rua e as Sugestões Inteligentes no app, só funciona porque os squads mantêm vivo o ciclo de análise, decisão e documentação a cada sprint.

Aqui vão alguns rituais que sustentam isso no dia a dia:

Revisão de decisões: antes de uma decisão importante seguir para execução, revisitamos perguntas como: quais pressupostos estamos assumindo? Qual é a qualidade da evidência? O que acontece se estivermos errados?

Comunidade de prática de análise: BAs de diferentes squads se reúnem periodicamente para compartilhar análises, discutir metodologias e revisar casos nos quais a análise mudou uma decisão (ou deveria ter mudado).

Revisão por pares: análises que sustentam decisões de alto impacto passam pela revisão de outra pessoa BA antes da apresentação ao stakeholder.

Onboarding analítico: novos BAs passam as primeiras semanas fazendo análises em dupla com pessoas mais experientes. O foco está menos em ferramenta e mais em julgamento analítico: como estruturar um problema, o que vale a investigar e quando parar de analisar.

Aprender a operar ferramentas é mais rápido, mas aprender a enquadrar problemas leva mais tempo.

Meu conselho para futuros Nubankers

Dica 1: pratique o enquadramento antes da análise

Nas entrevistas de case do Nubank (o famoso Crack the Case), não buscamos apenas pessoas capazes de chegar rapidamente a um número final.

O que avaliamos é a capacidade de estruturar logicamente um problema, separar fatores financeiros e não financeiros e articular os trade-offs envolvidos antes de mergulhar nos cálculos.

Um exercício simples: na próxima vez que receber um pedido de análise, escreva em uma linha quem é o decisor e qual decisão será tomada com aquele trabalho. Se você não conseguir responder isso com clareza, provavelmente o escopo ainda precisa ser refinado.

Dica 2: documente premissas, trade-offs e o custo de errar

Na entrevista e no dia a dia, as pessoas que mais se destacam são as que conseguem explicar claramente quais premissas assumiram, quais riscos existem na abordagem e o que mudaria a conclusão.

Uma análise com limitações bem documentadas demonstra maturidade analítica do que uma análise tecnicamente sofisticada sem rastro de auditoria.

Dica 3: lidere pela recomendação, não pelo relatório

Ao apresentar uma análise, comece pela implicação:

“Os dados sugerem que deveríamos realocar investimento de X para Y por causa desta evidência.”

Só depois mostre os dados que sustentam a recomendação.

Essa estrutura (recomendação primeiro, evidência depois) segue o princípio da Pirâmide de Minto e se aproxima muito da forma como o público executivo espera consumir informação. Ela sinaliza que você entende não apenas os dados, mas também o contexto de decisão do próprio trabalho.

Construa o futuro conosco

Se usar dados para fazer análises que guiam as decisões de negócio que impactam os milhões de Nu é algo que te interessa, assim como qualquer tipo de desafio analítico, estamos sempre procurando Business Analysts para diferentes squads de produto.