Data Product Prioritization: Solving the Speed-Scale Conflict

Photo by mahyar motebassem on Unsplash

When Speed and Scale Collide: The Data Product Prioritization Problem Nobody’s Solving

Three weeks ago, a director of sales ops walked into my office with a spreadsheet showing seventeen outstanding data requests—five of them over four months old. Two hours later, the VP of engineering escalated a pipeline rewrite that had been deferred twice. By end of day, I had a Slack message from finance asking why their cost allocation dashboard was “still not ready” six months after the kickoff meeting. HPCwire’s recent piece on moving from data bottlenecks to data products captures the tension perfectly: organizations want both speed and scale, but nobody’s addressing the brutal operational reality that sits between the vision and the execution. When you’re staring at a backlog that would take eighteen months to clear with the team you have, how do you actually decide what ships first?

According to Gartner’s 2024 Data and Analytics Leadership Report, 68% of data and analytics leaders cite prioritization as their top operational challenge—ahead of hiring, ahead of tooling, ahead of executive alignment. The problem isn’t a lack of frameworks. The problem is that most prioritization frameworks treat data products like software features: score them on impact and effort, stack rank, and ship. But data products don’t behave like features. They have compounding dependencies, hidden technical debt that only surfaces mid-build, and stakeholders who think their request is always the most urgent because they don’t see the fifteen others in the queue. The math that works for a product backlog breaks when applied to a data roadmap, and the gap between what practitioners say they prioritize and what actually ships is where roadmaps collapse.

The Hidden Cost of Saying Yes to Everything

Most data product teams don’t fail because they prioritize poorly. They fail because they never say no. According to McKinsey’s 2023 State of Data Infrastructure report, data teams that operate without formal prioritization gates deliver 40% fewer high-impact products per year than teams with explicit rejection criteria—not because they ship less, but because they ship the wrong things. Every stakeholder request that makes it onto the roadmap without a clear decision framework attached creates three downstream costs: engineering cycles spent on rework when requirements shift, PM time wasted translating between conflicting stakeholder languages, and opportunity cost from the high-impact work that never started because the team was underwater.

Here’s what that looks like in practice. A financial services company I consulted with last year had eleven data products in active development. Three of them had been “in progress” for over nine months. When we audited the backlog, we found that seven of the eleven products were initiated because a VP-level stakeholder asked for them directly—not because they mapped to a strategic outcome, not because usage data suggested demand, but because someone senior said “we need this.” The team had no formal mechanism to evaluate whether those requests aligned with company goals or had any measurable success criteria. So they said yes to everything, shipped almost nothing, and burned out two senior engineers in the process. The real cost wasn’t the wasted engineering time. It was the three high-impact products that never got staffed because the roadmap was already full of half-finished work that nobody was using.

The Priority Stack: A Four-Layer Decision Model for Data Product Roadmaps

David Ohnstad has spent the last eight years building and refining a decision model specifically for data product prioritization. It’s called the Priority Stack, and it’s built on the assumption that most prioritization frameworks optimize for the wrong outcome. They optimize for stakeholder satisfaction—getting requests into the backlog so people feel heard—when they should optimize for decision velocity: how fast can we move from request to shipped product that changes a business outcome. The Priority Stack has four layers, evaluated sequentially, and every request must clear all four before it enters the roadmap. Most requests fail at layer two.

Layer 1: Decision Clarity. What specific decision will this data product enable, and who is responsible for making that decision? Not “better visibility into sales performance”—that’s a vague wish, not a decision. A valid answer looks like this: “Regional sales directors will use this dashboard to decide whether to reallocate budget from underperforming territories to high-growth markets on a quarterly basis.” If the stakeholder can’t name the decision and the decision-maker, the request gets rejected at intake. According to research from Locally Optimistic, 61% of data product requests fail this test when forced to articulate it upfront. That’s not a problem—it’s a filter working correctly. Those requests would have failed later, after you’d already spent engineering cycles on them.

Layer 2: Outcome Measurability. How will we know if this product succeeded? The answer must be a number with a timeline. “Sales directors will make reallocation decisions 40% faster, measured by comparing decision cycle time in Q2 vs. Q4” is measurable. “Improved decision-making” is not. This layer kills roughly 30% of requests that survive layer one, because stakeholders often can’t define success in measurable terms—which means the product has no feedback loop, no way to know if it’s working, and no reason to maintain it once shipped. If you can’t measure success, you’re not building a product. You’re building a science project.

Layer 3: Political Capital Assessment. This is the counterintuitive layer, and it’s the one most prioritization frameworks ignore entirely. Every data product consumes political capital—from the PM who has to negotiate requirements, from the engineers who have to pause other work, and from the executive sponsor who has to defend why this shipped instead of someone else’s request. High-impact products are worth the capital spend. Low-impact products that consume capital you’ll need later for something strategic are net-negative, even if the effort score is low. David Ohnstad learned this the hard way three years ago when he greenlit a “quick” executive dashboard that took two sprints to build but required five months of stakeholder negotiation because it surfaced data discrepancies between two departments. The dashboard worked. But the political cost of resolving those discrepancies meant he couldn’t get buy-in for a customer churn prediction model that would have delivered 10x the business value. The question at layer three is not “can we build this?” It’s “is this worth the capital we’ll spend defending it?”

Layer 4: Dependency Mapping. What technical or organizational dependencies does this product require, and how many of them are outside your team’s control? A product that depends on a data source you own and a stakeholder who reports to your executive sponsor is low-risk. A product that depends on three upstream systems, two of which are managed by teams in different business units, is high-risk—not because the technical work is harder, but because your velocity is now controlled by people who don’t report to you and don’t share your roadmap priorities. According to Forrester’s 2024 Data Strategy report, products with more than two external dependencies take 2.3x longer to ship than initially estimated. That’s not a planning failure. That’s a structural constraint. Layer four forces you to account for it upfront, before you commit to a delivery timeline you can’t control.

When Technical Debt Becomes a Prioritization Blocker

Here’s the part that most data PMs get wrong: they treat technical debt as a separate category from feature work, something you “pay down” when you have capacity. But in data products, technical debt doesn’t sit quietly in the background—it actively blocks new work from shipping. A poorly designed data model doesn’t just slow down queries. It prevents you from adding new dimensions without a full rewrite. A pipeline that’s held together with manual intervention scripts doesn’t just risk breaking—it means every new data source requires custom logic that only one person on your team understands. When technical debt reaches a certain threshold, it stops being a maintenance problem and becomes a prioritization constraint. You can’t ship the high-impact product because the infrastructure required to support it doesn’t exist.

David Ohnstad encountered this two years ago while building a customer health scoring model. The model itself was straightforward—usage data, support ticket volume, contract renewal history. But the data sources lived in four different systems with inconsistent timestamps, and the ETL pipeline that was supposed to unify them had been patched so many times that nobody on the team could confidently explain how it handled duplicate records. The product manager’s instinct was to build the model first and fix the pipeline later. That would have been a disaster. If the underlying data couldn’t be trusted, the model’s output would be garbage, and stakeholders would lose confidence in every data product the team shipped after that. So David did the thing that felt wrong in the moment: he paused the model build, allocated two sprints to pipeline cleanup, and told the stakeholder the delivery date was moving by six weeks. The stakeholder wasn’t happy. But when the model shipped, it worked immediately, required zero post-launch fixes, and became the template for every predictive model the team built afterward. The lesson: technical debt becomes a prioritization blocker the moment it threatens the credibility of your output. At that point, it’s not optional maintenance—it’s the highest-priority item on your roadmap.

This is where David Ohnstad on AI and enterprise SaaS becomes directly relevant: if you’re building ML-driven data products, the governance layer—how you version models, track lineage, and audit output—is not separate from prioritization. It is prioritization. A model you can’t explain to stakeholders is a model you can’t ship. A prediction you can’t trace back to source data is a prediction that regulators won’t let you use. The infrastructure that makes models governable must exist before you commit to building the model, or you’re committing to a roadmap that can’t clear legal review.

The Real Prioritization Problem: You Can’t Say No Without a Framework

Here’s the contrarian claim that most senior data leaders push back on: stop optimizing for stakeholder satisfaction. Stakeholder satisfaction is a lagging indicator that measures whether people got what they asked for, not whether what they asked for solved the problem. According to research from Reforge, data teams that score highest on stakeholder satisfaction surveys often score lowest on product impact metrics—because they’re shipping what stakeholders request, not what stakeholders need. The goal is not to make people happy. The goal is to ship products that change decisions. Those two things overlap less often than most PMs assume.

The uncomfortable truth is that saying no without a framework feels arbitrary. When you reject a request because “we don’t have capacity,” stakeholders hear “your work isn’t important enough.” But when you reject a request because “this failed layer two of the Priority Stack—there’s no measurable outcome defined,” stakeholders hear “the ask isn’t ready yet, come back when you can articulate success criteria.” The first response creates resentment. The second creates accountability. A prioritization framework isn’t just a decision tool for the PM—it’s a communication tool that turns subjective judgment calls into objective evaluation criteria. The framework doesn’t make the politics go away. It makes the politics predictable.

This connects directly to the organizational culture shift required to execute a prioritization strategy effectively. As explored in David Ohnstad on leadership and career growth, data product prioritization requires leaders to coach their teams through ambiguity rather than dictate solutions. When a stakeholder’s request gets rejected at layer one because they can’t define the decision the product is supposed to support, that’s not a failure—it’s a coaching moment. The PM’s job in that moment is not to fix the request for them. It’s to help them understand why decision clarity matters and what a well-formed request looks like. Over time, stakeholders stop submitting half-baked requests because they’ve internalized the framework. The backlog shrinks not because the PM is saying no more often, but because stakeholders are self-filtering before they submit.

What This Means for Mid-Year Roadmap Resets

If you’re reading this in mid-2025, you’re likely staring at a roadmap that’s underwater. According to Gartner’s 2024 Data and Analytics Leadership Report, 73% of data teams enter Q3 with at least 40% of their H1 commitments still in progress. That’s not a velocity problem. That’s a prioritization problem. You committed to work that couldn’t clear the Priority Stack, and now you’re paying the cost in delayed delivery and stakeholder frustration. The fix is not to work faster. The fix is to audit your current roadmap against the four-layer model and kill everything that fails layer two. That will be uncomfortable. Some of those projects have executive sponsors. Some of them have been “almost done” for months. Kill them anyway.

Here’s what the audit looks like in practice. Pull your current roadmap. For every active project, write down the specific decision it enables and the measurable outcome that defines success. If you can’t write those two things in one sentence each, the project fails the audit. It doesn’t matter how much time you’ve already spent on it—that’s sunk cost. The question is whether continuing to invest in it will produce a shipped product that changes a business outcome. If the answer is no, stop working on it today. Redeploy the engineering capacity to something that can clear all four layers. You will ship fewer things this quarter. But the things you ship will actually get used, and that’s the only metric that compounds over time.

How do you prioritize data products when every stakeholder says their request is urgent?

Use a four-layer decision framework that evaluates requests based on decision clarity, outcome measurability, political capital cost, and dependency risk. Requests that can’t define a specific decision or measurable success criteria get rejected at intake, regardless of stakeholder seniority. This shifts prioritization from subjective judgment to objective evaluation criteria that stakeholders can understand and predict.

What is the biggest mistake data product managers make when building roadmaps?

They optimize for stakeholder satisfaction instead of decision impact. Data teams that score highest on stakeholder satisfaction surveys often score lowest on product impact metrics because they’re shipping what stakeholders request, not what stakeholders need. A prioritization framework that filters requests based on measurable outcomes prevents this misalignment from reaching the roadmap.

When should technical debt become a prioritization blocker instead of background maintenance?

Technical debt becomes a prioritization blocker the moment it threatens the credibility of your output or prevents high-impact work from shipping. If your data infrastructure can’t support the product you need to build, or if poor data quality will make stakeholders distrust your results, pausing feature work to fix the foundation is not optional—it’s the highest-priority item on your roadmap.

Two Takeaways: One for Practitioners, One for Leaders

For practitioners: Build the Priority Stack into your intake process today. Not next sprint. Today. Every request that enters your backlog must clear all four layers before it gets a ticket number. You will reject more requests in the first month than you’re comfortable with. That discomfort is the filter working. The goal is not to make stakeholders happy. The goal is to ship products that change decisions, and every request that fails the framework is a future failed product you just avoided spending three months building.

For leaders: Your data PM’s job is not to say yes to every stakeholder. If your PM has a 90% stakeholder satisfaction score, that’s a red flag—it means they’re not filtering aggressively enough, and your roadmap is full of low-impact work that won’t move business metrics. Give them air cover to say no. When a VP escalates a rejected request, your response should be “walk me through how this cleared the Priority Stack” not “why did you say no to this executive?” The framework only works if leadership enforces it when the pressure comes from above.

When was the last time you audited your roadmap not for what’s shipping, but for what’s consuming political capital without delivering measurable outcomes? If the answer is “never,” you’re not managing a roadmap—you’re managing a wishlist with deadlines attached. The difference between the two is whether you’re optimizing for throughput or impact, and only one of those keeps your team from burning out while delivering nothing that matters.

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.