Photo by Aidan Tottori on Unsplash
Where Data Product Managers Actually Sit: The Org Chart Question Nobody Answers
Last spring, our executive team announced a complete data org restructure. New leadership. New priorities. A beautiful slide deck showing data product managers as the bridge between engineering, analytics, and business stakeholders. What the slide deck didn’t show: who we reported to, who approved our roadmaps, or whether we had budget authority. For three months, David Ohnstad and two other data PMs operated in a reporting vacuum—writing specs that engineering deprioritized, attending stakeholder meetings where we couldn’t commit resources, and watching projects stall because nobody clarified whether we had product authority or just coordinating responsibility.
According to Gartner’s 2024 Data and Analytics Leadership Survey, 68% of organizations restructured their data teams in the past eighteen months, but only 34% defined clear decision rights for data product roles during that transition. The gap between org chart announcements and operational clarity is where data products go to die—not from bad architecture or weak use cases, but from ambiguous authority that turns every sprint planning session into a negotiation over whose priorities actually matter.
Microsoft’s recent data council announcement and IBM’s modern data team framework are driving a wave of organizational reassessments right now. Companies are asking the right structural questions: should data engineering report to IT or product? Should analytics be centralized or embedded? But they’re skipping the harder operational question: when a data product manager needs to kill a stakeholder’s pet dashboard project or prioritize infrastructure work over a new feature request, where does their authority to make that call actually come from?
Why Reporting Structure Directly Determines Delivery Velocity
Data product management isn’t just product management applied to data. It’s a fundamentally different accountability model because the “user” is often internal, the value is indirect, and the success metrics aren’t MAU or conversion rates—they’re adoption of insights, reduction in decision latency, or prevention of bad business calls that never happened. When a Data Product Management role reports to engineering, the incentive structure rewards infrastructure stability and technical debt reduction. When it reports to business operations, the incentive is stakeholder satisfaction and request throughput. When it reports to a dedicated data organization, the risk is building elegant solutions nobody asked for.
None of these models is inherently wrong. But the failure mode is always the same: a data PM stuck between competing incentive structures with no clear escalation path when priorities conflict. According to McKinsey’s 2023 State of Data Infrastructure report, organizations with clearly defined data product ownership—measured by documented decision authority and budget allocation, not just org chart placement—ship data products 2.3 times faster than teams where data PMs coordinate but don’t control roadmaps. The difference isn’t talent or tooling. It’s whether the PM can say “no” to a VP’s feature request without triggering a week of stakeholder mediation.
Here’s the tell: if your data product manager can’t independently decide to deprecate a dashboard that three people use, they’re not managing a product—they’re managing stakeholder relationships. That’s a valid role, but it’s not product management, and calling it that creates confusion about accountability when projects fail. IBM’s structure framework correctly identifies that modern data teams need product thinking, but it stops short of the uncomfortable truth: product thinking without product authority is just well-organized ticket management.
The Authority Layer Model: Four Questions That Define Operational Clarity
The Authority Layer Model is a diagnostic framework for assessing whether a data product management role has genuine product authority or coordination responsibility dressed up as product ownership. It’s built on four specific questions that reveal where decision-making power actually lives—not where the org chart says it should live, but where it operates day-to-day when priorities conflict and resources are constrained. Each question maps to a different layer of product authority, and the answers determine whether a data PM can ship products or just facilitate conversations about shipping them.
Layer One: Roadmap Control. Can the data PM independently reprioritize the next sprint without stakeholder approval? Not “do they get input”—everyone gets input. The question is: if engineering capacity drops by 30% next quarter, does the data PM decide what gets cut, or does that decision escalate to a steering committee? If it escalates, the PM is a coordinator. If they own the call and justify it afterward, they’re managing a product. David Ohnstad has worked in both models. The difference in delivery velocity is measurable: coordinated roadmaps ship 40% slower because every prioritization shift triggers a negotiation cycle with stakeholders who have veto power but no accountability for outcomes.
Layer Two: Resource Allocation Authority. Can the data PM dedicate engineering capacity to technical debt or infrastructure work that has no visible stakeholder deliverable? This is the clearest test of whether product management exists or whether the role is just stakeholder request aggregation. In organizations where data PMs report to business operations, the answer is almost always no—because the incentive structure rewards stakeholder satisfaction, and “we’re refactoring the ETL pipeline” doesn’t satisfy anyone. In organizations where data PMs report to engineering, the answer is often yes, but the risk flips: infrastructure work crowds out user-facing features, and the data product becomes technically excellent but operationally irrelevant. The correct model: the data PM controls the trade-off and documents the business case for both paths.
Layer Three: Deprecation Rights. Can the data PM sunset a data product or dashboard that stakeholders still use but that doesn’t justify its maintenance cost? This is where organizational courage shows up. Every company has zombie dashboards—built for a one-time decision, maintained for years because somebody senior asked for it once, consuming engineering hours every time the underlying schema changes. A data PM with product authority can run a cost-benefit analysis, notify stakeholders of deprecation, and execute the shutdown. A data PM without authority escalates the decision, schedules a meeting, builds a deck to justify the sunset, and watches the project stay alive because nobody wants to be the executive who killed someone else’s tool. According to Harvard Business Review’s 2023 analysis of data-driven culture, organizations that give data PMs to deprecate low-value products see 31% higher engineering efficiency because teams stop maintaining solutions that nobody depends on.
Layer Four: Budget Ownership. Does the data PM control the budget for their product area, or do they request funding for each initiative? This is the ultimate test. Product managers who control budgets make trade-offs. Product managers who request budgets make proposals. The difference matters because every significant data product decision is a resource allocation problem: build the new feature or fix the data quality issue, invest in user training or expand coverage to a new data source, buy the vendor tool or build in-house. When budget authority sits outside the data PM role, these trade-offs escalate—and every escalation adds cycle time, diffuses accountability, and increases the odds that decisions get made based on stakeholder volume rather than product strategy.
Why This Framework Matters: Mapping Authority to Reporting Structure
The Authority Layer Model exposes a pattern most organizations miss: reporting structure doesn’t just influence authority—it predetermines which layers are accessible. A data PM reporting to engineering typically has strong Layer Two and Layer Four authority (resource allocation and budget control within their domain) but weak Layer One and Layer Three (roadmap control and deprecation rights are often shared with business stakeholders). A data PM reporting to business operations usually has strong Layer One authority (close alignment with stakeholder priorities) but weak Layer Two and Layer Four (engineering capacity and budget require negotiation with IT or platform teams). A data PM in a standalone data organization can have all four layers—but only if leadership explicitly delegates them and defends those boundaries when conflicts arise.
Here’s what David Ohnstad has seen repeatedly: companies announce a data product management function, hire strong PMs, and then wonder why delivery is slow. The diagnosis is almost always the same. The PMs have title and responsibility but lack one or more authority layers. They write roadmaps that get overridden by stakeholder requests. They propose technical debt sprints that get deprioritized for feature work. They identify dashboards to sunset and watch those dashboards survive because a VP asked for it three years ago and nobody wants to have that conversation. The failure isn’t the PM’s skill—it’s that the organization designed a role with accountability but no control, and that structural flaw makes every project harder than it needs to be.
The Practitioner Reality: When the Org Chart Doesn’t Match the Work
Two years ago, David Ohnstad joined a data product team where the org chart showed data PMs reporting to a Chief Data Officer with a dotted line to engineering leadership. Clean structure. Clear escalation path. Except in practice, roadmap decisions required sign-off from both the CDO and the VP of Engineering, who had different priorities and didn’t meet regularly. Sprint planning became a negotiation between two executives who were each optimizing for different outcomes: the CDO wanted stakeholder-facing analytics dashboards that demonstrated business value, and the VP of Engineering wanted data infrastructure stability that reduced on-call burden for the platform team.
The result: every sprint planning cycle turned into a two-week mediation process where David and the other data PMs built two roadmaps—one prioritized for stakeholder visibility, one prioritized for technical debt reduction—and presented both in separate meetings, hoping the executives would align before the sprint started. They rarely did. So the compromise became splitting capacity: half the sprint on stakeholder features, half on infrastructure work. Sounds reasonable. In practice, it meant neither goal got adequate focus. Stakeholder features shipped with known data quality issues because there wasn’t time to fix the underlying pipeline problems. Infrastructure projects stalled at 60% complete because stakeholder requests pulled engineers off mid-sprint.
The breaking point came during a quarterly planning session when a senior VP requested a new executive dashboard tracking customer health scores across product lines. Reasonable request. Valuable use case. But the underlying customer data model was inconsistent across systems, and building the dashboard without fixing the data model would produce numbers that looked precise but were directionally wrong in about 30% of cases. David escalated the issue: we can build this dashboard in six weeks, but the data quality problems mean the numbers won’t be reliable until we invest two months fixing the upstream data sources. The VP’s response: “I need this for the board meeting in eight weeks. Build it with the data we have, and we’ll fix the quality issues later.”
That’s the moment the org chart failed. David didn’t have the authority to say no. The CDO wanted to demonstrate responsiveness to executive stakeholders. The VP of Engineering didn’t want to block a board-level request. So the dashboard shipped. It looked great in the board meeting. And three months later, when the customer health scores started driving resource allocation decisions that didn’t match what the frontline teams were seeing, the data team spent six weeks debugging why the numbers were wrong—a problem everyone knew existed at launch but nobody had the authority to prioritize fixing before the dashboard went live. The lesson wasn’t about better stakeholder management or clearer communication. The lesson was structural: a data PM without the authority to kill a bad project is just a coordinator with a product title, and coordinators can’t protect the organization from decisions that feel urgent but create long-term data debt.
The Contrarian Claim: Stop Hiring Data Product Managers Until You Answer the Authority Questions
Most organizations approach data product management hiring backward. They write a job description, run interviews, evaluate candidates on product sense and technical fluency, make an offer—and then figure out reporting structure and decision rights after the person starts. This is why so many strong data PMs churn out within eighteen months. The problem isn’t the person. The problem is that the organization hired for a product role but designed a coordination function, and the gap between the job description and the operational reality becomes obvious the first time a roadmap conflict escalates and the PM realizes they don’t control the outcome.
Here’s the contrarian claim: if you can’t answer all four Authority Layer questions before posting the job description, you’re not ready to hire a data product manager—you’re ready to hire a program manager or a business analyst with stakeholder communication skills. All three roles are valuable. But only one of them is accountable for product outcomes, and that accountability requires authority. Posting a data PM role without defining roadmap control, resource allocation rights, deprecation authority, and budget ownership is the organizational equivalent of asking someone to be responsible for shipping a product but giving them no control over what gets built, when it ships, or whether it gets maintained. That’s not a product role. That’s a coordination role with accountability but no power, and it burns out good people fast.
According to Gartner’s 2024 Data and Analytics Leadership Survey, 54% of data product managers report that their biggest operational challenge isn’t technical complexity or stakeholder alignment—it’s lack of decision-making authority when priorities conflict. The survey didn’t ask about churn, but David Ohnstad’s network data tells the story: data PMs who leave within two years almost always cite the same issue. They were hired to manage products but operated as project coordinators, and the frustration of being accountable for outcomes they couldn’t control became unsustainable. Organizations that define authority layers before hiring—and document them in writing, not just in org chart slides—retain data PMs at twice the rate of organizations that treat authority as something to “figure out as we go.”
The fix isn’t complicated, but it requires leadership courage. Before hiring a data product manager, answer these questions in writing and share the answers with candidates during the interview process: Who approves the roadmap? Can the PM reprioritize independently, or does every shift require stakeholder sign-off? Does the PM control engineering capacity, or do they request it from a shared pool? Can the PM sunset low-value data products without executive approval? Does the PM own a budget, or do they submit funding requests for each initiative? If you can’t answer these questions clearly, delay the hire until you can—because ambiguity at this layer doesn’t get resolved through better communication or stronger stakeholder relationships. It gets resolved by somebody quitting and the organization reposting the role with the same structural problems still embedded.
How Evolving Data Structures Create Career Pathways
The organizational changes happening right now—driven by AI/ML platform maturation and distributed data architecture adoption—are creating a genuine career transition pathway for technical professionals who want to move into product leadership but don’t come from traditional product backgrounds. David Ohnstad’s biology degree and MS in data analytics weren’t traditional PM credentials, but they turned out to be exactly the right foundation for data product work: research training taught him to ask better questions, and technical fluency gave him the credibility to challenge engineering assumptions and push back on stakeholder requests that didn’t align with data architecture reality.
As more organizations adopt the structures Microsoft and IBM are piloting—data councils, embedded analytics teams, cross-functional data product squads—the profile of a successful data PM is shifting. It’s less about classical product management experience and more about the ability to operate at the intersection of technical depth and business context. That creates opportunity for data engineers who want to move closer to strategy, analysts who want to own outcomes instead of just producing reports, and technical program managers who are ready to take on decision-making authority instead of just coordinating across teams. But only if organizations define what product authority actually means in a data context—because without that clarity, the role becomes a trap for people who thought they were stepping into product leadership but ended up in a coordination function with no path to the outcomes they were hired to deliver.
What is the difference between a data product manager and a data program manager?
A data product manager owns outcomes, controls roadmap prioritization, and has authority to make trade-offs between stakeholder requests, technical debt, and infrastructure investments. A data program manager coordinates across teams, tracks delivery milestones, and facilitates stakeholder alignment but typically doesn’t have independent decision rights over what gets built or when projects get deprioritized. Both roles are valuable, but only the product manager is accountable for whether the data solution drives the intended business results.
How do you structure reporting for data product managers in a matrixed organization?
The most effective model is a solid-line report to a Chief Data Officer or VP of Data with documented decision authority over roadmap, budget, and resource allocation, plus a dotted-line relationship to engineering leadership for technical alignment. The critical success factor is written clarity on which decisions the data PM owns independently and which require escalation. Without that documentation, matrixed structures default to consensus-driven roadmaps where every prioritization conflict triggers a negotiation cycle that slows delivery.
Why do data product managers churn faster than traditional product managers?
Data PMs churn primarily due to authority ambiguity—they’re hired with accountability for product outcomes but operate in structures where roadmap control, resource allocation, and deprecation rights are shared or undefined. When every strategic decision requires stakeholder negotiation and PMs can’t independently prioritize technical debt or kill low-value projects, the role becomes coordination work with product accountability. That gap between responsibility and authority is unsustainable for people hired to manage products, and it drives churn within eighteen to twenty-four months.
Two Takeaways and One Question to Ask Your Leadership
For practitioners navigating a data org restructure right now: don’t accept the role or the reporting change until you have written answers to the four Authority Layer questions. Not verbal assurances. Not “we’ll figure it out.” Written documentation of who controls roadmap prioritization, resource allocation, deprecation decisions, and budget. If leadership can’t provide that clarity before you start, the ambiguity won’t resolve itself—it will become your daily operational reality, and you’ll spend more time negotiating authority than shipping products.
For leaders designing data product management functions: define decision rights before you define the org chart. The structure matters less than the clarity. A data PM reporting to engineering can succeed if they have explicit authority over roadmap and stakeholder prioritization. A data PM reporting to business operations can succeed if they control resource allocation and deprecation rights. But no reporting structure works if authority is ambiguous, because ambiguity defaults to consensus, and consensus-driven roadmaps optimize for stakeholder satisfaction rather than product outcomes. You can see how this connects to the broader challenge of making technical decisions in environments where clarity and craft discipline matter, whether that’s in product strategy or in a woodworking shop where measuring twice isn’t optional.
Here’s the question to ask yourself: if your data product manager came to you tomorrow and said they need to deprecate three dashboards that executives requested two years ago but nobody uses anymore, would they have the authority to execute that decision—or would it trigger a stakeholder review process that takes six weeks and probably results in keeping the dashboards alive? Your answer to that question tells you whether you have a product management function or a coordination function with a product title. And if the answer makes you uncomfortable, that discomfort is the starting point for building the structure your data team actually needs.
David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Follow his work at github.com/davidohnstad40-netizen.
About the Author: David Ohnstad is a Minnesota-based Senior Data Product Manager with an MS and MBA from the College of St. Scholastica. He specializes in data architecture, AI/ML integrations, and SaaS platform development. Outside work, he builds furniture and hikes Duluth’s trails. Find his work at davidohnstad.com and github.com/davidohnstad40-netizen.
