My 8 Month Power BI Journey

If you were to ask me whether I am a Power BI expert, my answer would depend on who you are. If you knew nothing about Power BI, then I am certainly an expert. Perhaps, I’m a genius to you. But if you’re a seasoned data professional, with years of Power BI experience, then I am far from an expert.

The only people who would ever dare ask if I’m a Power BI expert are those in the data field. So, the unfortunate truth is that I cannot call myself an expert. But that’s okay. I haven’t worked with the tool for long, so I’m not afraid to say that I have a lot to learn.

Even though I’m not an expert, I can still say I’m dangerous with the tool. I’m competent enough to build end-to-end solutions and create reports/dashboards that are useful and valuable.

I feel confident developing with Power BI, but I couldn’t say the same about myself in 2025, when my Power BI journey commenced.

At my current data analyst job, my scope of work has revolved around a few things: building/maintaining reports, developing data models and SQL views for software teams, and using SQL to automate data processes.

When it comes to reporting, my team has relied on SQL Server Reporting Services (SSRS). It’s a legacy reporting tool that has been around almost as long as I’ve been alive. Since this job is my introduction to the data industry, SSRS is the first and only reporting tool I’ve ever encountered. So, although I find SSRS flexible and developer-friendly, I have no other tool to compare it to.

Over time, especially the last 10-15 years, numerous reporting and business intelligence (BI) tools have emerged and modernized the way data professionals interact with data. While thousands of other companies adopt these modern tools, my company has stuck with SSRS. Our reporting ecosystem has close to 100 frequently used reports, so migrating to a new system would be cumbersome.

Though eventually, everyone has to move on and grow.

In December 2024, my team and I realized we should explore a new BI tool to improve our data delivery and enable our users to interact with data. Since we already had a heavy investment in the Microsoft tech stack, Power BI was our obvious choice.

We spent January 2025 performing basic research and creating simple semantic models and reports. Our goal was to demo Power BI to the higher-level decision makers who would approve our pursuit of the tool and provide the necessary budget.

We started off hot. Everyone on my team learned enough for us to develop a working demo that showcased how Power BI could benefit us more than SSRS. Come February, we presented the demo to the decision makers and received approval to integrate Power BI into our toolbox. The agreement was to identify our pilot team and build a more sophisticated demo to present to them in March.

Things looked good for us. Our hopes were high, and we sensed momentum lurking around the corner.

But when we turned that corner, the expected momentum was nowhere to be found. February passed, and we made no progress. My team and I were bogged down by our usual day-to-day tasks and ad-hoc requests. None of us could make time to advance our Power BI knowledge. March rolled along, and the same thing happened. More tasks arose, and I received an urgent, time-sensitive project that filled my schedule. Halfway through April, the same trend persisted.

What should have been two months of rapid development and growth transformed into two months of nothing.

This was our wakeup call. Our company was growing fast, and every day introduced new problems that required our attention. We realized our usual day-to-day tasks and ad-hoc work would never stop, so we decided that one of us had to take on less work and completely immerse themself in the Power BI world.

That person was me.

For the next month, I took on fewer tasks and spent all of my time researching, exploring, and experimenting with Power BI. This worked. I learned the foundations of building Power BI development and architecting solutions from start to finish.

During this learning phase, we already knew who the pilot project team would be. Since no one on my team had Power BI experience, we couldn’t adopt the tool and start delivering solutions to everyone across the organization. Instead, we had to be strategic and start small. By beginning our Power BI journey with one team, we could figure out the most optimal ways to leverage Power BI so that when it came time to expand to other teams, we could deliver value fast.

Having one pilot team helped me focus my demo projects on reports and datasets that related to their work. Since my Power BI experience was basically two months old at the time, my builds were raw and scrappy. Despite this, my builds highlighted the advantages of Power BI over SSRS.

The pilot team liked what we had to offer and was willing to give it a shot. This happened around mid-May, so I told them I’d clean up my builds and create a production environment for them to use by the end of the month.

This was a big mistake.

I created my demo solutions by translating SSRS reports into Power BI. Aside from handy slicers and drill-throughs, I realized my Power BI reports were identical to their SSRS counterparts. The way users interacted with the reports felt the same. Mimicking SSRS reports in Power BI, while feasible, was not effective. I needed to do something different but didn’t know where to start.

So, instead, I created the production workspace with polished versions of the demo reports and gave the pilot team access. We agreed to meet two weeks later for a check-in meeting, so they had time to explore the new tool and determine what was and wasn’t useful. When the check-in meeting happened, the pilot team liked how they had an easier way to slice and access data, but nothing I built was going to save time.

It turns out I ignored a crucial part of the development process. I created my initial reports based on what the pilot team already had and what I predicted would benefit them. But since I’m not immersed in their day-to-day work, I was gambling. The smarter route would have been to build what the team said they needed, not what I predicted.

During the next check-in meeting, my team and I asked better questions. We probed the pilot team to learn not only about the data they needed but also how they used the data downstream. We walked through each report and asked what their goals were, how they planned to use the data, and how they would use the data after we delivered it. Through this process, we received mockups of the reports and insights they hoped to generate using our data. This helped a lot. Rather than guessing at what the team would find useful, I discovered what was actually useful. This allowed me to allocate my time and energy in the right direction.

The journey, once again, looked promising.

I wish I could say that my Power BI journey grew at an exponential rate and that weeks later I delivered exceptional results to our pilot team. But life’s not that simple. Instead, I hit another lull, and my momentum plummeted.

We were in June now, and I slowly merged myself back into the day-to-day ad-hoc requests my team had processed without me for the previous months. Combine that with yet another time-sensitive project and summer vacations, and I made little progress with Power BI.

In the middle of July, my time-sensitive project ended, and everyone returned from vacations. My team realized we were heading towards the same situation we faced in February and March, where day-to-day tasks pulled us away from Power BI. So, again, we agreed I should take on less work and go all-in on Power BI development.

This was the best decision we made in a while.

Now that I had a few months of Power BI development experience, things started to click. I could build reports without having to research a feature every five seconds, and I felt confident with my abilities. Between higher-quality check-in meetings with our pilot team and my newfound Power BI confidence, I could churn out Power BI reports within 1-2 days.

The feedback I received from our pilot team became more positive, and my builds saved time and became useful. For the first time all year, my Power BI journey looked optimistic.

Now that it’s the end of August, my journey is far from over. My team and I are finishing up the pilot phase and are on the verge of introducing Power BI to other teams. I’m hoping that, in six months’ time, my team will frequently deliver useful and time-saving Power BI solutions to 4-6 internal teams. I’m sure there will be lulls and periods where my Power BI development stalls, but now that my knowledge has grown and I can execute reports faster, my six-month goal is attainable.

Years ago, while searching for my first data analyst job, I put Tableau (a business intelligence tool similar to Power BI) on my resume. My naivety led me to believe that since I had built one terrible portfolio project with Tableau, I could say I was experienced. The truth is that I wasn’t even competent with the tool. Luckily, in all the interviews I had, none of the interviewers probed into my true Tableau proficiency. Had they done it, they would have exposed my lack of expertise and killed my chances at landing the roles.

However, if I were to throw Power BI on my resume today, things would be different. I would be confident enough to talk about how I’ve learned the tool quickly and built solutions that actually generate value and save time.

Revisiting what I said at the start of this essay, if you were to ask me if I were a Power BI expert, I would humbly say “no.” I’ve only worked with the tool for eight months, but factoring in the distractions and stalled periods, the number is closer to four months.

Although I'm not an expert, it doesn’t mean I’m incompetent or unable to deliver value with Power BI. I’m still dangerous with the tool. And if I continue to grow at my current rate and stay consistent, in six months' time, I will feel unstoppable with Power BI.

That’s something I look forward to.