Data Product Managers Bridge the Gap
Why I think most large companies need at least one PM on the data team
Your data team has everything on paper: smart people, solid tech stack, budget for tools. But lately, in your 1-on-1s, at team lunches, and even in formal team meetings most of the team is saying the same things:
They’re overwhelmed
They don’t know if any of their work is having impact
Stakeholders keep saying the team is too slow
Meanwhile, your stakeholders? They’re also frustrated. Your CRO complained (again) that the dashboard they requested three months ago still isn’t done. Your data lead pushed back that sales changed the requirements four times and that a Salesforce migration upstream meant they couldn’t even start ingestion until last sprint.
Everyone is working hard. Everyone feels like this shouldn’t be this hard. Yet, somehow, quarter after quarter its the same song, different verse.
Data is supposed to be the “new oil” and data and AI are supposed to be transforming everything, but the day to day feels more tiring than energizing.
Why can’t we get in a better rhythm?
The Diagnosis
To get value from data the company overall needs to do two things well:
Identify opportunities where data can power insights, operations, and products
Build solutions that address those opportunities in smart, cost effective ways
Most data teams are quite good at the second part - building solutions. But the first part? Identifying the right opportunities? That’s where things start to go wrong and the ripple effects follow throughout the entire project lifecycle.
We sometimes build the wrong things, things that:
Don’t get used
Had to be built urgently and compromises had to be made
Are useful, but not the most important things
Is this sounding familiar? You’re not alone. This pattern is so common and playing out at most companies. So why is it so common, even when everyone talks about driving business outcomes with data?
The Gap
Your data team is optimized for building. They’re excellent at technical implementation, architecting scalable solutions, optimizing for performance and cost.
Your stakeholders understand their domain deeply. They know what’s painful, what’s urgent, what might help.
But between “business problem” and “technical solution” there’s a massive translation gap—and everyone is fumbling to bridge it.
Why aren’t we better at bridging that gap? How did we get here?
Here’s my best guess. It was really obvious in the internet era that businesses had a huge opportunity to extract value from data. And that there were massive technical hurdles to overcome to build the infrastructure to make this easier. Breaking down silos, faster compute, etc.
So companies hired brilliant architects, engineers, data scientists and analysts and got to work.
I think maybe what businesses didn’t quite understand - is the complexity of building with data from an organizational standpoint. Here are a few complicating factors I see over and over:
Lack of Global Understanding on What’s Possible
It’s hard to even find all the opportunities in the business.
Business leaders making investment decisions for R&D may not even realize that the customer problem they are facing could be solved with ML or that the data exists to automate that operational problem.
Meanwhile, technical teams are struggling to understand strategic business priorities and are so swamped with inbound requests they often can’t get involved in early stage strategic conversations to suggest impactful work.
So the data work may end up going to whichever group has an idea and is the loudest in demanding time from the data team rather than strategically sourced and prioritized investments of data resources.
Organizational Complexity on System Ownership
Data problems are not as self-contained as software problems.
When your mobile app team wants to build a new feature, often the context they want is in their local database or they can capture it using user input. They can minimize cross team dependencies, which speeds up delivery immensely.
The problems data teams face almost always involve multiple teams. At a minimum the tech teams that own the systems where the data is captured, the business teams asking for a deliverable, and often many other adjacent teams (infosec, legal, devops, data science, analyst, etc). That cross-team coordination complexity creates massive friction. So teams end up in more meetings gathering context and coordinating timelines and less time just building the solution.
Jumping to Solutioning
Here’s an area where I see even the best intentioned teams go wrong.
Most data teams are drawn to the profession because they love to build and solve problems with data. They love being enablers and helpers. They build strong relationships with business counterparts and together they tackle problems.
That’s all great, essential even.
The problem arises when they jump to being useful and solutioning together too quickly without exchanging enough context.
The business often does not know exactly what they want. Sometimes they do, but I can’t tell you how many meetings I’ve sat in where someone requested something and after probing for more business context I realized that wasn’t really what they needed to solve their problem.
The more discovery I do, the more often I am able to say “Well what if instead of that dashboard we:
Built a slack bot that pushes these top 5 KPIs to you every Monday so you don’t have to remember to check?
Pushed that data back to your tool so you can act on it directly and not even need to check Tableau?
Helped you get that spreadsheet connected to the warehouse so it autoupdates and you don’t have to?”
And the stakeholder says “Oh, well yeah, that would be even better, you can do that?” The magic comes from deep diving together and sharing context back and forth until we find the *right* solution to build.
It’s so easy to just be an order taker, react, respond and quickly fulfill what they are asking for. And the people we’ve hired in data teams have a bias for action and they are under pressure to move fast. So once they hear a solvable problem it’s natural to jump to *how* and not spend long enough on the “what.”
How Product Management Bridges the Gap
The gap I’ve described—between business problem and technical solution—is exactly what product management exists to fill. I’ve been asked repeatedly (externally and at my own company) if we should have product managers on the data team - and if so, why?
Look, product managers are laser focused on finding user pain points and ensuring what the team builds will address it. Without product managers, you are asking other members of the data team to take on that labor, in addition to the work of building the best solution possible.
Does your data team have the capacity to do so?
Do they have the interest in that part of the work?
Are the incentives in the org aligned to where this work is rewarded or would it be invisible load they are trying to squeeze in along their other work?
The team is overworked, so #1 is usually no. We hired for technical acumen over soft skills so while I have had some engineers who enjoy this part of the work, most would rather focus on designing and building solutions, so #2 is usually no. And #3 - I think leaders can overcome this one if they are intentional about it, but usually you are just hoping it get squeezed in there.
If you hire a product manager their whole job is about finding the right work, defining it, and prioritizing it correctly so the delivery teams can focus on execution.
Here’s another way of thinking about it:
Marty Cagan, who wrote one of the seminal books on product management (Inspired), talks about 4 risks the team must balance:
Value: Will this solution be valuable to the user it’s intended for? Will they choose to use it?
Usability: Can the user figure out how to use it?
Feasibility: Can we build this with the team and technology we have?
Business viability: Does this solution work with the various aspects of our business (legal, partners, strategy, ethics, go-to-market
You’ve hired great engineers, data scientists and analysts who together manage the feasibility risk beautifully. But what about the other risks? Product managers should own the value & business viability risk. And usability risk in data - in absence of a designer - is shared across the entire team.
So the question is rarely, “Would hiring a product manager be useful?” - of course it would! Data product managers can focus on the work nobody else is explicitly accountable for:
They make the “what” problems explicit.
Instead of jumping to solutions, they push back with questions: “What decision will this inform? What does success look like? How will we know if this works?” They turn vague requests into clear requirements before engineering time is spent.
They shield the team from lower value work.
There are always more requests than the team could ever fulfill. PMs filter, prioritize, and sometimes say no—so engineers can focus on high-impact work instead of drowning in reactive requests.
And when necessary they take trade-offs to leadership to get the business to either reprioritize or fund additional head count to support the work - instead of expecting the team to just miraculously squeeze it in. It’s hard to do that advocacy without clarity around what’s been committed to, what’s been turned down, and what sits on the fringe depending on resourcing. PMs help organize that information and put it in the hands of leaders to make decisions.
They translate in both directions.
Business stakeholders get someone who speaks their language and understands their constraints. Engineers get someone who can articulate technical trade-offs in business terms and vice versa. Less meeting time spent in translation, more time spent building.
They drive adoption, not just delivery.
Building the thing is only half the battle. PMs schedule demos, feedback sessions, ensure documentation is available, accessible and clear. They track usage, iterate based on feedback, sunset what doesn’t work, and ensure what gets built actually drives outcomes.
They connect data work to strategy. Instead of a request queue, you get a roadmap aligned with company priorities. The team can see how their work ladders up to business goals, and stakeholders understand why some things get prioritized over others.
They make that alignment clear both to the data team AND to leadership so that data work doesn’t become an invisible enabler, but is seen as a strategic investment that powers the business.
When someone owns this work explicitly, the symptoms you’re experiencing—overwhelm, lack of impact, misaligned expectations—start to resolve. Not overnight, but quarter over quarter, you’ll notice the rhythm getting better.
Where to Learn More
If you’re curious about what data PMs actually do day today, I’ve written about it in more detail:
You can also follow some fellow Data PMs here on Substack like my friend Nick (who writes a lot about driving ROI with data products) and a few other data PMs I’ve come across recently:
If you know of others out there who I should follow, let me know in the comments - I’m always trying to find all the data product people I can to follow and learn from.
What an amazing article, thank you Anna for putting this all in words so eloquently! I'll bookmark this so I can share it with all my clients :D
Hi! I belong to the subset that work outside of enterprise data teams and literally monetize data (sell it as a core product). In this space, Adam Thomas is awesome. See https://pivotal.substack.com/