Data as a product
By the end of this module you will be able to:
- Explain Dehghani's data mesh principles
- Describe data contracts and their purpose
- Evaluate when data-as-product thinking applies
Data product as producer, contract, and consumer triple
A data product is a producer, a consumer, and a binding contract that names schema, freshness, and SLOs.
A data product is a producer, a consumer, and a binding contract between them. The contract names schema, freshness, quality SLOs, and support. Without the contract, the data is a dump; with it, the data is a product. Bitol ODCS v3.1.0 is the published shape; data mesh frames the same model architecturally.
Three SLOs every data product must carry
A data product binds three SLOs: freshness, quality pass rate, and availability latency.
A data product binds three SLOs: freshness (data is no older than X), quality (pass rate is at least Y percent), availability (read latency is under Z). Bitol ODCS v3.1.0 carries all three machine-readably; Google SRE Workbook defines the SLO discipline they implement.
Contract change as a four-step migration with overlap
Contract changes follow a four-step migration with an overlap window before retiring the old version.
Contract changes follow a four-step migration: propose with notice window, deprecate old version, serve both during overlap, retire old after every consumer migrates. Bitol ODCS v3.1.0 codifies this sequence; breaking changes without the overlap window are how producer-consumer trust collapses.
Real-world architecture · 2019
Zhamak Dehghani asked: what if data teams operated like product teams?
In 2019 and 2020, Zhamak Dehghani set out data mesh as a sociotechnical pattern for scaling analytical data. The core argument was that centralised data platforms create bottlenecks because one team cannot understand every domain's data, context, and change cadence.
Data mesh is a pattern and operating lens, not a universal target architecture. It asks domain teams to own data products with documentation, quality expectations, versioning, and consumer feedback loops. The previous module covered how to structure data. This module covers how to treat it as a product without turning every dataset into a product theatre exercise.
Centralised data teams become bottlenecks at scale. What if the teams that produce data also owned it as a product, with SLAs, documentation, and quality guarantees?
Treating data as a product means applying product management principles: who are the consumers? What do they need? How do we measure satisfaction? This shift changes data teams from cost centres (infrastructure providers) to value creators (product owners delivering reliable, documented, discoverable data).
Data mesh is useful only when its four principles are treated as operating commitments.
19.1 The four principles of data mesh
Dehghani's data mesh framing has four principles. Each is an operating commitment, not a label to add to a slide:
- Domain-oriented ownership: the team closest to the business process owns the analytical data it produces. Ownership includes meaning, quality, change control, and consumer support.
- Data as a product: domain teams treat data outputs as products with consumers. A product has documentation, quality service levels, versioning, discoverability, and a route for feedback.
- Self-serve data platform: a shared platform gives domain teams safe tooling for storage, pipelines, cataloguing, access control, observability, and deployment without each team rebuilding infrastructure.
- Federated computational governance: global policies are defined centrally but enforced through code, tests, contracts, and platform controls.
The leadership test is whether accountability changed. If central data teams still fix every issue while domain teams only attend workshops, the organisation has adopted mesh vocabulary but not the operating model.
“Domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance”
Zhamak Dehghani, Martin Fowler site - Data Mesh Principles and Logical Architecture
This is the clearest source-backed statement of the four mesh principles. The course treats them as a pattern to evaluate, not as a default destination for every organisation.
Common misconception
“Data mesh means every team builds its own data infrastructure.”
Data mesh separates domain ownership (who is responsible for the data) from platform infrastructure (the shared technology layer). The self-serve platform principle explicitly provides shared compute, storage, and tooling. Domain teams own the content and quality; the platform team owns the infrastructure. Duplicating infrastructure across teams is the opposite of data mesh.
Product thinking becomes operational when the product promise is written as a contract.
19.2 Data contracts in practice
A data contract is the interface between a data product and its consumers. Module 13 introduced contracts conceptually. In the data-as-product context, the contract is the product specification: it defines what consumers receive and what guarantees the producer makes.
The Open Data Contract Standard provides a practical shape for this promise: fundamentals, schema, references, data quality, support, pricing, team, roles, service level, infrastructure, and custom fields. Not every organisation needs every field, but every critical data product needs enough structure to make expectations testable.
Worked example: a revenue data product should define what counts as revenue, which refunds or credits are excluded, the currency and rounding rules, how late-arriving orders are handled, the freshness target, the owner, and the breaking-change process. Without those details, different teams can all be "using revenue" while making incompatible decisions.
“Keys and values expected in a YAML data contract”
Open Data Contract Standard v3.1.0 - Executive Summary
The ODCS structure turns the promise of a data product into fields that can be reviewed, versioned, tested, and enforced.
Common misconception
“Data mesh only works for large organisations with hundreds of engineers.”
The principles scale down. A team of 20 can apply domain ownership (the marketing analyst owns marketing data), data-as-product thinking (documented, quality-checked datasets), and shared infrastructure (a single cloud warehouse with access controls). You do not need a platform team of 50 to benefit from treating data as a product.
A company's centralised data platform team is a bottleneck: domain teams wait weeks for data to be ingested and transformed. Which data mesh principle most directly addresses this?
A data product has a freshness SLA of 60 minutes. Data has not been updated for 3 hours. What should happen?
A startup with 15 employees wants to adopt data mesh. A consultant says they need a dedicated platform team, domain data teams, and a governance council. Is this advice correct?
Product checks to carry forward
- Data mesh is a sociotechnical pattern, not a universal architecture. Use it when domain ownership and platform support solve a real scaling problem.
- A data product must have consumers, an owner, documented meaning, quality expectations, service levels, versioning, and a support route.
- A data contract is the verifiable layer of the product promise. It should make schema, semantics, freshness, quality, ownership, and change policy explicit.
- Small teams can apply product thinking without creating mesh bureaucracy. The useful test is whether accountability and consumer trust improve.
Standards and sources cited in this module
Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale
Chapters 3-6
Foundational text defining the data mesh operating model.
Open Data Contract Standard v3.1.0
Definition and schema sections
Open YAML standard for defining schema, quality, role, service-level, support, and infrastructure fields in data contracts.
Full article
Original article introducing data mesh. The opening case study references this publication.
Dehghani, Z. (2020). 'Data Mesh Principles and Logical Architecture'
Core principles
Source-backed statement of the four data mesh principles used in Section 19.1.
Data Governance knowledge area
Governance principles that data mesh extends with computational enforcement.
Module 19 of 26 · Applied Data