Written by: Nubank Editorial & Guilherme Lasinskas

At Nubank, Business Analysts connect data analysis to business decisions. Internally, the role is often described as the rational engine and business guardian inside a squad. In practice, that means working closely with the team to understand what the data is actually saying, what trade-offs exist in each path, and which assumptions we are making before any feature is prioritized, adjusted, or discontinued.

An important part of the role is being able to make — and monitor — decisions even in uncertain scenarios, when the data does not provide a definitive answer. Dashboards, queries, and reports are part of the routine, but the main deliverable of a BA is not a dashboard. It is clarity around which decision makes the most sense and why.

At the beginning of my second year as a Business Analyst at Nubank, I was asked to investigate why a metric had dropped. I opened the tools, built a segmented analysis by channel and customer profile, and spent two weeks deep in the data. When I finally compared the behavior to the same period in the previous year, the answer appeared: the drop was seasonal. It had happened every first quarter for the past three years, and I could have discovered that in an hour.

So what does a BA’s day-to-day actually look like in practice?

I have a degree in Computer Engineering with a specialization in Finance, and since I work as a BA in a multidisciplinary squad at Nu, I was invited to share what that experience looks like.

The morning: squad meetings and questions before any query

Nubank operates through squads: autonomous multidisciplinary teams responsible for specific areas of product and business. My day usually starts with a quick 15-minute meeting with the PM (Product Manager, responsible for prioritizing what the team will build) and the tech lead (the engineer responsible for the squad’s technical decisions).

In these alignments, each role contributes a different perspective. The tech lead evaluates technical feasibility and system impact. The PM brings the context of user experience and the product roadmap. As a BA, I analyze the data to understand which paths are available and what we are giving up with each one.

That combination of perspectives is one of the most important decision-making mechanisms here.

For example, I once participated in a discussion about discontinuing a feature with low adoption. The tech lead knew that removing the feature would free up engineering capacity, but it would also require a data migration no one had considered. The PM understood that the active users of that feature had a high-value profile. And I brought an analysis showing that adoption was growing in a specific segment that the aggregate dashboard was not revealing.

None of those perspectives alone would have led to the best decision. The tech lead alone would probably have recommended removing the feature based on maintenance costs. The PM would likely have argued to keep it because of the user profile. And the analysis alone would have suggested waiting longer.

Together, those three lenses led the squad to adapt the feature for the growing segment and deactivate it for everyone else, an alternative that did not even exist before the conversation. That is how multidisciplinary decision-making works in practice: one function’s blind spots are compensated for by another’s perspective. The more complex the decision, the more that complementarity matters.

Depending on the squad, this dynamic changes. In Credit and Fraud squads, for example, the BA role intersects heavily with data scientists and machine learning engineers. While those teams develop complex predictive models, such as risk scores, the BA’s role is to transform the output of those models into real decision policies.

In practice, that means answering questions like: at which score threshold should we approve a customer to balance user experience and business sustainability? The model provides the probability. The BA defines the decision threshold.

After alignment meetings, the analytical work begins. The tools I use most often in my daily routine include:

  • Databricks / Spark: a large-scale data processing platform. Most exploratory analyses start here, with queries in SQL and Scala on datasets with billions of records.
  • Business Intelligence tools: metric monitoring dashboards.
  • Documentation tools: every analysis that supports a product decision is recorded in a history accessible to the squad.
  • Artificial intelligence: used to accelerate query writing, data cleaning, and analysis prototyping.

But before opening any of these tools for a new analysis, I usually go through a quick checklist:

  1. Has this pattern appeared during the same period in previous years?
  2. Is there any known external factor that could explain this?
  3. Which decision will actually change based on what I find?

Check our job opportunies

The afternoon: solving a real problem

Afternoons are usually my focus block: calendar closed for deep analytical work.

At Nubank, BAs generally operate across four main fronts: building risk policies in Credit, analyzing campaign conversion in Marketing, scaling operational efficiency, or maximizing engagement in Product. The case below illustrates a classic challenge in the daily routine of a Product BA.

The problem

The squad launched a new screen in the app. The feature is running as an A/B test, splitting customers into five different groups. After a few weeks, preliminary data shows that two of those groups are presenting churn rates above the control group average.

The natural reaction would be to disable the screen and reallocate engineers to the next roadmap priority.

Framing the problem before opening any tool

Before diving into the data, I structure four questions inspired by hypothesis-driven analysis approaches commonly used in strategic consulting, adapted to the context of product squads:

What decision will be made based on this result? 

The squad is considering disabling the screen and reallocating engineering capacity. It is a concrete decision, with both reversible and irreversible costs.

What would need to be true for this decision to change? 

The screen would need to show retention equivalent to the average or some secondary benefit capable of justifying continued investment.

Have we already tried to answer this before?

There’s no previously documented analysis — just the weekly monitoring dashboard.

What’s the simplest data that answers this? 

Retention by group with a statistical significance test, before any more sophisticated modeling.

What the data shows

I then run a two-proportion z-test, comparing the churn rates of each test group against the control group.

Even with meaningful customer sample sizes, the two groups with the highest churn rates have p-values of 0.12 and 0.23. A p-value measures the probability that the observed difference happened by chance. The lower the value, the more reliable the conclusion. Values below 0.05 are typically considered statistically significant.

The results indicate that the observed difference is still compatible with random variation. In other words, there is not enough evidence to conclude that the new screen is causing churn.

When looking at secondary metrics, those same groups show increased engagement with other areas of the app. Customers exposed to the screen begin exploring features they had not previously used (p < 0.01, with statistical significance).

In practice, the new screen is functioning as an entry point to other product experiences — even in the groups that initially appeared problematic.

The impact

Two hours of structured analysis transform a binary decision (“disable it or not”) into a much more sophisticated discussion about what is gained and lost in each scenario.

The squad decides to keep the screen active, adjust the content shown to the groups with higher churn, and establish a new review in 30 days with clearly defined success criteria.

Without that framing, the estimated cost would have been three to four engineering sprints rebuilding something that was already working in practice.

Decision documentation

The final step of the analytical process is documenting every non-trivial decision in a document containing the data, assumptions, and trade-offs involved.

Without documentation, squads lose context quickly. Months later, no one can explain why a feature was discontinued, and someone ends up restarting the same analysis from scratch to answer a question that had already been solved before.

Our analytical culture: rituals and continuous learning

What most differentiates Nubank’s analytical environment, in my experience, is the combination of data scale and a culture that treats evidence-based decisions as an operational standard.

The continuous user-centered iteration that led to products like Street Mode and Smart Suggestions in the app only works because squads keep the cycle of analysis, decision-making, and documentation alive in every sprint.

Some rituals help sustain that in daily work:

Decision reviews: before an important decision moves into execution, we revisit questions like: what assumptions are we making? How strong is the evidence? What happens if we are wrong?

Analysis community: BAs from different squads regularly meet to share analyses, discuss methodologies, and review cases where analysis changed — or should have changed — a decision.

Peer review: analyses supporting high-impact decisions are reviewed by another BA before presentation to stakeholders.

Analytical onboarding: new BAs spend their first weeks pairing with more experienced teammates. The focus is less on tools and more on analytical judgment: how to structure a problem, what is worth investigating, and when to stop analyzing.

Learning how to operate tools is faster. Learning how to frame problems takes longer.

My advice for future Nubankers

Tip 1: Practice framing before analysis

In Nubank’s case interviews — the well-known Crack the Case — we are not simply looking for people who can quickly reach a final number.

What we evaluate is the ability to logically structure a problem, separate financial and non-financial factors, and articulate the trade-offs involved before diving into calculations.

A simple exercise: the next time you receive an analysis request, write down in one sentence who the decision-maker is and what decision will be made based on your work. If you cannot answer that clearly, the scope probably still needs refinement.

Tip 2: Document assumptions, trade-offs, and the cost of being wrong

In interviews and in day-to-day work, the people who stand out most are the ones who can clearly explain which assumptions they made, what risks exist in the approach, and what would change the conclusion.

An analysis with well-documented limitations demonstrates more analytical maturity than a technically sophisticated analysis with no audit trail.

Tip 3: Lead with the recommendation, not the report

When presenting an analysis, start with the implication:

“The data suggests we should reallocate investment from X to Y because of this evidence.”

Only then should you present the data supporting the recommendation.

That structure — recommendation first, evidence second — follows the Minto Pyramid Principle and closely matches how executive audiences expect to consume information. It signals that you understand not only the data, but also the decision-making context behind your own work.

Build the future with us

If using data to drive business decisions that impact millions of Nu customers sounds interesting to you — along with the analytical challenges that come with it — we are always looking for Business Analysts for different product squads.

Check our job opportunies