Data products fail in predictable ways. Most of the problems below pass every validation rule in Dawiso — nothing blocks you from publishing a product with a vague purpose or a service account as its owner. They surface later, as unanswered questions, stale data, and consumers who quietly go back to copying tables.
Each anti-pattern below describes what it looks like, why it causes problems, and what to do instead. They are ordered roughly by how often they occur.
The renamed table
Looks like a single table published as a data product, with the table’s own name, a description repeating that name, and no use case.
Why it hurts because it adds a layer of indirection without adding meaning. Consumers still have to work out what the fields mean and whether they can rely on the data, so the product earns nothing over direct table access — while implying a promise that nobody is maintaining.
Instead package data around a business question, not around a storage object. If a single table genuinely answers one, say which question in the value proposition and add the contract that makes the promise real. If it does not, leave it as a catalog asset.
The product nobody owns
Looks like a published product whose Owner is a service account, a team alias, a person who left, or nobody at all.
Why it hurts because every downstream question — can I trust this, may I use it this way, who approves my access — has no destination. A named Owner is the strongest predictor of whether a catalog gets used, because accountability is what consumers are looking for.
Instead name a real person before publishing. Ownership transfers in one action, so naming someone imperfect now is better than leaving it empty. Use Producer for the team alias and Custodian for the operators; the Owner stays a person.
The uncovered cross-team dependency
Looks like another team consuming your output port with no data contract attached, usually because the dependency grew informally.
Why it hurts because there is no agreed schema and no stated terms. You cannot tell which changes are safe, and the consumer has nothing to hold you to. The first breaking change is discovered in production by whoever is on call.
Instead attach a contract when data crosses a team boundary. Contracts are optional by design so you can start with lineage alone, but “another team depends on this” is the point where that stops being enough.
The kitchen-sink product
Looks like one product with many unrelated output ports, assets from every technology, and a description listing several audiences.
Why it hurts because a product is the unit of ownership, versioning, and trust. Bundling unrelated data means one SLA has to cover things with different requirements, one version number changes for unrelated reasons, and consumers take on a dependency far wider than they need.
Instead split by consumer and purpose. If two parts of a product have different audiences, different freshness needs, or different owners in practice, they are two products.
The forever-draft product
Looks like a product sitting in draft or development for months, often already used by someone through a side channel.
Why it hurts because the workflow state is what consumers read to decide whether to rely on the product. A product that is in use but not marked production sends the wrong signal, and it skips the checks that reaching production is supposed to enforce.
Instead move the product forward or retire it. If people already depend on it, finish the work and publish it so the state matches reality.
The silent breaking change
Looks like a field removed, renamed, or redefined in place, with no version change and no notice.
Why it hurts because consumers built on the old shape. The change surfaces as broken dashboards and failed pipelines somewhere downstream, and the debugging cost lands on people who did nothing wrong.
Instead treat the interface as a promise. Check the product’s consumers before changing an output port, then version and announce the change. See Versioning and breaking changes.
The unclassified sensitive product
Looks like a product exposing personal or restricted data with PII Level and Confidentiality left blank.
Why it hurts because reviewers cannot see what they are approving and consumers cannot see what they are agreeing to handle. Blank does not read as “not sensitive” to a system — it reads as unknown, and unknown is where compliance problems accumulate.
Instead classify at the source, on the columns and tables that carry the data, and let the values roll up. See PII Level and Confidentiality.
Reselling another product’s output
Looks like wrapping another team’s published output in your own product and presenting it as yours, with nothing added.
Why it hurts because it creates a contract you cannot honor. You are promising quality and availability for data you do not control, and consumers lose sight of where it actually comes from. Dawiso blocks the direct case: an asset already published by another product’s output port is not available to attach to yours.
Instead consume it through an input port and publish what you genuinely add. Lineage then shows the real chain, and the upstream owner stays accountable for their part.
Most of these share one root cause: treating the product record as paperwork to complete rather than an interface other teams will depend on. For the positive form of the same ideas, see What makes a good data product.