Business domain owned · structured interfaces · standardized quality
A data product is a labelled rack, not an unsorted bin.
- On the floor — not a unsorted bin (No label, no count, no owner), but a labelled rack (Part number, count, bay).
- In the system — not a spreadsheet export (Someone's copy, some day), but a data product (Owner, contract, interface).
From Excel to data product
Six steps to get started
Nothing here requires a lengthy IT project to get started. What matters most is the sequence. You can try it actually in Excel.
- 01
Pick the business
domainStart where the data is created, not where it's consumed. The domain that generates it is the only one that knows what it means when it looks wrong.
In ExcelDescribe the context of the Excel file and why it exists in 2-3 sentences - 02
Name the
ownerOwnership must be tied to an individual. You likely do not yet have this clarified. The easiest path is to nominate one person from the responsible department.
In ExcelAsk who created and maintains the Excel file. Add a tab with owner info - 03
Define the
interfaceWhat information from the Excel is consumed by whom. Think of this step like stakeholder management for projects.
In ExcelDescribe who needs which information in what format from your Excel file - 04
Set the
promiseEach of your stakeholders has expectations when to receive which data in which format. Data products standardize this in terms like completeness, freshness, accuracy, etc.
In ExcelList expectations of people using your Excel file data. For example, how frequent is which data asked for - 05
Publish the
dataEvery dataset is either saved locally, stored somewhere centrally and distributed via varying systems. Data products standardize discoverability, addressability and documentation.
In ExcelDescribe how your Excel file is stored and distributed. For example, local and via email or on Sharepoint. - 06
Operate and
manage changeEvery file should have a change history. But consumers rarely notice changes unless you tell them. Data products standardize how changes are monitored and communicated.
In ExcelWhen was the last time you checked who last edited your Excel file? It's usually an email or conversation telling you.
Six properties, or it's just a dataset
These are not aspirations. Each one is a test a consumer can run before they use the data — and a dataset that fails any of them is a file someone will eventually email you about.
Discoverable, addressable, trustworthy, self-describing, interoperable, secure — the DATSIS properties from data mesh practice.
Discoverable
A consumer can find it without knowing who to ask. If the route to your data is a person's memory, the product has a single point of failure and it is a human being.
Addressable
It has a permanent address that does not change when the team reorganises or the storage moves. A path that breaks on reorg was never an interface.
Trustworthy
It publishes what it promises — completeness, freshness, accuracy — as numbers, not adjectives. "Usually good" is not a service level.
Self-describing
Schema, semantics and lineage travel with it. A consumer should not need a meeting to learn what a column means.
Interoperable
It uses the identifiers everyone else uses. A part number that only makes sense inside one plant's system is a translation problem you have handed downstream.
Secure
Access is governed at the product, by policy, and it is auditable. Security applied after publication is a permission list someone forgot to update.
The model
Code, data, infrastructure — one deployable unit
Code
Transformations, the API that serves it, and the policy checks that run on every publish.
Data & metadata
The data itself plus what it means — schema, lineage and quality metrics.
Infrastructure
Storage, build, deploy and access from a self-serve platform.
The architectural quantum, data mesh's term for this, is defined as the smallest unit of architecture that can be independently deployed with high functional cohesion — Zhamak Dehghani.
We know where this breaks
Every failure mode on this page is organisational, not technical — a team named as the owner, a platform built before the first product, a promise that outlives the person who made it. None of them are fixed by a tool, so we do not start with one.
Get in touch
Failure patterns we look for first
01 — Owned by a team is owned by nobody
One name, or the promise decays quietly.
owner: "Operations" ← nobody owner: "M. Chen, maintenance lead"
02 — Platform built before the first product
The foundation gets designed for needs nobody has stated.
build platform → find use case ← stalls ship product 1 → generalise ← compounds
03 — Ownership drifts
Business domain ownership that holds across when scaled.
Q1: owner named, service level met Q3: owner moved on, service level still advertised
Your first data product already exists — downtime events, quality records, changeover times. It is not a product yet because nobody owns it, it has no published shape, and it makes no promise.