Every year, on the anniversary of the first-ever post on this blog, I write a post reflecting on what has happened to me professionally in the past year. While I’m not sure anyone really wants to look back on the events of 2020 there is a topic I’ve been intending to write about for some time that I think has some interesting parallels with the bigger challenges of this year – although I’ll keep my focus on Power BI and let you draw your own conclusions about the rest.

As you may know, I work on the Power BI Customer Advisory Team at Microsoft and a large part of my job involves collecting requirements from the large customers I support. I’m also closely involved with the Power BI community through social media, user groups and my old connections from the MVP programme, and as a result I spend a lot of time talking about the Power BI roadmap and the features we’re working on. One question I get asked all the time is this:

Why don’t you add [insert feature idea here] to Power BI?

It’s sometimes followed up by one or more of the following comments:

It would be so easy for you to do
I can’t believe you haven’t done it already
Power BI is unusable without it
[insert competitor name here] has had this feature for years

…and a real or virtual exasperated sigh.

In many cases I’m able to tell the person asking the question that we are in fact planning to add that particular feature; sometimes I get to tell them that the feature already exists in the product. The rest of the time I make sure I understand the request properly, tell the questioner that we take feedback very seriously (which we do) and then make a note of it so it can be discussed with the relevant program managers. You could say I’m a kind of human https://ideas.powerbi.com/

Why, though, are there so many features missing from Power BI that would be easy to implement/make the product unusable through their absence/are so obvious that all our competitors have them? The short answer is of course that “it’s complicated” but let me try to give you a better explanation based on my own experiences.

You may also know that up until eighteen months ago I worked as an independent consultant and trainer specialising in Power BI and Analysis Services for thirteen years; even before that had I worked with Analysis Services for several years in a variety of jobs. In my pre-Microsoft career I worked on hundreds of Power BI and Analysis Services projects from all over the world and I thought I had seen it all. I was wrong.

Although the job I do on the CAT team today is not so different from my previous job, the customers are much larger and their concerns are very different. Before, I rarely encountered customers who used Power BI Premium; now I work with them all the time. Before, I used to wonder who used features like Bring Your Own Key; now I know why it was so important for us to build it. The point is, of course, that with a product that has as many customers and users as Power BI it’s impossible for any one person’s experiences to be representative of everyone’s. It’s like the parable of the blind men and the elephant.

On the whole I think that on the Power BI team we do a good job of balancing the priorities of all of our different customers but with finite resources we can never make everyone happy. There are so many different “one simple features” that I’m asked about – each of them valid and useful – that it would be impossible to get them all done.

What’s more there are plenty of ‘easy’ features that we’d love to implement but which turn out to be much harder to deliver than you’d think, or which only make sense after something else more complicated has been done, or which have cost or security implications on our side that aren’t immediately obvious. Then there’s all the other work that needs to be done to keep the Power BI Service running, able to handle the ever-increasing load on it, and the work we need to do to interface with other Microsoft products for the benefit of the wider Azure platform. There are many other competing demands on the developers’ time.

So, to go back to where I started, it’s complicated. Simple problems like feature prioritisation aren’t always as simple as they first seem (see also this post by my colleague Matthew Roche). I don’t make decisions about which features do get built in Power BI although I am involved in the discussions; I know it’s a cliché to say this but the people I work with who do make these decisions are some of the smartest that I know and they do a better job of it than I ever could. Mistakes are made sometimes of course; I suppose the only way to establish whether the number of good decisions outweighs the number of bad ones is the success or otherwise of Power BI in the marketplace.

One last thing to say: I don’t want you to get the impression that I get irritated or angry when I’m asked the “Why don’t you add this one simple feature?” question. In fact I love being asked it: it shows how passionate our customers are, it stops us being complacent, and this feedback really does all get stored, crunched, analysed (in Power BI) and used to make a better product. Please do keep asking! I only wanted to explain why you don’t always get the answer I’d like to give you when you do ask it.

While the long-awaited small multiples feature that previewed in the December 2020 release is an obvious boost to Power BI’s data visualisation capabilities, did you know that you can use it to improve report performance too?

Earlier this year I wrote blog posts showing how you can improve report performance by showing the same amount of data in fewer visuals (for example by replacing several cards with a single table) and how the number of visuals on a page affects report performance even if they aren’t displaying any data; several other people have written similar posts too. Small multiples are just another way you can replace several visuals with a single visual that displays the same data.

To illustrate, consider the following report with five separate line chart visuals on it that are identical apart from the fact that there is a different filter set on each one:

Here’s what Performance Analyzer shows when the page is refreshed:

In this case everything is fairly quick, but notice that each DAX query takes 10-12ms and by the time we have reached the “Count Of Sales by Date for Terraced” visual the total render duration has reached 710ms.

Now, here’s the same data in a single line chart visual using small multiples:

It’s the same data and the same charts, but look at what Performance Analyzer shows now:

There are two things to point out:

1. There is only one DAX query which, at 12ms, performs about the same as each of the five DAX queries in the previous version of the report. In this case by requesting all the data in a single query, rather than five separate queries, Power BI has been able to optimise how it retieves the data it needs. This doesn’t mean that from a DAX point of view that the small multiples version of the report is five times faster than the original because Power BI will have run the five queries in parallel in that version, but in general you will see some improvement in overall performance from this consolidation of queries and in some cases this can be quite significant.
2. While the sum of the visual display durations for each of the separate visuals is basically the same as the visual display duration for the small multiples visual – which makes sense because they display the same data in the same way – the total duration of the small multiples visual is 486ms compared to 710ms for the total duration of the Count Of Sales by Date for Terraced visual in the original version, so there has been a definite overall improvement in rendering time. In fact, Performance Analyzer doesn’t really give you an accurate way of measuring the overall time taken to render a report page. A much better technique is the one I blogged about here, and this suggests the overall performance saving from using small multiples is almost 500ms.

In conclusion, then, if you have any groups of visuals on your reports that can be replaced by a single small multiples visual then I recommend that you do so – you may see an improvement in performance as a result. Remember also that it’s still early days for small multiples: as more and more features are added to it, and as more and more visuals support small multiples, the more opportunity you will have to consolidate visuals.