How many data products should we start with?

Start with a small, high-impact set. A good rule of thumb is 5–10 candidates that support the most business-critical use cases, so you can prove the operating model before scaling.

How do we decide what is a data product vs a data asset?

Use the Products, Assets, and The Rest classification from Step 1. Promote to Data Product when the dataset is critical to multiple teams or value chains and needs stronger standards, support, and reliability.

What if the business insists that “everything is important”?

Translate the ask into capacity math and trade-offs. Focus on the top 3–10% that drives most outcomes, and apply lighter standards to the rest.

What evidence can we use to prove “value”?

Combine quantitative and qualitative signals:

• Usage and adoption (who uses it, how often, how broadly)
• Criticality to key decisions and workflows
• Impact on KPIs (time saved, revenue protected, risk reduced)
• Downstream dependency (how many products and use cases rely on it)

How do we handle emerging or future use cases (especially AI)?

Do not rely only on historical usage. Co-invent with stakeholders: identify near-term bets and the unstructured or behavioral data that will likely become high value.

What are the minimum standards for a “valuable” data product?

Start minimal, then iterate:

• Clear owner and contact
• Basic documentation and definitions
• Basic lineage (at least upstream source and downstream consumers)
• Basic quality expectations aligned to the use case

When should we delete “The Rest”?

When data is unused, redundant, or confusing the landscape, and deletion is compatible with retention and compliance needs. Treat deletion as data hygiene, not failure.

How do we avoid turning this into a bureaucracy?

Keep the classification simple, make the decision process lightweight, and measure outcomes. If the process slows delivery more than it increases trust and adoption, it is too heavy.