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 or discussing a non-technical (but still work-related) subject. Two years ago I wrote a post about people who ask the question “Why don’t you add this one simple feature to Power BI?”, something which seems even more relevant now than when I first wrote it. This year I want to discuss a similar topic: people who ask “Wouldn’t it be great if Power BI did this?”, where “this” is some amazing, complicated new piece of functionality they have thought of.
First of all, let me explain why “Wouldn’t it be great if Power BI did this?” is different from “Why don’t you add this one simple feature to Power BI?”. The “one simple feature” question is asked by people who come across the same problem in their day-to-day work so frequently that they can’t understand why Microsoft hasn’t addressed it yet – which is why they are often so frustrated and angry – and where the solution seems obvious and easy. Expanding/collapsing column headers, the top-voted idea on ideas.powerbi.com, is a great example of this type of question: lots of people want it, there are no arguments about how useful it would be, but as Amanda’s comment on the item says it’s actually a lot harder for us to implement than you would think. Hopefully we’ll be able to do it soon.
The “wouldn’t it be great” question is different because it is is prompted by long years of experience of BI tools and projects and is the result of some very creative thinking: the solutions suggested are never obvious, never going to appear on ideas.powerbi.com, and are much more strategic. In the past I’ve been very much the type of person to ask the “wouldn’t it be great” question. For example, about fifteen years ago I remember writing a long email to the Analysis Services team asking for something vaguely like DirectQuery on datasets; more recently I remember trying to convince Chris Finlan that it would be good if paginated reports could render to adaptive cards. Luckily for me the people I sent these emails to were always very polite, even if nothing ever came of my galaxy-brain proposals.
Why does someone like me love asking the “wouldn’t it be great” question so much? It’s the IT equivalent of fantasy football: if you spend way too much time thinking about your favourite football team/BI tool then it’s only natural to imagine how cool it would be to be the coach/program manager of that team/tool and make important decisions about its destiny. Maybe you think you could do a better job than the people who are actually in charge. It’s harmless fun and a great way to while away a few hours with friends over a beer at a conference.
It’s important to understand why the “wouldn’t it be great” question is not a good way of requesting changes to Power BI though. My colleagues Kasper de Jonge and Matthew Roche, both of whom have many years of experience as program managers, helped me with this when I first joined the Power BI CAT team. Now, when I think of a “wouldn’t it be great” idea, I hear Kasper’s voice in my head telling me that it’s the CAT team’s job to collect and curate feedback and it’s the program managers alone whose job it is to design the product. From Matthew I learned the word “solutionize”, which according to the definition I found here means “to come up with a solution for a problem that hasn’t been defined (and might not even exist)” where “common examples are things like developing a feature because you can, iterating and building without research, or selecting a platform or pattern before knowing the required functionality”. Asking the “wouldn’t it be great” question is suggesting a solution when actually the people who design the solutions need to hear the details of the problem you’re trying to solve. If you provide enough details of the problem then it’s possible that the program manager will come to the same conclusion as you about the solution, but even then there are so many other factors to take into account (such as whether it’s even possible to implement your solution) that nothing can be guaranteed.
So, in summary, if you have a problem that you think Power BI needs to solve then you should spend as much time as possible defining that problem rather than imagining what the solution could be – that’s the best way to ensure it gets the attention it deserves from Microsoft. To be clear I’m not saying that you shouldn’t suggest a solution too, I’m just saying that solutions are not what you should be focusing on.
Great post Chris and thanks for the great work you have been doing with this blog for so long.
I took a course this year on “Data Questions” for creating dashboards, where this very thing was also addressed. It is very important to keep the request in the “Problem Space” and understand the real problem than in the “Solution Space” and just implement a preconceived solution.
By the way I would love to know what type of challanges the PBI team is facing when trying implement the column expand feature and how they they solve it. Even on high level 😉
Ok here’s a problem that I would see solutionized: Closing the loop in the user experience by allowing data write back both into the data source and into the currently loaded dataset. Not sure if this falls under the “why don’t you” or the “wouldn’t it be nice” category.
Thanks for the awesome blog posts over the years which I have used on multiple occasions.
What I would like is an easy way to refresh historical/older partitions/data on datasets. Right now the challenge is that for business users there is no quick and easy way to refresh older data. To achieve refreshing older data requires using SSMS, Tabular Editor or the RESTAPIs. This is great for the more technically minded. But even then there are still challenges such as how is the data actually partitioned for the dates that need to be refreshed (is it a year or month or day partition? I have managed to do this using Power Automate and the RESTAPIs)
It would be great to firstly have it where a user could put in the dates that they want the older data to be refreshed. Then the PBI service would then analyze the dataset and partitions and automatically determine which partitions need to be refreshed. Once the refresh has completed successfully to then email the user letting them know it is successfully or unsuccessful.
Sometimes the “wouldn’t it be great” ideas are directly opposed to the monetization of the product. And sometimes they appear to be backwards-looking (although hopefully seasoned PG developers will know that software technologies are cyclical – something that looks new may be simply the re-vitalization of something else that is very old):
Here are some ideas. The problems that these solve are fairly self-evident.
– Open-source the tabular engine, or at least make it a reusable .Net API that we could embed *locally* in our own custom applications (similar to how the engine is used in PBI desktop, and Excel power pivot, and in SSDT for VS).
– Source control everywhere. Ie. source control for models, PQ, reports (RDL), etc. Everything needs to be “source-controllable” without requiring us to build our own custom tooling to crack open json dataflows, and pbix’es.
– Bring some of the PBI tooling back into VS, where the enterprise data developers already spend most of their time (ie. where we do SSDT, bim models, spark etl’s, etc).
– Better parity between dataflows and datasets (insofar as REST api, personal-gateway connectivity, parameters, etc)
– MDX scripts for tabular models. I believe this was actually possible at ones point in the past (see prologica blog: “DAX Editor Adds Support for Tabular Default Members”)
(This would be a huge help to business users who continue to rely heavily on pivot tables in Excel, and would like to seamlessly push their MDX calcs back into the underlying cube itself – for the benefit of their colleagues.)
– Better parity between bim’s and pbix models. Now that Microsoft is encouraging the migration of models from AAS, we should be able to use all the “structured sources” in the bim’s that we deploy to PBI (eg. web connectors, and custom connectors).
@Chris
“Expanding/collapsing column headers”….”it’s actually a lot harder for us to implement than you would think”
There are actually two people who managed to do this
a) Excel Pivot table Team.
b) Inforiver custom visual.
Then there is always the “oh but..we are so constrained on resources….its definitely there on our backlog…however the Teal them had to take priority”
Cheers
Sam
I always make ‘Print Screen’-copy of the Data Model to a separate Page with notes.
I wish there was a Visualization that would just access the Data Model page and show the exact layout of that page, and Optionally show All DAX formulas (Measures, Calculated columns). If Documentation is easy, it will be done.