Data Product Prioritization: Managing Competing Stakeholder Requests

Photo by Jakub Żerdzicki on Unsplash

The Sales Ops Showdown: When Three Data Requests Hit Your Desk on the Same Tuesday

Three Slack messages arrived before 9 AM. Sales ops needed a customer acquisition dashboard by end of quarter. Marketing wanted the attribution model rebuilt from scratch. And the VP of engineering just flagged the data warehouse rewrite that had been “urgent” for six months. All three stakeholders believed their request was the priority. None of them were wrong.

According to McKinsey’s 2024 State of AI Report, 72% of organizations now classify themselves as “data-driven,” but only 31% report that their data teams can respond to business requests within agreed timelines. The gap is not a resourcing problem. It is a prioritization problem. And most data product managers are making prioritization decisions using frameworks designed for software products, not data products.

When HPCwire published their analysis last month arguing that data teams need to solve for “speed and scale,” they captured half the tension. Speed matters. Scale matters. But neither tells you what to build first when you have fifteen competing requests and four engineers. The missing piece is not velocity. It is the decision architecture that determines which velocity to optimize for.

Why Standard Product Prioritization Frameworks Break for Data Products

Most product teams use some version of RICE (Reach, Impact, Confidence, Effort) or a weighted scoring model. These work reasonably well for feature requests where the unit of value is a user interaction or a conversion event. They collapse when applied to data products, because data products operate on a different value curve.

A customer-facing feature delivers value when it ships. A data product delivers value when someone uses it to make a different decision than they would have made without it. That is not a semantic distinction. It changes what you measure, how you score impact, and what “done” actually means. According to Gartner’s 2023 analytics adoption study, 87% of enterprise BI projects achieve initial user adoption, but only 29% sustain usage beyond six months. The dropoff is not technical. It is decision architecture.

The failure pattern repeats: a data product manager receives a request, scopes the technical work, estimates effort, ships the dashboard or pipeline or dataset, marks it complete, and moves on. Six months later, nobody is using it. Not because the data was wrong. Because nobody defined what decision the data was supposed to change, who owned that decision, or how they would know if the data product succeeded.

This is where data product management strategy diverges from standard product work. You cannot prioritize data work using feature logic. You need a framework that scores requests based on decision impact, not user reach.

The Decision-Weight Prioritization Stack

Here is the framework I use when staring at fifteen competing data requests. David Ohnstad calls it the Decision-Weight Prioritization Stack, and it scores every request across four dimensions: Decision Frequency, Stakeholder Authority, Technical Dependency, and Political Capital Burn Rate.

Most prioritization models stop at impact and effort. That works for products where the PM controls the roadmap. Data product managers rarely control the roadmap. They negotiate it. The Decision-Weight Stack acknowledges that reality and builds negotiation leverage into the scoring model.

Step 1: Decision Frequency — How Often Will This Data Change a Choice?

Score each request based on how frequently the requester will use the data to make a different decision. Not how often they will look at it. How often it will change what they do.

High frequency: Daily operational decisions (pricing adjustments, inventory allocation, campaign spend). Score: 5 points.

Medium frequency: Weekly or monthly reviews that trigger tactical shifts (sales territory rebalancing, hiring pipeline adjustments). Score: 3 points.

Low frequency: Quarterly strategic reviews or one-time analyses. Score: 1 point.

The counterintuitive insight here: one-time executive requests often score higher on standard frameworks because of stakeholder seniority, but they deliver the least sustained value. A dashboard that changes daily pricing decisions for 40 account managers generates more cumulative decision value than a quarterly board deck, even if the board deck feels more important.

Step 2: Stakeholder Authority — Can the Requester Act on the Data?

This dimension eliminates ghost requests. A request has authority if the person asking for the data has the organizational power to act on what it reveals. If they need to escalate findings to someone else before anything changes, the request has low authority.

Direct authority: The requester owns the budget, headcount, or process the data will inform. Score: 5 points.

Indirect authority: The requester will present findings to a decision-maker, but does not control the outcome. Score: 2 points.

No authority: The requester is conducting exploratory analysis with no committed next action. Score: 0 points.

According to Harvard Business Review’s 2022 study on data culture, organizations with clearly defined data ownership structures achieve 3.5x higher ROI on analytics investments than those without. This step operationalizes that finding. If the person asking for data cannot act on it, the request should not block higher-authority work.

Step 3: Technical Dependency — What Else Breaks If You Skip This?

Some requests are not valuable in isolation, but become blockers if deferred. This dimension scores whether a request is on the critical path for other work.

Critical dependency: Three or more other requests depend on this pipeline, schema change, or infrastructure upgrade. Score: 5 points.

Moderate dependency: One or two downstream requests are blocked. Score: 3 points.

Independent: No other work depends on this request. Score: 1 point.

This is where infrastructure rewrites and technical debt finally get honest scoring. The data warehouse rewrite that engineering has been pushing for six months might score low on decision frequency and stakeholder authority, but if it is blocking the sales ops dashboard, the attribution model rebuild, and two other requests, it becomes the highest-priority item by dependency logic.

Step 4: Political Capital Burn Rate — What Does It Cost to Say No?

Every data PM operates with a limited reserve of organizational trust. Saying no to a VP of sales costs more political capital than saying no to a mid-level analyst. This dimension scores the reputational cost of deferring a request.

High burn rate: Saying no damages a critical stakeholder relationship or violates a previous commitment. Score: -3 points (negative score increases priority).

Medium burn rate: Deferral creates friction but does not break trust. Score: -1 point.

Low burn rate: The requester will accept a reasoned no or a delayed timeline. Score: 0 points.

This is the dimension most product frameworks ignore, because most product managers are not negotiating roadmaps with executives who believe their request is the only one that matters. David Ohnstad has sat in enough stakeholder reviews to know that purely rational prioritization loses to political reality. The Decision-Weight Stack acknowledges that and makes it explicit.

How the Framework Played Out in a Real Product Cycle

Six months ago, I was staring at the exact scenario described at the start of this article. Sales ops wanted their dashboard. Marketing wanted the attribution model. Engineering wanted the warehouse rewrite. I scored all three using the Decision-Weight Stack.

Sales ops dashboard: Decision Frequency = 5 (daily pricing decisions), Stakeholder Authority = 5 (VP of sales owned the process), Technical Dependency = 1 (independent request), Political Capital = -3 (VP had escalated twice). Total: 14 points.

Attribution model rebuild: Decision Frequency = 3 (monthly budget reviews), Stakeholder Authority = 2 (marketing analyst would present findings to CMO), Technical Dependency = 1 (independent), Political Capital = 0 (requester was flexible). Total: 6 points.

Data warehouse rewrite: Decision Frequency = 1 (one-time migration), Stakeholder Authority = 2 (engineering VP had indirect authority through platform stability), Technical Dependency = 5 (three other requests blocked), Political Capital = -1 (VP was persistent but not escalating). Total: 9 points.

The Decision-Weight Stack said: ship the sales ops dashboard first, then tackle the warehouse rewrite, then revisit the attribution model. That order violated my instinct, which was to clear the technical debt (warehouse rewrite) before building anything new. But the scoring was correct. The sales ops dashboard unblocked $4.2M in pricing optimizations in the first quarter. The warehouse rewrite, once completed, cleared the path for five downstream requests. The attribution model, when we finally built it four months later, revealed that marketing’s hypothesis about channel mix was wrong—but by then, the team had already shifted strategy based on qualitative feedback, so the data product became confirmatory rather than decision-driving.

The lesson: gut instinct told me to prioritize technical foundation. The framework told me to prioritize decision velocity. The framework was right. This connects directly to the point David Ohnstad makes about AI and enterprise SaaS: the infrastructure work feels urgent because it is visible and measurable, but the decision-support work drives revenue.

When Technical Debt Becomes a Blocker vs. a Distraction

The hardest prioritization question data PMs face is not “what should I build next?” It is “when do I stop building new features and fix the infrastructure?” Most teams err in one of two directions: they defer technical debt until the system breaks, or they obsess over infrastructure perfection and never ship anything valuable.

The Decision-Weight Stack resolves this by making technical dependency an explicit scoring dimension. Infrastructure work earns priority when it blocks high-value requests, not when it feels technically uncomfortable. If you have a pipeline that runs slowly but does not block any downstream work, it is a distraction. If you have a schema migration that prevents three teams from accessing the data they need, it is a blocker.

According to Forrester’s 2023 State of Data and Analytics Report, 63% of data engineering teams report spending more than 40% of their time on maintenance and technical debt remediation. The problem is not that teams are ignoring infrastructure. It is that they are treating all technical debt as equally urgent, which means they are constantly firefighting instead of building.

The Decision-Weight Stack forces a different question: what decisions are currently blocked by this technical issue? If the answer is “none,” defer it. If the answer is “three VP-level stakeholders cannot get the data they need,” it moves to the top of the queue regardless of how boring the work feels.

How to Say No Without Losing Stakeholder Trust

The hardest part of prioritization is not scoring requests. It is communicating the outcome to stakeholders who believe their request is the most important. Most data PMs handle this poorly. They either avoid the conversation (leading to passive-aggressive Slack threads) or they justify the no using technical jargon (leading to stakeholders who feel dismissed).

Here is the script I use when deferring a request: “I scored this request against the four criteria we use to prioritize data work: how often it will change a decision, whether you have authority to act on it, whether it blocks other work, and what it costs us politically to defer it. Based on that scoring, here is where it ranks relative to the other twelve requests we are currently evaluating. Here is when I expect to revisit it. And here is what would need to change for it to move up in priority.”

This script does three things. First, it shows that you have a methodology, not a gut feeling. Second, it makes the tradeoff explicit—stakeholders understand that saying yes to their request means saying no to someone else. Third, it gives them a path to escalation. If they believe your scoring is wrong, they can challenge the criteria. That is a productive conversation. What kills trust is when stakeholders believe prioritization decisions are arbitrary.

This is where leadership philosophy intersects with tactical execution. As David Ohnstad writes about leadership and career growth, the best managers do not dictate solutions—they coach teams through ambiguity by making decision criteria transparent and negotiable.

The Myth That More Data Solves Prioritization

Most data PMs, when they struggle with prioritization, assume the problem is insufficient information. They build more elaborate scoring models, add more criteria, or conduct stakeholder surveys to quantify importance. This is a mistake. More data does not improve prioritization decisions when the problem is not measurement—it is alignment.

The Decision-Weight Stack is not an optimization algorithm. It is a negotiation framework. The point is not to compute the objectively correct priority order. The point is to make the tradeoffs visible so that stakeholders can argue about them productively. If a VP of sales believes their dashboard should rank higher than the framework scores it, they can make that case by explaining why the decision frequency is higher than I estimated or why the political cost of deferral is steeper than I assumed. That is a conversation worth having.

What does not work is pretending that prioritization is a purely technical exercise. According to research from Reforge’s product leadership program, the most effective product managers spend less time optimizing their prioritization frameworks and more time negotiating alignment with stakeholders before decisions get contentious. The framework is a tool for making that negotiation legible, not a replacement for judgment.

Why ML Model Governance Changes What Data Bottlenecks You Should Solve First

If your organization is deploying machine learning models in production, your prioritization calculus changes. Data quality issues that would be minor annoyances in a reporting context become compliance risks in an ML context. Missing values that a human analyst can eyeball and adjust become training data drift that silently degrades model performance.

This is where the Decision-Weight Stack needs an additional filter: regulatory exposure. If a data pipeline feeds a model that makes automated decisions about credit, hiring, or pricing, any data quality issue in that pipeline carries legal risk. Those requests score higher on Technical Dependency even if they are not blocking other product work, because the failure mode is not “stakeholders complain”—it is “regulators audit you.”

According to research on ML model governance frameworks, organizations that treat training data as a compliance artifact (not just a technical input) report 40% fewer post-deployment model issues. If you are a data PM supporting ML products, your prioritization framework needs to account for this. A schema migration that fixes a training data inconsistency should score higher than a dashboard that makes executives feel informed but does not change their decisions.

The Prioritization Framework I Wish I Had Used Two Years Ago

Two years ago, I was managing a data product roadmap at a SaaS company where every department head believed their data request was the most urgent. I used a weighted scoring model that ranked requests by estimated revenue impact. It was a disaster. Revenue impact is impossible to estimate accurately for data products, which meant every stakeholder inflated their estimates, and I spent half my time adjudicating disputes about whose projection was more credible.

If I could go back, I would have used the Decision-Weight Stack from day one. Not because it produces perfect answers, but because it reframes the conversation. Instead of arguing about whose revenue projection is correct, stakeholders argue about decision frequency, authority, and political capital. Those are negotiable. Revenue projections are not.

The other mistake I made: I treated prioritization as a quarterly exercise. I scored requests at the start of the quarter, locked in a roadmap, and then ignored new requests until the next planning cycle. This created a perverse incentive where stakeholders would escalate aggressively to get their request into the current quarter, because they knew deferral meant a three-month delay.

What I do now: I re-score the roadmap every two weeks. New requests do not wait for the next planning cycle—they get scored immediately and inserted into the queue based on their Decision-Weight. This eliminates the escalation game, because stakeholders know that if their request scores higher than existing work, it will get prioritized regardless of when they submitted it.

How to Implement the Decision-Weight Stack on Your Team

Start by scoring your current roadmap. Take the next five requests on your backlog and walk through all four dimensions: Decision Frequency, Stakeholder Authority, Technical Dependency, and Political Capital Burn Rate. Do this in a 30-minute working session with your engineering lead and your most senior stakeholder.

The goal is not to achieve perfect scores on the first pass. The goal is to surface the criteria you are using implicitly and make them explicit. Most data teams are already making these tradeoffs—they just are not naming them, which means stakeholders perceive prioritization as arbitrary.

Once you have scored your current roadmap, publish the framework to your stakeholders. Do not ask for permission. Do not frame it as a proposal. State: “This is the methodology we use to prioritize data product work. Here is how your request scored. Here is where it ranks relative to other requests. If you believe the scoring is incorrect, here is how to challenge it.”

Expect pushback. Expect at least one VP to argue that their request should override the framework. That is fine. The framework is not designed to eliminate disagreement. It is designed to make disagreement productive. When a stakeholder argues that their request is more important than the framework suggests, you now have a structured conversation about which dimension they believe is scored incorrectly.

What is the Decision-Weight Prioritization Stack?

The Decision-Weight Prioritization Stack is a framework for scoring data product requests across four dimensions: Decision Frequency (how often the data will change a choice), Stakeholder Authority (whether the requester can act on the data), Technical Dependency (whether other work is blocked), and Political Capital Burn Rate (the reputational cost of saying no). It produces a weighted score that prioritizes requests based on decision impact rather than feature reach.

How do you prioritize data products when stakeholders disagree?

Make the prioritization criteria explicit and negotiable. Use a structured framework like the Decision-Weight Stack to score requests, then publish the scoring methodology to stakeholders. When disagreements arise, shift the conversation from “whose request is more important” to “which scoring dimension is incorrect.” This reframes prioritization as a negotiation based on shared criteria rather than an authority contest.

When should technical debt take priority over new data product features?

Technical debt earns priority when it blocks high-value downstream work, not when it feels technically uncomfortable. Score infrastructure requests using the Technical Dependency dimension: if three or more valuable requests are waiting on a schema migration or pipeline rewrite, it moves to the top of the queue. If the technical debt does not block decision-driving work, defer it.

Two Takeaways and One Hard Question

For practitioners: Stop treating prioritization as an optimization problem and start treating it as a negotiation problem. The Decision-Weight Stack is not an algorithm—it is a framework for making tradeoffs visible and defensible. Implement it by scoring your current roadmap in a 30-minute working session, then publishing the methodology to stakeholders.

For leaders: If your data teams are constantly firefighting and never shipping high-value work, the problem is not resourcing or velocity. It is prioritization. Audit whether your teams have a structured methodology for scoring requests, or whether they are making decisions based on whoever escalates loudest. The latter is not sustainable.

One question for you: When did you last revisit the data products your team shipped six months ago to check whether anyone is still using them to make decisions? If the answer is “never,” you are optimizing for shipping, not for impact—and that is the gap where most data product management frameworks break down.

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.