Most product management frameworks were built for consumer software. Clean user flows. Measurable conversion funnels. A/B tests with statistically significant sample sizes. Metrics that move in response to product changes within days or weeks.
Data-heavy industries don't work like that.
In industries like financial services, healthcare, logistics, or the promotional products ecosystem, the data is complex, the relationships between data points are non-obvious, and the feedback loops are long. A product change might not show up in the metrics for months. A data quality issue might not surface until it causes a real problem.
In these environments, the PM's job is fundamentally different.
What Changes in Data-Heavy Environments
In a consumer app, the PM's job is largely about prioritization and communication: deciding what to build and aligning the team around it.
In a data-heavy environment, the PM has to do something harder: understand the data well enough to know what questions to ask, what signals to trust, and what decisions the data actually supports.
This requires a different kind of fluency. Not the ability to write SQL queries or build data pipelines: that's the data engineer's job. But the ability to look at a data model and understand what it's actually measuring, to look at a metric and understand what it's actually capturing, and to look at an analysis and understand where the assumptions are buried.
The Signal Problem
In data-heavy industries, the hardest part of the job isn't building features. It's building signal.
Signal is the subset of your data that actually tells you something meaningful about what's happening in your product and your market. It's the metrics that move in response to real changes, not noise. It's the indicators that predict outcomes, not just describe them.
Most organizations have more data than they can use. Very few have more signal than they need. The PM's job is to close that gap: to work with data teams to identify which metrics actually matter, to push back on dashboards that track everything but inform nothing, and to build the feedback loops that connect product decisions to real outcomes.
The Patience Problem
Data-heavy industries also require a different relationship with time.
In consumer software, you can ship a feature on Monday and know by Friday whether it worked. In financial services or logistics, the feedback loop might be 90 days. The customer behavior you're trying to influence might only be observable quarterly.
This requires a different kind of discipline. You have to be willing to make decisions under uncertainty, hold hypotheses for longer, and resist the temptation to optimize for short-term metrics that don't reflect the outcomes you actually care about.
It also requires a different kind of communication with stakeholders: one that's honest about what the data can and can't tell you, and that builds confidence through rigor rather than false certainty.
The Actual Job
In a data-heavy industry, the PM's real job is to be the person in the room who understands both the human problem and the data system well enough to connect them.
Not the person who manages the roadmap. Not the person who runs the sprint. The person who can look at a complex data environment and say: here's what we know, here's what we don't know, here's what we need to find out, and here's how we're going to use what we learn to build something that actually works.
That's a harder job than managing a backlog. It's also a more valuable one.
What this looked like in my work
At iPROMOTEu, the real job was making supplier data usable for affiliates who had no interest in data infrastructure. The platform had rich supplier and order data that affiliates couldn't access in any meaningful way. My job was to translate that data into decisions: which suppliers to prioritize, which product categories were trending, which orders needed attention. The AI Intelligence Platform was the output of that translation work.
Read the full case study: AI Intelligence Platform: iPROMOTEu
