Design and roll out data products

||Connect docs via MCP

A data product is a use-case-scoped container that brings together the assets, description, README, linked terms, owner, and consumable output ports for one business outcome—the single place technical and business context live together. A domain is a logical grouping that mirrors the business (functions, lines of business, brands), and sub-domains give you finer ownership boundaries beneath a parent domain. This guide helps you scope products correctly, model domains and ports, govern publishing across many teams, and pilot without stalling on framework debates.

When to use what

Map your intent to the right building block. Start with one narrow pilot and iterate—don't resolve every definitional debate before building.

Your intent	Right mechanism	Notes
Group assets around a business use case with context	Data product	The container: description, README, linked terms, owner, score, ports
Define an ownership boundary or org grouping	Domain (with sub-domains)	The organizational layer; one named owner per product
Mark what consumers actually use	Output port	The consumption-layer asset consumers actually query—the "cake"; everything upstream is an asset, the "ingredients" (see the cake analogy below)
Connect one product to another	Include product A's output port as an asset in product B	Autogenerates business (product) lineage A→B
Show "can I trust this?"	Verified status + the product score	The verified mark is the more visible trust signal
Curate a consumer-facing storefront	Marketplace, grouped by domains and purposes	The curated, consumer-facing storefront that surfaces published products by domain and purpose, so non-technical users find trusted data without browsing the raw catalog
Give a user group a curated landing experience	Persona home pointed at a product or the marketplace	The single highest-impact lever for non-technical adoption
Feed a product to an AI agent	The product as the bundled asset scope for context	Avoids re-selecting tables each session
Ad-hoc, time-pressured grouping (hours)	Tags + a saved-search URL	Graduate to a data product once it stabilizes

A data product represents a business use case, not an artifact. Name and scope it around what a consumer is trying to achieve—"license utilization," not "License Dashboard." A report, dashboard, or query is an output port of the product, not the product itself. Creating one product per report inverts the model and breaks business lineage; this is the most common failure mode.

A data product qualifies when it solves a named business problem for an identifiable consumer, has an owner, and exposes at least one consumable output port. The recognized data-as-product criteria—discoverable, valuable, trustworthy, understandable, accessible, governed, and addressable—are what the native score measures as metadata completeness. A single-source product is just as valid as a multi-source one; redirect "how many sources make a product" back to the use case.

Start from your own definition. If your team already has a data-product framework, keep it and map Atlan's vocabulary onto it rather than replacing it.

Output ports vs assets—cake analogy

In one sentence

The output port is the cake—what consumers actually query. Assets are the upstream ingredients. Consumers don't need to touch the ingredients; they need the finished product.

• The output port is the consumption-layer asset end users actually query—the cake. Ask "what consumers actually use?" and make that the output port.
• Assets are all the upstream ingredients—raw tables and views feeding the output.
• Multiple output ports are allowed (for example a dashboard for visualization plus a materialized view for extraction on the same product).
• Output ports don't have to be leaf nodes. An authoritative gold table can be an output port of an upstream product and a non-output asset inside a downstream product—that overlap is exactly what stitches product lineage together.
• A shared asset can belong to more than one domain and appear in more than one product. Any dataset shared across domains must be its own product, so accountability is explicit. Never model this as one-domain-per-asset.

Product lineage

Product lineage is business lineage, scoped to products—not the column-level technical lineage that lives on the underlying tables. It autogenerates A→B when an output port of product A is included in the asset selection of product B at creation. Whether the path recalculates after a product already exists—and edge cases where input ports don't populate as expected—change with releases; confirm the current behavior in the product reference before relying on editing an existing product to add an upstream port.

Tags vs. custom metadata

• Tags for propagation through lineage, source-synced flags, simple boolean markers, and fast ad-hoc grouping under time pressure. Keep the tag set small.
• Custom metadata for grouped, typed fields (dropdown, text, date, multi-select) with visibility controls and badge display. Note that a multi-select field's type may be difficult or impossible to change once set—confirm the current constraint in the product reference before configuring.

Recommended sequence

Pilot with a crawl-walk-run approach: one product, one consumer cohort (10–20 people), one high-visibility use case tied to something leadership cares about. Build live in the tenant, bottom-up—don't design the full hierarchy top-down before building anything. Set two success metrics before you start: reduction in time to find data, and reduction in questions routed to engineering.

Build the first product in this order:

1. Create the domain.
2. Instantiate the product from selected assets. Discover the assets to include via lineage before opening the create-product flow—that flow assumes you already know what belongs.
3. Mark the output port explicitly (the consumption layer); everything upstream stays an asset.
4. Add a README and links to the support/intake channel so consumers know how to request changes.
5. Add business terms from the underlying tables up to the product level.
6. Assign a named business owner: the team most impacted if the data disappeared, not the data engineer who built the tables.
7. Configure a persona landing page so the target group lands on their product on login.
8. Keep it as a draft until enrichment is complete, then publish. Products stay editable after publishing—iterate after launch.

Enrich to "good enough," not perfect. Scope enrichment to the rollout-relevant asset layer; a minimum viable bar is description, owner, domain assignment, and certificate status. Don't wait for 100% or column-level coverage before launching—a solid majority verified beats blocking the rollout, and live demand tells you where to enrich next.

Roll out through a structured group session, not informal one-on-ones. Work through these steps in order:

• Have the internal champion drive the product demo (train-the-trainer) so follow-up questions route to the owner.
• Keep the session short—about 45 minutes—and narrate it around the audience's own use case rather than running a feature tour.
• Sequence technical audiences before business audiences: never run business training before personas and access are configured, or the first impression is a broken view.
• Verify query-access policies before the session—discover locked queries during the build, not when the audience can't run anything.
• Before broad rollout, run a two-step gate: internal validation with the build group (confirm the products address the use cases and query access works), then a short leadership checkpoint.

Expand by using the proven team as the forcing function. Lead with use-case value and the proven blueprint, not advanced features:

• Run primer calls with each new team lead to capture their pain points.
• Secure exec sign-off with the champion telling their own story.
• Run an expansion kickoff pre-loaded with the new teams' priorities.

As the portfolio grows, a three-tier hierarchy keeps it legible: foundational products (shared across domains—any dataset consumed by multiple domains is a strong product candidate), processed products (built on top of another product), and analytical products (report-grade, consumer-facing).

Two governance fields to set deliberately as you publish: sensitivity and criticality are informational labels, not access controls. Default sensitivity to internal (a "public" label alarms reviewers, especially in regulated industries), and frame criticality as "if this product disappeared tomorrow, how badly is the business hit?"

Govern publishing at scale

When many teams must publish and stewards lack bandwidth, reframe from "who curates" to "how to automate the first draft so stewards review rather than build":

• Automate first-draft shells. Establish selection criteria (usage, popularity, business impact), turn them into rules the API or MCP can consume to generate draft product shells, and have stewards only review and validate. Don't ask already-stretched stewards for a fixed percentage of weekly curation time—it generates resistance and kills the program.
• Own at the domain level, one named owner per product. Define ownership as "who is most impacted if this data disappeared," not "who built the tables." If two sub-teams have different first-line contacts for the same domain, split into separate products.
• Control sprawl. This is a governance-program challenge more than a tooling one. Use similarity detection to surface duplicates, and consider automating certification on canonical output-port assets so they surface first—confirm the available autocertification and search-ranking mechanics in the product reference—then socialize "look for the verified mark first." Never embed trust signals in asset names; that creates taxonomy debt.
• Certify on concrete pillars: a business owner and technical owner both assigned, metadata completeness (description, README, linked terms), and a data-quality baseline surfaced on output ports. Align on the verification standard before publishing, and automate tier assignment rather than updating it by hand. Keep the criteria narrow and iterate after the pilot.
• Let reviewers see drafts without making them owners by assigning a domain-level stakeholders group—don't degrade ownership semantics by making reviewers "owners."

If you need an org-specific maturity model, one approach is an automation-driven custom score computed on your own criteria and surfaced as a badge—confirm whether the native score can be disabled and what score-customization is currently available in the product reference. For visual trust tiers, use a custom-metadata field plus badge with automated assignment on conditions; prefer one enterprise-wide framework over per-domain naming.

Feed product to AI agent

Use the product as the bounded asset selection you give an agent as context, so you don't re-select tables each session. The real prerequisite is metadata quality, not the product container: enrich the fields the queries actually use first, then bundle those assets into the product and select it as the agent's scope. Data-quality work runs in parallel, not as a gate.

Common pitfalls

• One product per report or dashboard. Model products around use cases; the report is an output port.
• Marking every lineage asset as an output port: it floods the consumer view with upstream technical tables.
• Spending the whole session on definitional debate and creating nothing in the tenant.
• Adopting Atlan's definition wholesale before reconciling it with your team's existing framework.
• Sending new non-technical users to the raw catalog instead of a persona landing page on a curated product.
• Modeling a shared asset as belonging to a single domain: a shared asset can appear in multiple domains and products.
• Defaulting ownership to data engineering: it leaves consumers with no accountable business contact.
• Requiring 100% enrichment before rollout, or creating a duplicate "leadership-suffixed" product instead of using a persona.
• Assuming the marketplace can carry a product-only taxonomy independent of your governance domains. The marketplace's domain taxonomy is shared platform-wide—a fully separate product classification tree isn't a simple configuration. Design one domain taxonomy that serves both, or scope the divergence consciously.

Troubleshooting

Symptom	Likely cause	Next move
The product score shows 0 right after setup	The score refreshes on a periodic schedule rather than on demand	Set the expectation and check back later; for real-time signals, use custom-metadata tiers plus automation.
A query output port is flagged "lineage not present"	Query-type output ports have no downstream lineage by design	Normalize the warning; the real gap is usually missing linked terms or README. Drive to verified status instead of chasing the number.
MCP or Chat returns zero data products for a domain that has them	Semantic search can't filter on relationship fields	Use the two-step chain: resolve the domain identifiers first, then filter products by those identifiers (see below).
A user sees the domains but gets zero products when filtering	The persona policy is missing read on data products within the domain	Grant read on both domains and data products in the domain policy; don't test with admin tokens, which mask it.
A consumer can't run the product's query at rollout	Missing query-access policies	Discover locked queries during the build session; capture policy creation as a pre-rollout action for the governance owner.
A team wants a data-quality/reliability score on the product page	Scores live at the asset level today	Interim: surface a single value via custom metadata or the README/badge—confirm current product-level capability in the reference before promising a header widget.
An asset marked as an output port doesn't appear in business lineage as its own node	Output-port assets are folded into their product in the business-lineage view—expected, not a bug	To surface that asset standalone, remove its output-port marking; the view updates after the next refresh. Where you need lineage anchors without full product investment, create lightweight "bare-bones" products—no SLA, ownership, or enrichment required.
A semantic view built on the product fails on direct SQL but works through the warehouse assistant	A semantic-layer concern, not a data-products one	Semantic-view errors on a product-backed view are a separate topic—see the MDLH / gold-layer reference.
Streaming assets (for example, Kafka/Flink pipelines) aren't autolinked into the product	Transformation-tool tag extraction is adapter-specific and may not cover the streaming path	Confirm the connector's coverage for that adapter; where it's absent, scope a small API/SDK script that reads the pipeline's manifest or tags and links the assets.

Retrieving products by domain via MCP/Chat is a two-step chain, because semantic search can't reliably filter relationship fields: first resolve the domain identifiers from the domain name, then filter data products by those identifiers. Include every sub-domain identifier when querying under a parent, verify the domain resolution step before debugging product retrieval, and confirm the persona has read on both domains and products.

For the exact score mechanics, tier configuration, and marketplace feature specifications, route to the product reference. For the metadata gold-layer schema behind any metadata reporting, route to the gold-layer query reference.

Related

• Metadata enrichment: generating the descriptions and context that make a product trustworthy and AI-ready.
• Glossary, taxonomy & metrics: the linked terms that drive the discoverable dimension of the score.
• Governance, access & personas: persona landing pages, domain policies, and the marketplace access model.
• API, SDK & automation: automating first-draft product shells, and the two-step MCP retrieval chain.