top of page

Power BI as a Platform: More Airbnb Than Plumbing?

I like to think about good Power BI adoption more like Airbnb than plumbing. A logical comparison, I think you'll agree? But go with me on this, because there's a genuinely undervalued concept hiding inside most organisations' reporting environments, and it's unlocked with a change in mindset rather than more Power BI as a Platform: More Airbnb Than PlumbingCapEx funding.

A lot of businesses treat their analytics like a utility. Data flows in one direction: a dedicated team builds reports, everyone else consumes them, and when it's working well the whole thing should feel invisible, just like plumbing. Water comes out of the tap, you don't think about how it got there.

But I think there's significantly more value to be had, and the model for it is sitting on everyone's phone.


Power BI the platform, as a platform

On Airbnb, hosts easily become guests and guests become hosts. The same person creates value and consumes it, and the lines between the two sides blur. In platform economics, this is called a two-sided platform, and it's a business model that more and more companies are adopting.

The great thing about two-sided platforms is that they multiply the already exponential impact of network effects. Network effects means the product becomes more valuable as more people participate.

There's a book, Platform Revolution, that I read a few years ago as part of a course and loved how they contrasted traditional "pipeline" businesses, where value flows one way, with platform businesses where it circulates.

Pipelines push.

Platforms let value flow back and forth.

This really resonated with me because when I read it I had recently finished leading a large Power BI rollout, and was at the time working with a client on them building a reusable data platform operating model. In both initiatives the value to the organisation to be gained was through network effects.

What struck me about this business model was that Power BI environments can work the same way. The people building reports can also consume reports from other teams. Sales could be using marketing's campaign performance data. Finance could be pulling operations' cost data instead of requesting a manual extract every month. Suddenly the work one team invested in becomes useful to people who maybe never even knew it existed.

That's network effects playing out inside a business, and the value multiplies every time a second team picks up what the first team built.


The problem with most BI environments

Most data I see in organisations sits in one team's folder, or report, and never leaves, or is locked up in a data warehouse (and when non-technical teams want access it suddenly starts to resemble Alcatraz!). Teams aren't hoarding data out of malice, they just usually don't know what other teams have built, there's no easy way to find it. Even if they could find it, they wouldn't know whether to trust it! So they build their own version from scratch. It often is the case that the same prep, cleaning, presentation and analysis  gets recreated three or even four times across the business, and nobody realises.

There's a concept called "data liquidity" from research in MIT Sloan Management Review that describes how easily data assets can be reused and recombined to create new value. The finding was that while data is inherently reusable, the organisation has to deliberately activate that characteristic. It doesn't happen on its own. Shapiro and Varian made a related point in Information Rules: information is costly to produce but cheap to reproduce. Building a good analysis can be expensive, but when you start sharing it the ROI increases, and sharing internally is cheap when the operating model and infrastructure already exists to support it. But, what I see is actually most organisations just keep paying for the same work to happen over and over.


Compounding, not just sharing

A less academic reference, but just as valid!, James Clear of Atomic Habits fame, built his whole ethos on the idea that small improvements compound over time. Get 1% better each day and you end up thirty-seven times better in a year. The same logic applies to data environments, but only if the conditions are right. Each dashboard or underlying model that gets shared, each metric that gets documented, each dataset that gets certified and made discoverable adds a small amount of value on its own. But the compounding impact turns those small contributions into something really powerful, and the value is open-ended and uncapped.

The organisations I've worked with that get this right don't just have better dashboards. They make faster decisions because they're not waiting for someone to rebuild what already exists, they spot patterns across functions because teams are actually looking at each other's data, and they get compounding returns on every hour of analytical work because that work gets reused instead of sitting in a folder gathering dust.


So what does this actually require?

The shift from plumbing to platform isn't a technology change, to be successful it needs to be a design and culture change. It means thinking about:

  • Discoverability (can people find what's been built?)

  • Trust (do they believe it's accurate?)

  • Governance (who owns it and what happens when something breaks?)

  • Incentives (why would a team bother making their work reusable by others?)

None of that is a simple overnight change, but it is all possible, and the starting question is worth asking: is your Power BI environment designed so that value flows one way, or both?


If that's a question you're wrestling with, it's exactly the kind of conversation I love having.


References

  • Parker, G., Van Alstyne, M., and Choudary, S.P., Platform Revolution (2016)

  • Wixom, B.H., Piccoli, G., and Rodriguez, J., "Fast-Track Data Monetization With Strategic Data Assets," MIT Sloan Management Review (2021)

  • Shapiro, C. and Varian, H.R., Information Rules: A Strategic Guide to the Network Economy (1999)

  • Clear, J., Atomic Habits (2018)

bottom of page