Who is the customer for your data?

Who is the customer for your data?

A data product has a customer when a recognisable person or system depends on it to achieve a recurring outcome. �The business� is not a customer definition. A pricing manager choosing an offer, a planner setting inventory and an application checking eligibility have different questions, tolerances and access patterns even when they use the same source data.

Start with a customer�decision map. Record who consumes the data, the decision or workflow it supports, frequency, consequence of error, required grain and acceptable delay. Observe the work rather than accepting a feature list: consumers often ask for more fields when the real friction is unclear meaning, slow access or an inability to reconcile exceptions.

Design the product backward from that use. It should be discoverable, understandable, securely accessible and valuable without hidden assembly. Publish ownership, semantics, examples, lineage, quality status and service objectives. Different interfaces may serve different personas�a governed table for analysts, an API for applications and a concise view for managers�without creating different meanings.

Customer focus does not mean fulfilling every local request. Group needs around a cohesive domain concept, choose explicit trade-offs between freshness and accuracy, and protect interoperability through common identifiers and standards. One accountable owner should manage priorities and lifecycle while consumers participate in acceptance and change decisions.

Measure time to discover, time to first successful use, active consumption, support demand, service attainment and the business outcome enabled. Retire products with no consequential customer. Data becomes a product when its team is accountable not merely for producing a dataset, but for making a defined consumer reliably more effective.