Data Product Hiring: Why Technical Requirements Backfire

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.