Power BI for experts: 7 mistakes you don't want to make

Jokes (and espresso) aside, experts in Power BI are typically seasoned professionals who have a deep understanding of the various parts of the tool, as well as the processes and technologies around it. Experts usually have worked with Power BI for some time, but the time someone works with Power BI is not directly causative of expertise. What’s more indicative of someone’s expertise is: 

• The variety of scenarios and problems that they’ve encountered.   

• The effort and depth with which they’ve investigated and understood parts of the tool, often both in their own time and during projects. 

• Their understanding of the tool’s strengths and weaknesses, and the strengths and weaknesses of different features within it (as well as ways to best leverage the strengths and workarounds to mitigate the weaknesses). 

• Their specialization in one or more areas of the tool, like: 

• • DAX 

• • Data modelling 

• • Governance and administration 

• • Reporting (including paginated reports) 

• • Data visualization and dashboarding (which is related – but not equal to – reporting) 

• • And many others… 

Therefore, someone might be an expert with Power BI after only 1-3 years if they have seen a lot of things and put in extensive effort. In contrast, someone else who has used the tool for 5+ years but limited their experience to the same small models and a handful of reports, while not taking initiative to expand their knowledge, might still be an intermediate… or even a beginner. That’s perfectly fine, by the way, because chances are that this more seasoned intermediate is specialized in other things, like business disciplines, other tools, or even soft skills… all of which can help them succeed with Power BI. 

The bottom line is that an expert has seen and done many things, and has a deep (but still incomplete) understanding of Power BI, likely with deep specialization. But they still make mistakes!  

“Expert mistakes” might seem like an oxymoron (a figure of speech that combines two seemingly contradictory terms), but experts do still make mistakes. Plenty of mistakes! However, the mistakes that an expert makes look different than the mistakes a beginner or an intermediate makes. 

• Beginners tend to make a variety of mistakes as they learn, many of which revolve around the tool and technology they are learning. 

• Intermediates have grown their proficiency with the tool and technology. They still make mistakes with these tools and technology, but more commonly, their mistakes tend to be regarding the people and processes in their context, as intermediates grow to become more systemic and strategic in their approaches to solving problems. 

• Experts are, by definition, masters in their craft. However, this expertise costs time and focus that they can’t spend elsewhere, leading to blind spots in areas outside their domain of expertise, which they are probably unaware of. 

Below we list some of these mistakes that we think experts can make, including ourselves.  

Experts typically have a range of experiences that are quite broad, but not all-encompassing. Despite having a wide familiarity with the patterns and scenarios in Power BI, experts can fall into the trap of assuming that the things they see in their professional environment and networks reflect the aggregate circumstances of everyone else.  

To explain with an example, a Power BI expert A who works among centralized IT teams specializing in large-scale enterprise deployments will have a very different perspective from a Power BI expert B who typically works with finance teams or small businesses to create reports.  

• Expert A might assume that a certain level of IT control and structure is necessary for a Power BI project to succeed. They could favour tools like VS code, GitHub, and notebooks, and presume that any Power BI developer must know SQL to be successful. This expert focuses on performant and sustainable development, with practices like DataOps, and formalized processes, including automated testing and CI/CD. 

• Expert B might assume that business flexibility and agility are necessary for a Power BI project to succeed. They could favour Power BI Desktop, Excel, and SharePoint, and evangelize that teams can get value and success from Power BI without any deep technical knowledge or code. This expert focuses on well-designed solutions that prioritize business needs over technical details (within reason). 

While both of these individuals are Power BI experts, they have very different experiences, which have led to very different views and specializations. A mistake can be when Expert A assumes that their experience should reflect success for all Power BI projects, and that scenarios that Expert B is in are recipes for governance disasters and mistakes. Vice-versa, Expert B would make a mistake to presume that these more formal and structured processes are superfluous, and that Expert A “just doesn’t get it”. 

The reality of course is that there’s a wide spectrum of possibilities, and there just simply isn’t one “correct” perspective or pattern that applies to everything. Experts should avoid these mistakes by reminding themselves regularly that they are a by-product of their experiences, and actively seek to find and engage with new and different scenarios to broaden their own horizons and perspectives.  

Experts often know the “best” or “most optimal” technical approach to solve a problem, and can often implement this in a straightforward manner. Unfortunately, often, many of these “optimal” patterns and approaches can pile up to become cumbersome and… over-complicated. Not necessarily for the expert… but for everyone else. 

When you create a data model or report, you aren’t going to be the only person who has to use and manage it. Others will eventually have to fix or make changes to it, as well. The more complexity you build into that model or report, the more effort it will take someone (including your future self) to understand what you did and how it works. The time and effort cost can skyrocket… as well as the probability of mistakes!  

To avoid this, experts would do well to strike a balance between finding the most “technically optimal” approach and the “simplest” approach for their circumstances.  

• For models, this means that you might want to avoid calculation groups and convoluted DAX patterns in favor of more verbose and less elegant – but simpler – approaches.  

• For reports, this means that the beautiful custom visual that you spend hours (or days) toiling over for pixel perfection could be replaced with a simple bar chart that is less elegant, but easier for everyone to understand and maintain.   

Experts are often quite passionate about the tools they specialize in… we speak from experience, here! It’s exciting when new features and tools arise that enable new possibilities. For experts, change can be exciting, particularly when there’s a lot of buzz and hype for this change among their network and market, or – better yet – when that change addresses a long-standing issue or bug in the product. 

However, the excitement for these new features and tools can sometimes dominate the discussion, and the underlying problem or process the feature should address takes a back seat.  

Experts can sometimes rush to be a part of something new and exciting, even though it’s yet to be proven in the market, or when that excitement is artificially generated by marketing and commercial incentives. A consequence is that experts can sometimes let this excitement guide their decisions and guidance, opting for these features and tools because they’re new and not necessarily because they are effective or even appropriate for a client or organization. 

Experts should always remain critical and sceptical of new features and tools, framing them in the context of the “why”, and understanding how these features and tools will help us address new problems, or address old problems in a better way.  

Standing opposite the previous point, experts can sometimes become too critical, and their reaction to change isn’t excitement, but rather resistance or outright rejection. In this scenario, experts can sometimes feel threatened by drastic changes or departures from parts of the tool that they’re familiar with. 

Experts can sometimes be dismissive of these new tools, technologies, and approaches without considering the possible use-cases and benefits; why these new things have arisen. 

Again, we can return to the Copilot and Fabric Data Agents example. Skepticism of this nascent technology is certainly warranted, and an appropriate amount of measured risk mitigation is needed. That said, we shouldn’t dismiss these features outright. For instance, Copilot for Power BI can be very beneficial for intermediates and experts to generate DAX queries and measures, and in the right scenarios and circumstances, Fabric Data Agents can provide novel and innovative ways for people to engage with their data by using natural language. 

To avoid this mistake, experts must balance criticism and skepticism with open-mindedness. They should remain vigilant of the changes happening in the market, but also levy well-intentioned and constructive criticism, where appropriate.  

Experts have a propensity to resist change not just with tools and technology, but also with the solutions that they make. Especially with larger and more complex solutions, experts can push back against user change requests and feedback, favouring sustainable and stable solutions over irregular chaos that comes with business requests. 

While this stability is important, experts should ensure that their models and reports remain well-aligned to the current strategic objectives and priorities of the business. For this reason, experts should try to become more involved in business discussions and processes to better understand these objectives and priorities, and to help facilitate and assimilate data-driven decisions into these discussions.  

Experts (as well as beginners and intermediates) can dramatically increase the impact of their work by leaving their technical comfort zones and trying to build bridges with business teams. That way, they can better leverage their technical expertise with a more mature understanding of the business processes and problems users are trying to address. 

This is a short point – experts often like to build. Building is fun. Documentation is not building; documentation is not fun. So… it often just doesn’t get done. Creating good documentation takes significant time and effort, and it often involves not just written documents, but also diagrams, metadata, demonstrations, and even video content. 

When documentation and handover aren’t prioritized, experts can create a situation where the things they make become harder to maintain over time. This relates to mistake #2, where experts over-complicate solutions. However, without documentation, even simple and well-organized models and reports can quickly devolve into chaos. 

Experts can avoid this by ensuring that there is always ample time in a project for documentation and taking steps to ensure a successful handover from the start of a project. A good example of this can be regular (weekly or even daily) calls with support teams to give an overview of the project as it progresses. 

A side-effect of expertise is that it becomes harder and harder to see things from a beginner's perspective. Experts typically can forget what kinds of challenges that beginners face, and what their level of knowledge really is. This can make it difficult to teach and explain concepts; experts can easily overwhelm beginners with too much (technical) information. 

Ironically, this might be well reflected in an earlier article that we wrote about Mistakes that beginners make. We can postulate and remember the mistakes that we made as beginners, and we can look at the mistakes that we see beginners making. However, despite that mental effort, it’s still not a perfectly accurate depiction of the circumstances in which beginners find themselves, today.  

This is actually a common problem amongst technical content creators. The creators typically create content catering toward beginners, but in doing so, they make assumptions about who those beginners are and what challenges they face. With all their collective experience and knowledge, even Microsoft and the MVP community have an imperfect understanding and empathy for who beginners in Power BI are, right now, and what they might be struggling with. That’s why it is so important to engage with people outside of expert communities; everyday people who are just starting with Power BI, who don’t read blogs, attend conferences, or watch Power BI videos.  

The perspectives of these layman audiences are critical to understanding the challenges of someone to using Power BI for the first time. More importantly, this is how we can help and enable people to use data in the most effective and frictionless way possible. 

The following are other examples of mistakes that experts make, which we didn’t have time to talk about in this short article: 

• Not considering about atypical or “out-of-the-box” options to address certain problems, like R or Python visuals in a Power BI report. 

• Dogmatic thinking and practices, or dismissal of “simpler” tools like Excel that might still be the best choice for the scenario. 

• Fixating on technical details that, in the big picture, aren’t very important for getting business value. 

• Over-estimating deadlines and under-estimating business complexity and exceptions. 

• Trying to do everything themselves in a project, rather than working and delegating amongst a team.  

• Over-estimating the scope of their own expertise after they haven’t been challenged in some time. 

• Over-estimating how much other people know and care about Power BI or Fabric