Definitions.

Data Product Management

From observations, there currently seem to be 3 main types of job role within Data Product Management.

• (Data Product) Manager — Type A

  The DPM is responsible for a defined area of the business. They create data sets from source, make data sets available to the business where that requires technical implementation, and create outputs for non-technical users in the form of metrics or dashboards.

• (Data Product) Manager — Type B

  The DPM is responsible for a defined area of the business. They don't concern themselves with source data, or whether or not data is reusable. They push data into tools which rely on the tools having the functionality to make it easier to work with. Their primary function is to build and manage a suite of outputs or dashboards for non-technical users.

• Data (Product Manager)

  The DPM is dedicated to a defined area of data to own, and manages the Data as a Product — e.g. discovery, roadmaps, highest value first, open feedback loops. They may look after particular tooling such as experimentation, personalisation or AI tooling, and rely on the data already being in the tool while advancing the usage of that tool in the business. They may work with data teams to bring data into the tooling.

Data Product

A relatively ambiguous term that has changed over the years, but is usually a table or, more recently argued, a dashboard stored in something like S3, GCP or Tableau depending on its form. It could be multiple tables, manipulated often by SQL or tools such as Databricks, Snowflake or Tableau, though there are many others. It is almost always source aligned or consumer aligned, and often lies within the philosophical boundary of a Data Mesh, but could be in a database, warehouse or lakehouse. It is owned, loved and managed by a team within a domain. It often requires a technical team to integrate it to an output, but in the case of a dashboard can be used by non-technical users. It should also be well governed and have been through governance and legal so that it is ready to be used, as well as well documented and reusable.

• Consumer Aligned Data Product

  A table of data, or sometimes multiple tables of data, brought together to align to a use case for a given domain. It often might not fit the needs of other domains and, by definition, has been designed to fit the needs of some users. It can be re-used but, due to its consumer aligned design, would not be best placed elsewhere, and should not be adapted unless the domain which owns it agrees. In more recent years, dashboards have also been defined as consumer aligned Data Products.

• Source Aligned Data Product

  A table of data, usually singular, or in this case a Data Product that can be trusted. It has been brought into a domain for the benefit of the business so that it does not have to be done again, and can be used by other domains. It should stay relatively stable in its contents compared to the original source, but has been cleaned up so that subsequent teams can use it without much manipulation changed so little from its original source that another domain would not need to adapt it to its needs. It is the most reusable of all Data Products.

Treating Data as a Product

Applying product management principles to data. It governs how we think, interact and deliver, moving beyond a data team producing outputs to one where the output has customers, is owned, loved and managed, has a lifecycle and meets or exceeds user needs. It moves through stages such as discovery, defining, developing, delivering, iteration and feedback, often delivering at speed and making prioritised decisions on value and time with an MVP in mind that meets the immediate needs of the users and customers.