A report is not a data product

On a recent call, the transformation officer at a family-owned food group with twelve regional businesses put the distinction flatly:

"Whereas I'm like, data is a product. Report is not a product. Report is just whoever, whatever, you use it yourself. I don't care."

He was naming the ceiling of a centrally controlled BI team. The ceiling is the unit of work: a report answers one consumer's question at one moment. A food group with twelve regional businesses cannot run on one answer at a time.

Each regional team asks its own question, and each team's agent needs the same definitions underneath it. Your data engineering agent needs the meaning below the answer. A report is one answer; the meaning underneath it is the product.

A report answers one consumer; a data product is the meaning every consumer reads

A report is a finished answer. It carries the grain, the filters, the joins and the definitions that produced it, and it carries them for one audience at one moment.

The next report rebuilds the same meaning. The finance team's revenue number and a regional team's revenue number come from two queries that may agree by luck. Two consumers read one dataset, and each query gets its own chance to define revenue differently.

Report-as-a-product makes the report the deliverable. The team's job ends when the report is delivered, and the next consumer starts a new request. The report can be excellent and still leave the meaning locked inside it.

Data-as-a-product changes the unit. The data product is the reusable definition: the grain, the keys, the quality rules, the owner and the promise a consumer can hold the producer to. A report becomes one consumer of that product, and so does an agent.

A table with no owner, no grain and no quality rule is a report with a different shape. The data product is the artifact that states what a consumer is promised and who answers when the promise breaks.

Zhamak Dehghani's Data Mesh makes the same move. It treats the data product as the unit: owned and served with a contract and consumers, and reused by every report and every team (Data Mesh, O'Reilly, 2022).

The ceiling is the unit of work

A centrally controlled BI team can be excellent and still hit the ceiling. The queue is the architecture. Every new regional team or agent adds another request to the same queue, and the team answers it with another report.

The team scales with the number of consumers it can serve one at a time. It does not scale with the data. Adding an analyst raises the ceiling a little. Changing the unit moves the constraint: the team publishes definitions many consumers can read, and the ceiling becomes the product boundary and the delivery constraints it must meet.

The ceiling is visible in the lead time. A new regional team waits for its first report, then waits again for each question the report did not anticipate. The data is already there, and the answer still has to be built.

Report-as-a-product is the right unit for a single business question with a stable consumer. It is the wrong unit for twelve regional businesses whose agents ask different questions from the same data.

Central control can stay. A central team can own the platform and the rules and still serve every region, if it serves products instead of reports. What fails is the unit of work.

A semantic layer models meaning; a data product enforces the promise

The self-service objection deserves its full weight. A good semantic layer gives business users consistent metrics and dimensions, and self-service BI lets them answer their own questions without filing a ticket. That is a real gain, and it removes a large share of the report queue.

A modern semantic layer is more than a dashboard. It models entities and defines the keys that join them (primary, unique, foreign and natural in dbt), and it aggregates at a stated grain (dbt entities). A semantic model can carry the grain and keys for the relations it covers, and that is a genuine improvement over a report.

Enforcing the contract for the relation that feeds those metrics is a separate job: a named owner, quality checks that gate release, a freshness promise, a version, and a deprecation path. Those are the parts a consumer can hold a producer to.

That gap matters most for an agent. A person looking at a dashboard can read the timestamp and use their own context to judge whether the number is current. An agent needs the same freshness and authority expressed as data it can read.

When the metadata is not exposed as an explicit, machine-readable contract, the agent has to guess. It needs the promise written down.

A semantic layer can be right about the metric and wrong about the relation. It can define revenue correctly and still serve that revenue from a table that dropped a region, or from a table whose grain changed last week. The metric formula does not enforce the relation's promise; the data product does.

The semantic layer belongs inside the data product. It is one of the things the product exposes, and the product boundary is what a consumer holds.

When meaning is re-created in every report, nobody owns it

Two reports that disagree are a definition problem. Someone has to decide which revenue number is right, and that decision is usually made in a meeting because no artifact owns it.

The meeting is expensive because it has no source of truth to appeal to. Each report is locally correct against the query that produced it. The disagreement is in the definitions, and the definitions live in two places.

The cost lands on the buyer as risk and on the team as arbitration. The data team spends capacity explaining which number is right instead of changing the data. The business spends its meetings on the same question.

A data product gives the disagreement a place to resolve. The definition has an owner, a contract and a test. A report that disagrees with the product is wrong in a way the team can check, and the check happens before the meeting.

That is where the effort compounds. Each definition that gets a test removes a question from the next review, the same way an accepted change shrinks the next review in the build loop.

The abstraction objection names a real cost

The objection is fair. A data product is another artifact to define, own and maintain, and a bad one duplicates the catalog, drifts from the warehouse and pushes work onto the business. Teams have paid that cost.

The failure has a shape. The product is a renamed table with a contract that restates the schema, an owner who never answers, and a quality rule that passes because it checks nothing. That artifact earns the objection.

The cost is real when the product is a second description of the data that nobody generates, checks or owns. It is the same cost the report already pays, moved earlier and paid once instead of in every report.

The question is which artifact carries the meaning. In report-as-a-product, every report carries a copy and every copy can drift. In data-as-a-product, the meaning is carried once, and the reports and agents read it. The abstraction earns its keep when it replaces the copies.

The direction of ownership matters too. The data team keeps the platform and the rules; the business consumes a product with a contract and a team to call. A product that pushes work onto the business without those has not earned the name. The unit still stands.

The test for the product is the test for the report. Can a consumer hold the producer to a promise? If the answer is no, the artifact is a report with a new name.

A multi-entity business needs one definition its agents can read

A report is built for a person to read. An agent reads an interface, or it reads metadata directly. Given only a rendered dashboard, it can read what the surface shows but not whether the relation still honours its promise.

Give it a definition, a key, a grain, a quality rule and a contract, and it can decide whether it can answer. An agent fails on meaning that is not written down. Without that metadata it does not know which definition is authoritative, what the grain is, whether the data is fresh, or what a change will break. Report-as-a-product leaves it to guess at all four.

Twelve regional businesses multiply the readers. Each region has its own questions, its own language and its own agents. A central team cannot write a report for every combination, and it should not try.

One data product can serve all twelve because the meaning is the same even when the question changes. The region that asks about margin and the region that asks about stock both read the same definition, the same grain and the same quality rule.

This is the part the transformation officer was pointing at. The group did not need another report for one team. It needed reusable data that its regional teams and their agents could serve themselves from.

Write the reusable definition under the report you already have

The move can start with one report that a single consumer depends on, without a platform purchase or a reorganisation.

1. Pick one report that one team relies on and that another team has asked to reuse.
2. Write down the definition underneath it: the grain, the keys, the filters, the quality rules and the owner.
3. Name the consumers: the teams, the agents and the questions the definition has to serve.
4. State the promise a consumer can hold you to, and the check that proves it still holds.
5. Serve the report from that definition, then serve the next consumer from the same one.

The first product can stay small. It needs to prove that one definition can serve two consumers without being rebuilt.

The productivity claim is that the same team ships more with Vibedata: less time to PR and less time per PR, once the team changes what it focuses on and how it builds, and review compounds as each accepted change shrinks the next review.

Look at the report your team maintains for one consumer. What is the reusable definition underneath it, and who owns it?

References

• Zhamak Dehghani, Data Mesh, O'Reilly, 2022.