DEV Community: Osborn Sifuna

Power BI Is More Than Dashboards: Why It Belongs in Modern Data Work

Osborn Sifuna — Wed, 01 Jul 2026 14:34:55 +0000

Despite the rise of Python, R, notebooks, cloud warehouses, and custom analytics platforms, Power BI remains one of the most important tools in my data workflow. I do not see it as a replacement for code, and I would not use it to train a model or manage heavy data engineering logic. But I have learned that Power BI is where analysis becomes visible, repeatable, and usable for the people who actually need to make decisions from it.

I did not appreciate that at first. Early in my data journey, I was more excited by Python scripts, SQL queries, machine learning models, and clean notebooks. Dashboards felt like the final decoration after the “real” work was done. I thought the serious part of data lived in the code, while Power BI was just the place where charts went. That view changed when I started working with teams that needed more than answers. They needed a shared place to keep returning to those answers.

One project made that clear. I was working on a fraud-detection analysis for a payments team, and the model output looked solid in Python. We had suspicious transactions, merchant risk scores, flagged patterns, and supporting features. But every review meeting became a long explanation of screenshots, exported tables, and notebook cells. The business team wanted to slice the results by country, merchant category, payment channel, and time period. I could answer those questions manually, but it was slow and frustrating.

So I moved the analysis into Power BI. I connected the transaction data, built relationships between merchants, accounts, and payment events, and created measures to track fraud rate, flagged volume, average transaction value, and false-positive review outcomes. I used Power Query to clean inconsistent fields before loading the model, then used DAX to create calculations that matched how the risk team actually defined performance. Once the report was published, the conversation changed. Stakeholders stopped asking me to “pull one more cut” and started exploring the data themselves.

That is where Power BI earns its place. It turns analysis from a one-time explanation into a living product. A notebook can prove that an insight exists, but a good Power BI report lets people revisit that insight tomorrow, next week, and next month. For recurring business questions, that matters. Sales teams need to track pipeline movement. Finance teams need to monitor revenue leakage. Operations teams need to spot delays before they become expensive. Power BI gives those teams a practical interface for watching the business move.

The technical side is stronger than many people outside BI realize. Power Query is useful for cleaning, shaping, and standardizing data before it enters the model. Relationships force you to think carefully about grain, keys, and how tables connect. DAX can be challenging, but it is powerful when used for measures that respond dynamically to filters and context. Row-level security matters when different users should see different slices of the same report. In my opinion, learning Power BI well makes you better at data modeling because it exposes weak assumptions quickly.

Power BI also improves communication in a way code rarely does on its own. A beautifully engineered Python pipeline is valuable, but it does not automatically help a manager decide which region needs attention or which customer segment is underperforming. A report with clear filters, reliable measures, and thoughtful visuals gives non-technical stakeholders a way to ask their own questions. That does not reduce the value of technical work. It extends its reach.

I have seen this in churn analysis, demand forecasting, marketing performance, and financial reporting. The model may live in Python. The source data may come from SQL. The transformations may eventually move into a warehouse. But the decision often happens in Power BI because that is where people can see trends, compare segments, challenge numbers, and align on what action to take. In that sense, Power BI is not just a visualization tool. It is a meeting place for data and business context.

Power BI has real limitations, and ignoring them leads to bad systems. Complex transformations can become difficult to maintain if too much logic is hidden inside reports. DAX measures can grow confusing without naming conventions and documentation. Large models need careful performance tuning. Version control is not as natural as it is in code. When work becomes mission-critical, Power BI should sit on top of strong data pipelines, tested transformations, and governed datasets.

That is the balance I try to practice. I use SQL to get close to the source, Python to explore, automate, and model, and Power BI to make results accessible and durable. I chose data partly because I wanted a career with strong earning potential, but I stayed because I enjoy turning confusion into clarity. Power BI is one of the tools that makes that clarity visible. It reminds me that data work is not finished when the code runs. It is finished when people can understand the result, trust it, and use it to make a better decision.

Excel Isn’t Dead: Why It Still Belongs in Modern Data Work

Osborn Sifuna — Wed, 01 Jul 2026 14:22:22 +0000

I chose data for a reason I used to avoid saying out loud: the money mattered. I wanted a career that could pay well, open doors, and give me skills that were useful across industries. But I stayed in data for a different reason. I like the feeling of taking something messy, confusing, and ignored, then turning it into something people can actually use. That is also why I still use Excel, even while working with Python, SQL, dashboards, and machine learning tools.

For me, Excel is not a career path by itself. I am not trying to become “the Excel person” in the room. My path is in data analytics, applied data science, and eventually stronger analytics engineering work, where I can move between business problems, technical systems, and decision-making. Excel sits right in the middle of that path. It helps me understand data before I automate it, explain results before I productionize them, and work with stakeholders before I ask them to trust a model.

A typical week shows this better than theory. On Monday, I might receive a messy CSV from an operations team. The file has inconsistent customer IDs, blank fields, strange date formats, and duplicate rows. Before opening Python, I often open Excel. I use filters to inspect categories, conditional formatting to spot missing values, and quick pivot tables to understand what the dataset is really saying. That first look helps me avoid writing clean code for the wrong problem.

On Tuesday, I might use Power Query to clean a file that someone will need to refresh again next week. I can remove extra columns, split fields, standardize names, merge lookup tables, and leave behind a process that a business user can inspect. Could I do it in Python? Yes. Sometimes I should. But when the audience is a finance or operations team that already lives in Excel, Power Query becomes a practical middle ground between manual cleanup and full engineering.

By Wednesday, Excel often becomes my testing ground. If I am working on a fraud-detection model, for example, I may export flagged transactions into a workbook and use pivot tables to summarize risk by merchant, country, transaction type, or time of day. I might use XLOOKUP to bring in merchant metadata from another file, then apply conditional formatting to highlight unusually large transactions or repeated failed attempts. This does not replace the model. It helps me see whether the model output makes business sense.

On Thursday, Excel becomes a communication tool. I might send a workbook to a stakeholder who does not care about my notebook, my feature engineering, or my model validation process. They care about which customers are risky, which products are underperforming, or which region needs attention. Excel gives them a place to filter, comment, challenge, and add context. A perfect Python pipeline is useless if the people who need the output cannot act on it.

By Friday, I usually know what should stay in Excel and what should move out. If the task is small, temporary, or exploratory, Excel is enough. If the workflow is recurring, sensitive, large, or mission-critical, it belongs in code, databases, tests, version control, and documentation. That distinction matters. Excel becomes dangerous when people use it as hidden infrastructure. But it becomes powerful when people use it as a fast thinking space.

That is why I think technical people in data should stop treating Excel like a beginner tool. Pivot tables are still one of the fastest ways to summarize a dataset. Power Pivot and DAX can support serious business analysis. Dynamic array formulas make modern Excel more flexible than many people realize. Conditional formatting is simple, but it is excellent for quick exploratory analysis. Excel is not impressive because it is complex. It is valuable because it makes useful work happen quickly.

I also think Excel teaches something that coding alone does not always teach: proximity to the business. In a notebook, it is easy to become obsessed with elegance. In Excel, you are closer to how people actually argue with numbers. Someone will ask why a total changed. Someone will filter a region you forgot to check. Someone will notice that a “duplicate” is actually a valid business case. Those moments make the analysis better.

So yes, I use Python. I use SQL. I care about reproducibility, clean pipelines, and scalable systems. But I still use Excel almost every week because data work is not only about building technically correct solutions. It is about moving from confusion to clarity. It is about helping people trust what they are seeing. It is about turning raw information into decisions.

I may have entered data partly because I wanted a career with strong earning potential, but I stayed because the work rewards curiosity. Excel is one of the places where that curiosity starts. Before the model, before the dashboard, before the production pipeline, there is usually a messy file and a question. Excel gives me a fast way to begin answering it.