When I was a business person myself and I was working with finance in Excel, I was told very impressive stories about modern BI and Power BI.  They were so captivating that I switched my career to Power BI, and finally saw the truth. But not everyone is into changing profession.

Still, as report creators we have many interactions with clueless business people acting as stakeholders, having critical impact on investment in BI architecture, as well as looks and functions of Power BI reports. We have to convince them that one architecture is better than the other, and that the easy fix will take two weeks to implement, while the difficult thing I will do in an hour.

I am not talking about your usual data visualization stuff, where we struggle to convince them to replace pie charts and tables with bar charts and bar charts. I am talking about a few Power BI exclusive things.

Based on my personal experience on both sides of the spectrum – from someone who has colleagues working with Power BI to someone who has colleagues who don’t work with Power BI, I have compiled a short list of what I would like all my stakeholders to know. And when I teach them these things, I do see a significant positive impact.

Why business people have to know those 3 things

Before providing you a list, I will explain why do business people even need to know anything about Power BI. By “business people” I mean those who are involved in negotiating requirements for reports – visual and functional – and those who are managing the time and resources for creation of those reports.

First reason – smooth direct communication.

Power BI semantic model used to be called “dataset”. You might remember the amount of confusion when you say “dataset” then everyone assumes they understand what are you talking about, but you know they’re not.

When your stakeholders understand at least basic concepts – then you have a common language, you can safely assume that when you say “measure”, “slicer” or “card” they will understand what you are talking about, and you will save time and effort on explaining those things.

I am learning about data engineering for the same reason – to be able to communicate with data engineers.

Second reason – smooth indirect communication.

Have you ever experienced the feeling when you get an image created in Figma or PowerPoint, and then they say – please create such report. There might be bars with rounded corners, expectations that you drill-through by double-clicking on a cell in a table, and that tables basically work like Excel.

“But these things are impossible or challenging to do” – you reply.

And then you have to embrace that challenge. Or – a better case – start over the process of designing. But Stakeholders will still be disappointed because Power BI couldn’t deliver on Figma’s promises.

Such things happen when people without simple knowledge of the tool start designing a solution. Every low code tool has great limitations, it is the price you’re paying for speed of development. Which means that your project manager or product owner must know the critical limitations your tool has, and negotiate them with stakeholders early. There is no way you can have real-time data in Power BI, you have to use Real-Time Intelligence for that.

Last reason – going from idea to prototype faster.

By simply acknowledging the limitations of Power BI, and finding workarounds early, you will have a feasible prototype faster. Feasible means you will be able to start implementing it right away, without having discussions like: “hey, I think this might not work”.

Now let’s see what are those three most important topics for stakeholders to know.

1. Semantic layer exists

“We have the data in the database, so just pull it and start creatin’ “.

Yeah, sure.

First you have to shape those tables so they work with star-schema. You might need to do some merges (joins), maybe add some keys, perhaps even aggregate them, create all necessary dimension tables…

If you are lucky – tables are star-schema ready in the database. “So, just start creatin’ “

No, you still have to make all relationships, hierarchies, custom sorting (so, April is not first), and the last little step – create all those DAX measures. After a week, the sprint is over and you still have zero charts to show.

Knowing that semantic layer exists, it needs to be in certain shape, it is the necessary foundation of the report, and it takes time to create – is essential.

It aids the plan – so everyone will know that time for this “invisible” work has to be assigned. It helps to manage expectations – everyone will know that they will not see new charts for a while. Likewise, it helps to schedule the data engineering work – maybe together you will find a way how to adjust tables in the database, so you don’t need to pull those heavy merges in PowerQuery.

Even more disturbing is that semantic model is the foundation for Microsoft Copilot to work properly with data. Without proper attention to them – all your data AI strategy is not going to work.

2. Don’t talk solutions, talk problems

“We have made such report in PowerPoint, can you recreate it in Power BI?”

No.

You are the expert of the tool, but you are also an expert of data visualization and interface design. And then you see proposed solutions like: “I want to have a filter for categories, so I can compare categories to each other”. No. You need a visual with a breakdown by category to do that. “I want this table so I can export it to Excel and then filter out cases where a certain KPI (key performance indicator) is below target. No. You need an already filtered table. Then you can export.

It is best when stakeholders come with their problems and rely on you how to solve those problems. The more high level, the more abstract are they – the better. You might find they don’t need that visual, that page, or even the whole dashboard, maybe an additional filter on another one will do. Sometimes a single one-time email with a number is enough.

If you have business domain knowledge, you might even tell them they need to calculate this indicator differently, or they don’t need to track this indicator at all, so they can shut down the database and save money.

So much time of re-discussing solutions can be saved! And also how much potential is there to do things more efficiently!

The sooner everyone starts talking problems, the better the solutions.

3. It is difficult to plan Power BI work, because you are the end of the funnel

There are cases when you commit to delivering a report during the next two weeks, and then you find out that a column which is promised is still missing. Of course, you can do most of your work with placeholder measures, but final delivery will be dependent on when the column gets available.

Or there can be times when there is really no work for you because data is not ready yet. Or there can be times when all the data is ready, and you need to deliver multiple reports at once.

Or the users after seeing the report in action change their minds and ask for complete overhaul.

Working with Power BI reports is surprisingly unpredictable because the report is often the final step of a data project, and this step is dependent on multiple steps that have to happen before that.

That is why planning Power BI work is a special case. Maybe the solution is to provide the report creator with some dummy data, so they can at least figure out the layout. Maybe it is better treating Power BI report as a separate project and plan it accordingly. This uncertainty has to be addressed in one way or another.

And finally, the feedback on the report has to be managed because it can disrupt the plans significantly. Let’s assume that you had initial steps done right, and you were talking to your user before and during the creation of the report. Even then, when more users are involved in the final testing, they might bring their brand-new opinions. It becomes critical to filter what changes are “must haves right now” and which ones are “nice to have eventually”. Without this, a Power BI report might grow from a two-weeks project to a month and beyond.

A good start

I believe these are the main 3 things business people have to understand about Power BI. Obviously, there are more, and feel free to expand the list in the comments, but this is already a good start.

If you don’t work with Power BI and reached this paragraph – congratulations, your developers will love you now! If you do work with Power BI – send it to your business colleagues, they might find it useful.