There are not enough Data Product Managers - And that’s not the problem

Companies are under pressure to become AI-enabled. The same way they were pressured to become data-driven and before that digital.

Each wave follows the same logic: a new capability emerges and becomes unavoidable. And these shifts are never just about tools, individual up-skilling or individual adoption. They extend into transforming how organisations define problems, collect information from the business and validate that what gets built actually makes sense.

That transformation doesn’t happen on its own. Organisations created a role to carry it: the Data Product Manager, sitting between business intent and technical data systems. In theory, it drives these transformations both from a product perspective and at an organisational level. In practice, organisations struggle to hire for the role and onboard people into it. Not because demand is low but because the role itself is unclear.

Anna, Juha and Gaëlle have each felt this paradox from different parts of the world: strong bid prices and a persistent inability to fill the demand. Talents do exist but we are asking them to identify with and step into a role that looks like an unrelatable and long list of skills. This gap can be closed if we are honest about where it actually starts: what is a Data Product Manager responsible for?

This article revisits a piece Gaëlle published in Modern Data 101, now stress-tested across three countries and three perspectives.

A role introduced before being built

Building data products

A first straightforward definition would be: a Data Product Manager is someone who builds Data Products.

In principle, this means designing for a given business context and a defined functional responsibility, both a data model and the way this data is exposed and used.

In practice, however, very few organisations operate in such a structured environment. Many are still struggling to define what a data product actually is, let alone to establish architectures that can support their evolution.

As a result, the role of the Data Product Manager quickly extends beyond building. It involves navigating ambiguity, shaping definitions and contributing to the transformation of how data is managed within the organisation. This was the focus of the first article in Modern Data 101.

Requires a complex skillset

In this first article, Gaëlle described the skills of a Data Product Manager: product management, data management and agile at scale. This framing is useful as it breaks down the role into something more approachable.

But a skillset describes how someone operates and says nothing about why the role exists. And without that “why”, the role defaults into coordination: aligning stakeholders, managing expectations and facilitating discussions. Work that is necessary, but doesn’t scale and lacks the strategic grounding the role actually requires.

In that context, the Data PM becomes part “genie-in-the-lamp” and part “problem-solver”. They learn by proximity to others and do what seems to work. The logic behind their decisions stays opaque, especially to the people depending on them.

This becomes a structural problem the moment the role operates across teams and domains. Without a shared understanding of the role’s purpose, you end up relying heavily on the trust you can build with the people around you. Backlogs are shaped by context only the Data PM holds, which makes priorities harder for others to challenge or align with. People spend time answering questions without understanding the outcome, creating a “trust the process” dynamic rather than shared clarity. And the role’s scope shifts depending on who you’re talking to and what they believe you should own.

Now imagine building that trust simultaneously across ten source teams — each with at least a PM and a Tech Lead — while also serving 600 data consumers.

At that point, trust alone does not scale.

We have seen this pattern before.

When organisations decided to become data-driven, they created the Chief Data Officer role to carry the transformation. A decade later, the CDO remains one of the least consistently defined roles in the C-suite. Scope varies wildly from company to company. Tenure is among the shortest of any executive position. And organisations are still debating whether it should sit closer to IT, the business, or the CEO.

The role was introduced before the organisation understood what it needed from it. So the expectation shifts, sometimes immediately, sometimes over weeks. The CDO is expected to deliver the outcomes, define the method and enable others to do the same. All at once. So then the person hired into it pays the price.

Without a clear bounded context, everything becomes your responsibility. And when everything is your responsibility, nothing is measurable. “Escaping the Build Trap” describes exactly this failure mode: without a clear product purpose, teams default to output and lose sight of outcomes. “Team Topologies” goes further: when responsibilities aren’t explicit, cognitive load increases and effectiveness decreases. The same applies to an individual role within an organisation.

Without a clear “why”, the bigger picture disappears. First for the people around you. Eventually for you too.

As AI becomes a strategic priority, this pattern is only getting worse, the immediate organisational conclusion is that Data PMs need AI skills too. So the skillset expands again to another layer added to an already overloaded definition.

We did a few statistics on the presence of specific skills amongst a set of job offers. AI is with soft skills now present in most job offer postings no matter the job title.

But the same question remains unanswered: why? What problem is AI supposed to solve for a Data PM specifically? The conversation moves fast : straight to tools, straight to implementation and straight to how. We haven’t clarified what the role is responsible for, and we are already trying to automate it.

The actual job: managing ambiguity

In information theory, entropy measures the uncertainty of a signal, defined as the dispersion of possible interpretations or outcomes. In an information system over time and replications, new business contexts, new teams, the same signal is reused in different contexts and gradually acquires multiple meanings.

A system that initially produced a stable and shared meaning can drift toward multiple interpretations: the relationship between signal and meaning becomes less deterministic.

Information systems conceived to serve data are no different. As organisations grow, the same metric acquires multiple definitions across teams. The ownership definition becomes an historical decision that doesn’t make sense. Pipelines get rebuilt because no one knew the other existed. Concepts that were clear in one domain mean something subtly different in the next.

This happens because coherence requires continuous work to maintain it.

Data Product Managers actively maintain coherence by managing ambiguity. They do it by understanding the business, clarifying definitions, aligning domains and making trade-offs explicit.

Ambiguity is when a single signal can be interpreted multiple ways. The problem isn’t that you don’t have data, it’s that the same data means different things to different people.

Coming from an organisation perspective, March and Olsen define ambiguity as a lack of clarity about the meaning of concepts, the nature of problems or the connection between actions and outcomes.

Why is it the core problem ? Because ambiguity makes it impossible to provide a clear data model that will support business decisions. In particular, when you are trying to build transversal visions across systems and business domains.

So, a data product is valuable only when it reduces confusion in how decisions are made. Moreover, its construction is valuable because it brings clarity to the organisation.

The ambiguity Data Product Managers tackle are not only about the systems but also about the operational decisions they take everyday, for example with priorities.

Frank Knight made a distinction between risk (unknown outcomes with known probabilities) and uncertainty (unknown outcomes with unknown probabilities). Ambiguity in his framing is closer to uncertainty: you don’t just not know the answer, you don’t know the shape of the problem. A Data PM isn’t just resolving known unknowns, they’re structuring problems that haven’t been properly formed yet.

What should be built? In what order? And for whom?

Left unresolved, these questions create noise, rework and misaligned efforts.

Data PMs address this upstream by ensuring that effort is directed toward the most impactful problems.

They do not just prioritise work. They define what is worth working on in the first place.

When this is done well, something important changes for technical teams.

They no longer need to constantly question of whether a problem is worth solving, how it connects to the bigger picture or what success actually looks like

Instead, they receive problems that are:

• clearly framed

• understood by the business

• strategically grounded

• and ready to be solved

With clear acceptance criteria and a well-defined context, teams can focus on execution with confidence that their work will have real impact.

Why can’t the role find its place?

If the role is so impactful, why is it so difficult to define and scale? We argue that it operates in a space that organisations do not structure explicitly and sometimes many have never experienced.

Data leaders believe in the potential but often lack experience in product management. Their expertise lies in data, not in internal user centricity, designing products, defining Return On Investments with finance teams or structuring decision-making with executives.

On the contrary, product leaders lack the experience in data management that could help them shape their new transversal problems. Identifying, describing and solving a data architecture issue is very different from their usual operations.

As a result, both profiles struggle to define the role, hire the right profiles or support their growth.

In the following paragraphs, we address certain push-backs that we have faced over the years.

1/ Data PM is a duplicate role

The role sits in a space that is partially covered by others. Anna points out: “It sits in a space where IT leaders, data leaders, and architects each cover parts of the work. So it doesn’t appear as a clear gap. Some things don’t get done and others become a tax on existing roles, handled in disconnected and inconsistent ways.”

Moreover, if you describe its core functions, it overlaps with existing roles. Architects define system structure and platform vision. Analysts work with stakeholders to define needs and produce insights. Engineers build and maintain pipelines.

So the reasoning is straightforward: why not a simple trio with architects for structure, analysts for insights and engineers for pipelines.

Juha describes how this plays out in practice.

Data departments often assume that discovery, prioritisation, and design have already been handled by the business before a request reaches them. Their role is to respond, clarify a few details, and deliver.

From that perspective, a Data PM looks unnecessary. If a request exists, it must already be well-defined. And who knows what is needed better than the person who will use it?

At the same time, the business sees things differently. They consider shaping the solution to be data team responsibility. They know data can help, but expect experts to turn vague ideas into precise solutions. Every request feels urgent, and managing capacity is seen as the data team’s problem, not theirs.

This creates a structural gap where IT assumes the problem is already defined and the business assumes IT will define it.

In between, key activities fall through : discovery is incomplete, prioritisation is inconsistent and design decisions remain implicit. Work still gets delivered, but slowly, with rework and with growing frustration on both sides.

The system “works” only because individuals compensate for it. It is fragile, inefficient and difficult to scale.

2/ Data PM is a middle layer

Another common misconception is to see the Data Product Manager as a form of “glue work” already covered by project management. This confuses two fundamentally different roles: project management organises execution, while product management shapes what should be built in the first place.

Anna explains that product managers do not simply respond to requests; they invest in discovery: “We explore the broader user environment, understand how people actually work and identify what truly solves their problem. The result is not a response to a ticket, but a validated and refined use case, which significantly reduces the risk of building the wrong thing.” This work also includes rediscovering the past and curating its legacy.

In organisations focused on output (pipelines delivered, dashboards produced or features shipped) this work remains largely invisible. It does not increase volume; it improves relevance. As a result, its value is often underestimated.

But this is precisely where the Data Product Manager creates leverage. The role is not additive; it is multiplicative. It increases the quality, coherence and impact of what is already being built by reducing misalignment by design.

Recognising this requires a shift in perspective: from valuing short-term delivery to valuing long-term system clarity.

From Gaëlle’s experience, business teams are often the first to recognise the impact of a Data Product Manager. They see it in the quality of what is delivered: clearer problem framing, more relevant solutions and fewer iterations.

Because they are closest to the outcomes, they can appreciate and sometimes even measure the difference.

This makes strong business sponsorship critical. Without it, the role remains hard to justify. With it, the value becomes visible, supported, and easier to scale.

3/ Data PM scope is unclear

Juha highlights that corporate IT departments have traditionally been organised as internal service providers. Tickets come in and solutions go out. The boundaries between requester and provider have long been defined. Processes and roles standardised through frameworks like ITIL.

The Data Product Manager does not fit this model. The role operates across domains, teams, and systems, without a fixed boundary. Its scope is defined less by ownership than by interaction.

This creates a structural mismatch. Organisations are optimised to understand roles that have a clear perimeter. A role without one is harder to position, fund, and evaluate.

Anna points out that it introduces a significant cultural shift as well. Moving away from a request-driven model toward a discovery-led approach can feel counterintuitive in environments where responsiveness and delivery have been the primary measures of performance.

Taking time to understand before building is often mistaken for not delivering at all, seen as the posture of dreamers rather than doers.

The functional domain is its anchor

What makes Data Product Manager look redundant is that their role is often reduced to operating individual outputs (dashboards, datasets or pipelines).

But for this role to make a difference, it needs to be grounded in a functional domain:

• a coherent business area

• a shared semantic space

• a set of decisions

At this level, the role becomes necessary and effective: maintaining coherence across a whole business area.

Their role becomes building relationships with key stakeholders, collecting business needs supporting real operations and delivering for a clear business sponsor. They will both make sure that their data products form a coherent ecosystem from its functional perspective and that it supports real business outcomes.

A strong functional domain anchoring creates explicit boundaries that will clarify what is expected of you and for whom.

In that context, what good looks like ?

From Gaëlle’s experience, when the role is properly defined and anchored, the system starts to change :

• It moves from a picture with fragmented systems:

  • teams with scopes

  • teams with their users

  • teams with their definitions

• to a domain-oriented vision promoting user-centricity:

  • processes that we support successfully

  • processes that we struggle to support

  • processes that we don’t support yet

Your teams start to think about their problems in a one team approach: the system is structuring itself taking into consideration the constraints and context of others. And that impact extends beyond data products themselves.

At the domain level, Data PMs will influence sources, product managers and local governance teams.

At the corporate level, Data PMs influence how other parts of the organisation operate:

• how platform teams enable self-service

• how governance supports usage instead of blocking it

• how executives understand and prioritise data investments

This is when the role starts to scale.

This role will create frictions

When an organisation takes the leap to introduce the role, staff it properly and invest in strong product managers, the reaction is rarely neutral.

The work of reducing ambiguity is active and transformational.

It introduces constraints:

• fewer definitions, which lead to difficult alignment conversations

• clearer ownership, which limits how teams can operate independently

• explicit priorities, which mean some requests are no longer prioritised

The changes addressed are necessary for the end-users but also uncomfortable.

In practice, we have observed that as Data Product Managers become more effective, reactions become polarised. Some individuals welcome the clarity. Others resist it. This resistance takes different forms: organisational pushback, personal discomfort and conflict between teams.

Maturity is about the problem and not the solution.

We often use the term maturity but sometimes forget what it means.

A team is mature about a certain matter when they have realised the problem, and not when they have understood the solution.

In other words, teams have to experience the problems to increase their maturity.

Data PM is a form of positive disruption. It surfaces problems that were previously tolerated such as inconsistencies, unclear ownership and misaligned expectations.

Engineers may think: “just let me code.” Business stakeholders may think: “just deliver what I asked.” Both reactions reflect the same underlying tension: the role challenges existing boundaries.

In that sense, introducing a Data PM is not just adding a role. It is a recognition that these boundaries must be crossed, and that the friction that comes with it must be addressed.

Organisations tend to fall back to familiar ways of working. Resistance is not an anomaly. It is the default.

Which is why strong leadership is essential. Because without it, disruption is seen as a problem to eliminate, rather than as evidence that something meaningful is changing.

The talents exists but the transition doesn’t

We argue that Data Product Managers are talents that currently exist under different titles.

You already have people who could grow into the role:

• an engineer with strong systems thinking and communication

• an architect who understands how systems connect to business strategy

• an analyst who is tired of building without clarity on why

The potential is there but we are missing the transition. We believe that once the “why” of the role is clear, acquiring the skills becomes a matter of practice. But that transition is not trivial. It requires a shift in perspective, not just an accumulation of skills.

1/ Business functions

Transitioning into a Data PM role from business functions requires levelling up on two fronts.

First, product thinking: in order for work not to remain stuck in project mode, focused on delivery rather than value creation across the full lifecycle. Second, understanding what is possible with data: that we are not talking only about dashboards and that we are talking about system design. Without both, you can risk designing faster horses instead of cars.

But not all business profiles start from the same place and some are already closer to the role than they think.

1. Shadow IT profiles are often the strongest hidden candidates.

They build their own solutions, reconstruct data flows, and iterate based on real user needs. They already translate business problems into data outputs and maintain them over time. What they lack is not intent but scale. They optimise locally, without the tools or mandate to structure systems globally.

2. Finance teams are another powerful source.

FP&A analysts, controllers, pricing analysts constantly: reconcile conflicting definitions, align multiple sources of truth, and deal with the impact of data on decisions.

They already operate in ambiguity every day. They understand that a metric is not just a number but a negotiation between perspectives. What they lack is system-level thinking: moving from “my model works” to “the organisation shares a consistent definition.”

3. “Bridge” profiles.

Profiles such as functional consultants or business analysts in transformation programs. They already translate business processes into system requirements, navigate across multiple stakeholders and deal with complex trade-offs. They understand complexity, cross-team alignment and process dependencies.

But they are often stuck in requirement mode and not really challenging “should we build this?”. Additionally, an important change to their daily lives is that they currently do not own the outcomes (run mode).

Across these profiles, the pattern is the same.

They already understand: user needs, decision impact and the pain of inconsistent data. But they operate in silos, solving problems locally. The transition to Data PM is about shifting from solving a problem once to structuring how it should be solved across the organisation.

Gaëlle says: “The best Data PMs are not created from scratch. They are revealed in the places where the system is already breaking.”

2/ Product Managers

For Product Managers, the shift may seem natural but the challenge is adapting it to a different kind of asset.

Learning the nature of data

Data is not a feature or an application. It is reusable, composable, and evolves over time. A Data Product Manager must think beyond a single use case. They need to anticipate how data can be reused, combined, and interpreted across multiple contexts.

The shift is from building products to shaping information and it requires a level of abstraction.

User needs are less visible. They are not always expressed through interfaces, but through decisions, workflows, and interpretations. This requires a different mindset: not just delivering something useful, but ensuring that what is built remains useful as the organisation evolves.

Anna’s personal take is that :

For Product Managers, there’s catching up to do. Understanding the power and potential in its near-infinite reusability, is quite different from a purpose-built application for human users.

A Data PM needs to think ahead not only in terms of new technologies and capabilities that they could utilise in their product, but also in terms of how the utilisation of the data in their product could change.

They need to understand how data products can be built as modular components that can be combined and assembled into many different recipes for different users.

And they need to understand that user pain points won’t tie as cleanly to interfaces: it’s less developing applications and more thinking about the ways data can be utilised to solve problems in an organisation.

It’s a big mental shift. In a way, the users of a data product evolve at least as fast as the products themselves.

3/ Analytics teams

Analysts are often closest to the role. They understand users, business processes and real pain points better than most. They already operate at the intersection of data and decision-making.

From solving problems to structuring systems

As analysts, the goal is to solve a problem end-to-end, quickly and precisely. As Data PMs, the goal becomes ensuring that problems are solved consistently, across teams and over time. The shift is from delivering a solution to designing a system of reusable solutions.

This introduces new trade-offs:

• reusability over speed

• consistency over local optimisation

• maintainability over immediacy

What works once must now work everywhere.

Formalising your impact and business knowledge

Another shift is the necessity to document :

• business understanding in order to enable others to challenge you

• data understanding in order to pass your knowledge to others

• your own product to enable its discovery in details

• the engagement you take towards your customers

An important part of Data Product Manager impactful deliverables is the outcomes of their data discovery. What needs to be documented ? How ? When is it maintained ?

Anna lists :

As an analyst you build a bespoke solution end to end and your job is speed and precision. As a Data PM you now have to think about scale, reusability, cost, observability, maintenance, efficiency or even discoverability.

4/ Governance teams

Data Steward to Data Product Managers, is this shift straightforward? In several companies, data stewards are in charge of data modelling and business understanding, so they sometimes think that they are already doing the work.

From control to enablement

In order to move from governance to product, governance practitioners need to rethink their role from the perspective of the user.

Models, rules, validations shape how data is experienced.

Their role is no longer: “How do we create standards to improve understanding?” but: “How do we create trust without creating unnecessary friction?”.

Approaches such as non-invasive data governance, as defined by Robert S. Seiner, provide a useful direction. They focus on supporting decision-making rather than restricting it.

Becoming user-centric

From a product perspective, a data product is an experience of use.

The role is no longer to define rules in isolation, but to integrate them into how the product is built. In that sense, governance becomes a design discipline.

You are not controlling usage. You are shaping how the product behaves so that the right usage becomes the natural one.

5/ Engineering teams

Gaëlle has often seen Product Management perceived as “bullshit” or disconnected from real work by data engineers. A large part of the role involves discussing semantics, strategy and intent, which are areas that can feel distant from implementation.

Yet this is precisely where the opportunity lies. Product thinking creates the link between micro-level decisions and the big picture. It provides the context that allows engineering work to make sense beyond the immediate task.

From implementation to problem framing

For engineering teams, the gap is not technical but contextual.

Understanding business problems, user needs and organizational priorities becomes essential to building the right solutions. The nature of the work shifts: instead of implementing clearly defined requirements, engineers contribute to defining what should be built in the first place.

This introduces a fundamental change in perspective. The question is no longer: “What is the most interesting technical solution?” but: “What is the most relevant problem to solve next?”

User-centricity becomes the anchor for decision-making.

Deepening user understanding to scale infrastructure

This shift is particularly powerful because data engineers already know how to scale systems. What changes is not their ability to build but the way they frame what they build.

By combining their expertise in scalability with a deeper understanding of users and context, they are able to design systems that not only perform but remain relevant over time.

The transition toward data product thinking does not replace engineering strengths: it amplifies them. It connects long-term scalability with meaningful problem-solving.

Will we need data PM tomorrow?

If ambiguity is what Data PMs manage, a question could be: what happens when systems start managing ambiguity themselves?

AI has created the urge for clear and unambiguous definitions everywhere. Because when yesterday a newcomer was asking questions during its onboarding, you could brush it off, give the information and move on. Now if you want to perform, it forces you to think about architecture, semantic and context.

What we love about that is that it enables the externalisation of judgment: the part of the Data PM’s work that previously required a person in the room to say “these two definitions aren’t actually compatible.”.

So AI has created the urge and is helping define the problem. Is it a reduction of the role then?

No, it validates the need for data product managers: systems don’t resolve ambiguity but they make it visible faster. Which means the rate at which ambiguity surfaces accelerates and the demand for someone capable of structuring a response to it accelerates with it.

The Data PM’s work doesn’t get smaller as tooling improves. It gets more precise and feels more urgent. Faster systems will surface ambiguities faster, with less time to absorb the friction before it becomes a crisis.

What changes is the level at which the role operates. Less time spent naming the inconsistency. More time spent designing the structures that determine how the organization responds when the next one appears. From resolving ambiguity case by case, to building the conditions under which ambiguity can be resolved without everything depending on one person in the room.

That is a harder job than the current definition suggests. And a more important one.

The organisations that understand this will stop treating Data PM as a coordination role. They’ll start treating it as a structural function that needs real authority, because the system will always tend back toward ambiguity, and someone has to be accountable for that tendency.