Data product manager role: treating a dataset as a product

A table with customers

Suppose a hypothetical Indian retailer has a "customer 360" table used by marketing, the loyalty team, the app personalisation service and finance. Each team files requests: marketing wants more attributes, the app team wants lower latency, finance wants history that never changes once reported. Engineers cannot decide between these alone, and nobody owns the answer to "who is this table for and what does good look like?". That ownership is the data product manager's job.

The artefact: a data product one-pager

This is the document a data PM writes first, and revisits every quarter.

DATA PRODUCT: Customer 360 (v3)

Purpose
  One trusted, privacy-compliant view of each customer for marketing, loyalty and
  personalisation use cases.

Primary users and their jobs
  Marketing analysts    -> build campaign audiences
  Loyalty team          -> compute tier eligibility monthly
  App personalisation   -> fetch customer attributes during app sessions

Not for
  Financial reporting (use finance.certified_revenue); individual credit decisions

Contract
  Grain: one row per customer_id. Refresh: daily by 06:00 IST; online copy < 15 min lag
  Quality: customer_id unique; consented_marketing flag never null
  Privacy: phone and email visible only to approved roles; marketing use respects consent flag
  Change policy: breaking changes announced 30 days ahead; versioned columns

Success measures (quarterly)
  Adoption:      number of teams and jobs reading v3 instead of raw tables
  Reliability:   % of days refreshed by 06:00
  Quality:       open data issues older than 14 days
  User value:    time for a marketing analyst to build a new audience

Current priorities
  1. Retire v2 (3 remaining consumers)
  2. Add store-visit attributes (loyalty request)
  3. Latency improvement for app reads
Explicitly not now
  Real-time event stream (revisit next quarter)

The "Not for" and "Explicitly not now" sections do as much work as the rest. They prevent the product from becoming everything to everyone, which is how shared tables end up unreliable for all their users.

Prioritising requests you cannot all satisfy

A data PM receives more requests than the team can build. A light scoring helps make trade-offs visible, though the score informs rather than replaces judgement.

What fills the week

User interviews with consuming teams, a sprint review with data engineers, a data incident review when a refresh was late, negotiating a breaking change with the three teams still on v2, working with the privacy team on a new attribute, and updating the adoption dashboard. There is less writing of detailed requirements than a software PM might expect, and more negotiating between teams.

Consumers served, SLAs met and duplicate pipelines retired

Adoption of the data product, reliability against its contract, satisfaction of consuming teams, reduction of duplicate datasets, and delivery against the roadmap. In ML-heavy contexts, the business metrics of models that consume the product also count.

Data engineering, analytics and the teams that consume

Data PMs usually report to a head of data platform, chief data officer or product leadership. They work with data engineers and analytics engineers (who build), analysts, data scientists and product teams (who consume), and governance, security and privacy teams.

How it differs from product manager and analytics manager

A regular product manager owns a customer-facing product. A data PM's users are mostly internal teams, and quality, contracts and trust are the product. An analytics manager leads analysts answering business questions; a data PM owns the data those analysts use. The AI product manager is a related but distinct role focused on AI-powered features.

Data mesh, platform PM and data-as-a-product signals

• "Own the roadmap for our data platform / CDP / feature store" — true data PM.
• "Data contracts, SLAs, data quality" — platform-facing data PM.
• "Define metrics and build dashboards" — analytics role with a PM title.
• "Monetise data, external data products" — commercial data products sold to customers.
• "Technical background in SQL and data modelling required" — expected in most data PM roles.

Interview the consumers before the roadmap

Interview every consuming team in month one and write the one-pager. In month two, agree the contract and start measuring it. In month three, ship one priority and retire one duplicate dataset.

Senior data PM, platform PM or head of data products

Senior data PM, head of data products, platform product lead, or chief data officer tracks over time. People move into this role from analytics engineering, data analysis and data science. The Data Science programme builds the modelling, data quality and evaluation understanding a data PM needs to hold credible conversations with engineers.