Building Data Products — Principles, Anatomy, and Best Practices

"Data product" is the most overused term in modern data, and the most misunderstood. A data product is not a table, a dashboard, or a pipeline. It is a self-contained, owned, governed unit of data that is managed like a product — with a name, an owner, consumers, a contract, and a service level. The shift is from data as a byproduct of applications to data as a product built for the people who consume it.

The six properties of a good data product

A useful data product is, by design:

Property	What it means
Discoverable	Listed in a catalog, described in business terms, findable by search
Addressable	A stable, unique address consumers can reference and depend on
Trustworthy	Backed by quality guarantees and SLAs — freshness, completeness, accuracy
Self-describing	Ships its own schema, semantics, and documentation; no tribal knowledge required
Interoperable	Uses shared identifiers and standards so it joins cleanly to other products
Secure by default	Access governed by policy; PII/PII classification and masking built in

If a dataset is missing any of these, it is a table someone published, not a data product. The properties are the difference between reuse and re-derivation.

The anatomy of a data product

Concretely, a data product bundles more than data:

• Output ports — the interfaces consumers use (SQL/table, API, stream, file export), ideally served zero-copy so there is one source, not many divergent extracts.
• A data contract — the schema, semantics, quality, and SLA guarantees, versioned and enforced (covered in its own article).
• Metadata — business definitions, ownership, lineage, classification, and cost.
• Governance — access policies, PII masking, and audit, enforced at the port.
• Observability — freshness, volume, and quality signals the owner monitors.

# A data product is described, not just deployed
data_product:
  name: customer_360
  domain: customer
  owner: customer-data-team          # a named, accountable team
  version: 2.1.0
  output_ports:
    - type: sql        # zero-copy view, governed by row/column policy
      address: gold.customer_360
    - type: api
      address: https://api/data/customer_360/v2
  classification: [pii]
  sla: { freshness: 5m, availability: 99.9% }
  contract: contracts/customer_360@2.1.0

Best practices

• Domain ownership, not a central team. The domain that knows the data owns the product end to end. Central platform provides the paved road; domains provide the products — the federated, domain-driven model.
• Semantics first. Define what a field means — ideally against a shared ontology — before you publish it. Meaning is the product; storage is an implementation detail.
• Contract before consumers. Publish the data contract first, so consumers depend on an interface, not your physical tables.
• Zero-copy by default. Serve from one governed source; replicate only where latency or workload demands it. Copies are where trust goes to die.
• Build on the golden record. A customer data product is only as good as the MDM match & merge beneath it.
• Governance at the port, not in application code. Row/column policy, masking, and audit enforced where the data is served.

The path to implement

1. Pick a high-demand domain and name a product with a named owner.
2. Define its semantics and contract before exposing any data.
3. Expose governed output ports (SQL/API/stream), served zero-copy.
4. Attach quality SLAs and observability the owner is accountable for.
5. Publish it to a catalog / marketplace so it is discoverable and reusable.

Incipient's Data Product Factory templates governed products — build once, reuse everywhere — and the Data Marketplace makes them discoverable. The marketplace article covers how producers and consumers meet.

Talk to us about data products →