Treating data and analytics outputs as products — with defined customers, clear value propositions, usage metrics, and iterative improvement cycles — produces fundamentally different outcomes than treating them as deliverables. Data product management is the discipline that makes analytics investments compound rather than accumulate as maintenance burden.
Most data and analytics outputs are built as projects: a dashboard is requested, it is built, it is handed over, and the data team moves to the next request. The delivered dashboard may be used heavily, barely used, or not used at all — the data team typically does not know which, because once the project is delivered, there is no systematic feedback mechanism.
Treating analytics outputs as products changes this dynamic. A product has a defined customer, a value proposition that it delivers to that customer, metrics that measure whether it is delivering value, and an owner who is accountable for improving it over time. A product is not done when it is launched; it is continuously improved based on usage data and customer feedback.
Data product management applies this product thinking to analytics outputs — dashboards, data pipelines, APIs, ML models — with significant implications for how the data team operates.
What a Data Product Is
A data product is an analytics output that is:
**Discoverable**: The intended consumers can find it without asking someone who knows it exists. It is catalogued, searchable, and described accurately enough that a new user can determine whether it serves their need.
**Addressable**: It has a stable, reliable location or identifier. A dashboard at a URL that does not change. A data API at a consistent endpoint. A data source with a consistent name and location on the BI platform.
**Trustworthy**: Consumers can rely on the data being accurate and current. Quality is measured and visible. The data product's owner is accountable for its accuracy.
**Understandable**: The consumer can determine what the product contains and how to use it without asking someone. Documentation, descriptions, and metadata are part of the product.
**Governed**: Access is controlled appropriately. Ownership is defined. There is a process for requesting changes or reporting problems.
These are properties of the product, not just of the underlying data. A dashboard that sits on a hard-to-find SharePoint page, is accurate but undocumented, and has no defined owner is a data deliverable, not a data product.
The Data Product Owner Role
A data product has an owner — the person accountable for the product's quality, relevance, and adoption. The owner:
- Tracks usage metrics and understands who is using the product and for what purpose
- Collects and prioritises feedback from product consumers
- Advocates for the investment required to improve the product
- Makes trade-off decisions about which improvements to prioritise
- Decides when a product should be deprecated
In practice, data product ownership is often assigned to someone in the data team (an analytics engineer or BI developer), sometimes with a business counterpart who owns the business requirements. The key accountability is that the product is not considered complete at launch — someone is responsible for it through its useful life.
Usage Metrics as Product Metrics
Product thinking for analytics requires usage measurement. For BI dashboards and data products:
**Adoption metrics**: Unique active users per week/month, return user rate (users who use the product more than once), breadth of adoption (what percentage of the intended user group has used the product in the last 30 days).
**Engagement metrics**: Session depth (what do users do after loading the product — do they explore, filter, drill down, or immediately leave?), time on product (proxy for how useful the visit was), return frequency (how often does each user come back?).
**Value delivery metrics**: For products designed to support specific decisions, did those decisions get made using the product? For products designed to replace manual processes, did the manual process volume decrease? These require connecting usage data to business outcomes.
**Quality metrics**: Data freshness at time of use, error rates, load time, query failures. Quality metrics are part of the product experience.
From Request-Driven to Product-Driven Analytics
The shift from request-driven to product-driven analytics requires changes in how the data team operates:
**Product portfolio rather than backlog**: Instead of a backlog of requests, maintain a product portfolio with each product's current state, usage metrics, and improvement roadmap. New requests are evaluated against existing products first: does this request need a new product, or should it enhance an existing one?
**Discovery before building**: Before building a new data product, understand who the consumers are, what question they are trying to answer, and whether they will use a product to answer it. Analytics products built without user discovery are often delivered and never used. A lightweight discovery process (three 30-minute user interviews) prevents most abandoned product builds.
**Launch is not done**: Schedule a 30-day and 90-day review for each launched product. Is adoption at the expected level? If not, why — is it discoverability, quality, relevance? What needs to improve? The review creates the feedback loop that project delivery never had.
**Deprecation as part of portfolio management**: Data products that are no longer used should be deprecated — removed from the catalogue, with adequate notice to the few remaining users. A growing catalogue of unused content creates noise that makes the useful content harder to find. Deprecation is not a failure; it is responsible portfolio management.
Data Mesh and Data Products at Scale
The data mesh architecture formalises data products as the unit of ownership: each domain team owns and operates the data products that serve their domain's analytical needs, rather than a central data team owning all analytics.
This decentralisation shifts accountability for data product quality to the teams that best understand the business domain. Finance owns the revenue and cost data products; marketing owns the campaign and attribution data products. The central platform team provides the infrastructure and standards; the domain teams own the products.
Data product management practices — discovery, usage tracking, improvement cycles, deprecation — apply regardless of whether the organisation has adopted a data mesh architecture. They are the management practices that make any data investment compound over time.
Our BI strategy and data architecture practice helps organisations transition from request-driven to product-driven analytics — contact us to discuss data product management for your organisation.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →