Data Product Interface
The stable surface a data product exposes — its schema, its access path, its documentation and its guarantees — as distinct from the pipeline behind it.
Calling a table a data product changes nothing on its own. What makes it one is that it has an interface separate from its implementation, and consumers depend on the interface.
That means a stated schema with a compatibility policy; a documented access path, which may be a table, an API or a stream; documentation covering the semantics rather than the columns; a stated freshness and quality guarantee; and a named owner who answers when it breaks.
The separation is what earns its keep. The producing team can change the pipeline, the storage engine, the transformation framework or the partitioning as long as the interface holds. Without the separation, every consumer is coupled to implementation details and nothing can be changed — which is the position most warehouse tables are in, where a physical restructure requires finding everyone who queried it.
The other half is discoverability. A product nobody can find is not a product, so it appears in the catalogue with its owner, its guarantees and an example query. The test of whether the discipline is real: can a consumer in another domain go from "I need order data" to a working query without asking a human?