Need smarter insights in your inbox? Sign up for our weekly newsletter to get only the things that matter to enterprise AI, data and security leaders. Subscribe now
Over the past decade, businesses have spent billions on data infrastructure. Petabyte-scale warehouse. Real-time pipeline. Machine Learning (ML) platform.
Still, if you ask what operations will lead the reason for the increase in churn last week, you could get three competing dashboards. When you ask for funding and adjust the performance of your overall attribution system, you hear, “it depends on who you ask.”
In a world owned by dashboards, one truth continues to emerge. Data is not an issue. It’s product thinking.
The quiet collapse of “data as a service”
For years, the data teams operated like internal consultants – reactive, ticket-based, hero-driven. This “Data as a Service” (DAAS) model was fine if the data demands were small and the stakes were low. However, once companies became “data-driven,” the model was destroyed under the weight of its own success.
Take Airbnb. Before the launch of the metric platform, the Product, Finance and OPS teams pulled out their own versions of metrics, including:
- Night reservation
- Active User
- Available list
Even simple KPIs vary depending on the filter, source, and who was asking. In the leadership review, different teams presented different numbers.
These are not obstacles to technology. They are product failures.
result
- Data Distrust: Analysts are the second guess. The dashboard has been abandoned.
- Human Routers: Data scientists spend more time explaining inconsistencies than generating insights.
- Redundant pipeline: Engineers rebuild similar datasets between teams.
- Decision Drag: Leader delays or ignores actions due to inconsistent input.
Because data trust is a product issue, not a technical issue
Most data readers believe there is a data quality issue. However, if you look closely, you will find a data trust problem.
- Your experimental platform says that features hurt retention, but product leaders don’t believe it.
- The OPS sees dashboards that contradict their living experiences.
- Two teams use the same metric name, but use different logic.
The pipeline is working. SQL is healthy. But no one trusts the output.
This is a product failure, not an engineering failure. Because the system is not designed for ease of use, interpretability, or decision-making.
Input: Data Product Manager
New roles have emerged across top-level data product managers (DPMs). Unlike Generalist PMS, DPMS operates on fragile, invisible, and trans-working terrain. Their job is not to ship dashboards. It’s about ensuring that the right people get the right insights at the right time.
However, DPM does not plumb data into the dashboard or curate tables. The best goes further: they ask, “Is this actually helping someone to do their job better?” They define success in terms of outcome rather than in terms of output. “Did this be shipped?” But “Has this significantly improved the quality of someone’s workflow and decision-making?”
In reality, this means:
- It’s not just about defining users. Observe them. Ask them how they believe the product will work. Sit by them. Your job is not to ship data sets. It’s about making our customers more effective. It means a deeper understanding of how products fit into the real-world context of their work.
- Treat them like your own standard metrics and APIs – versions, documentation, governance – and make sure they are tied to the consequential decisions, such as unlocking a $10 million budget or launching a Go/No-Go product.
- It builds internal interfaces such as feature stores and cleanroom APIs, not as infrastructure, but as real products with contracts, SLAs, users, and feedback loops.
- Say no to sophisticated but unrelated projects. Data pipelines that the teams don’t use are technical debt, not advancements.
- Designed for durability. Many data products fail from vulnerable systems rather than from bad modeling: undocumented logic, flake-like pipelines, shadow ownership. Build on the assumption that your future self, or your exchange will appreciate you.
- Resolve horizontally. Unlike domain-specific PMS, DPMs need to zoom out constantly. The Lifetime Value (LTV) logic of one team is the budget entry of another team. A seemingly minor metric update can have secondary results across marketing, finance and operations. It’s my job to manage that complexity.
In businesses, DPM is quietly redefining how internal data systems are built, governed and adopted. They are not there to clean the data. They are there to make the organization believe it again.
Why did it take so long?
For years, we mistaken activities for progress. Data engineers have built the pipeline. Scientists have built the model. Analysts have built a dashboard. But no one asked: “Will this insight actually change business decisions?” What’s worse, we asked, but none of us owned the answer.
Executive decisions are currently via data
In today’s businesses, almost all major decisions (budget shifts, new launches, organizational restructuring) go through the data layer first. However, these layers are often not owned:
- The metric version used in the last quarter has been changed, but I don’t know when or why.
- The experimental logic varies between teams.
- The attribution models contradict each other, each contradicting plausible logic.
DPMS does not own a decision – they own an interface that makes decisions condemnable.
DPM ensures that metrics are interpretable, assumptions are transparent, and tools are consistent with the actual workflow. Without them, decision paralysis becomes the norm.
Why this role accelerates in the age of AI
AI does not replace DPMS. It makes them essential:
- 80% of the AI project efforts are still spent on data preparation (Forrester).
- Cost of garbage input compounds as a large language model (LLMS) scale. AI won’t fix bad data – amplifies it.
- Regulatory pressures (EU AI Act, California Consumer Privacy Act) drive organizations to treat product systems strictly with their products.
DPM is not a traffic coordinator. They are architects of the foundations of trust, interpretability and responsible AI.
So what now?
If you are a CPO, CTO, or data manager, ask:
- Who owns a data system that enhances our biggest decisions?
- Are internal APIs and metrics versions, discoverable and governed?
- Do you know which data products are employed and which quietly undermine trust?
If you can’t answer clearly, you don’t need any more dashboards.
You need a Data Product Manager.
Seojoon Oh is Uber’s Data Product Manager.
