Decide what counts before you build: a practical guide to data products

Most data teams now have a data products initiative, or are about to start one. The term has travelled fast, and it has picked up loose usage along the way. A dashboard gets called a product. So does a single table, or a whole department's data.

We think the useful work starts with a tighter definition. The definition decides everything that follows: who owns what, what "done" looks like, and which product you build first.

What a data product is

A data product is a set of related data about one area of the business. It is owned and maintained so that other teams can rely on it and reuse it. It is usually made up of several tables, plus six components that make it trustworthy:

• Personas: the owner, steward, consumers and other roles around the data
• Definitions: agreed descriptions of the data, and how often it is refreshed
• Quality: agreed checks on the data
• Discoverability: cataloguing and documentation so people can find and understand it
• Governance and consent: classification and rules on who can use the data, including consent
• Interfaces and adoption: a standard place to get the data from, with usage tracked

Reports and dashboards are built on top of data products. They aren't products themselves.

One practical point before going further: agree your language early. If your organisation already uses "product" for something it sells, "data product" will get confused with it in the first meeting unless someone settles the vocabulary.

Entities are the building blocks

Entities, like Customer or Order, are the components. A data product groups the entities that belong to one area of the business.

If you think in relational terms, entities are tables and a data product is roughly a published schema. It is a set of related tables with an owner, documentation, quality checks and access rules. Each entity is owned by exactly one product. Other products refer to it by key: an order holds a customer ID rather than keeping its own copy of the customer.

Some products are close to a single entity, such as Customer. Others bring several entities together around an area of work, like Marketing or Returns. Returns, for example, owns its own return requests, refunds and inspection results, while referring to customers and orders owned elsewhere.

Exactly where the boundaries sit will need agreeing, and some calls will be close. Does a refund belong to Returns, or to Orders? That's normal, and it is better done deliberately than discovered later.

Why each component earns its place

Each of the six components prevents a specific, familiar problem. Without them:

• It's unclear who decides, who maintains and who uses the data, so decisions stall and users' needs get missed.
• Teams report different figures for the same thing, such as revenue or active customers.
• Problems surface late, found by the people relying on the data, sometimes at a reporting deadline.
• Knowledge sits with a few people, so work is duplicated and hard to hand over.
• Data gets used without the right lawful basis, with regulatory and reputational consequences.
• Teams take their own copies, which drift apart and are hard to control or retire.

Most organisations are probably already paying these costs in some form. They're spread across enough teams that nobody sees the total. When you make the case internally, one or two specific, recognisable examples from your own organisation will do more than any general argument.

With the components in place, the picture changes. Roles are clear, and the data is shaped around the people who use it. There is one agreed version of key figures. Issues are caught early, and users know how far to trust what they're looking at. Data is used lawfully and in the way customers expect. People use data from one place instead of rebuilding it, and there's evidence of which products add value.

The upside is measurable. Research from McKinsey, published in Harvard Business Review in 2022, found that companies treating data as a product can implement it in new use cases as much as 90% faster, and cut total ownership costs by up to 30%. Much of that comes from reuse: at one large national bank, a single customer data product powered nearly 60 use cases.

What each product needs

Turn the six components into a checklist that every product is measured against:

• Personas: a named product owner and data steward, the consumers and their roles, and a one-page summary of purpose, users and scope
• Definitions: a data model showing tables, keys and links to other products, a glossary of key terms and measures, and a data contract covering schema, refresh and the change process
• Quality: quality rules and thresholds, suggested automated checks, and a quality report users can see
• Discoverability: a catalogue entry, lineage back to source systems, and example queries and uses
• Governance and consent: data classification applied across the board, access roles with an approval route, and consent and lawful basis rules
• Interfaces and adoption: a published location such as a warehouse schema or semantic model, usage measures, and a support and feedback route

Not every product needs all of this on day one. Some items are done once for the whole programme rather than per product: the operating model, the standards and templates, the product register and the roadmap.

A first view of the landscape

Start with an initial list of candidate products, based on what you already know, and expect it to change once you've spoken to the teams. Group the candidates by area of the business.

Two things are worth spotting early. The first is the foundation product that most others depend on. This is usually customer identity, contact details, consent and preferences, and it's likely to need to come first. The second is any area with different data, owners and users from the rest, which can be worked on in parallel.

Deciding what counts as a product

A definition only helps if you can apply it consistently. Work through these questions with your teams for each candidate product:

• Does it hold data nobody else does? Is it the source of truth for its own entities?
• Who owns the meaning and the rules? Is there one team that decides what the data means and how it can be used?
• Who relies on it? Which teams, reports and processes use it, and would they notice if it was wrong or late?
• Can it change on its own, without other products constantly having to change too?
• Where does the data live today? Which systems, spreadsheets or third parties hold it, beyond the core platforms?
• What does it depend on? Which other products need to exist first for it to work?

The size of the team and the complexity of the process don't settle the question on their own. They are useful hints that there's a real area of data, but the answers above should decide. Product boundaries shouldn't come down to which team is biggest.

A good first test case is a candidate that is large, has its own data, and depends heavily on other areas. If the questions work there, they'll hold up elsewhere.

Take returns at a retailer. It has its own data: return requests, return lines, refunds and inspection results, some of which may sit in spreadsheets. It has a large team. And it depends heavily on other products, particularly Customer and Orders.

That's what makes it a useful first test. Whether Returns ends up as one product, or is split across Orders and others, is exactly what working through the questions with the teams involved should decide. Either way, it can't come before Customer, which almost every other product depends on.

Baseline before you build

Once you have a candidate list, score each product against each component: not yet in place, partly in place, or established. The checklist above gives every cell a concrete test. For example: does Customer have a named owner and a one-page summary?

Do the scoring with the people who know the data, and don't arrive with the grid already filled in. A maturity score handed down before anyone has looked at the work puts data owners on the defensive. They are the people you most need on side. Filled in together, the grid becomes an honest baseline to measure progress against.

Prioritising: value, readiness and dependencies

Order the work using three inputs. Value is what the product would enable or unlock for the business. Readiness comes from the maturity assessment. Dependencies are the products that need to exist first.

Value and readiness combine into a simple grid:

• High value and ready: do first.
• High value and not ready: prepare first.
• Lower value and ready: do if the effort is low.
• Lower value and not ready: leave for now.

Dependencies can override the grid. Customer, for example, needs to come before Orders, because orders refer to customers.

Be clear about who decides what. Leadership decides value. We bring the readiness evidence and the dependency map. The output is a prioritised roadmap that both sides recognise.

A phased approach

We'd suggest three phases, with the scope and outputs of each agreed before it starts.

Agree and baseline. A delivery manager works with your head of data and data owners. This phase produces an agreed definition and checklist and a data product register showing scope, owner and main entities for each product. It also delivers the maturity assessment and a prioritised roadmap. The phase is small and useful on its own, which makes it an easy first step.

Design. The same group, plus architecture and governance input. This phase sets out the operating model, meaning the roles and the decisions each one owns. It also produces templates for each deliverable, specifications for the first one or two products, and an implementation plan and team.

Implement. A delivery team including analysts and engineers builds and publishes products one at a time, with owners and stewards in place and quality and usage reporting live. Each product delivered informs the plan for the next.

Where to start

• A working session to agree the product definition and the candidate list.
• Filling in the maturity and prioritisation grids together.
• Agreeing the roadmap.

The tables are the easy part. Ownership is the answer.

Dot Collective designs, builds and runs AI-enabling, mission-critical data infrastructure for the modern enterprise. Want to chat? Get in touch.