Why Taxonomy Matters
The term “data product” is used to describe everything from a cleaned dataset to a machine learning model to a self-service dashboard. This ambiguity is not harmless — it leads to misallocated investment, confused ownership models, and teams talking past each other when making portfolio decisions.
A useful taxonomy classifies data products not by their technology stack, but by the organisational function they serve and the decision type they support. This approach makes investment trade-offs visible and ownership assignments logical.
The Taxonomy
Tier 1: Foundational Data Products
Purpose: Establish trusted, governed representations of core business entities.
These are the “nouns” of the business — customers, products, transactions, employees, assets. Foundational data products are consumed by other data products, not directly by end users. Their quality determines the ceiling for everything built on top of them.
Characteristics:
- Owned by a single domain team with deep subject matter expertise
- Governed with strict schema contracts and SLAs
- Versioned and backwards-compatible
- Measured by adoption (how many downstream consumers) and quality (freshness, completeness, accuracy)
Examples: Customer 360 datasets, product master data, transaction ledgers, reference data services.
Common failure: Attempting to build Tier 2–3 products without stable Tier 1 foundations. This is the single most common reason data product initiatives stall.
Tier 2: Analytical Data Products
Purpose: Enable repeatable analysis and reporting for operational and tactical decisions.
These products combine and transform foundational data products into structures optimised for specific analytical use cases. They serve analysts, data scientists, and business users who need to answer recurring questions.
Characteristics:
- Owned by domain or cross-functional analytics teams
- Consume from Tier 1 products via declared dependencies
- Refreshed on defined schedules (daily, hourly, near-real-time)
- Measured by usage frequency and decision-influence (do people actually use this to make decisions?)
Examples: Customer segmentation models, financial reporting cubes, operational dashboards, cohort analysis datasets.
Tier 3: Intelligence Products
Purpose: Generate novel insight, prediction, or recommendation that changes how the organisation acts.
Intelligence products are where data capability translates into competitive advantage. They typically involve machine learning, advanced analytics, or complex event processing. They are also where most organisations over-invest prematurely.
Characteristics:
- Require stable Tier 1 and often Tier 2 products as inputs
- Owned by specialised teams (data science, ML engineering)
- Have explicit feedback loops to measure real-world impact
- Measured by business outcome (revenue influenced, cost avoided, risk reduced)
Examples: Propensity models, demand forecasting, anomaly detection systems, recommendation engines, generative AI applications.
Tier 4: Decision Products
Purpose: Embed data-driven logic directly into operational processes, reducing or eliminating human decision latency.
Decision products represent the most mature expression of data capability — where insight is operationalised into automated or semi-automated decision-making. They carry the highest organisational risk and require the strongest governance.
Characteristics:
- Consume from all lower tiers
- Operate in real-time or near-real-time
- Subject to regulatory, ethical, and risk governance
- Owned jointly by business process owners and technical teams
- Measured by decision quality, speed, and compliance
Examples: Credit decisioning engines, dynamic pricing systems, automated fraud detection, clinical decision support.
Using the Taxonomy
Portfolio Planning
Map your existing data products to the four tiers. In most organisations, this reveals an inverted pyramid: heavy investment in Tiers 3–4 (the exciting stuff) with underinvestment in Tiers 1–2 (the foundations). Rebalancing the portfolio towards foundational products is almost always the right first move.
Ownership Assignment
Each tier implies a different ownership model:
- Tier 1: Domain teams (they know the entities best)
- Tier 2: Analytics teams or domain teams with analytics capability
- Tier 3: Specialist data science / ML teams
- Tier 4: Joint ownership between business process owners and engineering
Investment Sequencing
The tiers are naturally sequential. You cannot build reliable Tier 3 products on unreliable Tier 1 products. Investment cases should explicitly identify their tier dependencies and be sequenced accordingly.
This is not to say you must complete all Tier 1 products before starting Tier 2 — but you must have the specific Tier 1 products that your Tier 2 initiative depends on.
Relationship to Data Mesh
This taxonomy is compatible with data mesh principles but adds a dimension that data mesh underspecifies: the functional tier of the product. In a mesh architecture, each domain might produce products at multiple tiers, but the ownership, governance, and quality expectations differ by tier.
The taxonomy also helps resolve a common data mesh tension: which products should be federated (owned by domains) versus which should be centralised (owned by a platform team). In general, Tier 1 products are strong candidates for domain ownership, while Tier 4 products often require cross-domain coordination that benefits from some centralisation.
This taxonomy is informed by data product portfolio work at Westpac (200+ data products across retail and institutional banking) and continues to evolve through advisory engagements.