Data Product Owner

A data product owner is accountable for the product’s commitments and usefulness to its consumers. Dehghani connects this role to product vision, roadmap decisions, and consumer satisfaction.

The roadmap identifies what to improve next. Consumer feedback and operating evidence show whether those choices help. The role connects these judgments to people who can implement and support the commitments.

What the role actually decides

Four areas need accountable product decisions. The owner’s mandate should specify which decisions are local and which require shared approval.

• What the fields mean. A bug fix restores an approved definition; a definition change proposes a new meaning. Both can alter published results. Assess affected periods, consumers, and numeric impact, then apply the contract’s notification, restatement, and approval criteria. A definition change also needs agreement on the new meaning.
• What is promised, and what is deliberately not. The data contract states supported fields and uses, quality targets, and change expectations. The owner agrees a scope the team can maintain and records its limitations.
• Which consumer request gets built next. Two teams will want incompatible things. Choosing, and telling the other one why, is the work.
• When to deprecate. Including telling a consumer that a field they query is going away, with notice and a date.

The owner need not implement every pipeline, but must understand the consequences of product decisions with help from engineers and domain specialists. Negotiating scope requires a credible view of data meaning, delivery constraints, and the effort needed to support consumers.

Not the same as the operational roles

The distinction between owner, steward, and custodian covers accountability for a data asset: who is answerable for it, who maintains its meaning day to day, who runs the systems holding it. A data product owner sits at the accountable end and adds the product duties — consumers, roadmap, contract, deprecation.

Keep responsibilities explicit even when one person holds several roles. Combining product ownership, stewardship, and engineering can work with sufficient authority, skills, time, backup coverage, and any required separation of duties. It becomes a capacity problem when incidents repeatedly displace agreed product work without an alternative owner or operator.

Where the role fails

Three conditions account for most appointments that change nothing.

• No named consumer. Without one, there is no satisfaction to measure and no basis for choosing what to build. The owner defaults to promising everything and changing nothing.
• Unclear decision authority. Give the owner authority within an agreed scope and a usable route for shared decisions. Cross-domain definitions and organization-wide controls may require other approvals. The owner remains responsible for impact analysis, coordination, and delivery; a shared approval does not by itself erase product ownership.
• More responsibility than the team can carry. Assess product complexity, change frequency, support demand, and available staff. There is no universal maximum number of products per owner; names in a catalog are insufficient when the commitments cannot be maintained.

Domain ownership works when someone can exercise the assigned responsibility. Product owners need local authority alongside the common rules and escalation paths established by governance. Naming an owner without that mandate leaves decisions unresolved.

The first ninety days, and what to measure

Start with observed accounts in query logs and reconcile them with query tags, BI or application metadata, registered owners, and consumer interviews. Shared service accounts can hide multiple teams, and offline or downstream uses may not appear in the logs. State the observation period and gaps. Write the contract with confirmed consumers, then publish a freshness objective and a support response target and report against both.

Evaluate verified consumer use, quality and support outcomes, unnecessary duplicate maintenance retired, time to answer comparable questions, and direct feedback. Legitimate caches and snapshots can remain. Product count describes responsibility and workload; it does not establish usefulness.

How the role fits with contracts, domain ownership, adoption, and the mesh and fabric framings is worked through in Who Is This Table For?.

References

• Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (2019-05-20)
• Dehghani, Data Mesh Principles and Logical Architecture (2020-12-03)
• Snowflake, QUERY_HISTORY view