DataTalks.Club Podcast Wiki

Comparison

Product Owner vs Product Manager: Data Product Role Boundaries

A podcast-grounded comparison of product owner, product manager, and domain owner responsibilities in data product and production ML teams.

Related Wiki Pages

Data Product Management Data Products Data Product Adoption Data Mesh Data Mesh vs Centralized Data Platform ML Product Manager Role Product Analytics Data Teams Data Engineering Platforms MLOps

Product owner and product manager aren’t stable titles across companies. In the DataTalks.Club archive, the useful split is practical. Look for who owns the product decision. Then look for who protects delivery, manages the roadmap, and aligns the data or ML specialists across teams.

Anna Hannemann gives the clearest comparison in Product Owners in Data Science. She says the distinction depends on the company. Some teams use only product owners. Some use only product managers. When only one title exists, that person often has to wear both hats (20:00-21:45).

For data and ML teams, start from the work rather than the title. A product owner is usually closer to team advocacy, delivery decisions, stakeholder translation, and product accountability. A product manager is usually closer to roadmap management, process, prioritization, and broader product strategy. A domain owner coordinates the data science or data product capability across several product teams.

Short Comparison

Use the title only after you name the decision that needs an owner:

Anna’s episode frames the product owner as the person who can make a release decision when a model is good enough. They still have to communicate the quality to stakeholders. She also places the product owner between stakeholders and data scientists or developers. The role translates requirements, advocates for the team, and shields the team when expectations don’t match the work (15:11-18:25).

Product Owner

In Anna’s definition, the product owner is close to product accountability. She describes the role as being willing to make decisions, including risky release decisions. A data scientist may ask for two more weeks to improve a model. The product owner may decide that the current quality is enough to go live, as long as the quality is communicated clearly (15:50-18:25).

That matters in data products because teams can keep improving a model forever. Someone still has to decide whether the model, dashboard, API, or manual fix is good enough for the next business step. Use Data Products for the object being shipped and Data Product Adoption for the adoption work after release.

The product owner also protects the team. Anna gives the example of a stakeholder asking whether one person can solve several data science use cases. The product owner has to explain why the work may need more than one generic resource. It may need a data scientist, a machine learning engineer, MLOps support, or data engineering work (18:25 and 21:45-22:08).

Product Manager

Anna doesn’t treat product manager as a weaker or less important role. She treats the boundary as organization-specific. In her personal split, product managers do more process management and streamlining, while product owners have stronger product ownership (19:06-20:00).

Other DataTalks.Club episodes use product manager in a broader way.

Sara Menefee starts data product management from customer discovery and hypothesis formation in Product Designer to Data Product Manager. She also includes data quality and documentation. Geo Jolly describes a technical PM in ML Product Manager and MLOps Platform Strategy. That PM owns roadmap direction, specifications, feedback, and stakeholder communication for an internal ML platform.

So the product manager side often owns the product-management system around the work. That includes discovery and roadmap work. It also includes prioritization, rollout, feedback, and metrics.

Use Data Product Management for the broader role and ML Product Manager Role when the product is an ML platform or ML-enabled system.

Greg Coquillo gives another data-product version in Build & Scale Data Products for AI. He treats data product management as customer discovery and strategy. It also covers solution design, roadmap work, and value creation for data products. His examples start from internal customers such as sales and marketing. He also covers finance, supply chain, and program teams (4:24-11:32).

That’s why the nearby comparison Data Product Manager vs Product Manager focuses on the extra data lifecycle and adoption work a data PM inherits.

Domain Owner

Anna’s current title in the episode is domain owner for data science. That role isn’t the same as a head of product. Data scientists and data analysts report to her, but they work inside product teams. Product people report elsewhere (38:32-39:13).

The domain owner watches for duplicated data science work across teams. Anna describes bringing data scientists together when they work on similar problems. She can rotate people into new initiatives and help justify work when a new domain needs funding, people, or external support (39:13-40:16 and 46:48-48:44).

That makes the domain-owner role closer to capability leadership than one product backlog. It connects to Data Teams, MLOps, and Data Product Management. The domain owner has to understand enough about several use cases to ask useful questions, but dedicated product teams can still run daily work.

Data Mesh Variant

In Data Mesh, teams use owner titles differently. Zhamak Dehghani uses “data product owner” and “data product manager” for one role. That role manages a domain’s data as a product for other domains in Data Mesh Implementation. In that role, the owner talks with consumer domains and decides which data product or access path is needed. They also manage guarantees such as quality, timeliness, integrity, and completeness (34:59-41:47).

This role is closer to product ownership for a data interface than to a scrum ticket owner. The owner has to know what producers can promise and what consumers need before they can trust the data. Use this section with Data Products, Data Engineering Platforms, Data Mesh vs Centralized Data Platform, and Data Product Management.

Technical Literacy

Technical literacy matters more when the product is a data or ML product. Anna says a product owner or product manager doesn’t always need a technical background. That’s especially true for customer-facing products where user understanding is the main constraint.

For technical products, she argues that the product person has to understand what the team is building (12:49-15:11).

Her recommender-system examples show why. At METRO, the team moved from manual newsletter support toward API-first recommender systems. The stack included MLflow, Datadog monitoring, and country-level scaling.

The product decision wasn’t only “which model performs best?” It included whether the team should expose an endpoint and automate support. It also included whether they could run A/B tests. They also had to separate recommendation IDs from customer-facing images, descriptions, and prices (22:08-30:01).

The product person also needs enough metric literacy to challenge whether a model improvement changes the business. Anna gives an example where a faster model may not matter if the model runs once a week and already finishes in a reasonable time. The product question is whether the improvement changes the business, not whether the model is technically more impressive (35:55-38:32).

Sara adds the data-platform version. A data product manager may not build every pipeline, but they still need to know how data moves from sources through transformations. They also need to understand warehouses, lakes, apps, and analysis tools. She treats SQL, documentation, and data quality as working literacy. PII and compliance matter too (19:38-28:30).

Title Fit

Use product owner when the role needs strong delivery-team advocacy and clear release authority. This title fits teams that expect one person to protect the team and translate stakeholder requests. That same person also makes “ship or wait” calls for a data or ML product (15:11-21:45).

Use product manager when the role needs broader product management:

This title fits organizations that expect PMs to own the product system around the team. Sara’s data-PM episode places customer discovery and hypothesis formation in that product system. She adds lifecycle planning, launch coordination, and measurement. She also includes quality and documentation (7:04-28:30).

Geo’s ML-platform episode adds roadmap direction and specification writing. It also covers feedback collection, backlog prioritization, and stakeholder communication for internal ML platforms (6:28-16:44).

Use domain owner when the role spans several data or ML product teams. This title fits organizations where data scientists, analysts, or ML specialists sit inside product teams. Those teams may still need common practices, staffing decisions, technical mentorship, and portfolio-level judgment (38:32-48:44).

Use data product owner or data product manager when a domain owns data for other teams to consume. In Zhamak’s Data Mesh framing, that title fits the cross-domain conversation about trust and guarantees. It also fits product interfaces and who should build the next access path (34:59-41:47).

The title matters less than the missing decision. If nobody can say “this model is good enough to ship,” you need product-owner authority. If nobody can decide which problem belongs on the roadmap, you need product-management judgment. If several teams repeat the same data science work, you need domain leadership. If teams consume data without clear guarantees, you need data-product ownership.

Business Problems Before Models

Anna’s strongest data-product lesson is that product ownership starts from the business problem. Operations teams often know the problem better than the data team. Anna says the team should ask the business what needs to improve before choosing a model, dashboard, or automation project (44:48-45:57).

She also gives a useful pushback example. If a business team has 200 broken text entries, the product answer may be manual cleanup rather than an AI system. For a larger assortment-optimization idea, the answer may be an MVP, external support, or new hiring only after the business can justify the investment (48:44-53:09).

Product owner vs product manager shouldn’t become a title debate. For data and ML products, compare who owns the concrete decisions.

Use these decision points:

These pages cover the surrounding roles, topics, and comparisons: