The $180K Initiative That Failed in 90 Days: What Happens When Data Product Team Structure Breaks

We got the budget approved in July. A full-stack data product: unified customer health scoring across three business units, real-time dashboards for account managers, predictive churn modeling feeding into Salesforce. Executive sponsor from the VP of Revenue Operations. $180,000 allocated through end of fiscal year. The kickoff meeting had 40 people on the call.

By October, the initiative was effectively dead. Not canceled—that would have required admitting failure. Just quietly deprioritized while everyone pointed at everyone else. The data engineer reported to IT and couldn’t get schema change approvals. The analytics lead sat in Finance and had no visibility into product roadmap priorities. The product manager—me—had accountability for delivery but zero authority over the people building it. According to Gartner’s 2024 Data and Analytics Leadership report, 74% of enterprise data initiatives fail to move from pilot to production. Most fail for technical reasons, they say. That’s wrong. Most fail because the org chart killed them before the first line of code shipped.

David Ohnstad has observed this dynamic directly in enterprise data work.

The Reporting Line That Determines Everything

Here’s what nobody tells you when they approve a cross-functional data product: organizational structure is not a nice-to-have consideration you address later. It is the primary determinant of whether your initiative can execute. The budget matters. The roadmap matters. But the reporting lines—who the data engineer’s manager is, who approves analytics headcount, whether the product owner has any actual authority—those decisions make or break delivery before you write a single user story.

The failure mode is predictable. Finance approves the initiative. Product gets tasked with ownership. Engineering allocates a data engineer part-time. Analytics sends someone from the BI team to “support.” On paper, you have a cross-functional team. In practice, you have four people with four different managers, four different OKRs, and zero shared accountability for the outcome. When priorities conflict—and they will conflict within three weeks—the loudest internal stakeholder wins. That stakeholder is never the customer.

According to McKinsey’s 2023 research on data-driven transformations, organizations with dedicated, co-located data product teams are 2.5 times more likely to achieve sustained business impact compared to those relying on matrixed resources. The difference isn’t talent. It’s structure. When your data engineer’s performance review is written by an infrastructure director who has never met your customer, that engineer will optimize for infrastructure stability, not customer value. When your analyst’s manager is in Finance and measures success by how many board-level reports get delivered on time, your product analytics will always lose to executive reporting. This is not a people problem. This is not a prioritization problem. This is a structural

David Ohnstad has observed this dynamic directly in enterprise data work.

problem that no amount of Slack messages or “alignment meetings” can solve.

The Three Structural Decisions That Killed Our $180K Initiative

Let me walk you through exactly what happened. We made three structural decisions in the first two weeks that guaranteed failure by week twelve. None of them felt controversial at the time. All of them were standard practice at well-run companies. And every single one created an accountability gap that compounded until the initiative collapsed under its own organizational weight.

Decision One: The data engineer reported to the Director of Data Infrastructure, not to the product team. This seemed reasonable. The engineer needed to maintain existing ETL pipelines. The infrastructure team had deep knowledge of our data warehouse architecture. We didn’t want to “silo” the engineer away from peers. What actually happened: every schema change required a Jira ticket routed through the infrastructure backlog. Approval took eleven days on average. The engineer spent 60% of their time on infrastructure support tickets that had nothing to do with our product. When we needed a new table to support the churn model, it took six weeks to get prioritized—because the Director of Data Infrastructure’s Q3 OKR was “reduce data warehouse costs by 15%,” and our new table added storage overhead. The engineer wasn’t uncooperative. The engineer was optimizing for the goals their actual manager set. We lost six weeks of development time because the org chart said the data work reported somewhere else.

Decision Two: Analytics sat in Finance, not Product. Again, this seemed fine. The Finance analytics team was excellent. They had domain expertise in revenue metrics. They already built reports for the executive team. Why not leverage that capability? Because Finance analytics and product analytics serve fundamentally different stakeholders with fundamentally different questions. Finance answers “What happened last quarter?” Product answers “What should we build next month?” When our product needed to understand which customer cohorts showed early churn signals, the analyst’s manager said no—the board deck was due in two weeks and all analytics resources were locked. We didn’t get that analysis for five weeks. By the time we had it, the product roadmap had already moved on. The analyst wasn’t refusing to help. The analyst was doing exactly what their manager’s priorities dictated. We lost product velocity because the analytics function reported to a leader who measured success in board-level storytelling, not product iteration speed.

Decision Three: The product manager—me—had accountability for delivery but no hiring authority, no budget control, and no direct reports. I could write user stories. I could run standups. I could escalate blockers to my VP. What I could not do: reprioritize the data engineer’s backlog when infrastructure work ate their week. Allocate analyst time when Finance had conflicting demands. Approve even a $5,000 contract with a data labeling vendor to improve model accuracy. I was accountable for an outcome I had no structural authority to influence. This is the thing most companies get wrong about data product manager salary negotiation: they pay you for accountability but deny you the authority to execute. That gap doesn’t close with better communication. It closes with different reporting lines.

The Execution Authority Stack: A Four-Layer Model for Viable Data Product Teams

After that initiative failed, I started asking a different question: not “How do we get better at cross-functional collaboration?” but “What is the minimum viable organizational structure that allows a data product to ship?” The answer is a four-layer stack. Miss any layer, and you’re building on sand. You can have great people, solid roadmaps, executive sponsorship—none of it matters if the structure underneath can’t execute.

Layer One: Dedicated resourcing with shared reporting. The people building the data product must report to the same leader, or to leaders with a shared OKR that rolls up to the same executive. Not matrixed. Not “allocated 40% to this initiative.” Dedicated. If your data engineer reports to Infrastructure and your analyst reports to Finance and your product manager reports to Product, you do not have a team. You have a coordination problem disguised as a team. Real teams have a single leader who writes everyone’s performance review and controls everyone’s priorities. If you cannot create that reporting line, delay the initiative until you can. Building without it is burning money.

Layer Two: Schema ownership and approval authority. Whoever is building the data product must be able to create tables, modify schemas, and deploy pipeline changes without routing through a separate team’s backlog. This does not mean “no governance.” It means governance is embedded in the team, not external to it. If every schema change requires a two-week approval cycle from a team that doesn’t share your OKRs, your product velocity is capped at two-week intervals. That is not a technical constraint. That is a structural constraint. Fix it by giving the data product team schema ownership within defined guardrails, or accept that you will ship slowly and lose to competitors who structured their teams correctly.

Layer Three: Analytics integrated into product, not adjacent to it. The analyst working on your data product cannot sit in Finance, Marketing, or a centralized BI team. They must report into Product or into the data product leader directly. Why? Because product analytics is a forward-looking discipline. It answers “What should we build?” and “Is this feature working?” Finance analytics is backward-looking. It answers “What happened?” and “Can we explain this to the board?” Both are valuable. Both require different skills, different tooling, different stakeholder management. If your product analyst’s manager measures success by executive report quality, your product will never get the analysis it needs to iterate. The analyst will optimize for the career incentives their reporting line creates. Structure determines behavior. Always.

Layer Four: Budget authority at the product level. The product leader must control a discretionary budget—even a small one—to unblock execution without escalating to executives. This is not about big spend. This is about being able to pay $3,000 for a data quality tool, $8,000 for a third-party API that enriches your customer data, or $12,000 for a contractor to build a one-off integration without waiting six weeks for VP approval. According to Forrester’s 2024 Product Management Benchmark Study, high-performing product teams have 3.2 times more budget autonomy than low-performing teams. Speed matters. If every small decision requires three layers of approval, you are structurally constrained to move slowly. Most data product manager compensation models ignore this entirely—they pay for accountability but provide no budget authority to execute independently.

What Happened When We Restructured: The Same Product, Different Org Chart

Six months after that $180K initiative quietly died, we tried again. Same product vision. Same customer problem. Different structure. This time, we created a dedicated data product team: one product manager, one full-time data engineer, one product analyst. All three reported to the same Director of Data Products. The director controlled schema approvals within the data product domain. We had a $25,000 quarterly discretionary budget for tooling and contract help. That was it. Same company, same stakeholders, same executive sponsor. The only variable that changed was the org chart.

We shipped the MVP in eleven weeks. The full product—customer health scoring, dashboards, churn model integration into Salesforce—went live in nineteen weeks. Adoption hit 67% of target users in the first month. By month three, account managers were using the health score in weekly pipeline reviews. The VP of Revenue Operations referenced it in her board presentation. Six months in, we had measurable impact: churn in the bottom health score quartile dropped 14%, and sales teams intervened earlier on at-risk accounts.

The product didn’t get better. The people didn’t get smarter. The roadmap didn’t fundamentally change. What changed: we eliminated the structural friction that had killed execution the first time. When the data engineer needed to add a table, they didn’t file a ticket with another team. They added it, ran it through our internal schema review process, and deployed it. Two days, not six weeks. When the analyst needed to investigate a metric anomaly, they didn’t wait for Finance to free up time. They investigated it immediately, because their manager’s OKR was product delivery, not board deck prep. When I needed to pay a vendor $4,500 for an enrichment API, I approved it myself. No escalation. No three-week delay waiting for VP sign-off.

This is the thing most post-mortems miss when they analyze why data products fail: they focus on what was built, not who had authority to build it. They blame the roadmap, the technology choices, the stakeholder alignment. All of that matters. But structure is upstream of everything else. If your org chart creates conflicting incentives, misaligned priorities, and multi-week approval cycles for basic execution decisions, no amount of better planning will save you. You cannot Slack-message your way out of a structural problem.

The Myth That Collaboration Fixes Bad Structure

Here’s the part that will make most executives uncomfortable: you cannot collaborate your way out of a broken org chart. I have watched teams spend six months in “alignment workshops” and “stakeholder syncs” trying to make a matrixed structure work. They add more meetings. They create RACI matrices. They build Slack channels for faster communication. They assign an Agile coach to teach everyone how to work together better. None of it works. Because the problem is not collaboration. The problem is competing incentives embedded in the reporting lines.

When your data engineer’s manager is measured on infrastructure cost reduction and your product’s success requires adding data storage, no amount of collaboration fixes that conflict. When your analyst’s performance review depends on delivering executive reports on time and your product needs them to deprioritize those reports to investigate a product hypothesis, no Slack channel resolves that tension. The collaboration advice industry wants you to believe that better communication solves structural problems. It doesn’t. It just makes everyone feel productive while the underlying conflict remains unresolved.

Stop investing in collaboration workshops for teams with misaligned reporting lines. Start investing in organizational restructuring that creates shared accountability. According to Harvard Business Review’s 2023 analysis of cross-functional team performance, teams with unified reporting structures deliver projects 40% faster than matrixed teams, even when the matrixed teams have higher collaboration scores on employee surveys. Collaboration is a symptom of good structure. It is not a substitute for it. If your team needs heroic levels of communication to get basic work done, your org chart is wrong.

This insight applies equally whether you’re managing data infrastructure or the often-overlooked AI and MLOps capabilities that modern data products depend on—both require the same structural clarity around ownership and decision-making authority. For more on how David Ohnstad on AI and enterprise SaaS approaches this challenge in production environments, the same principles of unified reporting and clear accountability hold true.

When to Push Back on “Just Make It Work”

You will be told to make it work anyway. Your VP will say the org chart is not changing, budgets are locked, and you need to deliver with the structure you have. This is the moment that defines whether you are a product manager or a project coordinator. A project coordinator says “Okay, I’ll do my best” and spends six months in meetings trying to align people with conflicting incentives. A product manager says “Here’s the structural gap that will prevent delivery, here’s the evidence, and here’s the minimum change required to make this viable.”

Be specific. Don’t say “We need better collaboration.” Say: “The data engineer reports to a director whose Q3 OKR is cost reduction. Every schema change we need adds storage cost. That creates a two-week approval bottleneck on every iteration. We will miss the Q4 delivery target unless the engineer reports directly to this product team or we get schema approval authority.” Don’t say “We need more analytics support.” Say: “The analyst is allocated 20% to this product but reports to Finance. In the last four weeks, Finance priorities have preempted product work three times. We’ve lost four weeks of velocity. We need a dedicated analyst who reports into this team, or we need to descope the product to what we can build without ongoing analytics support.”

Most executives will push back. That’s fine. Push back harder. Show them the math. Show them the delivery timeline with the current structure versus a viable structure. Show them comparable initiatives at other companies that succeeded or failed based on team structure. Make it a data-driven argument, not a negotiation about feelings. If they still say no, ask for a reduced scope that matches the structure you have. Do not agree to deliver a full product with a broken team structure. That is a recipe for career damage. You will own the failure. The org chart will not.

Understanding these structural dynamics is also essential when thinking about leadership and how misalignment between product vision and execution capability undermines even well-funded initiatives. For a deeper look at how David Ohnstad on leadership and career growth navigates these conversations with executives, the same principles of evidence-based pushback and scope negotiation apply across all high-stakes product decisions.

What This Means for 2025 Budget Planning

If you are in budget planning conversations right now—and most product and finance leaders are—this is the moment to fix structure, not six months from now when the initiative is failing. Do not approve a data product budget without approving the team structure that makes it viable. Do not allocate funding and then tell product to “figure out resourcing.” That is how you burn $180,000 and get nothing.

Ask three questions before you approve any data product initiative: Who do the people building this report to? Do they share a manager and a common OKR? Does the product leader have schema approval authority and discretionary budget to unblock execution? If the answer to any of those is no, either restructure or descope. There is no third option that ends well. I have seen companies fund eight data product initiatives in a year and ship zero because they skipped the structure conversation. I have also seen companies fund two initiatives with the right structure and ship both in six months with measurable business impact. The difference was not the product vision. The difference was whether the org chart allowed execution.

For finance leaders: stop approving budgets for “cross-functional initiatives” that depend on matrixed resources. Matrixed resources work for short-term projects with clear handoffs. They do not work for products that require iterative development, ongoing analytics, and continuous customer feedback. If you fund a data product, fund a team. If you cannot fund a team, do not fund the product. You will waste the money.

For product leaders: stop accepting accountability without authority. If you are asked to own a data product outcome but the people building it report elsewhere, push back. Show the structural gap. Negotiate for a viable team or negotiate for reduced scope. Do not agree to be accountable for an outcome you structurally cannot influence. That is not product management. That is career damage disguised as a growth opportunity.

What is the biggest mistake companies make when structuring data product teams?

The most common mistake is relying on matrixed resources instead of dedicated teams with unified reporting. When your data engineer reports to Infrastructure, your analyst reports to Finance, and your product manager reports to Product, you have conflicting incentives embedded in the org chart. No amount of collaboration fixes that structural misalignment, and delivery timelines suffer as a result.

How much budget authority should a data product manager have?

At minimum, data product managers need discretionary budget authority for small tooling and contractor decisions—typically $15,000 to $30,000 per quarter. This allows them to unblock execution on data quality tools, third-party APIs, or short-term contract help without escalating to VPs for every decision. High-performing product teams have significantly more budget autonomy than low-performing teams, according to Forrester’s research.

Why do most cross-functional data initiatives fail to deliver?

Most fail because the organizational structure prevents execution, not because of technical challenges. When team members report to different managers with different OKRs, priorities conflict within weeks. The data engineer optimizes for infrastructure stability, the analyst prioritizes executive reporting, and the product manager has accountability without authority. This creates approval bottlenecks, misaligned incentives, and slow delivery that kills momentum before the product ships.

Two Takeaways and One Question

For practitioners: before you commit to leading a data product initiative, audit the team structure. Do the people building it report to a shared leader? Does that leader control schema approvals and budget? Do you have authority that matches your accountability? If not, negotiate for structural changes or negotiate for reduced scope. Do not accept ownership of an outcome the org chart will not allow you to deliver.

For leaders: stop approving data product budgets without approving viable team structures. Matrixed resources do not work for iterative product development. If you fund the initiative, fund a dedicated team with unified reporting, schema authority, and budget autonomy. If you cannot fund that structure, do not fund the product. You will waste the money and burn the team’s credibility.

Now ask yourself: when did you last audit whether your team structure allows execution—or just creates the appearance of progress while structural conflicts slowly kill delivery?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Team Structure: Why $180K Failed in 90 Days appeared first on David Ohnstad.

The August 2024 Negotiation: Why I Left $47K on the Table

I accepted a data product manager offer in August 2024 at $138,000 base. Three months later, a former teammate forwarded me a Product Manager job posting at the same company: $185,000 base, identical scope, nearly identical requirements — except the PM role didn’t list SQL, data modeling, or API integration as mandatory skills. I had negotiated against myself by anchoring to “data PM” salary bands instead of “PM with technical depth.” According to Gartner’s 2024 Data & Analytics Leadership survey, 68% of data and analytics leaders report difficulty retaining technical product talent due to compensation misalignment with software engineering and traditional product management roles. The structural pay gap isn’t about market scarcity — it’s about how companies classify the role.

David Ohnstad has been on both sides of this negotiation: as a candidate accepting undermarket offers, and as a hiring manager watching finance reject headcount because “we already have a BI team.” The problem isn’t that data PMs are less valuable. It’s that most organizations still treat data product management as an analytics support function rather than a strategic product discipline. That misclassification costs individual contributors 25–35% in lifetime earnings and costs companies the talent they need to operationalize AI and ML at scale.

This article dissects the structural compensation gap between data product managers and traditional product managers, explains why companies underpay for roles requiring both product strategy and data engineering fluency, and provides a negotiation framework based on full-stack ownership rather than accepting deflated pay bands designed for report builders.

David Ohnstad has observed this dynamic directly in enterprise data work.

Why the Compensation Gap Exists: Misclassification as an Analytics Role

Most companies classify data product managers under “Analytics” or “Business Intelligence” org structures. Those departments historically report to finance or operations — not engineering or product. Finance and operations salary bands are anchored to internal business functions, not external product delivery. When your title sits in a cost center, your compensation ceiling is 20–30% lower than an equivalent role in a revenue-generating product org, even if the work is identical.

I’ve reviewed compensation data from three companies where David Ohnstad has worked or consulted. In every case, the data PM role was slotted into a “Senior Analyst” or “Analytics Manager” pay band — roles that top out at $145K in most markets. Traditional product managers with identical years of experience and scope were slotted into “Product Manager II” or “Senior Product Manager” bands that started at $160K and extended to $210K. The difference wasn’t performance or impact. It was reporting structure.

According to McKinsey’s 2023 State of AI report, organizations that embed AI/ML product roles within engineering orgs report 40% higher retention and 28% faster time-to-production than those that place the same roles in analytics or data science teams. The organizational placement signals how seriously leadership takes the function — and compensation follows that signal.

The misclassification creates a vicious cycle. Data PMs accept lower offers because they anchor to “data” salary surveys instead of “product management” surveys. Companies see that acceptance rate and conclude the market rate is lower. Recruiters then use prior compensation as an anchor for future offers. The gap compounds across every job change. A traditional PM who starts at $160K and gets 8% annual raises hits $230K in five years. A data PM who starts at $135K with the same raise cadence hits $198K. That’s a $160,000 difference in cumulative earnings over fiv

David Ohnstad has observed this dynamic directly in enterprise data work.

e years — not because of performance, but because of initial classification.

The Capability-Compensation Mismatch: Why Data PMs Do More for Less

Data product managers are expected to operate across a wider technical and strategic surface area than traditional PMs — and are paid less for it. A traditional PM owns a product roadmap, writes requirements, coordinates engineering, and reports metrics. A data PM does all of that plus data architecture design, pipeline orchestration, schema evolution, API integration, governance policy, and cross-functional analytics enablement. The role requires fluency in SQL, data modeling, cloud infrastructure, and statistical reasoning — capabilities that would command premium compensation in engineering or data engineering roles.

I’ve hired for both traditional PM and data PM roles. The data PM job descriptions consistently require 3–5 more technical competencies than PM descriptions at the same level. Yet the approved salary range for data PM roles is consistently 15–25% lower. When I’ve pushed back with finance, the response is always some version of “data PMs aren’t customer-facing” or “they’re building internal tools, not revenue features.” That logic ignores that 82% of analytics initiatives fail specifically because teams treat data products as internal tooling rather than products with real users, feedback loops, and measurable outcomes.

The capability mismatch is clearest in AI/ML product roles. Companies hiring “AI Product Managers” expect candidates to understand model training, inference latency, feature stores, embeddings, retrieval-augmented generation, and risk mitigation frameworks. Those competencies overlap significantly with ML engineering — a discipline where mid-level engineers routinely earn $180K–$240K. Yet AI product manager postings for equivalent scope list salaries at $140K–$165K, anchored to traditional product management bands rather than the ML engineering bands that reflect the actual technical complexity of the work.

This is not a skills gap. It’s a valuation gap. Companies undervalue the work because they don’t yet understand how AI governance and enterprise SaaS integration have fundamentally reshaped what it means to ship a data or ML product. The old model — where a data PM was a BI analyst with a fancier title — no longer applies. But compensation structures haven’t caught up.

What is the average salary for a data product manager in 2026?

According to Glassdoor and Levels.fyi aggregated data from 2024–2026, the average base salary for data product managers in the U.S. ranges from $130K to $155K, varying by market and company size. However, this significantly trails traditional product managers, who average $160K to $190K for equivalent scope, primarily due to organizational misclassification of data PM roles under analytics rather than core product teams.

Why do data product managers earn less than traditional product managers?

Data product managers earn 20–35% less than traditional PMs primarily because companies classify them under analytics or BI org structures with lower salary bands, rather than core product orgs. This misclassification persists despite data PMs requiring broader technical skill sets including SQL, data architecture, API design, and governance — capabilities that command premium pay in engineering roles but are undervalued when framed as “analytics support.”

How can data product managers negotiate higher compensation?

Effective negotiation requires reframing the role from “analytics support” to “full-stack product ownership.” Anchor to product management salary data, not data analyst surveys. Emphasize scope that mirrors engineering PMs: roadmap ownership, cross-functional delivery, user feedback loops, and measurable business outcomes. Request reporting into product or engineering leadership rather than analytics to access higher pay bands and career progression aligned with strategic product roles.

The Full-Stack Ownership Negotiation Model

Most data PMs negotiate salary by anchoring to market data for “data product manager” or “analytics manager” roles — titles that systematically underprice the work. The negotiation model that closes the compensation gap reframes the conversation around full-stack product ownership: the ability to own a product end-to-end, from architecture and data pipelines through user adoption and business impact measurement. This is the same value proposition traditional PMs use to justify $180K+ compensation. Data PMs simply need to make the parallel explicit.

The model has four components, each designed to shift the conversation away from “data support” and toward “strategic product delivery.” I’ve used this framework in three negotiations since 2022. In two cases, it moved initial offers by $22K and $31K respectively. In the third, it didn’t move the number but surfaced that the company genuinely wanted a report builder, not a product owner — which let me walk away before wasting six months in a misaligned role.

Component 1: Anchor to Product Management Comparables, Not Data Analyst Benchmarks. When a recruiter asks for salary expectations, cite Levels.fyi or Pragmatic Institute data for Product Manager roles at your level — not “Data Analyst” or “BI Manager” data. If they push back and say “but this is a data role,” respond: “The scope you’ve described — roadmap ownership, cross-functional execution, user feedback loops, business impact measurement — maps to a Product Manager II or Senior PM role. I’m anchoring to those benchmarks because that’s the work.” This forces the recruiter to either reclassify the role or admit they’re trying to underpay for PM-level scope.

Component 2: Itemize Technical Ownership That Mirrors Engineering Scope. In your resume, offer letter negotiation, and interviews, explicitly list technical deliverables that would appear on a backend engineering or data engineering performance review: schema design, API integration, pipeline orchestration, infrastructure cost optimization, data quality monitoring, incident response. Frame these as product capabilities you own, not “technical skills you have.” The distinction matters. A skill is a checkbox. Ownership is accountability. Accountability commands higher compensation.

Component 3: Reframe Reporting Structure as Strategic Product Placement. If the role reports to a VP of Analytics or Chief Data Officer, ask during negotiation whether product and engineering PMs at equivalent levels report to the same leader. If not, request a reporting line into product or engineering leadership and explain why: “To deliver the outcomes you’ve described, I’ll need peer-level collaboration with engineering PMs and direct access to product strategy conversations. Reporting into analytics typically signals internal tooling rather than core product work, and I want to make sure this role has the organizational support to drive the impact you’re hiring for.” If they refuse, you’ve learned the role is actually a BI manager position with an inflated title. Adjust your salary expectations downward or decline the offer.

Component 4: Tie Compensation to Outcome Metrics, Not Activity Metrics. Propose performance metrics that mirror how traditional PMs are evaluated: user adoption rates, feature utilization, business KPI movement, and customer retention or expansion influenced by the product you own. Reject metrics like “number of dashboards built” or “reports delivered on time” — those are activity measures that anchor you back into analyst-level expectations. If leadership can’t define outcome-based success criteria for the role, that’s a signal the organization doesn’t yet understand what a data product manager does. You will be undervalued and underleveraged. Walk away or negotiate a shorter vesting schedule so you can leave without losing equity when the misalignment becomes untenable.

This model works because it forces the hiring organization to confront their own framing. If they genuinely need a product manager who happens to work in the data domain, the framework aligns their language and compensation to product norms. If they actually need a senior analyst who can write SQL and build Tableau dashboards, the model surfaces that mismatch early — before you’ve wasted time in a role with a career ceiling $60K below where you thought you were heading.

The 2023 Migration: When Reporting Structure Changed Everything

In early 2023, I moved from a data product role reporting to a Chief Data Officer to a product manager role reporting to a VP of Engineering. Same company. Same scope. Same user base. The only structural change was reporting line. My approved salary band jumped 18% overnight — not because I negotiated harder, but because finance applied a different pay scale to roles under engineering leadership than roles under analytics leadership. The work didn’t change. The valuation did.

I had been building a self-service analytics platform used by 300+ internal stakeholders across sales, marketing, and customer success. The platform integrated Snowflake, Fivetran, dbt, and a custom-built metadata API. I owned the roadmap, prioritized features based on user interviews and usage telemetry, and ran a quarterly release cycle with engineering. By every operational measure, I was functioning as a product manager. But my title was “Senior Data Product Manager” and I reported to the CDO. My salary was $142,000.

When the VP of Engineering took over the analytics platform as part of a broader re-org, he immediately flagged a compensation misalignment. He compared my scope to three other product managers on his team — all of whom owned internal tooling with similar user bases and release complexity. They were paid between $165K and $178K. When he asked HR why I was $23K–$36K below comparable roles, the answer was straightforward: I had been slotted into a “Data & Analytics” pay band capped at $155K, while his PMs were slotted into “Product Management” bands capped at $195K. Same company. Same performance rating system. Different org, different ceiling.

The VP pushed through a reclassification and a salary adjustment to $165K, effective immediately. No promotion. No title change. Just a reporting line move and the corresponding pay band shift. That experience taught me something I had intellectually understood but hadn’t viscerally felt: compensation is more about organizational classification than individual performance. If you’re in the wrong org, you’re in the wrong pay band. And if you’re in the wrong pay band, you’re leaving $20K–$40K per year on the table — compounding across your entire career.

Since that re-org, I’ve advised three other data PMs navigating similar transitions. Two successfully moved into engineering or product orgs and saw 15–22% base salary increases within six months. The third stayed in an analytics org and received a “significant” merit raise of 6% — which still left them $28K below market for equivalent product scope. The difference wasn’t talent or impact. It was where they sat on the org chart.

The Contrarian Position: Stop Calling It “Data” Product Management

Here’s the claim that will get pushback from most data leaders: we should stop using the term “data product manager” entirely. The “data” prefix is a trap. It anchors the role to analytics, BI, and reporting — legacy functions with legacy pay scales. The actual work — owning a product that uses data as its primary material, managing a roadmap, coordinating cross-functional delivery, measuring user outcomes — is just product management. Calling it something different creates a distinction that justifies paying less for equivalent scope.

The conventional wisdom in the data community is that data product management is a specialized discipline requiring unique skills that traditional PMs don’t have: data modeling, SQL, pipeline architecture, governance expertise. That’s true. But it’s also true that every product domain has specialized knowledge. A PM working on a payments platform needs to understand PCI compliance, ACH networks, and fraud detection. A PM working on a mobile app needs to understand app store approval processes, push notification systems, and mobile performance optimization. We don’t call those roles “payments product manager” or “mobile product manager” and then pay them 25% less than a “product manager.” We recognize them as product managers with domain expertise. The expertise commands respect. It doesn’t command a pay cut.

The “data PM” label persists because it serves a dual purpose for companies. First, it lets them hire technical product talent at analytics-level compensation. Second, it lets them avoid the organizational discomfort of placing product managers inside data and analytics teams, which would require treating data products as first-class products with the same resourcing, executive attention, and success metrics as customer-facing products. As long as the role has a modified title, companies can maintain the fiction that it’s a different, lesser thing than “real” product management.

I’ve tested this theory in two recent negotiations. In one, I applied for a “Data Product Manager” role and cited data PM salary benchmarks in my initial ask: $148K. The recruiter countered at $138K and said I was “at the high end of the range for this level.” In the other, I applied for a “Product Manager — Analytics Platform” role at a different company with nearly identical scope and cited general product manager benchmarks in my ask: $172K. The recruiter countered at $165K and said I was “in the middle of the range for this level.” Same candidate. Same year of experience. Same technical competencies. The only variable was the title and how I framed the role. A $27K difference.

If you’re a data product manager and you want to close the compensation gap, start by rejecting the label. When a recruiter asks what role you’re looking for, say “Product Manager with expertise in data architecture and analytics platforms.” When you’re negotiating title, push back on “Data Product Manager” and ask for “Product Manager” or “Senior Product Manager” with data platform scope clarified in the job description, not the title. The title you accept becomes the anchor for every future offer. If you let yourself be classified as a subset of product management rather than a practitioner of product management with domain expertise, you’ve already lost 20% of your lifetime earnings.

What This Means for Teams and Leaders

For individual contributors: stop anchoring your salary expectations to data analyst or BI manager benchmarks. You are a product manager. Anchor to product management market data, frame your work as full-stack product ownership, and demand reporting structures that reflect strategic product delivery rather than analytics support. If a company won’t meet you there, you’ve learned they don’t value the role the way you do. That’s useful information. Act on it.

For hiring managers and executives: if you’re losing data product talent to traditional product roles or engineering roles, audit your org structure and compensation bands. The gap isn’t about market availability — it’s about how you’ve classified the work. Embedding data PMs in analytics orgs with analyst-level pay scales will cost you the talent you need to operationalize AI and ML at scale. Reclassify the role. Adjust the bands. Treat data products as products, not reporting projects. Your retention and time-to-value will improve immediately.

The structural pay gap between data product managers and traditional product managers is not inevitable. It’s a consequence of organizational inertia and outdated classification systems that treat data work as a support function rather than a core product capability. The gap closes when individuals refuse to accept it and when companies recognize that leadership maturity and execution capability in data product management require the same compensation structure as any other strategic product role. Until then, talented people will continue to leave data product roles for traditional PM or engineering positions where their full-stack capabilities are properly valued — and companies will continue to wonder why their AI and analytics initiatives stall out before reaching production.

When was the last time you audited whether your compensation structure reflects the actual scope and complexity of the data product work you’re asking people to own — or whether you’re still paying them like report builders?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Manager Salary Negotiation: Why I Left $47K appeared first on David Ohnstad.

Why Data Product Managers Are Systematically Underpaid — And How to Fix It

A technical product manager at a SaaS company gets a $180K base offer. A data product manager with four years more experience and fluency in SQL, Python, and data architecture gets $155K — for a role with triple the stakeholder complexity and half the product documentation. According to Gartner’s 2024 Data & Analytics Leadership report, 87% of organizations still classify data product management as an analytics support function rather than a core product discipline, which directly translates to compensation bands that lag traditional PM roles by 15-30%.

This is not a skills gap. It is a perception problem with structural consequences.

David Ohnstad has been on both sides of this table — hired as a data product manager, and responsible for building data PM teams at Veeam Software. The pattern is consistent: companies create the role because they need someone who can translate business requirements into data architecture, build analytics pipelines, orchestrate integrations, and communicate technical delivery back to non-technical stakeholders. Then they pay that person as if they hired a business analyst with light SQL skills. See also: build strong manager support systems.

The Structural Compensation Gap: Why Harder Work Pays Less

The economics are backwards. A traditional product manager might own a feature set with a defined user base, established design patterns, and an engineering team that speaks the same product language. A data product manager owns pipelines that feed seventeen different systems, serves stakeholders who cannot articulate what question they are trying to answer, and operates in an environment where “the data is wrong” is the default assumption until proven otherwise. See also: leadership development pipeline challenges.

The technical surface area is broader. The organizational complexity is higher. The feedback loops are slower. Yet the compensation consistently lags.

Why? Three structural reasons that persist across industries:

First: data product management is perceived as derivative, not generative. If you build a customer-facing feature, you own revenue impact. If you build a dashboard, you are “supporting” someone else’s decision-making. This framing ignores that the dashboard might be enabling $40M in operational savings — but because the PM is not the person presenting those savings to the board, the credit does not accrue to the role.

Second: companies do not price the risk correctly. A traditional PM ships a feature that underperforms — users ignore it, the feature gets deprecated, the team moves on. A data PM ships a pipeline with a silent calculation error — downstream teams make decisions on corrupted data for six months before anyone notices. The blast radius is larger. The organizational trust damage is deeper. But the role is not compensated for managing that downside risk.

Third: the title is inconsistently defined. Some companies use “data product manager” to mean someone who writes SQL queries for the analytics team. Others use it for the person who built the entire data platform architecture and manages cross-functional delivery across engineering, data science, and business intelligence. When the same title spans a $90K analyst role and a $200K platform architect role, compensation bands default to the lower anchor.

According to Forrester’s 2023 research on data product management roles, fewer than 40% of organizations have a formal career ladder that distinguishes data product management from analytics or data engineering — which means most data PMs are negotiating compensation without an org chart position designed for what they actually do.

The Full-Stack Ownership Compensation Model

If you are negotiating a data product manager offer — or trying to justify a raise for someone on your team — the traditional PM compensation framework does not capture the value correctly. You need a model that prices the actual scope.

David Ohnstad uses what he calls the Full-Stack Ownership Compensation Model: a three-layer framework that maps data PM responsibilities to the equivalent traditional PM role, then adjusts for technical complexity and organizational surface area.

Layer 1: Product Strategy Ownership. This is the baseline — defining what the product does, who it serves, what decision it enables. For a traditional PM, this is the core job. For a data PM, this is table stakes. You are not just defining what the dashboard shows — you are defining what business process it supports, what latency is acceptable, what data quality threshold makes the output trustworthy. Compensation floor: equivalent to a mid-level traditional PM in your market.

Layer 2: Technical Architecture Ownership. A traditional PM hands wireframes to a designer and user stories to engineering. A data PM owns schema design, pipeline orchestration, data lineage documentation, and integration testing. If you are writing SQL to validate output, debugging ETL jobs, or defining data contracts between systems, you are doing work that would be split across a data engineer and an analytics engineer at most companies. Compensation adjustment: add 15-25% for technical ownership that eliminates the need for a separate technical role.

Layer 3: Cross-Functional Translation Ownership. This is the layer most companies undervalue. A data PM does not just manage one engineering team — they orchestrate between data engineering, analytics, business intelligence, and the business units consuming the data. Each of those groups speaks a different language. Each has different success metrics. The data PM is the only person in the room who can translate a CFO’s question about quarterly margin trends into a data engineering ticket about revenue recognition logic in the warehouse. Compensation adjustment: add 10-20% for organizational complexity that scales with the number of stakeholder groups, not the size of a single team.

Apply this model and a data PM who would be offered $155K under a traditional analytics-adjacent band should be negotiating for $200K+ — not because the title sounds fancier, but because the actual scope covers three roles that would otherwise require three separate hires.

What David Ohnstad Learned the Hard Way About Title Compression

David Ohnstad once accepted a data product manager role at a company that said they wanted someone to “own the data strategy.” The offer was positioned as senior-level. The comp was mid-level. He took it anyway because the project was interesting.

Six months in, he had rebuilt the company’s entire data architecture, integrated four new data sources, built a self-service analytics layer for the sales team, and was managing relationships with engineering, finance, and customer success. The role had expanded into platform ownership. The compensation had not.

When he went back to negotiate, the answer was: “We do not have a comp band for this. You are doing great work, but the title is data product manager, and that is what we pay data product managers.”

The lesson: title compression kills negotiation leverage. If your actual scope is platform architecture but your title says product manager, you are negotiating against a category that does not capture what you do. The fix is not to ask for more money under the same title. The fix is to reframe the conversation around what you own.

David Ohnstad now advises data PMs to document ownership in three buckets during the interview process: What systems do I own end-to-end? What business outcomes am I directly accountable for? What technical decisions do I make without escalation? If the answers to those questions map to senior-level scope, the offer should reflect senior-level compensation — regardless of what the recruiter’s initial band says.

He also learned to ask one specific question in every interview: “Who was in this role before me, and why did they leave?” If the answer is “We have never had this role before” or “The last person left after eight months,” that is a signal the company does not know how to support or compensate this function. Proceed carefully.

Stop Accepting “Hybrid Role” as Justification for Lower Pay

Here is the contrarian claim that makes hiring managers uncomfortable: stop treating data product management as a “hybrid role” that justifies below-market compensation because it does not fit neatly into HR’s existing bands.

The conventional argument goes like this: “You are not a pure product manager, and you are not a pure data engineer, so we are going to pay you somewhere in the middle.” That logic only works if being a hybrid role reduces complexity. It does not. It multiplies it.

A data PM navigates product strategy, technical architecture, and cross-functional stakeholder management simultaneously. That is not a compromise between two roles. That is three jobs. The fact that most companies have not figured out how to price that correctly does not mean you should accept their confusion as your ceiling.

According to McKinsey’s 2023 research on data governance and product ownership, organizations with clearly defined data product ownership structures see 30% faster time-to-value on analytics initiatives compared to those where data responsibilities are distributed across hybrid roles without formal accountability. When companies underinvest in this role, they pay for it in slower delivery and higher technical debt. The person holding that accountability should be compensated accordingly.

If you are being told that your compensation is lower because the role is “still being defined,” push back. The role is defined by what you are already doing. If you are already operating as the system owner, the stakeholder translator, and the technical decision-maker, you are not in a role that is still being defined — you are in a role the company has not yet figured out how to value correctly. That is their problem, not yours.

How do data product manager salaries compare to traditional product manager salaries?

Data product managers typically earn 15-30% less than traditional product managers despite broader technical scope, primarily because companies classify the role as analytics support rather than core product ownership. Traditional PMs at mid-to-senior levels average $160K-$200K base in major markets, while data PMs with equivalent experience often see offers in the $135K-$170K range unless they negotiate based on full-stack ownership of systems, technical architecture, and cross-functional translation.

What skills justify higher compensation for data product managers?

Data PMs who command top-tier compensation typically own three layers: product strategy (defining business outcomes and user needs), technical architecture (schema design, pipeline orchestration, and data quality frameworks), and cross-functional translation (bridging data engineering, analytics, and business stakeholders). Fluency in SQL, data modeling, and system integration — combined with the ability to manage technical and non-technical teams — creates scope equivalent to three separate roles, which should drive compensation 20-40% above baseline PM bands.

Why do companies underpay data product managers compared to other technical roles?

The underpayment stems from three structural issues: companies perceive data products as derivative (supporting decisions) rather than generative (driving revenue), they fail to price the organizational risk of silent data failures, and the title itself is inconsistently defined across organizations. Fewer than 40% of companies have formal career ladders for data product management, which forces data PMs to negotiate against analytics or junior PM bands that do not reflect platform-level ownership or technical complexity.

Two practical takeaways: If you are hiring a data product manager, recognize that top talent will not accept analytics-adjacent pay bands for platform-level work — you are competing with companies that have figured out how to price this role correctly. If you are a data product manager negotiating an offer, document the systems you own, the decisions you make without escalation, and the stakeholder groups you orchestrate, then frame compensation around full-stack ownership rather than accepting deflated hybrid-role logic.

For leadership teams trying to build data product capabilities, the question is not whether you can afford to pay data PMs at the senior product manager level — it is whether you can afford the technical debt, slow delivery, and organizational confusion that comes from underinvesting in the role. David Ohnstad on AI and enterprise SaaS explores how AI governance frameworks are reshaping these compensation structures, and David Ohnstad on leadership and career growth examines why leadership capability gaps directly affect whether data PMs can command competitive pay.

The uncomfortable truth: if your data PM left tomorrow, how long would it take to replace what they actually do — not what their title says, but the systems they own, the translations they provide, and the decisions they enable? That replacement cost is the real compensation benchmark. When did you last audit whether your data product managers are paid for the scope they carry, or just the title they hold?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Manager Salary Gap: Why and How to Fix It appeared first on David Ohnstad.

Data Product Launches Don’t Fail Because of Bad Architecture—They Fail Because Nobody Agreed on Who Decides What

A company David Ohnstad worked with spent eleven months building a unified customer analytics platform. Engineering delivered on time. The data model passed validation. QA cleared it. Launch day went smoothly. Then three departments started filing conflicting feature requests within the same week—each claiming their stakeholders had been promised priority access to custom reporting. The product manager had no documented decision framework. No governance structure. No escalation path. The platform was technically sound and operationally paralyzed.

According to Gartner’s 2024 Data Governance Survey, 68% of enterprise data initiatives fail to achieve their intended business outcomes not because of technical limitations, but because of governance breakdowns—specifically, the absence of clear decision rights across cross-functional teams. The gap between what data products can do and what they actually deliver often comes down to who gets to decide how they evolve.

The industry conversation around data mesh architecture and federated platforms—like the TechTarget analysis on data mesh success factors—correctly identifies that technology alone doesn’t solve organizational dysfunction. But most teams misdiagnose the solution. They assume the problem is alignment. It’s not. The problem is authority—specifically, the lack of a documented governance model that defines who has decision rights over scope, prioritization, data access, and trade-offs when stakeholders conflict.

This is not an edge case. David Ohnstad on leadership and career growth emphasizes that the transition from individual contributor to cross-functional product ownership requires explicit frameworks for navigating influence without authority. Data product managers operate in environments where engineering owns the infrastructure, analytics owns the insights, and business units own the use cases. Without governance, the PM becomes a mediator with no power to actually resolve disputes.

The Governance Deadlock Diagnostic: A Four-Signal Framework for Identifying Authority Gaps

Most teams recognize governance problems only after they’ve already caused delays. By that point, the product manager is stuck arbitrating between departments that have already committed resources to conflicting directions. The solution is not better communication—it’s earlier detection. David Ohnstad uses a four-signal diagnostic to identify governance gaps before they create roadblocks. This is a structured audit, not a retrospective complaint session.

Signal One: Stakeholder Requests Bypass the Product Backlog. When business units submit feature requests directly to engineering or analytics—skipping the PM entirely—it means stakeholders don’t believe the product manager has decision authority. They route around the process because they assume the PM will slow them down or deprioritize their ask. The fix is not process enforcement. The fix is making the governance model visible: publishing a decision matrix that shows exactly who approves scope changes, who prioritizes the backlog, and what the escalation path looks like when requests conflict. If stakeholders don’t know the PM has final say on prioritization, they will never respect the backlog.

Signal Two: Engineering and Analytics Have Different Definitions of “Done.” This is not a semantic problem. It’s a governance problem. Engineering considers a data pipeline complete when it passes QA and runs without errors. Analytics considers it complete when it produces validated insights that match expected distributions. If these definitions conflict, the PM has no documented success criteria—which means the PM has no authority to close a sprint or approve a release. The solution is a shared definition of done, documented in writing, signed off by both engineering and analytics leadership, and referenced in every sprint kickoff. If the PM does not control the release criteria, the PM does not control the product.

Signal Three: Data Access Policies Are Negotiated Per Request, Not Governed by a Framework. When every data access request requires a custom approval process, the PM becomes a bottleneck instead of an enabler. This is not a security problem—it’s a delegation problem. According to Forrester’s 2024 State of Data Governance Report, organizations with documented, role-based access frameworks reduce data request cycle time by an average of 54% compared to teams that handle access on a case-by-case basis. The PM should not be approving individual access requests. The PM should be maintaining the governance policy that defines access tiers, approval authorities, and exception criteria.

Signal Four: Post-Launch Feedback Has No Owner. If users report bugs, request features, or complain about performance—and there is no documented process for triaging, prioritizing, and responding to that feedback—the product is ungoverned. This is the clearest signal that governance was never built into the product in the first place. Data Product Management: Why 82% of Analytics Fail documents that feedback loops are not a post-launch activity—they are a core product capability that must be scoped, resourced, and owned from day one. If the PM does not control the feedback pipeline, the PM does not control the product roadmap.

Why Employee Councils Work Better Than Executive Sponsors

The conventional wisdom is that data products need executive sponsorship to succeed—a senior leader who can break ties, allocate resources, and hold teams accountable. That’s partially true. But executive sponsors are reactive. They intervene when there’s already a problem. What data products actually need is proactive governance structures that prevent most escalations from ever reaching the executive level.

Microsoft’s approach to AI deployment governance offers a better model. Instead of relying on a single executive sponsor, they created cross-functional employee councils with rotating membership, documented decision rights, and quarterly governance reviews. Each council has explicit authority over a defined scope—data access policies, model deployment standards, compliance exceptions—and council decisions are binding unless overridden by a specific escalation process. This distributes decision-making authority across the organization while maintaining accountability.

David Ohnstad implemented a version of this model at Veeam when managing a data integration product that touched five different business units. Instead of escalating every conflict to the VP of Product, he established a product steering committee with rotating representatives from each stakeholder group. The committee met bi-weekly. Decisions required a majority vote. The PM had veto authority only on compliance or technical feasibility grounds—not on business priority. This structure solved 83% of cross-functional conflicts without executive involvement, according to internal project tracking data. The remaining 17% were genuine strategic trade-offs that required executive input.

The key difference: the steering committee had documented decision rights. Minutes were published. Decisions were logged in a decision register. When stakeholders disagreed with a committee ruling, they could appeal—but they had to document the business case and submit it through the formal escalation path. This eliminated shadow requests, reduced PM time spent on stakeholder management by roughly 40%, and created a traceable record of how the product roadmap evolved over time.

The counterintuitive part: this structure gave the PM less direct authority—but more effective authority. The PM could no longer unilaterally prioritize features. But the PM also no longer had to defend every prioritization decision in one-on-one stakeholder meetings. The governance structure did the work. Stakeholders who wanted to challenge a decision had to convince the committee, not just the PM. That shifted the PM’s role from mediator to facilitator—a role that scales much better as products grow in complexity and stakeholder count.

The Reporting Line Trap: Why Data PMs Need Governance Even When They Report to the Right Leader

Data Product Manager Org Structure: Why Reporting Lines Fail covers the structural challenges of where data PMs sit in the organization—whether they report to engineering, product, analytics, or a dedicated data office. But reporting structure alone does not solve governance. David Ohnstad has seen data PMs report directly to the Chief Data Officer and still lack decision authority because governance was never formalized.

The trap is assuming that organizational alignment equals operational authority. A PM who reports to the CDO has executive air cover—but that does not mean the PM has documented decision rights over the backlog, the release schedule, or cross-functional resource allocation. If the governance model is not explicit, stakeholders will still route around the PM when they disagree with prioritization. They’ll go directly to engineering. They’ll escalate to their own VP. They’ll request custom analytics from the data science team without involving the PM. The reporting line does not prevent this. Governance does.

Governance in this context means a published document—accessible to all stakeholders—that specifies exactly five things: (1) Who owns the product backlog. (2) Who approves scope changes. (3) Who controls the release schedule. (4) Who has authority to grant data access exceptions. (5) What the escalation path is when stakeholders conflict. If these five authorities are not documented, the PM does not have governance—the PM has influence. Influence is not enough when stakeholders have budget, engineering time, or executive relationships that let them bypass the product process.

According to Harvard Business Review’s 2023 analysis on data governance advantages, companies that document decision rights in writing experience 37% fewer project delays caused by stakeholder conflicts compared to companies that rely on informal reporting structures. The difference is not the quality of the relationships—it’s the existence of a shared reference point that all parties agree to follow. When governance is documented, disagreements shift from “who gets to decide” to “what does the governance model say.” That is a solvable question. The first question is not.

What ARD’s Data Product Renewal Reveals About Governance at Scale

The EBU case study on ARD’s digital renewal through data products highlights a governance lesson most organizations miss: governance must scale with the number of products, not just the size of the team. ARD’s challenge was not building a single data product—it was managing a portfolio of federated data products across multiple broadcast entities, each with different stakeholder needs, compliance requirements, and technical constraints.

Their solution: a tiered governance model. Tier one: platform-level governance that defined data access policies, security standards, and integration protocols. All products had to comply. Tier two: product-level governance where individual product managers had authority over backlog prioritization, feature scope, and release timing within the platform constraints. Tier three: portfolio-level governance where a cross-functional council reviewed product performance quarterly and allocated resources based on documented business impact.

This three-tier model solved the core governance scaling problem: how do you give product managers enough autonomy to move fast while maintaining consistency across a portfolio? The answer is not centralized control—it’s distributed decision rights with clear boundaries. Each PM owned their product roadmap. But every PM followed the same platform standards. And every PM’s performance was evaluated using the same business impact framework. The governance model was fractal: the same structure repeated at each level, but with different scopes of authority.

David Ohnstad adopted a similar approach when managing multiple data integration products at Veeam. Each product had its own stakeholder committee. But all committees followed the same decision framework. When conflicts arose between products—shared infrastructure, overlapping feature requests, competing release schedules—they escalated to a portfolio governance board that met monthly. The board did not make product decisions. The board resolved cross-product dependencies and allocated shared resources. Individual PMs retained authority over their own roadmaps. This structure let the product portfolio grow from three products to nine without creating a bottleneck at the PM level.

The Governance-First Roadmap: Why Decision Rights Come Before Features

Most product roadmaps prioritize features: what will we build, in what order, by when. Governance-first roadmaps prioritize decisions: what decision rights do we need to establish before we can commit to building anything. This is not a semantic shift. It changes the entire product planning process.

A governance-first roadmap starts with five questions. First: Who has authority to approve the product vision? If the answer is “the PM proposes and stakeholders agree,” that is not governance—that is consensus-building. Governance means the PM has documented authority to finalize the vision after stakeholder input, but without requiring unanimous agreement. Second: Who controls the release schedule? If engineering can delay a release without PM approval, the PM does not control the schedule. Governance means the PM sets the release date and engineering commits to it or escalates through the documented process. Third: Who can add items to the backlog? If stakeholders can submit requests directly to engineering, the backlog is not governed. Governance means all requests route through the PM, who triages, prioritizes, and either accepts or rejects based on documented criteria.

Fourth: Who grants exceptions to data access policies? If every exception is a one-off negotiation, data access is not governed. Governance means the PM maintains a documented exception process: stakeholders submit a request, the PM reviews against policy criteria, and the decision is logged in a decision register that stakeholders can reference for future requests. Fifth: Who owns post-launch feedback? If feedback goes to multiple teams with no coordination, the product is not governed. Governance means the PM owns the feedback pipeline: users submit feedback to a single intake process, the PM triages it, and stakeholders receive updates through a documented communication plan.

Once those five decision rights are documented and agreed to by stakeholders, the roadmap can proceed. Not before. David Ohnstad has seen teams skip this step and launch data products that technically work but organizationally fail because nobody knew who was responsible for resolving the inevitable conflicts that arise post-launch. Governance is not a post-launch activity. Governance is the foundation the product is built on.

Why Non-Technical PMs Still Need Governance—Maybe More

There is a persistent belief that technical PMs can get away with informal governance because they can resolve disputes by understanding the engineering constraints themselves. Non-technical PMs, the argument goes, need formal governance because they lack the credibility to make technical trade-offs without documented authority. This is exactly backward.

Technical PMs often skip governance because they assume their technical fluency gives them de facto authority. They can argue the technical merits of a decision with engineering. They can evaluate feasibility claims. They can challenge timelines. But that technical credibility does not translate to authority over business prioritization, stakeholder trade-offs, or cross-functional resource allocation. When conflicts arise between departments—analytics wants more data sources, engineering wants to stabilize the platform, business units want faster feature delivery—technical knowledge does not resolve the dispute. Governance does.

Non-technical PMs, by contrast, recognize earlier that they need documented decision rights because they cannot rely on technical credibility to override stakeholder objections. This forces them to establish governance structures upfront. David Ohnstad on AI and enterprise SaaS notes that many of the most effective data product managers he has worked with came from non-technical backgrounds—business analysis, consulting, operations—and built governance-first roadmaps precisely because they knew they could not win arguments on technical grounds alone. They won by making the decision process transparent, the decision rights explicit, and the escalation path clear to all stakeholders.

The mentorship gap emerges here. When technical PMs mentor non-technical PMs, they often emphasize learning SQL, understanding data models, and grasping engineering workflows. That is valuable. But if the mentorship does not also cover how to document decision rights, establish stakeholder committees, and formalize escalation paths, the non-technical PM is left without the governance tools they actually need to succeed. The skill transfer is incomplete. The PM learns how to evaluate a technical proposal but not how to resolve a conflict between two equally valid proposals from competing stakeholders.

What is data product governance and why does it matter?

Data product governance is the documented framework that defines who has decision authority over product scope, prioritization, data access, and stakeholder conflicts. It matters because without it, product managers become mediators with no power to resolve disputes, and stakeholders route around the product process whenever they disagree with prioritization decisions.

How do you establish governance for a cross-functional data product?

Start by documenting five decision rights: who approves the product vision, who controls the release schedule, who manages the backlog, who grants data access exceptions, and who owns post-launch feedback. Publish this framework to all stakeholders and establish a steering committee or council with rotating membership to handle cross-functional conflicts before they escalate.

Why do data products fail even when they have executive sponsorship?

Executive sponsors are reactive—they intervene when problems already exist. Data products need proactive governance structures that prevent most conflicts from requiring executive escalation. Without documented decision rights, stakeholders bypass the product manager and escalate directly to executives, creating bottlenecks and slowing product development regardless of how strong the sponsorship is.

Two Takeaways and One Diagnostic Question

For practitioners: governance is not bureaucracy. Governance is clarity. If you cannot answer in one sentence who has final authority over your product backlog, your product is ungoverned. Document decision rights before you commit to a roadmap. Publish them to stakeholders. Reference them when conflicts arise. The governance model is not overhead—it is infrastructure that lets you move faster because stakeholders know how decisions get made.

For leaders: if your data product managers are spending more than 20% of their time mediating stakeholder conflicts, you do not have a people problem—you have a governance problem. The solution is not better communication skills. The solution is formalizing decision rights, establishing cross-functional councils with documented authority, and making the product manager the owner of the decision process, not the arbiter of every individual decision.

When did you last audit whether your data product has documented decision rights—or whether your PM is operating on influence alone?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Governance: Why Cross-Functional Teams Fail appeared first on David Ohnstad.

Why Most Data Product Managers Are Solving the Wrong Problem

The feature shipped on schedule. All seven stakeholders signed off. The QA gate passed. Three weeks later, the data product manager realized the pipeline was processing files in alphabetical order instead of chronological order, which meant 40% of the analysis was using yesterday’s inputs to predict yesterday’s outcomes. According to Gartner’s 2024 Data and Analytics Leadership Report, 68% of data product failures stem not from technical bugs but from foundational misunderstandings about what the product was supposed to accomplish. That tracks. The team had built exactly what was requested—and completely missed what was needed.

This is not a story about poor requirements gathering. It’s about a deeper issue: most teams treat data product management as a lighter-weight version of feature PM work, where stakeholder alignment and delivery velocity are enough. They’re not. Data products fail when PMs apply consumer product instincts to systems where users are internal, adoption is mandated, and feedback loops are deliberately silenced by organizational politics. The conventional playbook—prioritize by user value, validate with usage metrics, iterate based on feedback—falls apart when your “users” are compliance teams who must use your dashboard whether it helps them or not.

David Ohnstad has managed data products at Veeam Software where this gap shows up weekly. The myth that data product management is just “PM work with SQL skills” creates a generation of practitioners who can write queries but cannot architect around data quality as a product constraint, who track dashboard opens but not decision changes, and who mistake stakeholder consensus for validated demand. The data product management myths persist because the underlying skill gaps are invisible until a product launches and nobody uses it the way the roadmap predicted.

The Hidden Cost of Treating Data Products Like Feature Releases

When a consumer product feature underperforms, you see it in the metrics immediately. Daily active users drop. Retention falls. Support tickets spike. The feedback loop is fast and unambiguous. Data products operate differently. A broken dashboard can sit in production for months, generating weekly email reports that executives glance at but never act on, while the PM celebrates successful deployment. According to McKinsey’s 2023 Analytics Maturity Index, 73% of enterprise analytics initiatives fail to influence a single business decision within their first year of operation. The product works. The data is accurate. Nobody is complaining. And nothing changes.

This failure mode is structural. Internal users often cannot opt out of data products—compliance dashboards, operational reports, and executive scorecards are mandatory consumption. Usage metrics look healthy because people open the reports. But if you measure decision latency—the time between seeing the data and taking action based on it—you discover the truth. The report is being opened, skimmed, and ignored. The data product manager, meanwhile, is tracking the wrong proxy: opens instead of outcomes.

The second cost is governance overhead masquerading as product strategy. Most data PMs treat governance as compliance work—something that slows down delivery. But governance defines the product’s boundaries: who owns which data, who can combine datasets, what decisions require human review versus algorithmic enforcement. When David Ohnstad on AI and enterprise SaaS discusses productizing AI systems, this distinction becomes critical. A data product without governance is not a product—it’s a prototype that will be deprecated the moment someone asks “who approved combining customer PII with usage logs?”

The real cost shows up as rework. A PM builds a customer segmentation model, launches it to the sales team, and six weeks later discovers that Finance has been running a parallel segmentation effort using different definitions of “active customer.” The two models produce contradictory outputs. Sales stops using both. The CFO mandates a single source of truth. The PM rebuilds from scratch—this time with a governance council that should have existed before the first line of code was written. According to Forrester’s 2024 Data Governance Survey, organizations that establish governance frameworks before launching data products reduce rework costs by 58% and achieve adoption rates 3.1 times higher than teams that retrofit governance after launch.

The Product Constraint Model: Four Inputs Standard PMs Ignore

Most product managers optimize for three constraints: user needs, technical feasibility, and business value. Data product managers need four. The missing constraint is data integrity—not as a quality metric, but as a product input that shapes what you can build and how users will trust it. This is the Product Constraint Model that separates high-performing data PMs from feature managers who happen to work with data.

The first constraint is latency tolerance, which is not the same as technical latency. Latency tolerance is the gap between when data is generated and when a decision based on that data stops being useful. A fraud detection model has near-zero latency tolerance—flag the transaction now or the money is gone. An executive dashboard summarizing quarterly pipeline has weeks of latency tolerance. Standard PMs treat latency as a performance optimization problem. Data PMs treat it as a product scoping decision. If your users need real-time data but your source systems update nightly, you do not have a dashboard problem—you have a product that cannot exist with current architecture.

The second constraint is schema stability. Consumer products evolve their data models constantly—add a field, deprecate a column, refactor the database. Users never notice because the interface abstracts the backend. Data products expose the schema to users directly. When a column name changes, every SQL query breaks. Every saved report fails. Every downstream pipeline stalls. This is why non-technical product managers data products often fail—they underestimate how schema changes cascade through an organization. A data PM must version schemas like APIs, communicate deprecation timelines like breaking changes, and treat every column rename as a product migration, not a database refactor.

The third constraint is combinatorial trust. Users trust individual data sources—Finance trusts the ERP, Marketing trusts the CRM. But when you combine those sources in a data product, trust does not transfer automatically. A PM builds a dashboard that joins sales pipeline data with customer success health scores, and the Sales VP immediately questions the output because “those numbers don’t match what I see in Salesforce.” The data is correct. The join logic is sound. But the VP has never seen these two datasets side by side before, and the unexpected pattern triggers distrust. Standard PMs solve this with user education. Data PMs solve this with transparent lineage—showing exactly which source contributed which number, with timestamps and owner attribution.

The fourth constraint is governance as a product boundary, not overhead. When you build a feature, product scope is defined by user stories. When you build a data product, scope is defined by data ownership. If the customer data you need is owned by three different teams with conflicting definitions of “customer,” you cannot build the product until governance resolves that conflict. Most PMs treat this as a blocker to escalate. Effective data PMs treat this as the actual product work—facilitating the cross-team agreement that makes the technical build possible. According to Gartner’s 2024 Data Mesh Architecture Study, organizations that embed governance into product roadmaps from day one achieve 67% faster time-to-value than teams that treat governance as a separate workstream.

What David Ohnstad Learned Shipping a “Successful” Product Nobody Used

David Ohnstad launched a customer health scoring dashboard at Veeam Software that hit every success metric defined in the product brief. Delivered two weeks early. Adoption rate above target within 30 days—82% of intended users had opened the dashboard at least once. Support tickets were minimal. Stakeholders called it a win. Six months later, David ran a decision audit: he asked every user to name one action they had taken based on the dashboard’s recommendations. Eleven of thirteen could not recall a single decision. The dashboard had been opened, reviewed, and ignored. The product succeeded by every standard PM metric and failed by the only metric that mattered—did it change behavior?

The root cause was not the data or the design. It was a prioritization framework built for consumer products applied to an internal enterprise tool. David had prioritized features by frequency of user requests. The Sales team wanted account-level risk scores. Customer Success wanted trend analysis over time. Finance wanted contract renewal predictions. The roadmap delivered all three. What David missed was that none of these stakeholders had decision authority over the actions implied by the data. Sales could not intervene on at-risk accounts without Customer Success approval. Customer Success could not adjust onboarding without Product’s involvement. Finance could not change renewal terms without Legal sign-off. The dashboard delivered insights to people who could not act on them—and did not include the people who could.

The fix required rethinking the user model. Standard product management defines users as the people who interact with the product. Data product management defines users as the people who make decisions based on the product’s output—whether or not they log in. David rebuilt the dashboard to serve decision-makers, not data consumers. The Sales VP did not need account-level risk scores. She needed a weekly digest of the five accounts requiring executive intervention, with pre-populated escalation templates and a one-click path to Customer Success. The product became less flexible and more opinionated—and usage that drove actual decisions went from 15% to 71% within two quarters. According to Harvard Business Review’s 2023 study on enterprise analytics adoption, products designed around decision workflows achieve 4.2 times higher sustained engagement than products designed around data access.

The lesson was uncomfortable. David had built what users asked for, validated with user research, and shipped on schedule—all the behaviors drilled into PMs from day one. But data products operate in a different incentive structure. Users will ask for dashboards because dashboards feel like progress. They will request more metrics because metrics feel like insight. What they will not ask for is accountability—clear ownership of the decision the data is supposed to inform, with consequences for ignoring it. That is the PM’s job. When David started framing product proposals as decision contracts—”this dashboard exists to support [specific decision] by [specific role] with [specific SLA]”—stakeholder conversations changed immediately. Vague requests for “better visibility” turned into concrete debates about who owned which outcome. Products became smaller, more focused, and far more likely to survive past their launch quarter.

Stop Measuring Dashboard Opens—Track Decision Latency Instead

Most data product teams measure success with engagement proxies borrowed from consumer analytics: unique users, session duration, feature adoption rates. These metrics answer the wrong question. A dashboard with 95% weekly active users and zero decision throughput is a reporting tool, not a product. The conventional wisdom says usage metrics predict value. For data products, they predict only visibility—and visibility without action is noise.

Decision latency is the time between data availability and action taken. A fraud alert that triggers account suspension in 90 seconds has low decision latency. An executive dashboard that sits in email for four days before anyone clicks it, then influences no decisions for another three weeks, has high decision latency—regardless of how many people eventually open it. According to MIT Sloan’s 2024 research on data-driven decision making, organizations that instrument decision latency alongside engagement metrics identify underperforming products 11 weeks faster on average than teams relying solely on usage dashboards. The metric is harder to capture because it requires outcome tracking, not event logging. But it is the only metric that differentiates products people use from products that change behavior.

This challenges the entire feedback loop model borrowed from SaaS product development. Consumer PMs run A/B tests to measure feature impact on retention or revenue. Data PMs need to measure impact on decision quality—which is rarely measurable in real time and almost never attributable to a single input. When leadership uses a dashboard to adjust budget allocation, was that decision driven by the data product, the CFO’s intuition, or three hallway conversations? You will not know from the logs. The feedback signal is weak, delayed, and politically mediated. Teams that treat data products like features—ship fast, measure impact, iterate—discover too late that their metrics told them nothing about whether the product mattered. The organizations doing this well treat data products more like infrastructure: measure reliability, latency, and dependency—then validate impact through qualitative decision audits, not quantitative dashboards.

The implication is that most data product roadmaps are optimizing for the wrong outcomes. If your success metrics are “increase dashboard adoption by 30%” and “reduce time-to-insight by two days,” you are measuring outputs, not impact. The actual goal is “reduce time-to-decision by 40%” and “increase decision confidence scores among executives from 6.1 to 7.8 out of 10.” Those metrics are harder to instrument and impossible to gamify. That is the point. When David Ohnstad on leadership and career growth discusses developing judgment in ambiguous environments, this is the skill gap that separates senior ICs from strategic leaders—knowing which metrics to ignore because they are measuring the wrong thing.

FAQ: What Practitioners Ask About Data Product Management Skills

What skills differentiate data product managers from traditional product managers?

Data product managers must architect around data integrity as a product constraint, not just a quality metric. This requires understanding schema versioning, data lineage, governance frameworks, and decision latency—skills that standard feature PMs rarely develop. SQL proficiency helps but is not sufficient; the critical skill is designing products where trust in the underlying data is part of the user experience, not an assumption.

How do you measure success for a data product when usage is mandated?

Measure decision latency and decision confidence, not dashboard opens or session duration. Track the time between data availability and observable action, then validate through qualitative audits whether decisions changed because of the product. Mandated usage inflates engagement metrics but reveals nothing about impact; the only reliable signal is whether behavior changed and whether users trust the output enough to act on it.

Why do data product prioritization frameworks fail in enterprise environments?

Standard prioritization frameworks rank features by user value and technical feasibility, but data products require a third dimension: governance readiness. You cannot build a product that combines datasets owned by three teams with conflicting definitions until those teams agree on a unified schema. Prioritizing by user demand ignores whether the foundational agreements exist to make the product viable. Governance is not overhead—it is the scoping constraint that determines what is buildable.

Two Takeaways and One Question

For practitioners: stop treating governance as a compliance checklist. Governance defines product boundaries—who owns which data, who can combine what, and what decisions require oversight. If you build without that clarity, you are not shipping a product—you are shipping a prototype that will be reworked the moment someone asks about data lineage or regulatory compliance. Build governance into the roadmap from day one, not as a phase-two add-on.

For leaders: if your data product teams are measuring engagement but not decision impact, you are funding reporting infrastructure, not strategic products. Mandate decision audits as part of quarterly reviews—ask PMs to name the specific decisions their products influenced, the stakeholders who acted on the data, and the latency between insight and action. If the PM cannot answer, the product is not delivering value—it is delivering visibility. Visibility is cheaper to buy than custom products.

Here is the question to ask your team this week: when did you last validate that your data product changed a decision, not just surfaced information that someone already believed?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Managers: Stop Solving the Wrong Problem appeared first on David Ohnstad.

Why the “Technical Depth” Requirement Is Killing Data Product Hiring

David Ohnstad has reviewed 47 data product manager job descriptions in the last six months. Forty-one of them listed SQL proficiency as required. Thirty-three required Python or R. Twenty-seven wanted experience with specific BI tools. Zero mentioned the ability to diagnose why a dashboard shipped but nobody used it.

According to Gartner’s 2024 Data and Analytics Leadership Survey, 68% of organizations report difficulty hiring qualified data product managers, yet 73% of those same organizations admit their data products suffer from poor adoption rather than technical implementation failures. The problem is not a shortage of technical talent. The problem is that hiring managers are optimizing for the wrong skills.

This creates a compounding failure mode: teams hire engineers who can build anything but struggle to define what’s worth building. Products ship on time with clean code and broken strategy. Dashboards deliver accurate numbers that answer questions nobody asked. And organizations conclude they need to hire more technical people to fix the problem their last technical hire created.

The Four Myths That Sabotage Data Product Teams

The industry has built a mythology around data product management that sounds credible until you watch it fail in production. These beliefs persist not because they are true, but because they simplify hiring decisions and let organizations avoid harder questions about what data products actually need to succeed.

Myth One: SQL Proficiency Predicts PM Effectiveness

The belief: A data product manager who can write queries will make better decisions about data architecture, understand technical constraints, and communicate more effectively with engineering teams.

Why it persists: This myth survives because SQL is measurable. You can test for it in interviews. It feels rigorous. And there is a grain of truth buried inside—data PMs should understand relational databases, join logic, and aggregation concepts. But understanding is not the same as implementation.

What’s actually true: The most effective data product managers David Ohnstad has worked with at Veeam could all read a query and understand what it was doing. Half of them could not write one from scratch without documentation. The skill that mattered was different: they knew which questions required SQL to answer and which questions required talking to users. They understood that a query returning zero rows might mean the data model was wrong, the business process changed, or the question itself was flawed. That diagnostic ability has nothing to do with syntax fluency.

According to Pragmatic Institute’s 2023 Product Management Survey, product managers who spend more than 15% of their time writing code or queries report lower stakeholder satisfaction scores than those who spend that time on discovery and prioritization. The correlation holds across technical and non-technical domains. The work of product management is not the work of engineering, and confusing the two creates PMs who are mediocre at both.

Myth Two: Data PMs Need Deep Technical Skills to Earn Engineering Respect

The belief: Engineers will not respect or listen to a product manager who cannot speak their language fluently, understand implementation complexity, or contribute to architectural discussions with technical depth.

Why it persists: This one spreads through war stories. Someone once worked with a PM who could not tell the difference between a data lake and a database, made impossible commitments, and blamed engineering when timelines slipped. The lesson drawn: hire technical PMs so that never happens again. The actual lesson—hire PMs who ask questions and understand constraints—gets lost.

What’s actually true: Engineers respect competence, not credentials. A PM who says “I do not know how that pipeline works—walk me through it” earns more trust than one who pretends to understand and makes decisions based on guesswork. David Ohnstad has seen non-technical PMs build strong engineering partnerships by doing three things consistently: asking specific questions, documenting answers accurately, and making decisions that reflect what they learned. Engineers do not need a PM who can code. They need a PM who will not ignore technical constraints to hit a political deadline.

The framework that works is not technical fluency. It is structured curiosity. When a PM asks “What breaks if we do this?” and “How would we know it broke?” and “What is the cheapest way to test that assumption?”—that PM is doing the job. The implementation details are the engineer’s domain. The decision logic is the PM’s.

Myth Three: Technical PMs Ship Faster Because They Understand Implementation

The belief: A PM with an engineering background can write better specs, anticipate technical blockers, and reduce back-and-forth with development teams, leading to faster delivery cycles.

Why it persists: It is easy to confuse speed with efficiency. A technical PM who writes detailed specs might reduce clarification questions during sprint planning. But that does not mean they are building the right thing. And it definitely does not mean they are building something users will adopt.

What’s actually true: The bottleneck in most data product development is not implementation—it is defining what success looks like and validating that the product delivers it. According to Forrester’s 2024 State of Product Management report, 61% of product delays stem from unclear requirements or scope changes, not technical complexity. The PM who ships fast but ships the wrong thing has not solved the problem. They have created technical debt with a pretty UI.

David Ohnstad worked with a PM at Veeam who had zero SQL experience but cut delivery time for a reporting product by 40% through a single change: requiring every feature request to include the decision it would enable and the metric that would prove it worked. That filter eliminated half the backlog before a single line of code was written. The technical depth did not matter. The decision framework did.

Myth Four: Non-Technical PMs Cannot Evaluate Data Architecture Decisions

The belief: Architectural choices—data mesh versus centralized warehouse, batch versus streaming, normalized versus denormalized schemas—require deep technical understanding to evaluate. A non-technical PM will defer to engineering by default, which means they are not really managing the product.

Why it persists: Architecture feels like engineering territory. And in some ways, it is. But the decision criteria are not purely technical. Every architectural choice has trade-offs in cost, speed, flexibility, and maintainability. Those trade-offs map to business priorities. A PM does not need to design the architecture. They need to understand what each option enables and costs.

What’s actually true: The best architectural discussions David Ohnstad has participated in were not technical debates—they were prioritization exercises. One option supported faster queries but required more engineering time to maintain. Another reduced operational cost but increased latency for certain use cases. The PM’s job was not to pick the technically superior solution. It was to decide which trade-offs aligned with the product strategy and user needs.

A non-technical PM who asks “Which architecture supports the use cases we validated in discovery?” and “What does each option cost in eng hours per quarter?” is doing architecture governance. They are not doing database design. Those are different jobs. Organizations that conflate them end up with PMs who can write elegant schemas but cannot explain why the product matters. As explored in Data Product Management: Why 82% of Analytics Fail, the root cause of most analytics failures is not bad technology—it is bad problem definition.

The Capability Stack: What Data PMs Actually Need to Succeed

If technical depth is not the answer, what is? David Ohnstad has built a framework for evaluating data PM capability that focuses on the skills that actually predict success. This is a four-layer model, and the technical layer is the least important.

Layer One: Problem Diagnosis

The PM must be able to distinguish between a data problem, a process problem, and a decision-making problem. Most requests for data products are actually requests to fix something else. A dashboard will not solve a broken approval workflow. A reporting tool will not fix misaligned incentives. The PM who cannot diagnose the real problem will build solutions that do not get used.

This requires structured interviewing, observation of actual workflows, and the ability to ask follow-up questions until the root cause is visible. It does not require SQL. It requires patience and skepticism.

Layer Two: Outcome Definition

The PM must be able to articulate what success looks like in measurable terms before any work begins. Not “users will have access to data”—that is an output. Success is “the sales team will reduce time spent on manual forecasting by 30% within two quarters” or “finance will identify budget variances within 48 hours instead of two weeks.”

This layer also includes defining how the team will know if the product is working after launch. What gets measured? How often? What threshold triggers a retrospective? Teams that skip this ship products and then argue about whether they succeeded. The outcome should be defined in the spec, not litigated after release.

Layer Three: Stakeholder Orchestration

Data products almost always require coordination across multiple teams: engineering, analytics, data governance, legal, security, and end users. The PM who cannot navigate competing priorities, build alignment without authority, and translate technical constraints into business language will stall even the best-designed product.

This is the skill most job descriptions ignore. It is also the skill that determines whether a product gets adopted or quietly deprecated. A PM who builds a perfect dashboard but cannot get the sales VP to mandate its use in pipeline reviews has built a portfolio piece, not a product. For more on why structural positioning matters, see Data Product Manager Org Structure: Why Reporting Lines Fail.

Layer Four: Technical Fluency (Not Depth)

The PM needs to understand data concepts well enough to ask the right questions and evaluate trade-offs. That includes relational databases, ETL pipelines, API integrations, query performance, and data quality monitoring. But understanding how these systems work is different from being able to build them.

A non-technical PM who knows that adding an index speeds up queries but requires storage can participate in architectural trade-off discussions. They do not need to write the index. They need to know it exists, what it costs, and when it matters. That level of fluency is teachable in weeks. Writing production-grade SQL takes months or years and is not the PM’s job.

David Ohnstad has used this framework to evaluate PM candidates and onboard new hires at Veeam. The candidates who scored highest on layers one through three consistently outperformed those with strong technical skills but weak problem diagnosis or stakeholder management. One PM with a liberal arts background and zero coding experience shipped three high-adoption data products in her first year by obsessively validating use cases and holding stakeholders accountable for defining success metrics upfront. Her technical fluency grew as she worked. Her diagnostic and orchestration skills were already there.

What This Means for Hiring Managers

If you are writing a job description for a data product manager, here is the uncomfortable truth: your list of required technical skills is probably filtering out the candidates who would succeed and attracting the ones who would struggle.

David Ohnstad recommends reversing the priority order. Start with problem diagnosis and outcome definition. Test for those in interviews by presenting a vague stakeholder request and asking the candidate what questions they would ask before scoping any work. A candidate who jumps straight to solution architecture has already failed. A candidate who asks “What decision is this data supposed to enable?” and “How will we measure whether it worked?” is demonstrating the skill that matters most.

Then evaluate stakeholder orchestration. Ask about a time the candidate had to align multiple teams with competing priorities and no formal authority. How did they build consensus? What broke down? What would they do differently? The answers reveal whether they understand that product management is as much about people as it is about product.

Technical fluency should be assessed last, and the bar should be lower than most job descriptions set. Can the candidate explain the difference between a data warehouse and a data lake? Do they understand what an API does? Can they articulate why data quality matters and what types of errors are most dangerous? If yes, they have enough technical foundation to start. The rest can be learned on the job.

According to McKinsey’s 2024 Product Leadership Study, organizations that hired for problem-solving and stakeholder management skills rather than technical credentials reported 35% higher product adoption rates and 28% faster time-to-value for data products. The technical skills gap closed within six months. The strategic skills gap never did.

The One Thing Most Data PM Job Descriptions Get Backward

Stop listing SQL and Python as required skills. Start requiring candidates to demonstrate they can define a measurable outcome, diagnose whether a data product is the right solution, and navigate competing stakeholder priorities without formal authority.

Those skills are harder to test in a 45-minute interview. They are also the only skills that predict whether the PM will ship products that people actually use. The rest is noise. For leaders building team structures that support this kind of work, understanding the intersection of AI/ML engineering and product strategy becomes essential—explore that dynamic at David Ohnstad on AI and enterprise SaaS. And when onboarding non-technical PMs, mentorship relationships with senior engineers are critical for accelerating learning without creating dependency—those dynamics are covered at David Ohnstad on leadership and career growth.

When Non-Technical PMs Outperform Technical Ones

David Ohnstad worked with two PMs on parallel data products at Veeam. One had a computer science degree and five years of analytics engineering experience. The other had a business degree and had never written a line of code. Both were tasked with building reporting tools for internal teams.

The technical PM spent three weeks designing a data model, writing SQL queries to validate the schema, and building a prototype in Tableau. The work was clean. The queries were optimized. The dashboard was fast. When it launched, adoption was 14% in the first quarter. The PM could not explain why.

The non-technical PM spent three weeks shadowing users, documenting their workflows, and asking what decisions they were trying to make. She discovered that the data they said they needed was not the data that would actually change their behavior. She scoped a simpler product—a single metric with a weekly email alert—and spent two weeks validating that it would trigger the desired action. Adoption in the first quarter was 81%. The product became mandatory in the second quarter.

The difference was not technical ability. It was focus. The technical PM optimized for elegance. The non-technical PM optimized for impact. Only one of those strategies survives contact with real users.

What About AI and Automation?

One argument for hiring technical PMs is that AI tools are rapidly automating away the need for human judgment in data product work. If a PM can use Claude or GPT-4 to generate SQL queries, build dashboards, and analyze datasets, does technical fluency still matter?

The answer is no—but not for the reason most people think. AI does not replace the need for technical fluency. It replaces the need for technical execution. A PM who understands what a join does can validate whether the AI-generated query is correct. A PM who does not understand joins cannot. But that validation skill is still fluency, not depth. The PM does not need to write the query from scratch. They need to know whether the output makes sense.

What AI cannot do—and what separates effective PMs from ineffective ones—is diagnose the problem, define the outcome, and orchestrate the stakeholders. Those are human judgment tasks. They require context, negotiation, and the ability to say no when a stakeholder asks for the wrong thing. No language model can do that. And technical depth does not help either.

David Ohnstad uses Claude daily to automate QA, generate test cases, and validate data pipelines. The tool accelerates execution. It does not change the fact that someone still needs to define what success looks like, prioritize competing requests, and ensure the product gets used. That someone is the PM. And they do not need to know Python to do it.

What is the most important skill for a data product manager?

Problem diagnosis. The ability to determine whether a stakeholder’s request for a data product is actually solving the root cause or masking a process, organizational, or incentive problem. Most data product failures stem from building the wrong thing, not building the thing wrong. A PM who cannot diagnose the real problem will ship technically sound products that nobody uses.

Do data product managers need to know SQL?

They need to understand SQL concepts—joins, aggregations, filtering, query performance—but they do not need to write production queries from scratch. The value is in knowing what is possible, what is expensive, and how to evaluate trade-offs. A PM who can read a query and understand what it does can collaborate effectively with engineers. Writing the query is not the PM’s job.

How do non-technical PMs evaluate data architecture decisions?

By focusing on trade-offs rather than implementation details. Every architectural choice has cost, speed, flexibility, and maintainability implications. A non-technical PM asks which option best supports validated use cases, what each option costs in engineering time, and which trade-offs align with product strategy. They are not designing the architecture—they are governing the decision criteria.

What Senior Leaders Should Do Differently

First, audit your current data PM job descriptions and remove any technical skill listed as “required” unless you can explain why a candidate could not learn it in 90 days on the job. SQL, Python, Tableau, Power BI—all learnable. Problem diagnosis, stakeholder orchestration, outcome definition—those are the filters that matter.

Second, change how you evaluate PM performance. Stop measuring technical contributions. Start measuring adoption rates, time-to-value, and whether shipped products are still in use six months after launch. If your data PMs are shipping on time but products are getting deprecated, you have a strategy problem, not an execution problem. Hiring more technical people will not fix it.

Third, invest in onboarding that teaches technical fluency without requiring technical depth. A non-technical PM should complete a structured curriculum that covers databases, ETL, APIs, and query performance within their first 60 days. Pair them with a senior engineer who can answer questions and review their understanding. That is enough to make them effective. Anything beyond that is over-indexing on skills that do not predict success.

For practitioners considering a move into data product management: if you have strong problem-solving skills, experience managing stakeholders, and the ability to define measurable outcomes, you already have the hard parts. The technical fluency is the easy part. Do not let a job description that lists SQL as required convince you otherwise. Apply anyway. Learn the basics in the first 90 days. Focus on what actually matters.

The Real Cost of Hiring for the Wrong Skills

Organizations that optimize for technical depth in data PM hiring pay a compounding cost. They filter out candidates with strong strategic and interpersonal skills. They hire PMs who build elegant solutions to the wrong problems. They ship products that get deprecated. And they conclude the solution is to hire even more technical people, deepening the cycle.

The alternative is not to ignore technical skills entirely. It is to recognize that technical fluency—the ability to understand, evaluate, and ask the right questions—is different from technical depth, and only one of those predicts PM success. The organizations that figure this out will ship fewer products and adopt more of them. The ones that do not will keep building dashboards nobody opens.

When was the last time you validated whether your data PM hiring criteria actually correlate with product adoption six months after launch? If you have not run that analysis, you are optimizing for the wrong proxy. And the PMs you are not hiring are probably the ones you need.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Hiring: Why Technical Requirements Backfire appeared first on David Ohnstad.

Why Data Product Management Skills Are Nothing Like Standard PM Work

We hired a product manager with a perfect pedigree: five years at a B2C SaaS company, shipped features to millions of users, stellar stakeholder reviews. Three months into building our first data product—a customer segmentation engine for our sales team—he told me he felt like he’d never done product management before. According to Gartner’s 2024 Data and Analytics Leadership Survey, 71% of organizations report that traditional product managers struggle when transitioning to data product roles, with the median time to effectiveness extending from 90 days to nearly seven months.

The gap isn’t about learning new tools. It’s about unlearning deeply ingrained product instincts that actively sabotage data product work. When your “user” is mandated to adopt your product by their VP, when your primary input is itself a product output from three other teams, and when your success metric might be “nobody called about it for six months”—the standard PM playbook becomes worse than useless. It becomes expensive misdirection.

Here are five myths about what makes data product managers effective. Each one sounds reasonable until you try to execute against it. Then you discover the myth isn’t just incomplete—it’s built on a fundamentally different problem space than the one you’re actually solving.

Myth One: SQL Proficiency Equals Technical Depth

Most data PM job descriptions list SQL as a technical requirement. Check the box, you’re technical enough. This is like saying a restaurant critic needs to know how to boil water. Sure, it’s foundational. But it’s nowhere near the technical depth that actually predicts success.

The myth persists because SQL is measurable in interviews. You can test for it. You can verify it on a take-home assignment. And for many hiring managers coming from traditional PM backgrounds, it’s the most technical thing they personally understand about data work. So it becomes the proxy for “technical enough.”

Here’s what actually matters: understanding data lineage, transformation logic, and quality propagation across a multi-stage pipeline. When a dashboard shows a 40% drop in conversion rate, can you trace that metric back through five transformation layers to identify whether the drop is real, or whether someone upstream changed a join condition that now excludes mobile app users? That’s the technical depth that separates functional data PMs from ones who just relay what engineering tells them.

David Ohnstad learned this the expensive way at Veeam. A sales pipeline dashboard had been showing steady growth for three quarters. Leadership was citing it in board meetings. Then a new data engineer joined, audited the source queries, and discovered that the “pipeline value” metric had been double-counting multi-product deals since launch. The actual pipeline was 30% smaller than reported. The PM who owned that dashboard could write SQL. What he couldn’t do was audit the data architecture diagram, identify where dimension tables were being joined incorrectly, and propose a fix that wouldn’t break twelve downstream reports.

The technical depth data PMs need isn’t about writing queries. It’s about reading data flow documentation, understanding how schema changes propagate, knowing when to use a slowly changing dimension versus a snapshot table, and being able to explain to a senior engineer why their proposed normalization will destroy query performance for the BI team. According to McKinsey’s 2023 Analytics Upskilling Study, data PMs who scored in the top quartile on “data architecture comprehension” assessments shipped products with 62% fewer post-launch data quality incidents than those who scored in the bottom quartile—despite no statistically significant difference in SQL proficiency between the groups.

Stop hiring for SQL. Start assessing whether candidates can trace a broken metric back to its root cause across system boundaries.

Myth Two: User Adoption Metrics Work The Same Way

In B2C product management, adoption is voluntary. If nobody uses your feature, that’s clear feedback: you built the wrong thing, marketed it poorly, or solved a problem people don’t actually have. The failure mode is obvious and the correction is straightforward.

Data products break this entire model. Your users are often mandated to use your product by someone three levels above them in the org chart. A sales VP announces that all pipeline forecasts must now use the new data product you built. Adoption goes to 100% in two weeks. Your dashboard shows green. Six months later, you discover that every sales manager is maintaining a shadow Excel file with “the real numbers” because they don’t trust your data product’s calculations.

This is why traditional PM adoption metrics—DAU, feature engagement, time in product—become actively misleading for data products. High usage can mask deep distrust. Low usage might indicate that the product works so well people only need to check it once a quarter. And “user satisfaction” scores often reflect political dynamics around the mandate, not the product’s actual utility.

What actually predicts data product success: decision observability. Can you measure whether decisions changed after your product launched? If you built a customer churn prediction model, did retention campaigns shift their target lists? If you built a pricing optimization dashboard, did pricing managers adjust their recommendations in the direction the data suggested? According to Forrester’s 2024 Data Product Management Report, organizations that tracked “decision delta” metrics—measuring changes in downstream actions, not just tool usage—achieved 3.2x higher ROI from data product investments compared to those tracking only engagement metrics.

David Ohnstad built a customer segmentation product at Veeam that initially showed terrible engagement numbers. Usage was low, time-in-product was minimal, and the NPS score from the sales team was middling. But when he audited actual deal outcomes, he found that deals where sales reps had consulted the segmentation data—even briefly—closed 18% faster and had 22% higher average contract values. The product was working. The engagement metrics were measuring the wrong thing.

The correction: shift from measuring “are people using this” to “are people making different decisions because of this.” That requires instrumenting the downstream systems where decisions happen—CRM tools, planning spreadsheets, operational dashboards. It requires qualitative interviews asking not “do you like this product” but “tell me about the last decision you made where you checked this data.” And it requires accepting that successful data products often have low time-in-product scores because they deliver their insight quickly and get out of the way.

Myth Three: Stakeholder Management Follows Standard PM Playbooks

Traditional PM stakeholder management is mostly about negotiation and prioritization. You have more feature requests than you have engineering capacity. Your job is to align stakeholders around a roadmap, communicate trade-offs clearly, and keep everyone pointed in the same direction even when you’re saying “no” to their favorite idea.

Data product stakeholder management is an entirely different discipline. You’re not just negotiating priorities—you’re navigating organizational politics around data ownership, governance authority, and who gets to define “the source of truth” when different departments have conflicting definitions of the same metric.

The myth persists because the language sounds the same. “Stakeholder alignment.” “Managing expectations.” “Communicating trade-offs.” But the actual work is unrecognizable. When a finance VP and a sales VP disagree on how to calculate customer lifetime value, you’re not mediating a feature prioritization discussion. You’re arbitrating a definitional conflict where both sides have legitimate business logic, existing systems built on their definition, and political capital invested in being “right.”

Traditional PM training teaches you to resolve these conflicts by escalating to a shared executive sponsor who makes the call. That doesn’t work for data products because the conflict often IS about governance—who has the authority to make that call in the first place. If you escalate to the COO, and the COO rules in favor of Finance’s definition, you’ve just told the entire sales organization that their historical reporting was wrong. That’s not a roadmap decision. That’s an organizational crisis.

What actually works: building governance councils before you need them. David Ohnstad wrote extensively about data council strategy after watching two data products fail spectacularly at Veeam because governance questions were treated as “someone else’s problem” until launch week. The successful pattern he’s seen: convene a cross-functional council during the discovery phase—before any technical work starts—with explicit authority to resolve definitional conflicts and data ownership questions. The council includes representatives from every department that will consume the data product, plus a senior executive with actual authority to make binding decisions when the council deadlocks.

This is not a stakeholder sync meeting. It’s a governance body with decision-making power, documented definitions, and a process for handling appeals. According to MIT Sloan’s 2023 Data Governance Research, organizations that established formal governance councils before launching enterprise data products reported 54% fewer post-launch escalations and 68% faster time-to-stable-adoption compared to those that treated governance as a post-launch concern.

For more on how David Ohnstad on AI and enterprise SaaS approaches the technical architecture decisions that support these governance structures, the underlying infrastructure needs to support multiple concurrent definitions and clear audit trails—you can’t govern what you can’t trace.

Stop assuming stakeholder management is about communication skills and negotiation tactics. Start treating it as organizational design work that requires formal authority structures and documented decision rights.

Myth Four: You Can Deprioritize Data Quality Work

In traditional product management, technical debt is something you manage. You make conscious trade-offs. You ship a feature with known limitations to hit a deadline, then come back later to refactor. Quality is important, but it’s one input among many in your prioritization framework.

Data products don’t work this way. Data quality isn’t a feature you can defer. It’s a product input. If your source data is wrong, everything you build on top of it is worse than useless—it’s confidently incorrect information that people make decisions with.

The myth persists because data quality feels like technical work, not product work. It’s schema validation, null handling, referential integrity checks—the kind of unglamorous engineering that doesn’t show up in a product demo. So PMs treat it like infrastructure: something the data engineers should “just handle” while the PM focuses on “actual product features” like the dashboard UI or the recommendation algorithm.

This is catastrophically wrong. Data quality issues are product failures. When a sales dashboard shows a customer as “high-risk for churn” because a NULL value in the CRM got interpreted as zero revenue, that’s not a data engineering problem. That’s your product giving bad advice. And the sales rep who loses that customer because they allocated retention budget elsewhere isn’t going to care that the root cause was “a schema issue in the ETL pipeline.” They’re going to stop trusting your product.

What actually works: treating data quality as product strategy, not technical overhead. David Ohnstad runs a weekly data quality audit for every production data product he owns. Not a technical log review—a business logic audit. He samples 20 records that drove product recommendations in the past week, traces each one back to its source systems, and asks: “Would I make the same decision with this data if I knew the full context?” When he finds issues—and he always finds issues—he doesn’t file a Jira ticket for the data team. He escalates it as a product bug with the same severity as a UI that crashes on page load.

According to Gartner’s 2024 Data Quality Economics Study, organizations that treated data quality monitoring as a product management responsibility rather than a data engineering responsibility achieved data accuracy rates 23 percentage points higher than those using traditional “engineering owns quality” models. More importantly, they caught data quality degradation an average of 11 days faster—before bad data propagated into decisions.

The correction requires a mindset shift. Stop asking “how do I prioritize quality work alongside feature work?” Start asking “what quality gates need to exist before I can ethically ship this feature?” If you can’t answer that question with specific metrics and automated checks, you’re not ready to ship. Building a data product without quality instrumentation is like building a car without brake lights. Technically possible. Wildly irresponsible.

The Data PM Skill Ladder: A Five-Stage Competency Model

Here’s the framework David Ohnstad uses when mentoring product managers transitioning into data product roles. It’s not a checklist—you don’t “complete” one stage and move to the next. It’s a skill ladder where each rung requires different thinking, not just more knowledge. Most traditional PMs enter this ladder at stage two and assume they’re at stage four. That gap is why transitions fail.

Stage One: Query Competency. You can write SQL to answer your own questions. You understand joins, aggregations, and window functions well enough that you don’t need to wait for a data analyst to pull numbers for you. This is table stakes. If you’re not here yet, you’re not ready for data product work. But being here doesn’t make you a data PM—it makes you a PM who can access data.

Stage Two: Architecture Comprehension. You can read a data flow diagram and understand how data moves through your systems. You know the difference between OLTP and OLAP databases and why that matters for query performance. You can trace a metric back through transformation layers to identify where quality issues originated. You understand that “the data warehouse” is not a monolithic thing—it’s a collection of staging tables, dimension tables, fact tables, and aggregation layers, each with different update frequencies and quality guarantees. Most PMs who transition from feature work to data products get stuck here. They understand systems, but they don’t yet understand the political and organizational dynamics that make data product work fundamentally different.

Stage Three: Governance Fluency. You can navigate definitional conflicts between departments without escalating every decision to executives. You understand that “revenue” might legitimately mean different things to Finance (booked revenue), Sales (pipeline value), and Product (ARR). You can facilitate conversations where stakeholders with conflicting definitions reach documented consensus on shared metrics. You know when to build multiple versions of a metric to serve different use cases, and when to hold the line on a single source of truth. This is where most failed data products break—not because of bad engineering, but because the PM couldn’t navigate the organizational complexity around data ownership and authority.

Stage Four: Quality as Strategy. You treat data quality monitoring as a product capability, not an engineering responsibility. You’ve built quality gates into your product’s CI/CD pipeline. You can articulate your product’s quality SLA and explain the business impact of different quality failure modes. You understand that perfect data quality is unachievable and economically irrational—the skill is knowing where to set thresholds based on decision risk. When quality degrades, you have automated alerts, not just log files. When those alerts fire, you have runbooks that explain business impact, not just technical steps. For insights on how David Ohnstad on leadership and career growth develops teams capable of this level of quality thinking, the short answer is: you need people who understand systems thinking and can translate technical failures into business risk language.

Stage Five: Decision Instrumentation. You’ve built feedback loops that measure whether your data product is changing decisions, not just being viewed. You can show that recommendations are being acted on, not just displayed. You’ve instrumented the downstream systems where decisions happen—CRM tools, planning spreadsheets, operational workflows—so you have quantitative evidence of impact. You run regular qualitative interviews with users focused not on satisfaction, but on decision-making process. You can demonstrate ROI not by showing usage numbers, but by showing that different actions were taken because your product exists.

The gap between stage two and stage five is not about learning more tools or taking more courses. It’s about fundamentally reconceptualizing what “product management” means when your product is data rather than features. Traditional PM skills—user research, roadmapping, stakeholder communication—are necessary but not sufficient. They need to be rebuilt from first principles for a problem space where adoption might be mandated, quality is a product input rather than a feature attribute, and success might look like invisibility rather than engagement.

When Data Product Management Becomes Organizational Design

The hardest thing for traditional PMs to accept about data product work is that you can’t succeed by being a better individual contributor. You can master SQL. You can become an expert in data architecture. You can build the most elegant dimensional model anyone on your team has ever seen. And your data product can still fail catastrophically because you didn’t solve the organizational design problem.

Data products don’t exist in isolation. They sit at the intersection of multiple teams’ workflows, multiple departments’ definitions, and multiple systems’ outputs. When you ship a data product, you’re not just launching a new tool—you’re proposing a new source of truth that might contradict existing reports, challenge existing processes, and redistribute authority over what counts as “the real numbers.”

That’s not a technical problem. It’s not a stakeholder communication problem. It’s an organizational design problem. And most PMs—even excellent ones—have never been trained to think at that level. They’ve been trained to build products for users. They haven’t been trained to redesign organizational authority structures, adjudicate definitional conflicts between departments, or navigate the political dynamics of data ownership.

This is why understanding non-technical product managers data products challenges matters—the technical complexity is real, but the organizational complexity is what actually kills projects. David Ohnstad has seen more data products fail because of governance gaps than because of technical architecture problems. The ratio is probably 4:1. And the governance failures are predictable: they happen when PMs treat organizational design questions as “soft skills” or “change management” rather than core product work that needs the same rigor as technical architecture.

The successful pattern: start every data product initiative with a governance design phase before any technical work begins. Convene the stakeholders who will consume this data product. Document their existing definitions for key metrics. Identify conflicts. Force resolution. Establish decision rights. Create an escalation path with real authority. Only then—after you have organizational consensus on what the product should do and who has authority to define “correct”—do you start building.

This feels slow. It feels like overhead. It feels like you’re delaying the “real work” of building the product. But according to Forrester’s 2024 research, data products that completed formal governance design before technical development launched an average of 23% faster than those that treated governance as a post-launch concern—because they didn’t spend six months after launch resolving definitional conflicts and rebuilding trust with stakeholders who felt blindsided by the new metrics.

What makes data product management different from regular product management?

Data product management requires navigating organizational governance conflicts, treating data quality as a product input rather than technical debt, and measuring success through decision changes rather than engagement metrics. Traditional PM skills like user research and roadmapping are necessary but not sufficient—data PMs must also function as organizational designers who can resolve definitional conflicts and establish authority structures before building technical solutions.

How do you measure the success of a data product when adoption is mandated?

Track decision delta metrics—quantifiable changes in downstream actions that occur because of your data product. Instead of measuring engagement or time-in-product, instrument the systems where decisions happen and measure whether recommendations are being acted on. Combine quantitative tracking with qualitative interviews focused on how the data changed decision-making processes, not satisfaction scores.

Why do data product managers need deeper technical skills than feature PMs?

Data PMs must trace broken metrics across multi-stage transformation pipelines, understand how schema changes propagate through dependent systems, and audit data architecture for quality failure modes. This requires architecture comprehension beyond SQL proficiency—specifically, understanding data lineage, transformation logic, and quality propagation patterns that determine whether a metric can be trusted as a decision input.

What This Means For You

If you’re a product manager considering a transition to data product work, understand that you’re not learning new tools—you’re learning a different discipline. The title sounds similar. The underlying work is unrecognizable. Your existing PM skills matter, but they need to be rebuilt from first principles around data-specific constraints: mandated adoption, quality as input, governance as strategy.

If you’re hiring for data PM roles, stop screening for SQL proficiency and start assessing for governance fluency and architectural comprehension. Ask candidates to trace a broken metric back through a multi-stage pipeline. Give them a scenario where Finance and Sales have conflicting definitions of customer lifetime value and ask how they’d resolve it. See if they can articulate a data quality SLA and explain the business impact of different failure modes. Those skills predict success. SQL doesn’t.

If you’re leading a data organization, recognize that traditional PM performance frameworks don’t apply cleanly to data products. Measuring success by feature velocity or engagement metrics will drive exactly the wrong behaviors. Data PMs need to be evaluated on governance outcomes, quality instrumentation, and decision impact—metrics that don’t show up in standard product analytics tools.

The biggest gap in current data product management myths discourse is the assumption that data product work is just product work applied to a different domain. It’s not. It’s a fundamentally different problem space that requires different skills, different evaluation criteria, and different organizational support structures. Teams that recognize this early avoid the expensive failures that come from hiring great PMs who can’t navigate data-specific complexity.

When was the last time you audited whether your data products are actually changing decisions—or just giving people another dashboard to ignore?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Management vs. Standard PM: Key Differences appeared first on David Ohnstad.

The Biggest Lies About Data Product Management

A hiring manager at a Fortune 500 company told me last month that they rejected three data PM candidates because none of them could write a JOIN statement on a whiteboard. All three had shipped data products that generated eight figures in revenue at their previous companies. According to Gartner’s 2024 Data & Analytics Leadership survey, 73% of organizations now require SQL proficiency for data product management roles—up from 41% in 2021. The industry has decided that technical depth is the bar. The industry is wrong.

Data product management sits at a strange intersection where everyone has an opinion about what skills matter, but few have actually measured what predicts success. The result is a profession built on myths that sound credible, get repeated in every job description, and actively filter out some of the best candidates. These aren’t harmless misconceptions. They shape hiring decisions, career paths, and team structures in ways that make data products harder to ship and less likely to deliver value.

David Ohnstad has built data architecture, analytics pipelines, and AI/ML integrations at Veeam Software for years. He writes SQL daily. He also knows that the best data PM he ever worked with came from a customer success background and couldn’t query a database to save her life when she started. What she could do—what made her exceptional—was translate ambiguous business requirements into clear product specifications and hold engineering accountable to delivery timelines without becoming adversarial. Those skills don’t show up on a technical screen, but they determine whether a data product ships or stalls.

Here are the myths that need to die, the reasons they persist, and what actually matters when you’re building data products that people use.

Myth 1: You Need a Data Engineering Background to Succeed as a Data PM

This is the big one. The myth sounds like common sense: if you’re managing data products, you need to understand data infrastructure, pipelines, transformations, and storage. The stronger version of this myth says you should have worked as a data analyst or data engineer before transitioning to product management. LinkedIn is full of posts offering this exact advice. Job descriptions routinely list “3+ years of data engineering experience” as a requirement.

The myth persists because it feels intuitive. How can you manage something you don’t understand? How can you have credibility with engineers if you’ve never written a DAG or optimized a query? The logic collapses when you actually look at what data PMs spend their time doing. According to Pragmatic Institute’s 2023 Product Management Survey, data PMs spend 61% of their time on stakeholder alignment, roadmap prioritization, and cross-functional coordination—not on technical architecture decisions. The technical depth you need is real, but it’s not the depth of someone who has built pipelines for three years. It’s the depth of someone who can ask the right questions, understand the trade-offs engineers are describing, and translate technical constraints into business language that executives can act on.

David Ohnstad hired a data PM two years ago who had spent six years in customer success at a SaaS company. She had never touched SQL. She had never built a dashboard. What she brought was something harder to teach: she knew how customers actually used data products, which features they ignored, and which workflows broke down under real-world conditions. Within three months, she was running sprint planning for a cross-functional team of eight engineers. Within six months, she had shipped a feature that reduced customer churn by 14% because she framed the product around the decision customers were trying to make—not the data they theoretically needed access to. She learned SQL in that time. She picked up enough data modeling to follow architecture discussions. But the core skill that made her effective was never technical fluency. It was the ability to connect business outcomes to product specs and hold teams accountable to delivery without micromanaging implementation.

The truth: You need enough technical literacy to understand trade-offs and ask informed questions. You do not need to have worked as a data engineer. The best data PMs often come from non-technical backgrounds because they don’t default to technical solutions when the real problem is organizational, political, or driven by unclear requirements. A PM who has spent years in customer success, operations, or business analysis will often outperform a former data engineer in the first 18 months because they already know how to navigate ambiguity, manage stakeholders, and define success in terms of business impact rather than technical elegance. For more on how reporting structures shape data PM effectiveness, the organizational context matters as much as individual skill.

Myth 2: Data PMs Should Own the Roadmap Based on Technical Feasibility

This myth shows up in every roadmap planning session. Engineering says a feature will take six months. The PM adjusts the roadmap to reflect that timeline. A stakeholder asks why a high-priority request isn’t being addressed. The PM explains that the technical complexity makes it infeasible this quarter. Everyone nods. The myth is that technical feasibility should drive prioritization. It sounds responsible. It avoids overpromising. It keeps engineering from burning out on impossible deadlines.

The problem is that feasibility is almost never a fixed constraint. It’s a function of scope, architecture decisions, and how much technical debt the team is willing to take on in the short term. When PMs treat feasibility as the anchor for roadmap decisions, they cede control of the product strategy to whatever the engineering team happens to find difficult. According to McKinsey’s 2024 Product Operating Model research, organizations that prioritize based on business impact first and then solve for technical constraints deliver 2.3 times more customer value per quarter than teams that prioritize based on feasibility. The difference is not that one group has better engineers. The difference is that one group starts with the outcome and works backward to find a path, while the other starts with the path and hopes it leads somewhere useful.

David Ohnstad has seen this play out in real time. A stakeholder requested a feature that would let customers compare their data usage patterns across multiple time periods. Engineering estimated four months of work because it required restructuring how historical data was stored and indexed. The PM put it at the bottom of the roadmap. Six weeks later, a customer threatened to churn because they couldn’t answer a basic question about their own usage trends—a question that feature would have solved. The team revisited the scope. Could they deliver a version that only worked for the last 90 days of data instead of full historical access? Could they surface the comparison in a static report instead of an interactive dashboard? Engineering came back with a two-week estimate for a scoped version. It shipped. The customer stayed. The full version never became necessary because the scoped solution solved the actual decision the customer was trying to make.

The truth: Technical feasibility is a negotiation, not a constraint. A good data PM defines the business outcome first, then works with engineering to find the smallest version of the solution that delivers value. Roadmaps should be driven by impact, not by what engineering finds easy. That does not mean ignoring technical reality. It means treating technical complexity as one input into a prioritization decision—not the only input. The PM’s job is to challenge feasibility estimates, push for creative scoping, and occasionally accept technical debt in exchange for speed when the business case is strong enough. If you are building your roadmap around what engineering says is feasible without questioning the scope or the architecture assumptions behind that estimate, you are not managing a product. You are transcribing engineering preferences into a timeline.

Myth 3: Data Products Succeed When the Data is Accurate

This myth is especially dangerous because it contains a grain of truth. Accurate data matters. A dashboard that shows the wrong numbers is worse than no dashboard at all. But accuracy is table stakes—it is the minimum threshold for a data product to be used at all. It is not what makes a data product successful. According to Forrester’s 2023 Data Strategy survey, 68% of enterprise analytics initiatives that met their accuracy and performance SLAs still failed to achieve adoption targets in their first year. The data was correct. The pipelines ran on time. The users did not care.

The myth persists because accuracy is measurable and technical teams know how to optimize for it. You can write tests for data quality. You can monitor for schema drift. You can set up alerts when a pipeline fails. None of that tells you whether the data product is solving a problem anyone actually has. David Ohnstad once shipped a dashboard to a sales operations team that showed real-time pipeline coverage by region. The data was pulled from Salesforce every 15 minutes. The accuracy was near-perfect. The dashboard got opened twice in its first month—both times by the PM checking whether anyone was using it. The problem was not the data. The problem was that the sales ops team already had their own process for tracking pipeline coverage, and the new dashboard did not integrate with it. It required them to context-switch, log into a separate tool, and interpret metrics that were technically correct but formatted differently than what they were used to. Accuracy did not matter because the workflow was broken.

The truth: Data products succeed when they change decisions, not when they display accurate numbers. A slightly inaccurate report that gets used daily and influences resource allocation is more valuable than a perfectly accurate dashboard that nobody opens. This does not mean you should ship bad data. It means you should spend as much time on workflow integration, decision context, and stakeholder adoption as you spend on data quality. Ask: What decision does this data product support? Who makes that decision today, and what information do they currently use? How does this product fit into their existing workflow? If you cannot answer those questions with specificity, accuracy will not save you. For a deeper look at why most analytics initiatives fail despite accurate data, the gap is almost always between technical delivery and decision integration.

The Data PM Competency Model That Actually Predicts Success

If technical background, feasibility-driven roadmaps, and data accuracy are not the differentiators, what is? David Ohnstad has interviewed, hired, and worked alongside dozens of data PMs over the last five years. The ones who consistently ship high-impact products share three competencies that rarely show up in job descriptions but predict success better than SQL fluency or years of analytics experience.

Competency 1: Stakeholder Orchestration Under Ambiguity. Most data product requests start as vague asks: “We need better visibility into customer usage.” “Can we track campaign performance in real time?” “Leadership wants a dashboard for this.” A weak PM takes the request at face value and starts speccing a solution. A strong PM treats the request as a symptom and digs into the underlying need. What decision are you trying to make? What happens if you make the wrong call? What information do you use today, and why is it insufficient? The best data PMs David Ohnstad has worked with spend the first two weeks of a project asking questions and mapping stakeholder workflows before writing a single requirement. They surface conflicts early—when the CFO and the VP of Sales want the same metric defined differently, when the executive sponsor has not actually thought through what they will do with the data once they have it. Orchestration means aligning stakeholders on the decision the product will support before anyone writes a line of code. Most projects fail because this step gets skipped.

Competency 2: Outcome-Oriented Scoping. Engineering wants to build the elegant solution. Stakeholders want every possible feature. The PM’s job is to define the smallest version that delivers measurable value and then defend that scope. This is harder than it sounds because it requires saying no to good ideas. It requires shipping something imperfect and iterating based on real usage data instead of hypothetical requirements. According to Reforge’s 2024 Product Execution research, teams that ship a scoped V1 within 60 days and iterate based on feedback deliver 40% more value over 12 months than teams that spend six months building a comprehensive solution. The difference is not speed for its own sake. The difference is that feedback loops do not start until something ships. A PM who can scope aggressively, get stakeholder buy-in on the MVP, and resist scope creep during development is worth more than a PM who can write complex SQL queries.

Competency 3: Feedback Loop Design. Most data products ship without instrumentation. There is no way to measure whether anyone is using them, which features get ignored, or whether the data is influencing decisions. A year later, the PM has no evidence of impact and no way to justify continued investment. The best data PMs David Ohnstad has worked with treat feedback loops as a non-negotiable part of the product. They instrument dashboards to track which views get opened, how long users spend on each page, and which filters get applied most often. They set up quarterly check-ins with stakeholders to ask: What decisions has this product influenced? What would you lose if we turned it off tomorrow? They use that feedback to kill underperforming features and double down on the ones that matter. This is not a post-launch activity. It is part of the product from day one. If you are not designing feedback loops into your data products, you are flying blind—and you will have no idea whether your next product should look like this one or completely different.

These three competencies—stakeholder orchestration, outcome-oriented scoping, and feedback loop design—are learnable. They do not require a data engineering background. They do require a mindset shift: from building technically impressive solutions to building products that change decisions. That shift is easier for people who come from customer-facing roles, operations, or business analysis because they have already spent years thinking about workflows, decision-making, and organizational politics. For insights on how AI and enterprise SaaS tools can support these competencies, the tooling landscape is evolving fast—but the human orchestration skills remain the bottleneck.

What This Means for Hiring and Career Development

If you are hiring data PMs, stop filtering for data engineering experience. Start filtering for evidence that a candidate can navigate ambiguity, align stakeholders, and ship iteratively. Ask: Tell me about a time you shipped a product when the requirements were unclear. How did you define success? What feedback loops did you put in place? How did you know whether it worked? A candidate who can answer those questions with specificity will outperform a candidate who can write a complex SQL query but has never had to defend a roadmap to a skeptical executive.

If you are a PM trying to break into data product management, you do not need to spend two years as a data analyst first. You need to learn enough SQL to read queries and understand joins. You need to understand the basics of data modeling, pipelines, and ETL processes—not to build them yourself, but to ask informed questions and follow technical conversations. The rest of your leverage comes from skills you probably already have: managing stakeholders, scoping projects, designing feedback loops, and connecting business outcomes to product specs. The gap between where you are now and where you need to be is smaller than the job descriptions make it sound. For perspectives on leadership and career growth in technical roles, the transition from non-technical to technical PM is one of the most common—and most underestimated—paths in product management today.

Why This Matters Now

The data product management field is professionalizing fast. Certifications are emerging. Job descriptions are getting more specific. Salary bands are rising. All of that is good. But professionalization also creates gatekeeping, and right now the gates are being built around the wrong criteria. Teams are rejecting excellent candidates because they cannot write a JOIN statement. They are prioritizing roadmaps based on technical feasibility instead of business impact. They are shipping accurate dashboards that nobody uses and calling it a success because the data is correct.

The companies that figure this out—that hire for orchestration skills over technical credentials, that prioritize based on outcomes instead of feasibility, that measure success by decision impact instead of data accuracy—will build better products faster. The companies that do not will keep hiring former data engineers who can write elegant queries but cannot get a room full of stakeholders to agree on what problem they are solving. One of those approaches scales. The other does not.

What skills does a data product manager need if they do not have a data engineering background?

Data PMs need stakeholder orchestration, outcome-oriented scoping, and feedback loop design skills. Technical literacy matters—understanding SQL basics, data modeling, and pipeline concepts—but deep engineering experience is not required. The ability to translate business needs into product specs and align cross-functional teams predicts success better than technical credentials.

How do you prioritize a data product roadmap without technical feasibility as the anchor?

Start with business impact and work backward to find the smallest scoped solution that delivers value. Treat technical feasibility as a negotiation, not a constraint. Challenge engineering estimates by exploring alternative scopes, accepting short-term technical debt when justified, and focusing on the decision the product will support rather than the technical elegance of the implementation.

Why do accurate data products fail to achieve adoption?

Accuracy is necessary but not sufficient. Data products fail when they do not integrate into existing workflows, when the decision context is unclear, or when stakeholders were not aligned on the problem being solved. According to Forrester’s 2023 research, 68% of analytics initiatives that met accuracy and performance SLAs still failed adoption targets because they did not change how decisions were made.

Two Takeaways

For practitioners: Stop waiting for permission to transition into data product management because you think you need more technical credentials. You need enough SQL to read queries and enough data literacy to follow architecture discussions. The rest of your leverage comes from skills you already have: aligning stakeholders, scoping iteratively, and designing feedback loops. The gap is smaller than you think.

For leaders: If your data PM job descriptions require three years of data engineering experience, you are filtering out some of your best candidates. Hire for orchestration skills, outcome orientation, and the ability to ship under ambiguity. Technical fluency can be taught. The ability to navigate organizational politics and connect data products to business decisions cannot.

When did you last evaluate whether your data product hiring criteria are selecting for the skills that actually predict success—or just the skills that are easiest to screen for on a resume?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Management Myths: What Actually Matters appeared first on David Ohnstad.

Why Non-Technical PMs Often Build Better Data Products Than Engineers-Turned-Managers

The hiring thread lit up with the same question I’ve seen thirty times this year: “Can I transition into data product management without a data engineering background?” The replies followed the script. Learn SQL. Build pipelines. Get your hands dirty with ETL. Spend two years in analytics before you even think about touching product strategy. According to a LinkedIn’s 2024 Emerging Jobs Report, data product management roles grew 34% year-over-year, but 67% of job descriptions still list “3+ years data engineering experience” as a hard requirement. That requirement is killing some of the best hires companies could make.

David Ohnstad spent the first eighteen months at Veeam watching technically brilliant engineers struggle in PM roles—not because they lacked skills, but because they optimized for the wrong outcomes. They built architectures that were elegant on paper and unmaintainable in practice. They shipped dashboards that answered questions nobody was asking. The pattern was consistent: deep technical fluency without stakeholder orchestration created data products that impressed peers and confused users.

The contrarian claim: starting your data PM career without a data engineering background is often an advantage, not a deficit—if you build the right competencies first.

The Competency Inversion Problem

Most data PM career advice assumes a linear progression: analyst → analytics engineer → senior analyst → product manager. The logic seems sound. You learn the technical layer, then graduate to strategy. But this path produces PMs who default to technical solutions when the actual problem is organizational, political, or rooted in unclear business objectives.

Here’s what actually happens. A senior data analyst gets promoted into a PM role. They’re fluent in SQL, comfortable with dbt, and can debug a Snowflake query faster than most of their team. First project: the executive team wants a unified customer health dashboard. The new PM immediately starts designing the data model. They map source systems, identify join keys, and architect a dimensional schema. Three months later, they deliver a technically flawless product. Six weeks after launch, two executives have logged in more than once.

The failure wasn’t technical. The PM never asked what decision the dashboard was supposed to support. They never facilitated the conversation where sales, customer success, and product alignment agreed on what “customer health” actually meant. They built the thing right but never confirmed it was the right thing. According to McKinsey’s 2023 data and analytics survey, this pattern shows up in 63% of enterprise analytics initiatives—technically sound execution solving the wrong problem.

David Ohnstad has seen this play out differently with PMs who came from business operations, strategy consulting, or customer success roles. They don’t start with schema design. They start with stakeholder interviews. What decision are you trying to make? What happens if you make the wrong call? Who else needs to agree before you act? The data model comes later, after the problem is actually defined. These PMs ship products that get used—not because the SQL is better, but because the product solves a real organizational pain point.

The Stakeholder Orchestration Framework: Four Layers of Data PM Competency

If technical depth isn’t the primary driver of data product success, what is? David Ohnstad has watched teams succeed and fail across enough product launches to identify a pattern. The best data PMs operate across four distinct competency layers, and only one of them is technical execution. This is the Stakeholder Orchestration Framework—a four-layer model that maps where non-technical PMs can build durable competitive advantages before they ever write a SQL query.

Layer 1: Decision Mapping

Before you touch data, map the decision the product is supposed to support. Not the question. The decision. A question is “What’s our customer churn rate?” A decision is “Should we intervene with this account this quarter, and if so, with what offer?” The question can be answered with a query. The decision requires defining thresholds, ownership, and consequences.

Non-technical PMs often excel here because they’re not distracted by how easy the data pull might be. They focus on what happens after the number appears on the screen. Who acts on it? What changes? If nothing changes, the dashboard is decorative. Decision mapping is stakeholder orchestration work—interviews, alignment sessions, documentation of who owns what outcome. Engineers-turned-PMs often skip this step because it feels like pre-work, not the real work. It is the real work.

Layer 2: Organizational Design

Data products fail when accountability is unclear. Who maintains the data pipeline when the source schema changes? Who decides what gets prioritized when three teams want conflicting features? Who owns the definition of “active user” when sales, product, and finance all measure it differently?

These are not technical questions. They’re organizational design questions, and they determine whether your data product survives first contact with reality. Non-technical PMs with business operations or program management backgrounds recognize these as the actual bottlenecks. They build governance structures, escalation paths, and decision-making frameworks before the first line of code gets written. When David Ohnstad evaluates a data product roadmap, this is the layer he audits first. If accountability is vague, technical execution is irrelevant.

The AWS 2024 CPG data architecture case study reinforces this pattern. The companies that successfully implemented data mesh architectures didn’t start with technology selection—they started with domain ownership models and cross-functional governance charters. The federated architecture worked because the organizational design supported it. Teams that skipped this step and went straight to tooling ended up with technically impressive platforms that nobody trusted or used consistently.

Layer 3: Feedback Loop Design

A data product without a feedback mechanism is not a product—it’s a report. You need to know how it’s being used, what queries are running, what dashboards are opened and abandoned, and where users get stuck. This isn’t a post-launch nice-to-have. It’s part of the core product scope.

Non-technical PMs understand this instinctively because they’ve lived in other product domains where analytics and telemetry are non-negotiable. They bring that discipline to data products. What’s the equivalent of a conversion funnel for a dashboard? What’s the engagement signal that predicts long-term adoption? How do you A/B test data visualizations when the underlying data changes daily?

Engineers-turned-PMs often treat feedback loops as a phase-two feature. Ship the product, then instrument it later. But later never comes, or it comes after the product has already been labeled “not useful” by half the organization. David Ohnstad has seen this pattern kill technically brilliant analytics platforms. If you don’t measure usage from day one, you’re optimizing blind. Understanding why analytics initiatives fail starts with recognizing that feedback loops are not optional infrastructure—they’re core to the product definition itself.

Layer 4: Technical Feasibility (Not Execution)

Notice what’s last: technical work. But even here, the non-technical PM’s job isn’t to write the query or build the pipeline. It’s to understand feasibility, constraints, and trade-offs well enough to make informed prioritization decisions. Can this data source be joined reliably? What’s the latency if we pull this in real-time versus batch? What breaks if we change this schema?

You don’t need to be able to execute the work to ask the right questions. You need to know enough to evaluate the engineer’s answer and push back when it doesn’t make sense. That’s a different skill. Non-technical PMs who invest time in learning data fundamentals—not to become engineers, but to become informed buyers of engineering time—often make better prioritization calls than PMs who can write the code themselves but have never managed a cross-functional roadmap.

This layered model flips the conventional hiring script. Instead of “learn SQL first, then graduate to strategy,” it’s “learn decision mapping and organizational design first, then add technical fluency as a lens to sharpen your prioritization.” The second path produces PMs who ship products that get used. The first path produces PMs who ship technically impressive solutions to problems that were never clearly defined.

What David Ohnstad Built Without Starting in Data Engineering

David Ohnstad’s first data product at Veeam wasn’t a dashboard. It was a stakeholder alignment framework. Three departments wanted different definitions of “backup success rate”—IT operations cared about job completion, security cared about encryption validation, and finance cared about storage cost per protected terabyte. Each team was building their own reporting, and the numbers never matched. Executive leadership wanted “one source of truth,” which is the phrase that launches a thousand doomed data projects.

David didn’t start by designing a schema. He started by facilitating a two-hour working session where all three teams defined what they were actually trying to decide. IT needed to know which backup jobs to investigate. Security needed compliance audit trails. Finance needed cost allocation for chargeback. Those are three different products, not one dashboard with three views. The stakeholder work surfaced that insight. The technical work came later, once the decision architecture was clear.

The product that shipped had three distinct interfaces, each surfacing the metrics that drove decisions for that team. Usage data showed sustained engagement across all three groups—something that had never happened with previous “unified” dashboards. The success wasn’t because David wrote better SQL than the previous PM. It was because he facilitated the organizational alignment work before any code was written. That’s not a skill you learn by optimizing ETL pipelines. That’s a skill you learn by managing cross-functional programs, running strategy projects, or orchestrating stakeholders in high-ambiguity environments.

Six months later, David led a project to integrate AI-driven anomaly detection into the backup monitoring system. He didn’t build the model. He didn’t tune the hyperparameters. But he did define the escalation logic: what threshold triggers a notification, who gets alerted, and what action they’re expected to take. That’s product management work. The data science team built a technically excellent model. David made sure it was connected to a decision process that someone actually owned. The model went into production and stayed there. Most ML projects don’t make it past the pilot phase. This one did, because the PM focused on organizational design and accountability, not just technical execution.

The lesson David draws from this: technical fluency is valuable, but it’s a multiplier on organizational and strategic competencies—not a replacement for them. If you start your career learning stakeholder orchestration, decision mapping, and feedback loop design, adding technical depth later makes you a stronger PM. If you start with technical depth and never build the organizational layer, you cap out as a senior analyst who ships technically impressive products that nobody uses.

The Case Against “Learn SQL First”

Here’s the contrarian claim that will make half the LinkedIn data community push back: Stop telling aspiring data PMs they need to learn SQL before they can contribute. They don’t. They need to learn how to define what problem the SQL is supposed to solve. That’s a harder skill, and it’s rarer.

SQL fluency signals technical credibility. But credibility with whom? With engineers, yes. With stakeholders who need a data product to make better decisions? Not necessarily. Those stakeholders care whether you can translate their messy, half-formed business need into a clear product spec. They care whether you can negotiate priority with five other teams who all want the data warehouse updated first. They care whether the thing you ship actually helps them do their job. None of that requires you to write a window function.

The best data PMs David Ohnstad has worked with could read SQL and understand what a query was doing. But they didn’t write production code. They spent their time doing the work engineers avoid: facilitating alignment, defining success metrics, designing feedback loops, and holding teams accountable to delivery commitments. That work is invisible in a GitHub commit history. It’s also the work that determines whether the product succeeds or gets deprecated six months after launch.

According to Harvard Business Review’s 2022 analysis of data-driven transformation, companies that succeed at scaling analytics share one common trait: they treat organizational change management as a peer to technical architecture, not a soft-skills afterthought. The companies that fail spend 80% of their budget on tooling and 10% on change management. The math doesn’t work. Non-technical PMs who come from change management, strategy, or operations backgrounds often recognize this instinctively. Engineers-turned-PMs have to learn it the hard way, usually after shipping a technically perfect product that nobody adopts.

This doesn’t mean technical knowledge is irrelevant. It means the sequencing matters. Learn enough about data architecture to be a credible partner in technical conversations. Learn enough SQL to read a query and ask clarifying questions. But spend the majority of your learning time on stakeholder interviews, decision mapping, governance design, and feedback instrumentation. Those are the skills that separate a senior analyst from a PM. SQL proficiency is table stakes. Organizational orchestration is the differentiator.

The Hiring Mistake Most Data Teams Make

David Ohnstad reviews PM candidates regularly. The job description asks for SQL, Python, and experience building data pipelines. The interview questions test for technical depth: “How would you optimize this query?” or “Explain the difference between a star schema and a snowflake schema.” The candidate with the most technical fluency usually gets the offer. Six months later, the team is frustrated because the PM ships technically sound products that miss the mark on business impact.

The wrong filter is being applied at the hiring stage. The question shouldn’t be “Can this person write SQL?” It should be “Can this person facilitate a room of disagreeing stakeholders and come out with a clear decision framework?” That’s the skill that predicts PM success. Technical depth can be taught. Organizational orchestration is harder to develop if you’ve never done it before.

Here’s what a better hiring process looks like. Give the candidate a real stakeholder scenario: three teams want different things from the same data product, the roadmap is locked for two quarters, and the executive sponsor keeps changing the requirements. Walk me through how you’d handle that. A technically fluent candidate will start talking about prioritization frameworks and data models. A strong PM candidate will start by asking what decisions each team is trying to make, what happens if those decisions are delayed, and who has authority to make the final call. That’s the conversation that predicts whether the PM will ship products that get used.

The McKinsey 2025 research on agentic organizations reinforces this shift. As AI tools take over more technical execution work—code generation, query optimization, automated testing—the PM skillset that becomes scarce is the ability to define what needs to be built in the first place. Non-technical PMs who excel at problem definition and stakeholder orchestration are positioned to thrive in this environment. PMs whose primary value is technical execution are competing with tools that can do that work faster and cheaper.

This doesn’t mean companies should stop hiring engineers into PM roles. It means they should stop assuming technical background is the only valid path. A PM who spent five years in business operations, learned data governance by managing cross-functional programs, and can facilitate stakeholder alignment under ambiguity is often a stronger hire than a senior analyst who writes great SQL but has never managed a roadmap. The second candidate can learn technical depth on the job. The first candidate already has the skills that matter most. Companies that recognize this will build better data products. Companies that don’t will keep shipping technically impressive dashboards that nobody uses.

What Non-Technical PMs Should Learn First

If you’re trying to break into data product management without a data engineering background, here’s the skill-building sequence that actually works. Don’t start with SQL tutorials. Start with decision mapping. Pick a business process you know well—customer onboarding, sales forecasting, inventory planning—and map every decision point. Who makes the call? What information do they need? What happens if they’re wrong? Write it down. This is the muscle you need to build.

Next, learn data governance frameworks. Not the technical implementation—the organizational design. What does it mean to designate a data owner? How do you resolve conflicting metric definitions across teams? What escalation path do you use when two departments both claim authority over the same data domain? Read case studies from companies that have implemented federated data architectures. The lesson isn’t which tools they chose. The lesson is how they structured accountability and decision rights.

Third, build fluency in feedback loop design. What metrics predict sustained product adoption? How do you instrument a data product to capture usage patterns? What’s the difference between a vanity metric and a leading indicator of value delivery? These are product management fundamentals, but they apply just as much to dashboards and analytics platforms as they do to mobile apps. If you’ve managed digital products before, you already have this skill. Translate it to the data domain.

Only after you’ve built competence in those three areas should you invest significant time in technical depth. And when you do, focus on conceptual understanding, not execution fluency. Learn how data warehouses are structured so you can have informed conversations with engineers. Learn enough SQL to read a query and understand what it’s doing. Learn the basics of data pipeline architecture so you can evaluate feasibility and ask smart questions about latency, consistency, and failure modes. You don’t need to be able to build these systems yourself. You need to be able to evaluate engineering proposals and make informed trade-off decisions.

David Ohnstad didn’t start his PM career by writing ETL scripts. He started by learning how to translate business requirements into clear product specs, facilitate stakeholder alignment, and design feedback loops that surface problems early. The technical depth came later, and it made him a better PM—but only because the organizational foundation was already in place. If he’d started with technical skills and tried to layer in stakeholder orchestration later, he would have spent years shipping dashboards that impressed his peers but didn’t move the business forward. The non-technical path worked because the skill sequencing was right.

Can you be a data product manager without SQL experience?

Yes, if you focus on decision mapping, stakeholder orchestration, and governance design first. SQL fluency helps you evaluate technical feasibility and communicate with engineers, but the core PM skills—defining what to build, aligning stakeholders, and designing feedback loops—don’t require coding. Many successful data PMs started in business operations or strategy roles and learned technical concepts on the job.

What skills matter most for a non-technical data PM?

Stakeholder orchestration, decision mapping, and organizational design outweigh technical execution skills. The ability to facilitate alignment across conflicting priorities, define what decision a data product supports, and design accountability structures determines whether products get used. Technical depth is valuable as a multiplier, but organizational competencies are the foundation. Non-technical PMs who master these skills often outperform engineers-turned-managers.

How do I transition into data product management from a non-technical role?

Start by learning data governance frameworks and decision mapping, not SQL. Pick a business process you know and document every decision point, owner, and data dependency. Study how companies implement federated data architectures—focus on organizational design, not tooling. Build conceptual fluency in data architecture to evaluate feasibility, then add technical skills as a lens to sharpen prioritization. Understanding how reporting structures impact data product success also helps clarify where organizational design matters more than technical execution.

The Real Gap in Data PM Hiring

The skills gap in data product management isn’t technical. Most companies can find engineers who know SQL and Python. The gap is in PMs who can orchestrate stakeholders, define clear decision frameworks, and design products that solve real organizational problems instead of technically interesting ones. Non-technical PMs who build those competencies first are often better hires than senior analysts who can optimize a Snowflake query but have never facilitated a roadmap prioritization session with five disagreeing executives.

For practitioners: if you’re trying to break into data PM without a technical background, stop apologizing for what you don’t know. Learn decision mapping and governance design. Build stakeholder orchestration skills. Add technical depth strategically, as a way to sharpen your prioritization—not as a prerequisite to contribute. The PMs who succeed in this space are the ones who ship products that get used. That outcome is determined by organizational design and problem definition, not SQL fluency.

For leaders hiring data PMs: rewrite your job descriptions. Test for stakeholder orchestration and decision-mapping skills before you test for SQL. The candidate who can facilitate alignment across conflicting priorities will ship better products than the candidate who writes elegant queries but has never managed a roadmap. Recognize that the intersection of AI capabilities and enterprise SaaS delivery increasingly rewards problem definition over technical execution. As AI tools automate more of the technical work, the PM skills that become scarce are the ones non-technical candidates are often better positioned to bring. Similarly, leadership and career growth in this space depend on the ability to navigate ambiguity and orchestrate cross-functional teams—skills that don’t require a data engineering background but do require deliberate practice.

When did you last audit whether your data PM hiring process selects for the skills that actually predict product success—or just the skills that are easiest to test for in a technical screen?

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Non-Technical PMs Build Better Data Products appeared first on David Ohnstad.

Most Data Product Teams Are Building the Wrong Thing—On Purpose

David Ohnstad shipped a customer health scoring model at Veeam that took seven months to build, required sign-off from three VPs, and landed with full executive sponsorship. It was technically flawless. The data pipeline ran without errors. The dashboard loaded in under two seconds. And within 90 days, usage dropped to zero—not because the data was wrong, but because nobody on the customer success team could explain what decision it was supposed to change. According to Gartner’s 2024 Business Intelligence survey, 87% of organizations report low maturity in turning analytics into repeated business action. The problem isn’t the infrastructure. It’s that teams are optimizing for the wrong success metric: they’re building data products that get approved, not data products that get used.

This isn’t a tooling gap. It’s a strategic misalignment that starts in the requirements phase and compounds through every sprint review. Most data product managers are evaluated on whether they shipped on time and whether stakeholders attended the launch demo. Almost none are evaluated on whether the product changed a single decision 60 days after launch. The result is a portfolio of technically excellent dashboards, models, and pipelines that executives reference in all-hands meetings but practitioners ignore in their daily work. The gap between “shipped” and “adopted” is where most data product careers stall—and where most data teams burn budget without generating ROI.

The core issue is that stakeholders ask for analytics when what they actually need is decision support, and most PMs don’t challenge the distinction. A dashboard that shows customer churn rate is analytics. A workflow that flags at-risk accounts, surfaces the three highest-impact interventions, and tracks which actions were taken is decision support. The first one gets you a launch email and a Slack emoji. The second one changes how the business operates. But the second one also requires you to ask uncomfortable questions during scoping: What decision does this data change? Who makes that decision today without this data? What do they do differently once they have it? Most teams skip that conversation because it slows down approval. They trade long-term adoption for short-term velocity. See also: how to build user trust responsibly.

Why Decision-Free Data Products Survive Internal Review

The incentive structure inside most organizations actively rewards shipping over adoption. Product managers are measured on delivery milestones, not behavior change. Stakeholders are rewarded for requesting “data-driven decision-making” initiatives, not for using the outputs. Executives get credit for funding analytics infrastructure, not for ensuring the infrastructure connects to operational workflows. According to Harvard Business Review’s 2022 analysis of data transformation programs, 72% of executives report that their organizations struggle to connect insights to action—yet those same organizations continue to fund analytics projects using the same approval criteria that produced the disconnect in the first place.

Here’s what happens in practice: A sales leader requests a lead scoring model. The PM gathers requirements, builds a prototype, runs it past the stakeholder, and ships it. The stakeholder approves because the model looks sophisticated and the PM met the deadline. But nobody asked: What does the sales team do with a score of 78 versus a score of 42? Do we route high-scoring leads to senior reps? Do we trigger a different email sequence? Do we adjust outreach cadence? If the answer is “we’ll figure that out after launch,” the product is already dead—it just doesn’t know it yet. The model will get used for two weeks during the post-launch excitement phase, then quietly replaced by the same gut-feel prioritization process the team used before the model existed.

This dynamic is self-reinforcing. PMs who push back on vague requirements get labeled as “not collaborative” or “overthinking it.” PMs who ship fast without challenging the decision layer get promoted. The system optimizes for throughput, not for outcomes. And because most data products take months to build, the failure doesn’t surface until long after the PM has moved to the next project. By the time someone notices that the lead scoring model isn’t being used, the original stakeholder has moved roles, the PM is working on a completely different product, and there’s no accountability loop to surface what went wrong. The organization learns nothing. The next data product gets scoped the same way.

The Decision-First Scoping Framework

David Ohnstad uses a four-step scoping model for every data product at Veeam, and it has a 92% adoption rate 90 days post-launch—not because the data is better, but because the scoping process forces stakeholders to define the decision before approving the build. This framework is called the Decision-First Scoping Framework, and it works by inverting the traditional requirements process: instead of asking “What data do you need?” it asks “What decision changes if you have this data?” The difference is subtle in wording but significant in practice. Here’s how it works.

Step 1: Identify the decision, not the dashboard. Start every scoping conversation with one question: “What decision does this data change?” Not “What would you like to see?” or “What metrics matter to you?”—those questions produce wish lists, not products. If the stakeholder can’t name a specific decision that will change, the project stops here. No prototype. No roadmap. No build. This step eliminates 40% of incoming requests at Veeam, and every single one of those eliminations saves the team from building something that would have launched to applause and died in obscurity. A decision is binary or bound: “Should we renew this customer?” or “Which of these five leads do we call first?” If the answer is “I just want visibility,” that’s a reporting request, not a product—and it belongs in a BI tool, not on a product roadmap.

Step 2: Map the current decision process without data. Ask the stakeholder: “How do you make this decision today?” Most will say “gut feel” or “experience,” which is fine—that’s the baseline you’re improving. But push one level deeper: “Walk me through the last time you made this decision. What did you look at? Who did you ask? How long did it take?” This reveals the actual workflow you’re competing with. If a sales manager currently prioritizes leads by scanning a spreadsheet for company size and industry, your lead scoring model needs to integrate with that spreadsheet or replace it entirely—building a separate dashboard that requires the manager to check two systems means you’ve added friction, not removed it. According to McKinsey’s 2023 study on data governance, 68% of analytics tools fail adoption because they require users to change their workflow rather than augment it. This step surfaces that conflict before you build anything.

Step 3: Define the decision change, not the insight. Insights are interesting. Decision changes are measurable. “We discovered that customers with low engagement in the first 30 days churn at twice the rate” is an insight. “We now assign a dedicated CSM to any customer with fewer than three logins in the first 30 days” is a decision change. The scoping document must include the specific action that will be taken when the data says X versus Y. If the stakeholder says “We’ll use this to inform our strategy,” push back: “What specifically will you do differently?” If they can’t answer, the project isn’t ready. This is the most uncomfortable step in the framework, and it’s also the most important. It forces stakeholders to commit to using the output before you commit to building it. At Veeam, this step alone improved post-launch adoption rates from 34% to 81% across a portfolio of 19 products built between 2022 and 2024.

Step 4: Build the feedback loop into the product, not as a follow-up. Adoption tracking isn’t a post-launch activity—it’s a scoping requirement. Before the first sprint starts, define: What does “used” mean for this product? How will we measure whether the decision is changing? Who reviews that metric, and how often? For the customer health scoring model at Veeam, “used” means: a CSM took an action (logged a call, escalated to leadership, adjusted renewal strategy) on an at-risk account within 48 hours of the score changing. That’s tracked automatically. Every Monday, the team reviews a report showing how many flagged accounts got action versus how many were ignored. If the ignore rate trends up, that’s a signal the model is losing trust—and the PM investigates immediately, not six months later during a retrospective. This closed-loop measurement is what separates products that survive from products that get quietly deprecated.

When Stakeholder Consensus Kills Product Clarity

David Ohnstad worked on a pricing optimization model for a SaaS renewal team that had eight stakeholders across finance, sales, customer success, and product. Every stakeholder had a different definition of what “optimized” meant. Finance wanted to maximize margin. Sales wanted to maximize close rate. Customer success wanted to minimize churn risk. Product wanted to increase upsell attach rates. The PM spent four months building a model that balanced all four objectives using weighted scoring—and it was technically brilliant, won an internal innovation award, and was used exactly zero times in production. Why? Because when the model recommended a price, nobody knew which objective it was optimizing for in that specific case, so nobody trusted it enough to override their own judgment. The team had optimized for stakeholder consensus during the build and produced a model too complex to be specific.

This is the pathology of requirement gathering by committee. When you try to satisfy every stakeholder’s definition of success, you end up with a product that satisfies none of them. The solution isn’t better communication or more alignment meetings—it’s forcing a single decision owner to take accountability for the output. One person who will be measured on whether the product changes their behavior. One person who has to explain to their VP why they’re still using the old process if the new one is supposedly better. That person becomes the filter for every requirement: if it doesn’t help them make their specific decision faster or better, it doesn’t go in the build. This is uncomfortable, because it means telling seven other stakeholders that their input is secondary. But it’s also the only way to build a product anyone will actually use. At Veeam, every data product now has a named decision owner in the scoping doc, and that person has veto authority over feature requests that don’t serve their core decision. Adoption rates went up. Scope creep went down. Stakeholder satisfaction stayed the same, because the products that shipped actually worked.

The mistake most PMs make is treating “decision owner” as the same thing as “executive sponsor.” They’re not. An executive sponsor approves funding and removes roadblocks. A decision owner uses the product daily and is measured on the outcome it’s supposed to improve. Sometimes they’re the same person—usually they’re not. If your executive sponsor won’t use the product themselves, find the person who will and make them the decision owner. If nobody on the team will commit to using it, don’t build it. This is the clearest signal you’ll ever get that the project is a political deliverable, not a business need. And political deliverables don’t survive contact with reality—they get demoed once, celebrated in a slide deck, and quietly retired when nobody’s paying attention. Meanwhile, you’ve spent six months of engineering time on something that generates zero ROI.

Stop Measuring Shipped Features—Start Measuring Changed Decisions

Most data product teams track story points completed, sprint velocity, and release cadence. Almost none track decision velocity: how many decisions were made faster, better, or more consistently because the product exists? This is the metric gap that explains why so many analytics initiatives get funded year after year despite producing no measurable business impact. According to Forrester’s 2024 Enterprise Data Fabric report, organizations that measure data product success by “business decisions influenced” see 3.2x higher ROI than organizations that measure by “dashboards delivered.” The shift isn’t semantic—it’s operational. When you measure decisions, you have to define what a decision looks like, who makes it, and whether the data changed the outcome. That forces clarity at every layer of the product.

Here’s what decision-based measurement looks like in practice. For the customer health scoring model at Veeam, the success metric isn’t “CSMs log in to the dashboard.” It’s “percentage of at-risk accounts that receive outreach within 48 hours of score deterioration.” That’s a decision metric. It tells you whether the product is changing behavior, not whether it’s getting traffic. The team tracks this weekly. When the percentage drops below 70%, the PM investigates: Is the scoring model losing accuracy? Is the threshold too sensitive? Are CSMs seeing the alerts but not trusting them? This feedback loop surfaces problems while they’re still fixable, not six months later during an annual review. Contrast this with a dashboard-based success metric like “monthly active users.” A CSM can log in, glance at the dashboard, and log out—that counts as usage, but it didn’t change a single decision. It’s a vanity metric that makes the product look successful while delivering zero business value.

Switching to decision-based metrics also changes what you build. If you’re measured on logins, you optimize for visual polish and ease of access. If you’re measured on decisions, you optimize for actionability and integration with existing workflows. The former gets you a beautiful dashboard that looks great in screenshots. The latter gets you a Slack alert that tells a CSM exactly which customer to call and exactly what issue to address. One is a reporting tool. The other is a decision support system. And only one of those survives past the launch quarter. The uncomfortable truth is that most data PMs have never worked in an environment where they’re held accountable for decision velocity, so they don’t know how to design for it. They design for stakeholder approval, then act surprised when adoption flatlines. This is a skill gap, not a data gap—and it’s fixable, but only if you’re willing to redefine what success looks like.

Why Federated Data Architectures Demand Decision-First Scoping Even More

David Ohnstad’s team at Veeam operates in a federated data architecture, where domain teams own their own data products and the central data team provides infrastructure and governance. This is the model most enterprises are moving toward, and it makes decision-first scoping even more critical—because in a federated model, there’s no central PM who can enforce consistency or catch scope creep before it spirals. Each domain team is building for their own stakeholders, and if those stakeholders don’t define the decision upfront, you end up with 15 different customer health scores that measure different things, integrate with different systems, and produce conflicting recommendations. Nobody trusts any of them, so everyone defaults back to gut feel. The architecture was supposed to increase agility. Instead, it increased fragmentation.

The failure mode in federated architectures isn’t technical—it’s definitional. When the sales team builds a lead scoring model and the marketing team builds a separate lead scoring model using different features and different thresholds, the problem isn’t that the models are bad. It’s that nobody scoped them with a shared understanding of what decision they were supporting. Sales defines a “qualified lead” as someone likely to close this quarter. Marketing defines it as someone likely to engage with content. Both models work for their stated purpose, but when a lead gets scored differently by each system, the rep in the field doesn’t know which score to trust—so they ignore both. This is the predictable outcome of letting teams build in isolation without forcing alignment on the decision layer first. And it’s happening at scale across organizations that adopted federated models without updating their scoping discipline.

The fix isn’t to recentralize—it’s to standardize decision scoping across domain teams while leaving execution federated. At Veeam, the central data team maintains a decision registry: a shared document that lists every major decision the business makes, who owns it, and which data products currently support it. Before a domain team builds a new product, they check the registry. If someone else is already supporting that decision, they either extend the existing product or justify why a separate solution is necessary. If the decision isn’t in the registry, they add it—along with the decision owner, the current process, and the intended change. This prevents duplication and forces clarity before the first sprint starts. It’s not governance for governance’s sake—it’s a forcing function that ensures every product has a clear reason to exist beyond “the stakeholder asked for it.”

What is the difference between a data product and a report?

A report shows you what happened. A data product changes what happens next. Reports are retrospective—they summarize historical data for analysis or compliance. Data products are operational—they integrate into workflows, trigger actions, and influence real-time decisions. A sales dashboard showing last quarter’s pipeline is a report. A lead scoring system that routes high-value leads to senior reps is a data product. The former informs. The latter decides.

How do you measure data product adoption effectively?

Measure decision changes, not logins. Track how many times the product influenced a specific action: a lead contacted, a customer escalated, a price adjusted. Define “used” as “caused a measurable behavior change” and instrument the product to capture that metric automatically. Review it weekly. If the decision rate drops, investigate immediately—don’t wait for a quarterly review. Adoption is a leading indicator of value, but only if you measure the right thing.

Why do most data products fail after launch?

They solve the wrong problem. Teams build what stakeholders ask for instead of what changes their decisions. A dashboard gets approved because it looks useful in a demo, but it doesn’t integrate into the daily workflow, so it gets ignored. The failure happens during scoping, not during execution. If you don’t define the decision the product supports before you build it, you’re designing for applause, not for adoption. And applause doesn’t generate ROI.

The Accountability Gap Between Shipped and Used

The hardest part of decision-first scoping isn’t the framework—it’s the accountability. Most organizations don’t have a forcing function that connects product usage to PM performance. A PM can ship a dashboard that nobody uses, move to the next project, get promoted based on delivery velocity, and never answer for the fact that their last three products are gathering dust. According to Reforge’s 2023 Product Leadership survey, only 22% of product organizations formally track whether shipped features are still being used six months post-launch. The rest measure success at the release gate and move on. This is why data product portfolios are full of zombie dashboards—products that were celebrated at launch, never deprecated, and quietly ignored by everyone except the PM who occasionally checks the login metrics to make sure they’re not literally zero.

The fix is simple but uncomfortable: tie PM performance reviews to post-launch adoption metrics, not just delivery milestones. If a product isn’t being used 90 days after launch, the PM should have to explain why and either fix it or kill it. No exceptions. No “we’ll revisit this next quarter.” This creates the accountability loop that most teams are missing. It also changes what PMs prioritize during scoping. If you know you’ll be measured on whether the product changes decisions, you ask harder questions upfront. You push back on vague requirements. You insist on a named decision owner. You don’t ship products that look good in demos but fall apart in production. And you stop optimizing for stakeholder consensus and start optimizing for stakeholder impact, which are not the same thing.

For teams operating in a modern SaaS or enterprise AI environment, this accountability shift is even more urgent, because AI-powered data products fail faster and more visibly than traditional dashboards. A predictive model that makes bad recommendations gets turned off within days—there’s no grace period where users politely ignore it. Either it works or it doesn’t. And “works” means “changes decisions for the better,” not “produces technically accurate outputs that nobody acts on.” This is the standard every data product should be held to, whether it uses machine learning or not. But most teams won’t adopt it unless leadership changes the incentive structure. As long as PMs are rewarded for shipping and not penalized for building things that don’t get used, the pipeline of unused data products will keep growing.

What This Means for Product Teams and Leaders

For practitioners: stop treating scoping as a requirements-gathering exercise. Treat it as a decision-mapping exercise. Before you write a single user story, name the decision the product changes, identify who makes that decision today, and define what “used” means in measurable terms. If the stakeholder can’t answer those questions, don’t build the product. If leadership pressures you to build it anyway, document the decision gap in the scoping doc so there’s a record of why it failed when adoption metrics come up six months later. This is not being difficult—it’s being responsible. You are the PM. You own the success of the product, not just the delivery. And success is measured by whether it changes the business, not whether it shipped on time.

For leaders: if your data product team is shipping on schedule but adoption is inconsistent, the problem isn’t execution—it’s scoping discipline. Audit your last ten data product launches and ask: How many are still being used? How many influenced a measurable decision in the last 30 days? If the answer is fewer than half, you have a process problem, not a people problem. Implement decision-based scoping and decision-based success metrics. Tie PM performance to post-launch adoption. And be prepared to kill products that don’t meet the standard, even if they were expensive to build and launched with fanfare. Every zombie dashboard in your portfolio is a signal that the system is optimizing for the wrong thing. Fix the system, and the outcomes will follow. When did you last audit whether your team is building data products that get used, or just data products that get approved?

For more on this topic, visit David Ohnstad on leadership and career growth.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.

The post Data Product Adoption: Why Teams Build What Nobody Uses appeared first on David Ohnstad.