Stage 1
Define: what makes it a product
A dataset becomes a data product when someone owns it, someone else depends on it, and the terms between them are written down. Everything below follows from those three facts.
| Dimension | Data project | Data product |
|---|---|---|
| Funding | One budget line, closed at delivery | Sustained run cost with a named cost centre |
| Success measure | Shipped on time and on budget | Consumers active, decisions changed |
| Ownership after launch | The team disperses | A named owner carries the pager |
| Interface | A report, a file drop, a dashboard link | A versioned contract: schema, semantics, SLOs |
| Change handling | Schema changes surprise consumers | Semantic versioning with a deprecation window |
| End state | Quietly abandoned, still running | Deliberately retired against a usage threshold |
DATSIS, and the evidence for each
The six usability characteristics that came out of data mesh practice are easy to agree with and hard to prove. Score your product honestly — the bars below are your answers, nothing else.
Your DATSIS profile
Weakest characteristic first — that is your next piece of work.
Set the toggles to see where you stand.
Stage 2
Build: six stages and the artifact each one owes
A stage is not finished when the work feels done. It is finished when it hands the next stage something concrete.
Who decides what
Skill radars flatter everyone and settle nothing. The question that actually causes arguments is who holds the pen at each stage.
| Stage | Data product manager | Data engineer | Analytics / ML | Domain owner | Governance |
|---|
D decides · B builds · R reviews · I informed
Stage 3
Evaluate: signal on one axis, utility on the other
These two failures look identical in a status report and need opposite responses. A model that beats its baseline but changes no decision is not a smaller version of a model that changes decisions badly — it is a different problem.
Signal validity
Answer for the product as it stands today, not as you hope it will be.
User utility
Utility is a property of the decision, not of the dashboard.
Answer both columns
The marker sits at the origin until you tick something. It moves only in response to your own answers.
Stage 4
Validate: the contract, the tests, the monitors
Validation is three separate jobs at three separate times, and skipping the first makes the other two guesswork.
At design time
Write the contract before the pipeline. The Open Data Contract Standard (ODCS v3.1.0, stewarded by Bitol under the Linux Foundation AI & Data) gives you a YAML structure covering schema, semantics, quality rules, SLAs, roles and support — so the agreement is machine-checkable rather than a wiki page.
At build time
Unit-test transformation logic, run contract tests in CI, and fail the merge on a breaking schema change. A pipeline that runs green while emitting wrong numbers is the default failure mode, not an edge case.
At run time
Monitor freshness, volume, distribution drift and null rates against the thresholds the contract already declared. Alert the owner, then tell affected consumers through lineage — not through a support ticket they open first.
The six quality dimensions, and which ones bite
| Dimension | Question it answers | How hard to automate |
|---|---|---|
| Completeness | Are required values present? | Mechanical — null and coverage checks |
| Uniqueness | Is each entity represented once? | Mechanical — key and duplicate checks |
| Validity | Do values conform to the declared type and domain? | Mechanical — schema and range checks |
| Timeliness | Did the data arrive inside the SLO window? | Mechanical — freshness monitors |
| Accuracy | Do values match the real world? | Hard — needs an external reference or audit |
| Consistency | Do systems agree with each other over time? | Hard — needs cross-system reconciliation |
Teams that report high data quality are usually measuring only the first four. The two that damage trust are the two that cannot be checked inside a single pipeline.
Launch readiness
Twelve things that are cheap before launch and expensive after it.
Stage 5
Retire: the stage nobody plans
Warehouses fill with products that nobody uses and nobody dares delete, because no one wrote down what "unused" means. Decide the threshold while the product is still popular.
Define the trigger
For example: fewer than three distinct consumers for two consecutive quarters, or a successor product covering the same contract. Put the numbers in the contract at design time.
Give notice through lineage
Lineage tells you who is downstream. Notify them directly, with the end date and the migration path, not via a catalog banner nobody reads.
Remove it fully
Drop the schedule, archive the data under its retention policy, close the catalog entry, and release the cost line. A half-retired product is worse than a live one — it still runs and nobody owns it.
Where teams lose the plot
- Renaming existing tables "data products" without adding an owner or a contract.
- Writing the contract after launch, from whatever the pipeline happens to emit.
- Treating pipeline success rate as the quality metric consumers care about.
- Building because the data exists, rather than because a decision is waiting.
- Measuring adoption in dashboard views instead of decisions changed.
- Shipping a breaking schema change with a Slack message as the deprecation policy.