Notes from the Power BI Gebruikersdagen 2026
At the Power BI Gebruikersdagen 2026 I attended several sessions on modelling, governance, AI and the evolution of the Power BI platform. As with most events like this, the most interesting insights were not only in the big announcements, but in the presentations and conversations that show how organisations actually organise their data. This page is about data products and data contracts.
From datasets to data products
A term that came up in several sessions was data product — not as a marketing term, but as a way of looking at datasets and data platforms differently. Traditionally, data was seen as an intermediate step: collected, processed and ultimately used for reports, with the dataset itself rarely an explicit part of the design.
A data product approach changes that. The dataset itself becomes a product that is deliberately designed, managed and maintained. It gets a clear owner, a purpose and defined expectations around its use.
What a data product can be
Many people immediately think of a dataset or semantic model when they hear data product, but in practice a data product can take many forms, such as:
- a semantic model in Power BI
- a dataset used by multiple reports
- a dashboard that answers a specific information need
- a data pipeline that makes data available
- a bronze layer in a lakehouse
- a standardised table used by multiple teams
All of these deliver value to users — that is precisely why they can be seen as data products, and it helps to treat them as such.
Why data products are useful
When data is treated only as a technical artefact, problems tend to follow:
- multiple definitions of the same metric
- datasets with no clear owner
- pipelines that keep running while nobody uses them anymore
- dashboards where nobody knows where the numbers come from
Treating data as a product leads to different questions:
- who is the owner
- who uses this
- which definitions apply
- how often is the data refreshed
- what happens when something changes
These questions make data more reliable for the organisation.
The role of data contracts
An important concept within data products is the data contract: a description of what users of a dataset or data pipeline can expect, formalising agreements between the party that delivers data and the party that uses it. A data contract might describe:
- which tables or fields are available
- what the meaning of columns is
- how often data is refreshed
- what quality expectations apply
- what happens when a schema changes
The goal is predictability: users know what they can rely on, and developers know what impact their changes have.
How to shape data contracts
A data contract does not need to be a complex document. It often starts with simple metadata, such as:
- a description of the dataset
- definitions of important fields
- an owner or point of contact
- a refresh frequency
- a list of known limitations
Modern data platforms increasingly support this through tooling — dataset documentation, data catalogues, lineage information and metadata in semantic models. But the most important step remains someone taking responsibility for capturing this information in the first place.
Data products within Power BI and Fabric
Within the Microsoft ecosystem the concept of data products is becoming increasingly visible. Semantic models are shared across reports, datasets get endorsement labels, lineage shows how data flows through the platform, and Fabric lakehouses and pipelines make it easier to build clear, structured layers. All of these developments support the same idea: data is not just a stepping stone to a report, but a product that needs to be designed and maintained.
Reflection
One of the useful observations from the Gebruikersdagen was that data products are not only relevant for large organisations. Even small teams end up with datasets used by multiple reports, or pipelines that feed multiple analyses. At that point it already makes sense to think about ownership, definitions and expectations around use — not because it is required, but because it prevents a lot of confusion later.
How I approach this in the engagements I take on is described on the page about how I work. The approach varies by team and context, but the questions are always the same.
Data products start with clear governance: the related article on data governance explains that foundation. The rest of the series is on the overview page.