most read
Software Engineering
Why We Killed Our End-to-End Test Suite Sep 24
Product
Product Managers: what they do and why we need them Feb 15
Software Engineering
The value of canonicity Oct 30
Careers
We are building diverse teams with the most creative and innovative professionals for each position we open.
Written by: Giovana Nobrega Costa
Before I worked with data, I worked with things you could touch. My background is in manufacturing engineering, and before moving into analytics I worked at Embraer for around four years as a Process Development Engineer on the Manufacturing Strategy team. I had no practical analytical background to speak of: no years of writing queries, no experience building models, datasets, and no habit of thinking about a business through its metrics.
So when I joined a fintech company known for making decisions with data, directly as a Senior Business Analyst, I was fairly sure I knew where I would struggle. I expected the technical side to be the wall. The people around me seemed fluent in SQL and Scala, and I assumed that the distance between us was measured in lines of code.
I was wrong about that. Not because the technical part was trivial, but because it turned out not to be the hard part.
I recently shared this story in a workshop on demystifying the use of data in product management. This post is the written version of its most personal part: what actually changed for me when I moved into a data role, and what I wish I had known before.
The gap I expected
When you come from a field outside data, it’s easy to see analytics as a technical club. The entry ticket seems to be knowing the tools: writing queries that join the right tables, updating datasets as databases change, building monitoring dashboards, or creating decks that surface the key numbers and charts. From the outside, those tasks can look like the whole job because they’re the most visible part of it.
In practice, that part came faster than I expected. Besides the excellent internal training materials, the support of my buddy – a Nubank colleague assigned to help during my first few weeks – was invaluable. She created exercises using real data to answer questions such as, “How many customers used Product X in the last 30 days?”; I solved these exercises in both SQL and Scala, the two languages I needed to learn for my day-to-day work. This hands-on approach helped me become proficient in both within just a few weeks. It was not effortless, but it was learnable, and it followed a path I recognized: you get stuck, you look it up or ask someone, and the next time you are a little faster. And back then, we didn’t have AI tools to help us debug our code even faster.
That is the first thing I would tell anyone looking at a data role from a product, credit, , operations or any other area, with the same fear I had. The tools are real, and they matter. But they are a skill you can build, and they are rarely what separates a good analysis from a weak one.
Check our job opportunies
The gap I actually had
What took me longer was something no SQL or Scala exercise tests: the “so what”.
I could pull the data. I could build the table, calculate the metric and put it in a chart. I could even create a beautiful and organized deck. However, I would reach the moment when someone looked at what I had produced, and the real questions began. What does this mean? What should we do about it? Why does it matter for the business?
These fundamental questions came up when I created one of my first dashboards, early in the rollout of automatic debit. The data was available and the charts were in place, but I still needed time to understand how customers used the product and build enough business context to identify and answer the most relevant questions. I faced the same challenge when putting together a presentation summarizing the product’s performance.
My manager guided me and gave me constructive feedback that helped me identify areas for improvement. One piece of feedback I remember as if it were yesterday was: “Spend less time formatting dashboards and presentations, and more time understanding the ‘so what’ – go beyond simply describing what the charts show”. In other words, I needed to focus first on what the numbers were telling me and how to turn them into useful insights before making final adjustments.I used that feedback as a north star to keep developing and sharpening my analytical skills more broadly.
That was the real shift for me. Data, on its own, does not move a business. A number describes something that happened. It only becomes useful when someone interprets it and turns that interpretation into a decision. If I stop at the number, I have done the part of the work that is easiest to see and skipped the part that actually matters.
A beautiful dashboard is not an answer
As noted in the feedback my manager gave to me, there is a particular version of this trap that is easy to fall into, and it is the dashboard.
Dashboards are useful. They make information available, they save people from asking the same question every week, and a well-designed one is satisfying to build. But a dashboard is a way of showing data, not a conclusion about it. It can be clean, interactive and full of filters, and still leave the person looking at it with the same question they had before: so what should I do?
Because a dashboard looks finished, it is easy to confuse it with an answer. The effort is visible, the visual quality is high, and it feels like delivery. But if the person who needed a decision still has to figure out what the numbers mean, the work has only moved from my desk to theirs.
Seen through that lens, the first question in any piece of analysis is not which chart to build. It is which decision the analysis needs to support, and what someone would need to know to make it.
Data, analysis, recommendation
The way I think about analytics now is as a chain with three links:
data → analysis → recommendation
The data is the raw material: what happened, how much, when and for whom. The analysis is the interpretation: why it happened, what is different from what we expected, what seems to be driving the change. The recommendation is the position: given what we see, this is what I think we should do, because of X,Y,Z reasons, and this is what we would expect to change if we do it.
Most of the effort people associate with data work lives in the first link. Most of the value lives in the other two. It is tempting, especially when you are new and still proving that you can handle the tools, to treat the recommendation as optional, almost as if it were someone else’s job. It isn’t. An analysis without a recommendation hands the hardest part of the thinking to whoever reads it, and that person usually has less context than the one who did the analysis.
That distinction matters because it changes what “done” means. A query that runs is not done. A metric that is correct is not done. The work is done when someone can make a better decision because of it.
Why this matters in product management
Conversations about data in product management often start with the tools: which metrics to track, which dashboards to build, which experiments to run. Those questions are important. But a product team’s decisions depend less on how much data it has and more on whether someone turns that data into a clear recommendation that the team can discuss, challenge and act on.
That is the part I think needs demystifying. Using data well in product is not about becoming the most technical person in the room. It is about getting to the “so what” quickly and saying it clearly, with the analysis behind it to support the conversation.
The analysis we build will depend heavily on the product’s phase. For a new product about to begin a phased rollout with a small customer sample, the priority may be to monitor performance and stability: Is the product stable? Are unexpected errors occurring, and are they affecting customers?
Answering these questions requires data, but the analysis should also lead to a clear recommendation. For example, if the product is stable and performing as expected, we could recommend increasing the rollout after reviewing the key stability metrics and confirming that they meet expectations.
Behind every product launch, a series of data-driven “so what?” questions drive important decisions. It’s common to gather data through direct experimentation with customers to understand their real behavior rather than rely on assumptions.
A business analyst’s role spans the entire process, from designing the test to interpreting the results and recommending a course of action. For more details on experimentation and examples of product cases, check this video.
Watch here.
What I would tell someone starting where I started
Looking back, the fear I had before joining was pointed at the wrong thing. I spent energy worrying about the part that turned out to be learnable, and arrived less prepared for the part that actually defines the work. The technical gap closes with practice. The “so what” gap only closes when you start treating the recommendation as part of the job.
So if you are coming from outside of data, learn the tools, but don’t stop there. Before you build anything, write down the question. When you have the number, ask what it means. When you know what it means, say what you would do.
A beautiful dashboard is not an answer. The answer is what you recommend doing with what it shows.
Check our job opportunies