A data product can pass every technical review and still deserves to be retired. That happens when an accurate, governed, documented asset has no dependable place in anyone’s work. When a forecast, pricing review, campaign decision, or service intervention arrives, people return to the spreadsheet, report, or analyst they already trust.
The timing makes this problem harder to ignore. BARC and Actian’s 2026 research with more than 300 enterprise data leaders found operational adoption rose from 48% in 2024 to 69% in 2026. KPMG’s 2025 survey of 250 executives found only 35% had achieved extensive value from their initiatives. Adoption is moving faster than proven value.
The practical test is simple: does the product remove work from a recurring decision? If the user still has to search, interpret unfamiliar fields, request access, reconcile definitions, and rebuild the output, the product has shifted technical work without improving the user’s job.
What Makes a Data Product Usable?
A curated dataset becomes a product when it has a defined consumer, a clear job, an accountable owner, a service expectation, and a managed life after release.
ISG Research’s 2025 Buyers Guide describes data products as reusable assets created with product thinking, supported by data contracts and feedback mechanisms, and designed for discovery and self-service consumption. This brings user experience and ongoing management into an architecture-heavy conversation.
I would add one requirement: a usable product needs a named moment of use.
“Sales analytics” is too broad. “Give regional sales leaders a trusted view of renewal risk before the Monday pipeline review” is specific enough to design against. It identifies the user, the decision, the timing, and the consequence of failure.
That is the foundation for business data products that survive beyond launch.
Start With the Decision, Then Work Back to the Data
Many teams begin with available data. They inventory tables, clean fields, assign owners, create a semantic layer, and publish a catalog entry. Users arrive after most design choices have already been made.
Reverse that sequence.
Start with a recurring business task and observe how people complete it today. Which inputs do they collect? Which definitions cause arguments? Which manual steps consume time? Which exceptions force them to call another team? Which information arrives too late?
This creates a better product brief:
| Design question | What the team needs to know |
| User | Which role will consume the product repeatedly? |
| Job | Which decision, analysis, or workflow does it support? |
| Timing | When does the user need the information? |
| Grain | What level of detail supports the job? |
| Trust | Which definitions and controls must be visible? |
| Action | What should the user be able to do next? |
This approach changes data product adoption because the team designs around a user habit that already exists. The product has somewhere to land.
Ownership Has to Include Decision Authority
Ownership is often assigned as a governance field. A name appears in the catalog, while decisions about quality priorities, access, funding, and user requests still move across several teams.
KPMG found that 60% of respondents centralized data product ownership within IT. The same study found only 55% considered data management a collaborative effort co-owned and managed by IT and the business. That gap helps explain why technically sound assets can still miss business context.
A practical owner needs authority over purpose, service level, change priority, and retirement. The owner should know which users the product serves, which requests deserve engineering effort, how fresh the information must be, and when maintenance is no longer justified.
Engineering, governance, and domain specialists still have defined responsibilities. One person, however, needs a coherent view of the product as a service to users.
This is where the data product operating model becomes real. It defines who can make product decisions rather than simply documenting who is involved.
Data Quality Should Be Written as a User Promise
“High-quality data” is too vague to manage.
Quality requirements should describe what the user can depend on. A finance close product may require strict completeness by a fixed cut-off. A marketing audience product may care more about freshness and consent status. A supply planning product may need reliable product-location relationships and explicit treatment of late-arriving transactions.
Write those expectations as product promises:
- Customer status is refreshed by 6 a.m. local time each business day.
- Finance-approved revenue definitions are used across published measures.
- Records that fail required validation are quarantined before publication.
- Users can see the source, freshness, and owner of each critical field.
- Breaking schema changes require notice before release.
These promises turn quality into something users can observe. They also help engineering teams prioritize defects according to business consequence.
Access Is Part of the Product Experience
A catalog entry that ends in an access ticket is only partly self-service.
Access design should cover entitlement rules, approval paths, delivery interfaces, documentation, and the first successful use. Long discovery and approval cycles make a product difficult to fit into a recurring operating rhythm.
I use time to first useful answer as an adoption measure. The clock starts when an eligible user decides they need the product. It stops when they can answer the intended business question without help from the product team.
This measure exposes friction that usage dashboards miss. A user may have access and still be unable to identify the right field, filter, join, or definition.
For business data products, access quality includes the effort required to become productive.
Data Products Need a Lifecycle, Including an Exit
Product language creates an obligation that project language often avoids: someone has to care for the asset after launch.
A healthy lifecycle has five states: proposed, validated, active, changing, and retired. Each state needs entry criteria. The overlooked state is retirement.
Teams hesitate to remove assets once other work depends on them. The result is overlapping products, old definitions, duplicate interfaces, and unclear ownership. Discovery becomes harder as obsolete entries accumulate.
Retirement should be triggered when there are no active consumers, the business process has changed, another product has replaced the capability, maintenance cost exceeds justified value, or the underlying definition is no longer approved.
A portfolio becomes easier to trust when users know obsolete entries are deliberately removed.
Measure Adoption by Dependency, Not Visits
Views, queries, subscriptions, and API calls show consumption. They do not show whether the product matters.
A stronger model separates three levels of use:
- Discovery: the intended user can find and understand the product.
- Repeat use: the user returns without repeated support from the data team.
- Workflow dependency: a recurring decision or process now relies on the product.
The third level is where data product adoption becomes economically meaningful. Removing the product would create visible friction, delay, or risk.
Value measurement should connect the product to the job it was designed to improve. Depending on the use case, teams might track decision cycle time, analyst preparation hours, reconciliation effort, duplicate pipeline reduction, exception rates, or downstream use cases served.
A revenue metric will not fit every product. Some exist to reduce control risk, establish consistent definitions, or remove repeated manual work. The value measure should match the original job, which is why Data Analytics Consulting should begin with business workflows, not only available datasets.
A Better Data Product Operating Model Uses Product Reviews
Technical monitoring tells teams whether pipelines are running. Product reviews tell them whether the asset still deserves investment.
A quarterly review can ask:
- Who used the product repeatedly?
- Which business workflows depended on it?
- Where did users still create manual workarounds?
- Which quality or access issues caused the most friction?
- Should the team maintain, change, merge, or retire it?
This review gives the owner evidence for prioritization and gives business sponsors a reason to stay involved after release. It also prevents the catalog from becoming a museum of completed data projects.
The discipline should be selective. A product with no clear consumer should struggle to receive funding. A heavily used product with recurring friction should move up the backlog.
Adoption Checklist for Enterprise Data Assets
Before calling a product ready, test whether a real user can move from discovery to action without relying on tribal knowledge.
- A specific user role and recurring business job are documented.
- The owner has authority over purpose, priorities, service expectations, and retirement.
- Business definitions and critical metadata are understandable without an analyst translating them.
- Quality targets are tied to the intended use.
- Eligible users can discover the product and understand how to receive access.
- Documentation includes examples that match real business questions.
- Changes are versioned and communicated to affected consumers.
- Feedback has a visible route into prioritization.
- Usage is measured beyond raw views or query counts.
- At least one outcome measure is tied to the original user job.
- Retirement criteria exist before the product becomes obsolete.
This checklist is intentionally user-centered. Architecture still matters, but technical completeness cannot compensate for weak demand.
The Real Product Test Happens After Launch
Enterprises are formalizing ownership, contracts, catalogs, marketplaces, and reusable data products. The 2026 BARC and Actian study also found that 61% of surveyed organizations were using data contracts operationally, reflecting a wider push toward explicit expectations between producers and consumers.
The harder discipline is deciding what deserves to exist.
Useful data products have a clear customer, remove friction from a real job, carry explicit service promises, and have owners who can make choices across the lifecycle. Their value becomes visible in repeated use and in the business process that would feel their absence.
That gives leaders a sharper portfolio question: if we stopped maintaining this product next month, who would notice, which workflow would suffer, and what measurable problem would return?
If the team cannot answer those questions, the next priority is probably not another feature. It is finding the user.
