Paradox: Enterprises pour millions into AI, yet 70% of data products never move the needle

When a $5 million AI model lands on a dashboard and nobody asks “What decision does this support?” the result is a costly ghost. David Ohnstad watched a Veeam analytics feature sit idle for months while the finance team kept asking for ROI numbers. According to Gartner’s 2024 Forecast, 71% of data initiatives fail to deliver measurable ROI.

Why Data Product ROI Gets Ignored and What Happens

Skipping a concrete ROI model turns a data product into a vanity metric. The failure mode is simple: budget overruns, stakeholder fatigue, and eventual shutdown. A mid‑size retailer in 2023 invested $2.2 M in a customer‑segmentation pipeline, only to discover the model never entered production because the marketing team couldn’t see the incremental revenue impact. The project was killed after 11 months, costing the company an additional $500 K in sunk engineering time.

When ROI is invisible, the data product lives in a feedback vacuum. Without a loop that ties usage back to profit or cost‑to‑serve, the product becomes a data‑dump rather than a decision engine. The result is the same pattern Bain highlighted in “Why AI Stumbles Without a Solid Data Strategy”: AI projects flounder when the underlying data economics are undefined.

Value‑Flow ROI Framework

This is a five‑step process that quantifies every dollar flowing into and out of a data product. The steps are deliberately counter‑intuitive; they force you to look beyond traditional cost accounting.

1. Data‑Acquisition Cost Ledger – Capture not just licensing fees but also the hidden labor of data contracts, compliance reviews, and schema harmonization. In many enterprises, contract overhead adds 12‑18% to raw data spend.
2. Pipeline Efficiency Ratio – Measure processing time versus business‑critical latency thresholds. A 20% reduction in latency often translates to a 5% lift in conversion for real‑time recommendation engines.
3. Incremental ARR Attribution – Tie new revenue directly to the data product. Use A/B testing or causal inference to isolate the uplift. According to McKinsey’s 2023 State of AI, firms that attribute ARR at product level see three‑times higher net‑benefit.
4. Cost‑to‑Serve Savings Calculator – Quantify reductions in manual reporting, data‑engineer overtime, and third‑party vendor fees. Forrester’s 2022 AI Business Impact Study found AI projects without this calculation cost 27% more on average.
5. Feedback‑Loop Revenue Index (FLRI) – Combine usage frequency, decision‑impact score, and satisfaction surveys into a single KPI. When FLRI dips below 0.6, the product is at risk of becoming a dead weight.

Why this matters: most teams stop at step 1, assuming that knowing the acquisition cost is enough. The reality is that the downstream economics—especially incremental ARR and cost‑to‑serve savings—drive the business case. By closing the loop with FLRI, you embed a continuous validation mechanism directly into the product’s health dashboard.

Practitioner Example: The Silent Data Leak That Cost $850 K

In Q2 2025, Veeam launched a new data‑quality monitoring feature for its backup analytics suite. The product promised to reduce false‑positive alerts by 30%, which the engineering team quantified as a $850 K annual cost‑to‑serve saving. The rollout was celebrated with a launch email and a demo video.

Two weeks later, a senior analyst noticed that the alert count hadn’t changed. Digging deeper, the team discovered a schema mismatch in the underlying telemetry feed that silently dropped 11 days of events. Because the monitoring feature relied on that feed, the promised reduction never materialized. The error went unnoticed for 11 days because the feedback loop—FLRI—had not been wired into the product’s health page.

If the Value‑Flow ROI Framework had been applied, step 2 (Pipeline Efficiency Ratio) would have flagged the latency spike, and step 5 (FLRI) would have triggered an alert when usage metrics stalled. The team would have patched the schema issue within 24 hours, preserving the $850 K savings. David Ohnstad now insists on embedding FLRI dashboards from day 0 for every data product.

Stop Treating AI Adoption as a Cost Center – A Contrarian Claim

Most senior leaders treat AI projects as expense items, tracking only spend versus budget. The conventional wisdom is that “lower spend means better discipline.” The data says otherwise. According to Gartner’s 2024 Forecast, organizations that invest in detailed ROI tracking see a 45% higher success rate than those that merely cap budgets.

When you reframe AI as a revenue driver, the metrics shift. You start asking, “What incremental ARR does this model generate?” instead of “How much did we spend?” This change forces product teams to build the feedback mechanisms that the Value‑Flow ROI Framework mandates. The result is a virtuous cycle: better data, better decisions, higher revenue.

What is a data product ROI framework?

A data product ROI framework is a structured method for quantifying the total economic impact of a data‑driven offering, from acquisition costs through incremental revenue and cost‑to‑serve savings. It links technical metrics to business outcomes, enabling continuous validation.

How do you calculate incremental ARR for a data product?

Use controlled experiments or causal inference to isolate the revenue lift attributable to the product. Track the metric over a defined period, subtract baseline performance, and apply the product’s pricing model to derive ARR. Align the calculation with the product’s usage cohort for accuracy.

Why do most AI projects fail to deliver ROI?

Because they skip the feedback loop that ties model performance to business impact. Without a mechanism like the FLRI, teams cannot see whether the AI is moving the needle, leading to hidden failures and wasted spend.

Cross‑functional leaders need a clear line of sight on the economics of every data product. For practitioners, the Value‑Flow ROI Framework offers a playbook that can be implemented in a sprint. For executives, it provides the hard numbers needed to justify budget allocations during Q4 planning cycles.

When you embed the FLRI into your product health dashboard, you turn usage data into a leading indicator of financial performance. This aligns with the insights from this week’s David Ohnstad on AI and enterprise SaaS article, which stresses the importance of operational metrics that speak the language of finance.

Leadership must also champion the framework. The cross‑functional execution model described in the recent wp4 article shows that teams with a dedicated ROI champion achieve 22% faster time‑to‑value. By assigning ownership of the FLRI to a product owner, you ensure that the feedback loop never stalls.

Two Takeaways for Practitioners and Leaders

Practitioner: Wire the Feedback‑Loop Revenue Index into your product’s health page from day 0. It’s the cheapest guardrail that prevents silent failures like the Veeam case.

Leader: Require every data product business case to include incremental ARR and cost‑to‑serve savings calculations. Treat ROI as a non‑negotiable deliverable, not an after‑thought.

When was the last time you audited whether your data product’s cost model matches its actual financial impact?

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

For more on this topic, see data product management.

For more on this topic, see Data Product Manager Salary Gap: Why and How to Fix It.

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 ROI: Why 70% of AI Initiatives Fail appeared first on David Ohnstad.

The Dashboard Masquerade: Why $4M in “Data Product” Investment Actually Built Reporting Infrastructure

A Fortune 500 retail company announced a $4 million data product initiative in early 2024. Eighteen months later, they had eleven Tableau dashboards, three Snowflake schemas, and a team of five analysts maintaining nightly refreshes. When the CFO asked which data products were generating measurable business value, the silence lasted long enough to be uncomfortable. According to Gartner’s 2024 State of Data and Analytics report, 73% of enterprise “data product” initiatives are actually analytics infrastructure projects with better branding—and leadership doesn’t realize it until budget renewal season.

The confusion isn’t semantic. It’s structural. Analytics dashboards and data products serve fundamentally different purposes, create value through different mechanisms, and fail in different ways. But because both involve data, pipelines, and visual interfaces, teams treat them as evolutionary stages of the same thing: analytics 1.0 becomes a data product when you add governance, SLAs, and a product manager. That’s like saying a bicycle becomes a car when you add better brakes.

This distinction matters more now than it did two years ago. With dbt Coalesce happening in five days and Q4 budget conversations already underway, data leaders are being asked to justify headcount, platform spend, and team structure for “data product” work. If you can’t articulate what separates a data product from a dashboard—with specific examples, not metaphors—you’re asking for analytics budget with product-tier pricing. The math doesn’t work, and your CFO knows it.

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

What Actually Breaks When You Confuse the Two

The failure mode isn’t that dashboards are bad. The failure mode is resource misallocation at scale. When a team receives data product funding but builds analytics infrastructure, three specific problems compound over time: engineering gets staffed for the wrong skills, success metrics measure the wrong outcomes, and opportunity cost becomes invisible until a competitor ships something you can’t replicate with Looker.

David Ohnstad saw this firsthand at Veeam when a cross-functional team proposed a “customer health data product” in Q2 2024. The initial spec included predictive churn scoring, automated intervention triggers, and an API for the customer success platform to consume risk signals in real time. The actual deliverable six months later was a Tableau dashboard showing lagging indicators of support ticket volume, login frequency, and license utilization—metrics the CS team already tracked manually in spreadsheets. Nobody lied. The requirements document said “data product.” The team genuinely believed they were building one. But every design decision optimized for human consumption, not programmatic integration.

The financial impact was measurable. The analytics dashboard cost $180,000 in engineering and analyst time, required ongoing maintenance from two full-time roles, and served fourteen users. A true data product—risk scores exposed via API—would have served the same fourteen users plus automated playbooks, triggered Salesforce workflows, and enabled the customer success platform to route high-risk accounts without human triage. The ROI calculation for the dashboard tracked report adoption. The ROI calculation for the data product would have tracked intervention velocity and prevented churn. Same budget. Different outcomes. The business case broke because leadership approved funding for the second thing and received the first.

This isn’t a unique story. According to Forrester’s 2025 Data Strategy Survey, 64% of organizations that claim to have “operationalized data products” cannot name a single system that consumes their data product outputs programmatically. They have consumers who look at outputs. That’s analytics. The distinction is whether downstream systems act on the data without human interpretation in the loop.

The Consumption Model Diagnostic: A Three-Part Test for Identifying Real Data Products

Here’s the framework David Ohnstad uses when a stakeholder asks whether something qualifies as a data product or remains an analytics asset. It’s a three-question diagnostic that focuses on consumption patterns, not delivery infrastructure. Call it the Consumption Model Diagnostic. If you can’t answer yes to at least two of these three questions, you’re building analytics—and that’s fine, as long as you’re honest about it when requesting budget and headcount.

Question one: Does a system consume this output programmatically? Not a person looking at a chart. Not a person downloading a CSV and uploading it somewhere else. A system making a decision or taking an action based on the data without human intervention. Examples that count: an API returning a credit risk score that a loan approval workflow consumes, a machine learning feature store that serves model inputs in production, a real-time pricing engine that adjusts offers based on inventory and demand signals. Examples that don’t count: a dashboard that shows credit risk scores for human review, a weekly email with model performance metrics, a report that helps pricing analysts decide what to charge. The presence of a human in the decision loop disqualifies it.

Question two: Would breaking this output cause a system failure, not just a reporting gap? If the data stops flowing, does something stop working—or do people just stop seeing updates? When Veeam’s backup success prediction model went down for four hours in mid-2025, automated remediation workflows in customer environments stopped triggering. That’s a system failure. When a utilization dashboard goes down for four hours, analysts complain in Slack and check again after lunch. That’s a reporting gap. Data products sit in the critical path of operational systems. Analytics sits in the critical path of human understanding. Both matter. They’re not the same thing.

Question three: Is there a feedback loop where consumption behavior improves the product? Real products get better as they’re used. A recommendation engine learns from click-through behavior. A fraud detection model retrains on labeled transaction outcomes. A demand forecasting service adjusts based on actual fulfillment data. Analytics dashboards don’t have this property—adding more users doesn’t make the chart more accurate. You can build feedback loops into analytics (user surveys, adoption tracking), but those measure satisfaction with the delivery mechanism, not improvement in the underlying output quality. Data products have a reinforcement learning characteristic that analytics fundamentally lacks. Use improves performance. That’s a product behavior.

Apply this diagnostic to your current portfolio. Most teams discover that 80% of what they call data products are actually analytics with good engineering practices—versioned datasets, automated pipelines, SLA monitoring. Those things are valuable. They’re table stakes for analytics that doesn’t break constantly. But they don’t convert analytics into a product. A reliable dashboard is still a dashboard.

Why the Industry Keeps Getting This Wrong: Incentives and Legacy Mental Models

The confusion persists because three forces push teams toward mislabeling analytics as products: vendor positioning, hiring incentives, and the legacy career ladder that emerged from business intelligence roles. Each force is rational in isolation. Together, they create systematic misclassification that makes honest budgeting almost impossible.

Vendor positioning is the most visible force. Every major analytics platform added “data product” language to their marketing in 2023-2024 because customers started asking for it. Tableau promoted “governed data products” that are actually curated datasets with row-level security. Looker repositioned its semantic layer as “productized metrics” when the underlying functionality is a centralized definition library. These aren’t lies—they’re feature sets described with product framing because “better dashboard governance” doesn’t justify a platform migration. The vendors aren’t confused. They’re responding to what buyers are asking for. But when a Tableau sales deck calls governed datasets “data products,” teams who buy Tableau absorb that framing and apply it internally.

Hiring incentives make the problem structural. A Data Product Manager role commands $140,000 to $180,000 in most markets, according to Dice’s 2025 Tech Salary Report. An Analytics Manager role in the same company averages $110,000 to $135,000. If you’re building analytics infrastructure but staff it with product managers, you’re paying a 25-35% wage premium for skills the work doesn’t require. But if you’re genuinely building data products and staff it with analytics managers who’ve never shipped an API or managed a feature backlog, you’ll fail differently—delivering reports when the business needed embedded intelligence. The role definitions are porous enough that companies often don’t realize they’ve made the wrong hire until nine months in, when a product roadmap looks suspiciously like a BI reporting backlog.

The legacy mental model is hardest to displace because it’s embedded in how data teams evolved. Most data product managers came up through analytics roles—building dashboards, running SQL, designing dimensional models. That’s David Ohnstad’s background too. The instinct when asked to “build a data product” is to build what you know how to build well, with better process. That produces highly governed, version-controlled, SLA-backed analytics. It doesn’t produce products. Making the leap requires unlearning the assumption that better analytics infrastructure is the same thing as product development. It’s not. Analytics projects fail when data is wrong or nobody uses the dashboard. Data products fail when the API contract breaks, the latency exceeds downstream tolerance, or the model predictions degrade below the accuracy threshold that automated decisions require. These are different failure modes requiring different skills.

Here’s the contrarian claim most senior data leaders will resist: Stop hiring “data product managers” to fix your analytics delivery problems—they’ll build products you don’t need while your reporting backlog grows. If the actual work is “deliver accurate, governed dashboards faster,” hire analytics engineers and give them a prioritization framework. If the actual work is “expose data capabilities that other systems consume programmatically,” hire product managers with API experience and accept that you’ll deliver fewer dashboards. Trying to do both with the same headcount and calling everything “data products” is why salary expectations are disconnected from actual role responsibilities and why Q4 budget conversations devolve into arguments about terminology instead of value delivery.

Five Myths That Persist in the SERP and Conference Talks

Myth one: A data product is just analytics with an SLA. This is the most common misconception in practitioner content. The argument goes: if you add data quality monitoring, uptime guarantees, and on-call rotation to a dashboard, it becomes a product. This confuses operational rigor with product definition. An SLA describes how reliably something is delivered. It doesn’t change what is being delivered. A dashboard with 99.9% uptime is a highly reliable dashboard. It’s not a product unless something other than a human depends on that uptime. Reliability is necessary for data products—nobody builds an API with no uptime commitment—but it’s not sufficient to transform analytics into a product.

Myth two: Data products must include machine learning. The inverse misconception: if it doesn’t have a model, it’s not a data product. This eliminates entire categories of legitimate data products—feature stores, master data APIs, event streams, reference data services—that provide structured, consumable data without predictive logic. Machine learning models are often data products, but the defining characteristic is programmatic consumption and system integration, not statistical methodology. A rules-based scoring engine exposed via API is more of a data product than a machine learning model whose predictions are displayed in a dashboard for human review. The presence of ML is orthogonal to the product question.

Myth three: Self-service analytics is a data product. This framing appears in almost every “what is a data product” article on Medium and in vendor content. The argument: if business users can explore data without bothering analysts, you’ve productized your analytics. But self-service describes the access model, not the consumption pattern. Giving more people access to dashboards doesn’t change the fact that humans are still the consumers. A self-service analytics platform is infrastructure that enables analytics delivery at scale. It’s valuable. It’s not a product in the sense that an API or embedded feature is a product. Nobody wakes up on Monday and decides to “buy” access to your Looker instance the way they’d adopt a fraud detection API. They’re granted access by IT. That’s not product adoption. That’s provisioning.

Myth four: If you charge for it, it’s a product. Cost recovery doesn’t equal product status. Plenty of IT organizations implement chargeback models for analytics infrastructure—business units pay based on compute usage, storage footprint, or report volume. This creates accountability and aligns incentives, but it doesn’t convert the deliverable into a product. A product has users who choose to adopt it because it solves a problem better than alternatives. Chargeback-funded analytics has consumers who are required to use it because the company mandated a standard reporting platform. The presence of a price signal is necessary for external-facing data products (you’re selling access to data or insights). It’s not sufficient for internal-facing data capabilities unless adoption is genuinely optional and competitive with outside alternatives.

Myth five: Data mesh equals data products. The data mesh architecture treats datasets as products, assigns ownership, and emphasizes domain-driven design. This is closer to true product thinking than traditional centralized BI, but it’s still not the same thing as data products in the programmatic sense. A well-governed domain dataset with clear ownership and SLAs is a high-quality analytics asset. If it’s consumed exclusively by dashboards and analysts writing SQL, it’s not a product—it’s a productized data asset, which is a different concept. The confusion happens because data mesh literature uses “product thinking” to describe governance discipline, ownership accountability, and user empathy. Those are product management skills applied to data delivery. They don’t automatically result in products that systems consume programmatically. You can run a data mesh and still deliver only analytics. You can also build real data products without a mesh architecture. The two concepts overlap but aren’t synonymous.

What This Means for dbt Coalesce and Q4 Planning

If you’re headed to dbt Coalesce this week, watch how speakers describe their “data products.” Count how many examples involve downstream systems consuming outputs programmatically versus how many examples involve humans looking at better-organized data. The ratio will tell you whether the data community has converged on a shared definition or whether we’re still in the “everything is a data product if you govern it well” phase. Based on CFP session titles published in early September, most talks are still focused on analytics delivery—how to build reliable metrics, how to implement semantic layers, how to scale transformations. Those are critical problems. They’re not product development problems. They’re data engineering and analytics engineering problems.

For Q4 budget planning, this distinction determines whether your headcount request gets approved. If you ask for data product managers and describe analytics deliverables in the business case, finance will either cut the budget (you’re asking for expensive resources to do cheaper work) or approve it and then wonder why dashboards cost $180,000 per analyst. If you ask for analytics engineers and describe actual data product deliverables in the business case, you’ll get rejected for under-resourcing the work. The fix is to separate the asks: request analytics resources for analytics work, request product resources for product work, and accept that you may need different team structures and leadership approaches for each. Trying to run both out of one team with one budget line is how you end up with $4 million spent and eleven dashboards to show for it.

Two explicit takeaways—one for practitioners, one for leaders. Practitioners: audit your current roadmap and tag every item as “analytics” or “product” using the three-question diagnostic earlier in this article. If everything is tagged “product” but nothing has programmatic consumers, you’re mislabeling. Relabel honestly, then decide whether that’s a problem. Sometimes the right answer is to build great analytics and stop calling it product development. Leaders: the next time someone proposes a “data product” initiative, ask them to name three systems that will consume the output without human intervention. If they can’t, you’re funding analytics with product pricing. Adjust scope or budget accordingly.

What’s the difference between a data product and an analytics dashboard?

A data product is consumed programmatically by other systems—like an API serving fraud scores to a payment processor—while an analytics dashboard is consumed by humans who interpret the data and then take action. The distinction is whether downstream decisions happen automatically or require human review in the loop.

How do you know if your data product is actually just analytics with good engineering?

Apply the Consumption Model Diagnostic: Does a system consume this programmatically? Would breaking it cause a system failure, not just a reporting gap? Is there a feedback loop where usage improves performance? If you can’t answer yes to at least two, it’s analytics with operational rigor, not a product.

Why do companies keep mislabeling analytics projects as data products?

Three forces drive the confusion: vendor marketing repositioned analytics platforms as “data product” tools, hiring incentives reward teams for using product titles even when doing analytics work, and legacy career paths train data leaders in dashboard delivery rather than API-first product development. Honest budgeting requires separating the two.

When was the last time you checked whether your “data products” are actually changing system behavior—or just providing humans with better reports? If the answer involves a dashboard, you know what work remains.

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 Products vs Analytics Dashboards: The $4M Mistake appeared first on David Ohnstad.

Data Product Management: The Complete Guide to Building Products That Ship, Not Just Dashboards

You’ve seen this meeting. Someone presents a dashboard, calls it a “data product,” and the room nods along. Three months later, nobody uses it. The dashboard didn’t fail because of bad visualizations or slow queries—it failed because it wasn’t actually a product. It was a report dressed up in product language, and the difference matters more than most practitioners realize.

This guide exists because most content on data product management treats the discipline as “analytics with better governance” or “dashboards that scale.” That framing misses the fundamental shift. Data products generate value through autonomous decision-making, embedded intelligence, or revenue-generating services. They have users, not viewers. They evolve based on usage patterns, not refresh schedules. And they require a completely different skillset than traditional analytics delivery.

What follows is the framework David Ohnstad uses at Veeam Software to distinguish actual data products from analytics theater. You’ll learn what separates product thinking from report thinking, the specific skills that matter at each stage of maturity, and the mistakes that derail teams who confuse the two. This isn’t an overview—it’s the practitioner playbook for building data products that ship.

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

What Most Teams Get Wrong About Data Product Fundamentals

The confusion starts with language. “Data product” became a catch-all term for anything involving data and users, which means it now describes everything from a Tableau dashboard to Stripe’s fraud detection API. According to Gartner’s 2025 Data and Analytics Leadership Report, 68% of organizations claim to have “data products” in production, but only 23% measure product-specific metrics like feature adoption or user retention. The gap reveals the problem: teams are labeling outputs as products without changing how they build, measure, or improve them.

A data product is not a dataset. It’s not a dashboard. It’s not even a well-governed data pipeline. A data product is a system that uses data to make decisions, generate predictions, or enable capabilities—and it improves through usage feedback. Spotify’s Discover Weekly playlist is a data product. Your quarterly sales dashboard is not. The difference comes down to three characteristics that most articles skip:

First, data products have active users, not passive consumers. Someone doesn’t just look at a data product—they interact with it, trigger actions based on it, or rely on it to complete a workflow. Netflix’s recommendation engine powers what you watch next. That’s product behavior. A marketing attribution report shows what happened last quarter. That’s analytics output. The recommendation engine gets better as you use it. The report stays static until someone manually updates it.

Second, data products measure success through usage and impact, not accuracy alone. A machine learning model with 94% precision that nobody trusts enough to use has failed as a product, even if it succeeds as a technical artifact. According to MIT Sloan’s 2024 study on enterprise AI adoption, models with lower accuracy but transparent decision logic saw 3.2x higher adoption rates than black-box alternatives with superior performance metrics. The product question isn’t “Is this model accurate?” It’s “Will someone change their behavior because of what this model tells them?”

Third, data products evolve through feedback loops built into the system itself. When a user clicks “not interested” on a recommended article, that signal trains the next iteration. When someone ignores a fraud alert, that behavior becomes training data. Traditional analytics requires someone to manually decide what to change based on what the report shows. Data products automate that loop. The gap between those two approaches is the gap between analytics and product management.

The hardest part isn’t building the model or pipeline—it’s shifting from “ship the report” to “ship the capability.” Product managers trained in SaaS delivery understand this instinctively. Data teams trained in analytics delivery struggle with it because their entire career rewarded delivering insights, not enabling decisions. A McKinsey analysis from 2025 found that data teams with at least one member who had shipped consumer-facing products were 2.7 times more likely to successfully deploy data products than teams composed entirely of analytics or engineering backgrounds. The skill gap isn’t technical. It’s product thinking.

Here’s what that looks like in practice. David worked on a retention prediction model at Veeam that scored customer churn risk weekly. The first version lived in a data warehouse table that account managers could query if they remembered it existed. Accuracy was solid—83% precision. Adoption was 11%. The team treated it as an analytics project: build the model, validate the output, hand it off. Nobody used it because nobody had a workflow that started with “go query the churn table.”

The second version embedded the score directly in the CRM, flagged high-risk accounts in the daily dashboard view, and triggered automated follow-up tasks for account managers. Same model. Same data. Different product design. Adoption jumped to 68% in the first month because the product fit into existing workflows instead of requiring users to create new ones. That shift—from “here’s the data” to “here’s what you should do”—is what separates data products from analytics outputs.

Most frameworks for building data products miss this distinction. They focus on data quality, model performance, or governance processes—all necessary, none sufficient. The next section introduces a framework that starts with product questions first, then builds the data capabilities to answer them.

The Decision-Enabled Product Framework: Five Stages to Ship Data Products

Building data products requires a different sequence than building analytics. Analytics starts with “What data do we have?” Data products start with “What decision are we enabling?” The Decision-Enabled Product Framework reverses the traditional analytics workflow by anchoring every stage to user behavior, not data availability. The five stages move from decision design to continuous improvement, with each stage producing artifacts that inform the next. Here’s how it works.

Stage One: Decision Mapping — Define What Changes

Before writing a single query, map the specific decision this product will enable. Not the insight it will surface—the action someone will take differently because this product exists. Decision mapping requires answering three questions with brutal specificity: Who makes the decision? What exact action do they take? What changes as a result?

Most teams skip this and jump straight to “build a churn model” or “create a recommendation engine.” That’s how you end up with technically sound systems that nobody uses. A churn model is not a decision. “Proactively contact at-risk customers before they cancel” is a decision. The model enables it, but the product design starts with the workflow, not the algorithm.

At Veeam, David mapped a decision around backup verification compliance. The decision: which backup jobs should engineers prioritize for manual testing each week? The action: engineers run restore tests on flagged jobs. The result: critical data gets verified before an actual disaster, reducing recovery failures. That clarity drove the product spec. The ML model ranked jobs by risk, but the product delivered a prioritized weekly checklist integrated into existing sprint planning tools.

The common mistake here is defining decisions too broadly. “Improve customer retention” is a goal, not a decision. “Trigger a retention campaign for accounts that miss two product logins within 14 days” is a decision. The more specific the decision, the clearer the product requirements become. Vague decision definitions produce vague products that try to do everything and end up useful for nothing.

Stage Two: Usage Design — Build the Interaction Model

Once you know the decision, design how users interact with the product to make it. This is where most data teams fail because they default to “show them the data and let them decide.” That’s analytics. Products reduce cognitive load by surfacing the right information at the right time in the right format.

Usage design answers: Where does the user encounter this product? What’s the smallest interaction that delivers value? What happens after they act on it? For the backup verification product, the interaction model was a Slack notification every Monday with the top five at-risk jobs, each with a one-click link to run the test. Engineers didn’t need to query anything, interpret risk scores, or remember to check a dashboard. The product came to them in a tool they already used, with the exact action pre-loaded.

Contrast that with the first iteration, which lived in a separate analytics portal that required logging in, filtering jobs by risk tier, and exporting a list. Functionally identical. Usage dropped to near zero within two weeks because the interaction model required too much effort. According to Forrester’s 2025 Data Product Adoption Study, products requiring more than two clicks to reach specific information saw adoption rates 73% lower than embedded alternatives. Friction kills adoption faster than any technical limitation.

The mistake teams make is treating usage design as a front-end problem. It’s a product architecture decision. If your data product requires users to “go check the dashboard,” you’re building analytics, not a product. Products push intelligence to where decisions happen. Dashboards wait for someone to pull insights from them. The mental model shift is massive.

Stage Three: Capability Assembly — Build What Enables the Decision

Now build the data capabilities required to support the interaction model you designed. Notice the sequence: decision first, interaction second, data infrastructure third. Most teams do this backward, which is why they end up with orphaned models that never integrate into actual workflows.

Capability assembly includes data pipelines, models, APIs, integrations, and automation—everything required to deliver the interaction you designed. For the backup verification product, that meant a weekly batch job that scored all backup jobs against failure risk factors, an API endpoint that returned the top-N risky jobs on demand, and a Slack integration that formatted results and posted them to the engineering channel. Three capabilities, all designed to enable one specific interaction.

The key discipline here is resisting scope creep. Engineers love building reusable platforms. Product managers love adding “one more feature.” Both instincts kill momentum. Ship the minimum capability set that makes the core decision possible, then iterate based on usage. The backup verification product launched with five risk factors. It now uses twelve, but only because actual usage revealed what mattered. Starting with twelve would have delayed launch by six weeks and delivered marginal improvement.

Common mistake: building capabilities based on what data you have instead of what decision you need to enable. That’s how you get “interesting insights” that don’t change behavior. If the decision requires data you don’t have, either find it, proxy it, or revisit whether the decision is achievable. Don’t build a product around available data that doesn’t fully support the decision. It will underperform and erode trust in future products.

Stage Four: Feedback Instrumentation — Measure What Matters

Feedback loops are not optional. They are the difference between shipping a data product and shipping a static report. Instrumentation means capturing three types of signals: usage (who’s interacting with it), outcomes (what changed because of it), and learning (what the product should do differently).

For the backup verification product, usage metrics tracked how many engineers clicked through to run tests each week. Outcome metrics measured whether flagged jobs actually had higher failure rates during testing. Learning metrics captured when engineers skipped a recommended test, which became training data to improve ranking logic. All three signals fed back into the product automatically—no manual analysis required.

Most teams measure usage and stop there. That tells you if people clicked, not if the product worked. Outcome metrics connect product interactions to business results. For a churn prediction product, usage is “account managers viewed the at-risk list.” Outcome is “viewed accounts had X% lower churn than unviewed accounts.” If outcomes don’t improve, usage is theater. You built something people interact with that doesn’t actually help.

According to IDC’s 2024 Enterprise Data Strategy report, 71% of organizations measure data product usage, but only 31% measure outcome impact. The gap explains why so many “successful” data products get quietly retired a year after launch. People used them, but nothing improved, so leadership cut the investment. Outcome instrumentation is the only sustainable defense against that cycle. For more on why this measurement gap matters, see Data Product Management: Why 82% of Analytics Fail.

The implementation mistake is treating instrumentation as something you add after launch. Build it into the product from day one. If you can’t measure whether the product improves the decision it was designed for, you’re not ready to ship. Feedback loops are infrastructure, not features.

Stage Five: Continuous Product Evolution — Iterate Based on Signals

Data products improve through usage, not through quarterly roadmap planning. Continuous evolution means using the feedback signals you instrumented to automatically update model logic, refine recommendations, or adjust what information surfaces to users. This stage separates products that compound value over time from projects that stagnate after launch.

The backup verification product evolved in three meaningful ways based on usage signals. First, engineers consistently skipped jobs from certain backup types, so the model learned to downweight those factors. Second, jobs flagged as high-risk but passing tests revealed data quality issues in one risk signal, so the team replaced it with a better proxy. Third, usage patterns showed engineers preferred getting notifications on Tuesdays instead of Mondays, so the schedule shifted. None of those changes came from a roadmap—they came from observing how the product was used.

The discipline here is distinguishing signal from noise. Not every skipped recommendation means the model is wrong. Not every feature request deserves implementation. Continuous evolution requires interpretation: which signals indicate the product isn’t serving the decision well, and which are just variance in how different users work? Product managers earn their salary in this stage by knowing the difference.

Common mistake: treating the product as “done” after launch. Analytics projects finish when you deliver the report. Data products finish when usage drops to zero—which, if you instrument feedback correctly, should never happen. The moment you stop iterating based on usage signals, you’ve turned a product back into a report. The competitive advantage of data products is that they get better through use. Teams that don’t exploit that advantage waste the entire point of building products instead of analytics.

Advanced Techniques That Separate Senior Practitioners

The Decision-Enabled Product Framework gets you to functional data products. The techniques below get you to products that compound value faster than competitors can copy them. These are not beginner moves—they require product maturity, organizational trust, and technical depth most teams don’t have in their first year of data product work.

Progressive Disclosure Architecture: Hide Complexity Until Users Need It

Most data products overwhelm users by exposing all available information upfront. Senior practitioners design progressive disclosure: show the minimum to make the decision, then reveal layers of detail only when users actively seek them. Netflix doesn’t show you every algorithm factor that determined a recommendation—it shows you the title and a percentage match. Click for more info, and you get categories and similar titles. Click again, and you see full metadata. Three layers, each optional, each serving a different depth of engagement.

David implemented this for a customer health scoring product at Veeam. The default view showed account managers a red/yellow/green status and one recommended action. That’s it. Click through, and you see the six factors driving the score. Click again, and you see historical trends and alternative actions. Most users never got past the first screen, which was the point—they didn’t need to. The product made the decision easy by hiding complexity until it became relevant.

The technique requires understanding decision depth. Some decisions are binary and fast: “Should I follow up with this account today?” Others are strategic and slow: “Should we adjust our entire enterprise sales motion based on health trends?” Progressive disclosure serves both by letting users control how deep they go. The mistake is designing for the complex use case and forcing simple users to navigate unnecessary detail. Start with the simplest decision path, then build layers for power users.

Confidence-Aware Product Design: Tell Users When You Don’t Know

Most data products present predictions as facts. Senior practitioners design products that communicate uncertainty and help users make better decisions because of it, not despite it. A churn score of 78% means nothing without context. A churn score of 78% ± 12% with a confidence flag that says “low recent activity data—check manually” is specific.

David’s team at Veeam built confidence scoring into every ML-driven product. Low-confidence predictions surfaced differently: different visual treatment, explicit uncertainty language, and recommended verification steps. High-confidence predictions came with automation options: “Auto-generate ticket?” Low-confidence predictions required human confirmation. The result was higher trust—users knew when to rely on the product and when to double-check.

According to Deloitte’s 2025 AI Trust report, products that explicitly communicated prediction confidence saw 2.4x higher long-term adoption than products that presented all outputs with equal authority. Users don’t trust black boxes, but they do trust systems that admit when they’re uncertain. The implementation challenge is instrumenting confidence scoring into models that weren’t designed for it. That requires rethinking model architecture from the start—retrofitting confidence after launch is expensive and often inaccurate.

The technique works because it aligns with how humans make decisions under uncertainty. We don’t expect perfect information. We expect honest information. Data products that acknowledge limitations build trust. Products that oversell certainty get abandoned the first time they’re obviously wrong.

Common Mistakes and How to Fix Them

Mistake One: Treating Data Quality as a Prerequisite Instead of a Product Feature

Teams delay shipping data products because “the data isn’t clean enough yet.” That’s analytics thinking. Product thinking ships with imperfect data and surfaces data quality as part of the user experience. If a customer health score is based on incomplete usage data, tell the user. Show which signals are missing. Let them decide if the score is still useful or if they need to wait for better data.

The fix is confidence-aware design (see above) combined with transparent data lineage. Show users what data powers the product, when it was last updated, and what’s missing. That turns data quality from a blocker into a feature. Users can choose to act on partial information if they understand the gaps. The backup verification product shipped with incomplete risk signals for certain backup types. Instead of waiting six months for full coverage, the team shipped with a clear label: “Limited data—manual review recommended.” Users appreciated the honesty and used the product despite the gaps.

Mistake Two: Measuring Model Performance Instead of Decision Impact

Data scientists optimize for accuracy. Product managers optimize for outcomes. A model with 92% accuracy that nobody trusts has zero decision impact. A model with 78% accuracy that users rely on daily to prioritize work has massive impact. The mistake is celebrating model metrics instead of tracking whether decisions improved.

The fix is instrumenting outcome metrics from day one. For a churn prediction product, outcome metrics are: did accounts flagged as high-risk churn more than unflagged accounts? Did account managers who acted on predictions retain more customers? Did revenue from flagged accounts improve after intervention? If you can’t answer those questions, you’re measuring the wrong things. Model performance is a leading indicator. Decision impact is the only metric that justifies continued investment. For more on this measurement gap, see Data Product Manager Salary Gap: Why and How to Fix It, which covers how compensation misalignment often reflects this same metric confusion.

Mistake Three: Building Horizontal Data Platforms Instead of Vertical Product Solutions

Engineers love reusable infrastructure. Product managers love solving specific problems. The tension plays out in data products as teams build “platforms for anyone to create data products” instead of shipping actual products that solve real decisions. Platforms are important—eventually. But they don’t deliver user value until someone builds a product on top of them.

The fix is ship vertical first, extract horizontal later. Build the churn prediction product. Make it work for one team. Then, if you see patterns worth generalizing, extract a platform. Most teams do this backward: they build the platform, then struggle to find use cases that justify the investment. According to Gartner’s 2025 analysis, vertical-first data product strategies achieved production deployment 4.3 months faster on average than platform-first approaches. The platform will emerge naturally from solving real problems. Forcing it upfront slows everything down.

Mistake Four: Delegating Product Ownership to Data Engineers

Data engineering builds capabilities. Product management defines what capabilities to build and why. Delegating product decisions to engineers produces technically impressive systems that miss user needs. Someone has to own the decision: what does this product do, for whom, and how do we measure success? That’s a product role, not an engineering role.

The fix is clear ownership boundaries. Engineers own “how does this work and does it scale?” Product managers own “what does this do and does it matter?” If your data team doesn’t have a dedicated product manager, the most product-minded person on the team needs to step into that role explicitly. Shared ownership of product decisions produces design-by-committee mediocrity. One person has to own whether the product succeeds. That person is the product manager, even if their title says something else.

Frequently Asked Questions

What’s the difference between a data product and a dashboard?

A dashboard shows information. A data product enables decisions. Dashboards require users to interpret data and decide what to do. Data products recommend actions, automate decisions, or embed intelligence directly into workflows. If users just look at it, it’s a dashboard. If they act differently because of it, it might be a product.

How do you measure data product success?

Three metrics matter: usage (are people interacting with it), outcomes (did the decision improve because of it), and learning (is the product getting better through use). Most teams measure usage and stop. Outcome metrics connect product interactions to business results. Learning metrics track whether feedback loops are improving performance over time.

What skills do data product managers need that analytics PMs don’t?

Data product managers need to understand data architecture well enough to know what’s possible, SQL well enough to validate outputs independently, and product thinking well enough to design interactions that reduce cognitive load. Analytics PMs can succeed by interpreting insights. Data product PMs must design systems that make decisions, not just surface information. The skill gap is bridging technical depth with product design, which most people learn from only one side.

How long does it take to ship a minimum viable data product?

Four to eight weeks if you scope ruthlessly. Most teams take longer because they build horizontal platforms instead of vertical solutions, or because they treat data quality as a prerequisite instead of a feature. The Decision-Enabled Product Framework forces early scoping decisions that prevent scope creep. Ship the minimum capability set that enables one decision, measure outcomes, then iterate.

What’s the biggest mistake teams make when building their first data product?

Treating it like an analytics project with a different name. They focus on data quality, model accuracy, and governance—all necessary, none sufficient—while ignoring interaction design, feedback loops, and outcome measurement. The result is technically sound systems that nobody uses because they don’t fit into existing workflows. The fix is starting with the decision and working backward to capabilities, not starting with data and hoping someone finds it useful.

Tools and Resources for Data Product Management

The tools that matter depend on where you are in the product lifecycle, but three categories are non-negotiable: instrumentation, experimentation, and integration. For instrumentation, Census and Hightouch excel at reverse ETL—pushing data product outputs into operational tools where decisions happen. David uses Census at Veeam to surface model predictions directly in Salesforce, eliminating the dashboard layer entirely.

For experimentation, Statsig brings feature flagging and A/B testing to data products. Most teams skip this because they think experimentation is only for consumer apps, but the best data products test variations just like SaaS products do. Does showing confidence intervals increase trust? Does highlighting the top recommendation drive faster decisions? You won’t know without testing. Statsig makes it possible to run those experiments without rebuilding your product each time.

For integration and workflow automation, Zapier and Make (formerly Integromat) let you connect data product outputs to business workflows without writing custom integrations. The backup verification product started as a Zapier workflow—model output in Snowflake triggered a formatted Slack message. Shipping fast matters more than building custom infrastructure, and these tools let you validate product-market fit before investing in permanent plumbing.

The resource David recommends most is Measure What Matters by John Doerr. It’s not a data product book, but the OKR framework it teaches applies directly to outcome measurement. Too many data products measure outputs (models deployed, dashboards built) instead of outcomes (decisions improved, revenue retained). Doerr’s framework forces clarity on what actually matters, which is the skill that separates successful data product managers from analytics teams calling themselves product teams.

For practitioners wanting to go deeper on AI/ML infrastructure decisions that enable or constrain data product capabilities, explore more at David Ohnstad on AI and enterprise SaaS. For leadership and team execution strategies that determine whether data products get adopted across organizations, see David Ohnstad on leadership and career growth.

Shipping Data Products in 2026: What dbt Coalesce Reveals About the State of the Industry

The dbt Coalesce conference happening this week offers a useful temperature check on where the industry is in the data product maturity curve. The session topics reveal a telling pattern: heavy emphasis on governance, data quality, and platform architecture—all necessary foundation—but relatively few talks on decision design, user adoption, or outcome measurement. That gap mirrors what David sees in enterprise teams: lots of investment in building better data infrastructure, not enough focus on whether anyone uses what gets built.

The most promising signal from this year’s Coalesce agenda is the emergence of “semantic layer” and “metrics layer” sessions. These topics indicate practitioners are starting to ask the right questions: how do we make data consistently interpretable across teams? How do we ensure everyone measures churn the same way? Those are product questions dressed up as infrastructure questions. The teams asking them are one step away from realizing they’re building products, not pipelines.

What’s missing from the conversation—both at Coalesce and in most data product discourse—is honest discussion about failure modes. Most conference talks celebrate successes. The real learning comes from understanding why data products fail, which is almost always the same reason: they solve the wrong problem, or they solve the right problem in a way that doesn’t fit user workflows. The Decision-Enabled Product Framework directly addresses both failure modes by forcing decision clarity upfront and designing interactions before building capabilities.

If you’re attending Coalesce or following along remotely, watch for one specific pattern in the talks: does the speaker describe what decision their data product enables, or do they describe what insights it surfaces? That linguistic difference reveals whether they’re building products or analytics. The industry is slowly shifting toward product language, but most teams haven’t yet made the operational changes required to deliver on it. The framework in this guide gives you the operational playbook the conference talks won’t.

Here’s the question to carry forward: If data quality and governance problems were completely solved tomorrow, would your team know how to build data products that users actually adopt? If the answer is no, the problem isn’t infrastructure. It’s product thinking. And product thinking is a skill you build by shipping products, measuring outcomes, and iterating based on what you learn—not by attending conferences or reading frameworks. This guide gives you the map. Shipping is still on you.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Follow his work at github.com/davidohnstad40-netizen.

The post Data Product Management: The Complete Guide appeared first on David Ohnstad.

Why Most Data Product Managers Are Building the Wrong Thing

We built a recommendation engine that processed 14 million transactions daily, delivered personalized results to 200,000 users, and reduced query latency by 73%. Six months later, the VP of Sales asked why they still couldn’t answer the one question that actually mattered: which customer segment was most likely to churn in the next 90 days. According to Gartner’s 2024 State of Data and Analytics report, 78% of data and analytics leaders say their teams build products that don’t address the decisions executives are actually trying to make. The gap isn’t technical. It’s conceptual. Most data product managers start with the data they have instead of the decision they need to support.

This creates a quiet but expensive failure pattern. Teams ship dashboards nobody trusts, pipelines nobody uses, and models that answer questions nobody asked. The organization spends money. Engineers ship features. PMs present at quarterly reviews. But the business still makes decisions the same way it did before the data product existed—often with a spreadsheet someone downloads from the system the data product was supposed to replace.

The root cause is a fundamental misalignment in how data product managers define scope. Traditional product management starts with user needs and builds backward to features. Data product management requires the opposite: start with the decision, work backward to the data architecture that can support it, then forward again to the interface that makes the decision faster or more accurate. Most PMs skip the middle step. They assume the data is ready. It rarely is.

The Hidden Cost of Building Data Products Without Decision Clarity

When a data product doesn’t map to a specific decision, it becomes a data curiosity. Users explore it. They find it interesting. They don’t change behavior. This is the pattern David Ohnstad has seen repeatedly at Veeam Software: analytics platforms with high adoption metrics and zero decision impact. The dashboard gets opened. The report gets generated. The meeting still ends with “let me pull some numbers and get back to you.” Nothing accelerated.

According to McKinsey’s 2023 report on data-driven decision making, organizations that clearly define the decision before building the analytics infrastructure see 4.2x higher ROI on data investments compared to teams that build first and ask questions later. The gap compounds over time. A data product built without decision clarity requires constant rework. Every stakeholder requests a new dimension, a different filter, or an alternate visualization because nobody started with a shared understanding of what decision the product was supposed to enable.

The failure mode looks like this: a marketing team requests a customer segmentation tool. The data product manager builds a solid clustering model with demographic, behavioral, and transactional features. The model runs nightly. The results populate a dashboard. Marketing opens it twice, says “this is interesting,” and continues using their existing manual process for campaign targeting. Why? Because the PM built a segmentation tool, not a campaign targeting accelerator. The decision—who gets which message—still required manual work the data product didn’t eliminate.

This isn’t a training problem. It’s a scoping problem. The PM delivered what was requested instead of solving for the underlying decision. The request was “we need customer segments.” The decision was “which 10,000 customers should receive the Q4 promotion to maximize revenue without cannibalizing full-price purchases.” Those are not the same thing. One is a data artifact. The other is a decision framework with embedded constraints, tradeoffs, and downstream consequences.

The Decision-First Scoping Framework

This is a four-stage process that forces alignment between what you build and what decisions it enables. Most teams skip directly to stage three—data modeling—and wonder why adoption stalls. The framework works backward from impact, not forward from data availability.

Stage 1: Name the Specific Decision and Its Frequency. Not “improve customer retention.” That’s an outcome, not a decision. The decision is: “Every Monday, the account management team decides which 50 at-risk enterprise accounts to prioritize for outreach this week.” The frequency matters because it defines latency requirements. A decision made quarterly tolerates batch processing. A decision made hourly requires near-real-time infrastructure. Most data products fail because they optimize for the wrong cadence. If leadership reviews a metric monthly but the dashboard updates hourly, you built expensive infrastructure nobody needs. Conversely, if a frontline team needs hourly updates and your pipeline runs nightly, the data is already stale when it arrives.

Stage 2: Identify the Current Decision Process and Its Failure Mode. How is this decision being made today? What goes wrong? This is where most PMs discover the real problem isn’t missing data—it’s conflicting data from three systems that produce different answers to the same question. At Veeam, David Ohnstad worked on a sales forecasting product where the VP of Sales, the finance team, and the RevOps team each had their own pipeline reports. All three pulled from the same CRM. All three showed different totals. The failure mode wasn’t “we don’t have forecasting data.” It was “we have three forecasts and no process for reconciling them, so every executive meeting starts with 20 minutes of arguing about whose numbers are correct.”

The data product that solved this didn’t add more metrics. It eliminated the reconciliation problem by creating a single source of truth with clear lineage documentation. That’s a different technical requirement than “build a sales dashboard.” Stage 2 forces you to document the current state honestly. If the decision process today is “the CMO’s gut feel based on anecdotal feedback from three sales calls,” you now know your data product must be more persuasive than anecdotal evidence—not just more accurate. Accuracy is necessary but insufficient. The product has to change the decision-maker’s behavior, which means understanding what currently drives their confidence.

Stage 3: Map Required Data to Decision Inputs, Not Available Data to Possible Outputs. This is the inversion most teams miss. Start with “what inputs does this decision require to be 20% faster or 15% more accurate?” Not “what data do we have that might be relevant?” If the decision is “which customer segment to target for upsell,” the required inputs might be: propensity score, current contract value, renewal date, recent support ticket sentiment, and competitive win/loss data. Now assess: which of these exist? Which are derivable? Which require new instrumentation? If three of the five inputs don’t exist in reliable form, you now have a scoping decision: build the full solution with a 9-month timeline, or build a minimum viable decision aid with the two inputs that are ready and clearly document the limitation.

Most teams try to hide this gap. They build the product with available data, hope nobody notices the missing inputs, and then face credibility damage when the results don’t match expectations. The better path: surface the gap in the scoping phase, get explicit agreement on the constraint, and build the roadmap around progressively improving input quality. For more on how compensation structures and team incentives shape these decisions, see Data Product Manager Salary Gap: Why and How to Fix It.

Stage 4: Define Success as Decision Velocity or Quality Improvement, Not Engagement. This is the contrarian step that most product orgs resist. If your success metric is “dashboard opens per week” or “number of active users,” you are measuring curiosity, not impact. The correct success metric for a data product is: “time from question to decision decreased by X%” or “decision accuracy improved by Y% as measured by [downstream outcome].” For a customer churn model, the success metric isn’t model AUC or precision-recall. It’s “percentage of at-risk accounts saved after intervention” compared to baseline save rates before the model existed. That metric requires partnership with the team making the intervention. It requires tracking outcomes over weeks or months. It’s harder to measure. It’s also the only metric that proves the product is working.

When Stakeholder Requests and Decision Needs Diverge

Three years ago, a finance executive asked David Ohnstad’s team for a real-time revenue dashboard. The request was specific: update every hour, break down by product line and region, show variance from forecast. The team built it. The dashboard was beautiful. It updated flawlessly. The executive opened it four times in the first month, then never again. Why? Because the decision the executive was actually making—monthly budget reallocation—didn’t require hourly granularity. What he needed was a variance alert system that surfaced only the three product lines more than 10% off forecast, with a root cause analysis for each. The dashboard gave him 40 data points to scan. The decision required three anomalies with context.

This is the most common failure pattern in data product management: building what was requested instead of solving for the underlying decision. Stakeholders are often wrong about what they need because they don’t have visibility into what’s technically possible or what data actually exists. A request for “a customer 360 view” usually means “I want to make better decisions about which customers to invest in, but I don’t know what data I need to make that call, so I’m asking for everything.” If you build the 360 view, you deliver a data swamp. If you probe the decision—”What specific choice are you trying to make about customer investment?”—you might discover they need a tiering model with three segments, not a comprehensive profile.

The PM’s job is to translate the request into the decision, then build for the decision. This requires pushback. It requires saying “I heard your request for X, but I think the decision you’re trying to enable is actually Y—can we validate that before I scope the build?” Most PMs skip this conversation because it feels confrontational. The alternative is shipping a product nobody uses and then being asked why adoption is low. The confrontation happens either way. Better to have it during scoping than during retrospectives.

According to Forrester’s 2024 study on data product adoption, 62% of failed data initiatives traced back to misalignment between what was built and what decisions stakeholders were actually trying to make. The study found that organizations with formal decision-mapping processes in their product intake workflows had 3.1x higher data product retention rates after 12 months. The mapping process doesn’t need to be elaborate. It needs to be explicit. For insights on how leadership gaps exacerbate this misalignment, consider exploring perspectives on David Ohnstad on leadership and career growth.

Why Data Availability Is the Wrong Starting Point

Most data product roadmaps are built backward from data warehouses. The logic goes: we have sales data, marketing data, and product usage data—what can we build with this? This is the inverse of effective product management. You end up with solutions searching for problems. Dashboards that show what’s easy to measure instead of what matters. Models that predict things nobody needs predicted.

The correct starting point is the decision inventory: what decisions does this business make repeatedly that could be faster, cheaper, or more accurate with better data infrastructure? Once you have that list, you map each decision to its required inputs. Then—and only then—you assess what data exists and what gaps need to be filled. This often surfaces uncomfortable truths: the decision the CEO cares most about requires data the company doesn’t collect. Now you have a real scoping conversation: do we instrument the missing data, or do we build a proxy model with available data and clearly document the limitation?

Starting with data availability creates a second-order problem: you attract the wrong stakeholders. The people who show up to use a data product built around available data are the people whose questions happen to align with what you can already measure. You miss the high-value decisions that require new instrumentation or data partnerships. You end up serving the easy problems instead of the important ones. For related analysis on why analytics initiatives fail when they optimize for the wrong problems, see Data Product Management: Why 82% of Analytics Fail.

This dynamic is particularly visible in organizations that celebrate “time to first dashboard.” Speed is irrelevant if you’re building the wrong thing. A dashboard delivered in two weeks that nobody uses is worse than a four-month build that eliminates a recurring decision bottleneck. The faster you build the wrong solution, the more organizational trust you burn when it doesn’t get adopted. Better to spend the extra month validating the decision architecture than to iterate through three dashboard versions trying to guess what stakeholders actually need.

How AI Governance Constraints Shape What You Can Measure

As organizations adopt AI-powered features in data products—predictive models, anomaly detection, natural language query interfaces—the measurement infrastructure becomes exponentially more complex. You’re no longer just tracking “did the user open the dashboard.” You’re tracking “did the user trust the model’s recommendation enough to act on it” and “what happens when the model and the human disagree.” These are not questions your existing product analytics stack can answer without significant instrumentation work.

According to MIT Sloan’s 2024 research on AI adoption in enterprise settings, 71% of organizations deploying AI-assisted decision tools lack the measurement infrastructure to detect when users are overriding AI recommendations, which means they can’t measure whether the AI is actually improving decision quality or just adding cognitive overhead. The governance layer—who can see what predictions, how model outputs are logged, what audit trails exist—directly constrains what product metrics you can capture.

This is where the AI engineering layer intersects with product management. If your ML engineers haven’t built prediction logging with user action tracking, you cannot measure decision impact. You can measure model accuracy in a test set. You cannot measure whether the model changed real-world outcomes. David Ohnstad has seen this gap repeatedly at Veeam, where AI-driven recommendations were deployed without the telemetry to track whether account managers actually followed the recommendations or ignored them. Six months later, leadership asked “is this model working?” and the only honest answer was “we don’t know—we’re not measuring it.” For more on how model governance and measurement infrastructure need to be built together, explore David Ohnstad on AI and enterprise SaaS.

Stop Measuring Engagement. Start Measuring Decision Elimination.

Here’s the contrarian claim most data product teams won’t accept: high engagement is often a symptom of failure, not success. If users are opening your dashboard daily, spending 15 minutes exploring the data, and then going back to their spreadsheet to make the actual decision, your product is entertainment—not infrastructure. The goal of a data product is to make a decision faster or more accurately, not to make data exploration a daily ritual.

The metric that actually matters is decision elimination: how many decisions that previously required a meeting, an email thread, or a manual analysis can now be made in under 60 seconds with your product? If the answer is zero, your engagement metrics are measuring the wrong thing. According to Harvard Business Review’s 2023 analysis of enterprise analytics ROI, organizations that measured decision velocity—time from question to action—saw 2.7x higher returns on analytics investments than organizations that measured dashboard usage or query volume.

This requires a mindset shift. Instead of celebrating “500 monthly active users,” ask “how many recurring decisions did we automate?” Instead of tracking “average session duration,” measure “percentage of questions answered without follow-up.” These are harder metrics to instrument. They require tracking outcomes, not just interactions. But they’re the only metrics that prove a data product is actually doing its job: making the business faster or smarter at the decisions that matter.

The best data products are invisible. They answer the question so clearly that the user never thinks about the underlying complexity. The worst data products require training sessions, office hours, and Slack channels full of “how do I interpret this metric?” questions. If your data product requires ongoing support to use, it’s not a product—it’s a service contract. Real products are self-evident.

How do you identify the right decision to build a data product around?

Start by interviewing decision-makers about their recurring pain points, then map those to decisions that happen at least monthly with clear success criteria. The best candidates are decisions currently made with incomplete data, conflicting sources, or manual processes that create bottlenecks. Validate that solving this decision will materially change an outcome the business cares about, not just make someone’s day slightly easier.

What’s the difference between a data product and a dashboard?

A dashboard displays information and requires the user to interpret it and decide what action to take. A data product embeds the decision logic, surfaces only specific findings, and often automates the next step. If your “product” is just data visualization without workflow integration or clear decision triggers, it’s a dashboard. Products reduce decision latency. Dashboards increase data visibility.

Why do most data products fail to get adopted after launch?

Most fail because they were scoped around available data instead of actual decisions, which means they answer questions nobody is asking. Adoption fails when the product doesn’t eliminate a painful manual process or make a high-stakes decision measurably faster or more accurate. If using the product requires more effort than the current workaround, stakeholders will revert to the old process within weeks.

What This Means for Data Product Managers in Q4 Planning

For practitioners: stop accepting vague requests like “we need better analytics.” Push back with “what specific decision are you trying to make, how often, and what does success look like?” Document the current decision process, identify the failure mode, and build only for decisions where better data infrastructure will measurably change outcomes. If you can’t describe the before-and-after state in terms of decision velocity or quality, you don’t have a product—you have a science project.

For leaders: audit your existing data products against this question: “Which recurring decisions are materially faster or more accurate because this product exists?” If the answer is unclear, you have an engagement problem masquerading as a product. Redirect your team’s roadmap toward decision elimination, not feature expansion. The metric is not how many dashboards you ship. It’s how many decision bottlenecks you collapse.

When was the last time you measured whether your data product changed a decision, or just confirmed what 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 Strategy: Why You’re Building the Wrong Thing appeared first on David Ohnstad.

Why Data Product Success Metrics Are Lying to You

We built a customer segmentation platform that became the highest-adopted data product in company history. Three hundred seventy-two active users in the first quarter. A 94% satisfaction score in our feedback survey. Leadership cited it in the all-hands as proof our data team was delivering. Six months later, we discovered the platform had increased the average time-to-decision by 11 days and spawned 47 competing analysis workflows across departments because nobody could agree on which segment definitions to use. According to Gartner’s 2024 Analytics and BI Survey, 67% of data and analytics leaders report that their teams struggle to demonstrate business value despite high user engagement scores.

The problem is not that we measured adoption wrong. The problem is that adoption, engagement, and user satisfaction are borrowed from consumer product playbooks where more usage genuinely means more value. For internal data products, high engagement can mask organizational dysfunction. A dashboard that 200 people check daily might mean you have created an essential decision-support tool. Or it might mean you have institutionalized a data bottleneck that forces every analyst to manually verify numbers before trusting them.

Most data product teams enter Q3 reviews armed with metrics that make them look successful when they are actually creating drag. This is not a communication problem. This is a measurement framework problem. See also: why most AI projects fail.

The Decision Velocity Gap: What Actually Breaks During Budget Season

When finance teams start cutting headcount and tools during Q4 planning, data products get evaluated on cost-per-user, engagement trends, and survey scores. These metrics tell you nothing about whether the product is accelerating or slowing down the decisions it was built to support. The cost is immediate and visible. The value is assumed from proxy signals that do not measure decision impact.

Here is what breaks: a data product with 400 monthly active users and an NPS of 72 still gets cut if the CFO cannot see a line between that product and faster revenue decisions, reduced operational cost, or eliminated manual work. User satisfaction does not translate to finance language. Decision velocity does. According to McKinsey’s 2023 study on data-driven organizations, companies that measure decision speed alongside data quality see 2.3 times higher ROI on analytics investments than those tracking engagement alone.

David Ohnstad saw this firsthand at a previous role where a pricing analytics platform had stellar engagement metrics but was quietly increasing the time required to finalize contract approvals. Sales reps were using the platform to generate pricing scenarios, then re-creating the analysis in spreadsheets to verify the logic before presenting to leadership. The platform was adopted. It was not trusted. That distinction only surfaced when someone mapped the full contract approval workflow and discovered the platform had become an additional review step, not a replacement for manual analysis.

The lesson: high usage does not mean high trust. High trust is what eliminates redundant work. If your data product is not reducing query volume, cutting approval cycles, or retiring manual processes, engagement metrics are measuring activity, not value.

The Impact Decomposition Framework: Four Metrics That Predict Retention

Most data product managers defend their roadmaps with adoption curves and feature usage heatmaps. These matter for consumer products where engagement correlates with revenue. For internal data products, you need a different stack. This is a four-layer model that measures whether your product is actually changing how decisions get made or just adding to the process.

Layer 1: Query Elimination Rate. Track how many redundant queries, manual reports, or duplicate analyses your product has retired. This is the inverse of adoption — you want usage to go down in specific places because your product has replaced them. At Veeam, David Ohnstad worked on a pipeline monitoring product where success was not how many people used the dashboard, but how many fewer Slack messages went to the data engineering team asking “Is the pipeline broken?” A 40% reduction in support queries over three months signaled the product was working. The dashboard usage stayed flat, but the support burden dropped. That is the metric that justified the headcount.

Layer 2: Decision Cycle Compression. Measure the time between data request and decision execution for the workflows your product supports. If you built a margin analysis tool for pricing teams, the relevant metric is not how often it gets opened — it is whether contract approvals that used to take 9 days now take 6. This requires instrumenting workflows outside your product, which most teams skip because it is hard. That is exactly why it is valuable. The teams that measure this are the ones that survive budget cuts.

Layer 3: Data Debt Reduction. Count how many shadow datasets, unofficial transforms, or manual reconciliation steps your product has eliminated. Every spreadsheet that pulls from your warehouse and applies custom logic is technical debt. Every “clean” version of a table that lives in someone’s personal schema is a data quality risk. A data product that centralizes customer segmentation should reduce the number of segmentation models in production, not add to them. Track this monthly. If your product launches and the number of competing definitions increases, you have not solved the problem — you have made it worse.

Layer 4: Trust Verification Bypass. This is the hardest one to instrument and the most predictive of long-term retention. Measure how often users validate your product’s output against another source before acting on it. If analysts are pulling data from your product, then cross-checking it in another tool or spreadsheet before sharing with leadership, your product is not trusted. It is tolerated. The way to measure this: track which reports get exported, modified, and re-uploaded versus which get shared directly. A healthy data product has a high share-through rate. A product that is not trusted shows high export volume with low direct sharing.

This framework shifts the conversation from “How many people are using this?” to “How many decisions are faster, cheaper, or more confident because this exists?” That is the question finance teams actually care about when they review your budget in Q4.

Why This Matters More in Q3 Than Any Other Quarter

Most product teams treat Q3 reviews as a retrospective exercise. For data products, Q3 is when next year’s funding gets decided. Leadership is not asking “Did you ship features?” They are asking “Should we keep funding this, expand it, or cut it?” The teams that survive are the ones that can tie their product to measurable business outcomes using the language finance and operations understand.

Here is the problem: if you have spent the last three quarters tracking adoption, engagement, and NPS, you do not have the data to make that case. You have user satisfaction scores. Finance does not budget based on satisfaction. They budget based on cost avoidance, revenue acceleration, or operational efficiency. According to Forrester’s 2024 report on data and analytics investments, 58% of enterprise data initiatives fail to secure continued funding after the first year because teams cannot translate usage metrics into financial impact.

David Ohnstad has seen this gap kill products that were genuinely useful. A few years ago, a customer health scoring model he helped build had 200+ weekly active users across sales and customer success. The team presented engagement trends and survey feedback in the Q3 review. Finance asked one question: “How much faster are renewal decisions happening because of this model?” Nobody had measured that. The product got defunded. Not because it was not valuable — because the team could not prove the value in terms leadership could budget against.

The contrarian take: stop measuring data products like you measure SaaS apps. Your users are not paying you with dollars. They are paying you with trust and time. If your product does not reduce the time they spend verifying data or eliminate redundant work, high engagement means you have built a step in the process, not a solution to the problem.

The AI Measurement Constraint Nobody Talks About

If your data product includes any AI or machine learning components — forecasting, classification, recommendation engines — the measurement problem compounds. Most teams treat model performance metrics (accuracy, precision, recall) as product success metrics. They are not. A model with 92% accuracy that nobody trusts is not a successful product. It is a science experiment.

The issue is that AI/ML engineering decisions around model governance, monitoring infrastructure, and explainability directly constrain what product-level metrics you can even capture. If your ML engineers built a model that cannot log prediction confidence scores or surface feature importance, you cannot measure trust verification bypass. If your model pipeline does not track which predictions get overridden by users, you cannot measure decision cycle compression. As David Ohnstad on AI and enterprise SaaS has explored in depth, the infrastructure choices made during model development define what product metrics are even possible to calculate later.

This is why data product managers need to be in the room when AI/ML architecture decisions get made. If you wait until the model is deployed to think about measurement, you have already locked yourself into a limited set of proxy metrics. The teams that get this right define the instrumentation requirements before the first training run.

Leadership Capability Gaps That Kill Execution

Even with the right metrics framework, execution fails when leadership does not understand how to interpret decision velocity data or translate it into roadmap trade-offs. A common failure mode: a product leader sees that decision cycle time has dropped by 15% and interprets that as success without checking whether total decision volume has increased. If your product cut decision time but also made people question more decisions because the data is harder to interpret, you have not improved velocity — you have shifted the bottleneck.

This is where leadership and team execution capability directly impacts whether your data product strategy delivers or stalls. As David Ohnstad on leadership and career growth has written about, the ability to coach teams through ambiguous measurement problems and translate complex data outcomes into executive language is not a soft skill — it is the skill that determines whether your product survives budget season. A technically excellent data product with a leader who cannot defend its value in CFO language gets cut. A mediocre product with a leader who can tie it to cost avoidance or revenue impact gets funded.

The gap is real. Most data product managers come from analytics or engineering backgrounds where they learned to optimize models and pipelines, not to navigate budget politics or coach stakeholders through metric interpretation. That is a career ceiling. Learning to build the right measurement framework matters. Learning to use it in a room full of finance and operations leaders matters more.

What to Do This Week If You Are Heading Into Q3 Reviews

If you are presenting a data product in the next 30 days and your slide deck is full of adoption curves, user satisfaction scores, and feature release timelines, rebuild it. Finance and operations leaders do not budget based on those signals. They budget based on measurable impact to cost, speed, or quality of business decisions.

Start by mapping the decision workflows your product was supposed to improve. Not the use cases you pitched in the roadmap deck. The actual business decisions. For each one, identify the baseline time-to-decision before your product launched and the current time-to-decision. If you do not have that data, you cannot make a retention case. Instrument it this week. Track one decision workflow end-to-end. Measure how long it takes. Compare it to the manual process it replaced. That is your headline metric.

Next, count how many redundant data sources, shadow datasets, or manual reports your product has eliminated. If the answer is zero — if your product added to the data landscape without retiring anything — you have a problem. Data products that increase total data infrastructure complexity without reducing manual work do not survive budget cuts. Find one thing your product has replaced and put that number in the deck.

Finally, ask your most active users this question: “When you pull data from this product, do you verify it against another source before acting on it?” If the answer is yes, your product is not trusted. It does not matter how high your NPS is. Trust verification bypass is the metric that predicts whether people will fight to keep your product funded or let it quietly disappear in Q4 cuts.

What metrics should data product managers use instead of adoption rates?

Data product managers should measure query elimination rate, decision cycle compression, data debt reduction, and trust verification bypass. These metrics capture whether a product is actually changing how decisions get made, not just adding another step to the process. Adoption and engagement are useful as secondary signals, but they do not predict retention or justify budget in finance reviews the way decision velocity and cost avoidance do.

How do you measure decision velocity for internal data products?

Measure decision velocity by tracking the time between data request and decision execution for workflows your product supports. Instrument one end-to-end decision process, measure the baseline time before your product launched, and compare it to current cycle time. If contract approvals used to take 9 days and now take 6, that 33% reduction is your velocity metric. This requires tracking workflows outside your product, which is why most teams skip it and rely on engagement proxies instead.

Why do data products with high engagement still get defunded?

Data products with high engagement get defunded when they cannot demonstrate measurable impact on decision speed, cost reduction, or data quality. Engagement metrics show activity, not value. If users are checking a dashboard daily but still verifying the output in spreadsheets before acting, high engagement signals low trust. Finance teams budget based on business impact, not user satisfaction scores. Products that cannot tie usage to faster decisions or eliminated manual work do not survive Q4 budget reviews.

The One Question Every Data PM Should Answer Before October 1

For practitioners: if your data product disappeared tomorrow, which decisions would take longer, cost more, or require manual work that is currently automated? If you cannot name three specific decisions with measurable time or cost differences, you do not have a defensible budget case. Build that map this week. Instrument one workflow end-to-end. Get the baseline. That number is worth more than any adoption curve when you are sitting in a room with finance leaders deciding what gets funded next year.

For leaders: the teams that will ask you to defend data product budgets in Q4 are not going to accept engagement metrics as proof of value. They are going to ask whether the product reduced cost, accelerated revenue, or eliminated risk. If your product managers cannot answer that question with specific numbers, they are not ready for the conversation. Coach them through the measurement framework now, before the budget cycle starts. The difference between a product that gets expanded and one that gets cut is not the quality of the dashboard. It is the quality of the business case. As explored in Data Product Manager Salary Gap: Why and How to Fix It, the ability to translate technical delivery into measurable business outcomes is the skill that separates senior data PMs from those who plateau at mid-level roles.

Here is the question that should make you uncomfortable: when was the last time you measured whether your data product is making decisions faster, or just making your users busier? If the answer is never, your Q3 review is going to be harder than it needs to be. The measurement infrastructure you build this week determines whether your product survives the Q4 budget conversation. Most teams wait until they are in the room to realize they are missing the data. That is too late. The time to instrument decision velocity is now, while you still have a quarter to prove it matters.

For more on this topic, see Data Product Management: Why 82% of Analytics Fail.

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 Success Metrics: Why They’re Misleading appeared first on David Ohnstad.

Most Data Product Budgets Die in August, Not October: The Pre-Defense Problem

We built a $220K data platform integration that shipped on time, under budget, with clean documentation. Finance killed it three weeks before Q4 planning. Not because the deliverable was wrong — because we couldn’t explain in five minutes why it mattered more than the six other platform investments competing for the same headcount allocation. According to Gartner’s 2024 Data & Analytics Leadership Survey, 68% of data product investments fail to secure renewal funding not due to technical failure, but due to inability to articulate business-aligned success metrics during budget review cycles.

The problem isn’t that data PMs build the wrong things. The problem is they start defending budget value eight weeks too late. By the time most teams assemble their Q4 budget justification deck, the real decisions have already happened — in hallway conversations between finance and division heads, in quarterly business reviews where data products weren’t represented, in executive offsites where roadmap priorities got reordered without a single data PM in the room. Budget season doesn’t start when finance sends the template. It starts the moment your last quarter’s delivery hits production and stakeholders form their first impression of whether it was worth the cost.

This isn’t about better slide decks or tighter ROI calculations. This is about whether you built the feedback instrumentation to measure business impact from day one, and whether you have the vocabulary to translate technical capability into CFO-legible outcomes before anyone asks. Most data PMs treat budget defense as a fourth-quarter event. The ones who keep their funding treat it as continuous product instrumentation. See also: how coaching culture strengthens budget arguments.

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

Why Data Product Value Conversations Fail Before They Start

Finance speaks in opportunity cost. Engineering speaks in technical debt reduction. Business stakeholders speak in time saved or decisions accelerated. Data product managers get caught in the translation gap — defending platform capabilities to people who don’t care about pipelines, defending usage metrics to CFOs who want to know why this costs more than the SaaS alternative they saw at a conference last month.

The core failure is this: most data product teams measure the wrong proxy variables. They track dashboard logins, query volumes, API calls — lagging indicators that show usage but not impact. When budget conversations arrive, they present graphs of adoption that look impressive until someone asks the obvious question: “What decision changed because of this data product that wouldn’t have changed otherwise?” And the room goes quiet.

According to McKinsey’s 2023 Analytics Impact Study, only 23% of enterprises could quantify a direct business outcome tied to a specific data product investment within 90 days of launch. The other 77% reported usage metrics, satisfaction scores, or technical performance SLAs — none of which answer whether the product justified its cost. The gap isn’t in the data product’s capability. The gap is in how value gets instrumented, measured, and communicated from the first sprint.

Here’s what makes this especially painful: the best-performing data products often have the weakest budget defense cases. A data product that becomes invisible infrastructure — deeply embedded, relied upon daily, never breaking — stops generating the visible wins that executives remember during planning season. The product that’s perpetually half-broken and requires weekly firefighting gets more executive attention because the pain of its absence is constantly visible. Budget re

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

newals reward visibility, not stability. That’s backwards, but it’s reality.

The Pre-Budget Value Instrumentation Model

This is a four-stage process that starts before the first line of code gets written and runs continuously through the product lifecycle. Each stage builds the evidentiary foundation that budget conversations require. Skip any stage and you’re defending retrospectively instead of proving proactively.

Stage 1: Decision Mapping Before Development — Before sprint zero, identify the three most expensive decisions this data product will influence and document the current cost of making those decisions poorly. Not hypothetical value. Actual cost. How long does the decision take now? How often does it get revisited because the data wasn’t clear? What does one wrong decision cost in lost opportunity, rework, or customer churn? This becomes your value ceiling. If your data product can’t measurably improve at least one of these high-cost decisions, don’t build it — you will not survive budget review.

Stage 2: Leading Indicator Selection — Pick two leading indicators that predict whether the decision quality is improving, measurable within 30 days of launch. Lagging indicators like “revenue influenced” take quarters to prove. Leading indicators like “time from question to confident answer” or “percentage of decisions made without escalation” show value immediately. The best leading indicator I’ve seen: reduction in repeat analysis requests. If stakeholders ask the same question three times, the data product didn’t answer it. If they ask once and move forward, it did. That’s measurable weekly.

Stage 3: Baseline Documentation — Two weeks before launch, document the current state with painful specificity. How long does the decision take today? How many people are involved? What’s the error rate? What’s the stakeholder confidence score? This is not a feel-good exercise. This is the control group. When budget season arrives and someone asks “How do we know this made a difference?”, you need the before-state documented by someone other than your team. Get a business stakeholder to sign off on the baseline. Their name on the measurement makes it credible.

Stage 4: Continuous Value Logging — Instrument the product to capture decision velocity, not just usage. Who used the data product is less valuable than what decision they made faster because of it. Build lightweight feedback loops: a single-question survey after every dashboard interaction (“Did this data change your next action? Yes / No / Still deciding”), a Slack integration that logs when someone references the data product in a decision thread, a quarterly stakeholder interview that asks “What decision would you have made differently without this?” These inputs feed the budget narrative. Without them, you’re guessing.

Most data product teams resist this model because it feels like overhead. It is overhead. It’s also the difference between renewing your budget and explaining to your team why the platform they built is getting deprecated. The teams that survive budget cuts are the ones who treated value measurement as a product feature from day one, not a retrospective justification exercise.

The ARR-Guardian Case Study: Measuring Impact When the Product Becomes Infrastructure

At Veeam, we built a renewal risk scoring model that integrated into the customer success platform. Technical execution was clean: sub-200ms query response, 94% prediction accuracy on 90-day renewal likelihood, full audit trail for compliance. Usage was high: CS team accessed it daily, account reviews referenced it consistently. But six months in, we faced a budget reallocation conversation. Another team wanted our headcount for a customer-facing feature with more visible impact.

We survived that conversation because we had instrumented decision velocity from week one. We tracked how long account reviews took before and after the model went live. Average review duration dropped from 47 minutes to 22 minutes. We tracked escalation rates: how often did a CS manager need to pull in a director to make a renewal decision? That dropped 38% in the first quarter. We tracked decision confidence: post-review surveys asked “How confident are you in the recommended action?” Confidence scores above 8/10 went from 54% to 81%.

But the number that saved the budget was opportunity cost. We calculated how many additional accounts the CS team could now review per quarter with the time saved. At an average account value of $47K annually, the incremental coverage was worth $1.2M in at-risk ARR that previously wouldn’t have gotten proactive attention. That number — $1.2M in coverage expansion — was the budget defense. Not prediction accuracy. Not usage stats. Not stakeholder satisfaction. The delta between what decisions could be made before and after.

The model became invisible infrastructure within nine months. Nobody talked about it. It just worked. That’s usually the death sentence for budget renewal. But because we had logged decision velocity and opportunity cost continuously, we had a value narrative that didn’t depend on executive memory or visible heroics. When finance asked why we needed to maintain this investment, we showed them a spreadsheet of incremental ARR coverage that would disappear if the product went away. Budget approved. The lesson: measure the absence cost, not just the presence value.

Stop Measuring Adoption — It Tracks Visibility, Not Value

Here’s the contrarian position that gets me into arguments with other data PMs: adoption metrics are a trap. High adoption of a low-value data product is worse than low adoption of a high-value one, but most teams celebrate the former and panic about the latter. Adoption measures how often people interact with the product. It does not measure whether those interactions produced better outcomes.

I worked with a team that built a real-time sales dashboard used by 200 people daily. Adoption looked great. Budget got cut anyway. Why? Because when finance asked what decisions changed, the sales VP admitted the dashboard was “nice to have” but didn’t influence pipeline prioritization. High usage of a low-stakes product is a budget risk. Conversely, I’ve seen a data product used by exactly seven people — senior finance analysts — that survived three rounds of budget cuts because those seven people made capital allocation decisions worth $80M annually, and they couldn’t do their job without it.

Adoption is a leading indicator of engagement. It is not a proxy for impact. The most dangerous thing a data PM can do is present a usage graph to a CFO and assume it speaks for itself. It doesn’t. Usage without outcome articulation reads as “people clicked on things.” That’s not a budget defense. That’s a vanity metric.

According to Forrester’s 2024 Data Strategy Report, enterprises that tied data product funding to outcome metrics (decision speed, error reduction, opportunity cost avoidance) had 3.2x higher budget renewal rates than those defending based on adoption and satisfaction scores. The shift is straightforward: stop measuring whether people used the product, start measuring whether the product made expensive decisions less expensive.

Building the Budget Narrative Before Budget Season Starts

The budget defense narrative doesn’t start when finance sends the Q4 planning template. It starts in the first sprint retrospective when you document what stakeholders expected to change and what actually changed. Every quarter, assemble a lightweight value log: three decisions that moved faster, two decisions that didn’t need escalation, one decision that would have gone wrong without the data product. These don’t need to be massive wins. They need to be specific and attributable.

The format that works: stakeholder name, decision context, time delta or cost delta, their words. Example: “Sarah Martinez, Regional Sales Director — needed to reallocate Q3 territory coverage. Before: 11 days to pull pipeline data and model scenarios. After: 2 days using the territory planning model. Her quote: ‘We reallocated two weeks earlier than we could have last year, which gave the team time to adjust before end-of-quarter.’ Value: earlier reallocation likely prevented $120K in missed quota.” That’s a budget narrative building block.

Collect four to six of these per quarter. By the time budget season arrives, you have 16-24 concrete examples of decisions that got better because the data product exists. That’s not a slide deck exercise. That’s evidence. When someone asks “What happens if we cut this?”, you have a specific answer: these 20 decisions revert to the old speed, cost, and error rate. Do you want that? Most executives don’t. But they need the specificity to understand what they’re risking.

David Ohnstad has watched too many strong data products get cut because the PM assumed the value was obvious. It’s never obvious. The product that survives budget scrutiny is the one where the PM treated value documentation as a weekly discipline, not a quarterly scramble. Building that discipline requires acknowledging that your job isn’t just shipping features — it’s continuously proving why the features justify their cost.

This intersects directly with how AI and enterprise SaaS products are evaluated during procurement cycles — where stakeholder alignment and outcome articulation often matter more than technical capability. Similarly, understanding leadership and career growth strategies helps PMs navigate the internal mobility dynamics that can disrupt roadmap continuity during budget planning season, especially when key team members transition to new roles mid-cycle.

The Federated Ownership Trade-Off: When Distributed Accountability Kills Budget Clarity

Federated data architectures promise distributed ownership and domain-aligned accountability. They also create a budget defense nightmare: when five teams co-own a data platform, who defends its value during budget cuts? The answer is usually “nobody clearly,” which is how platforms get deprecated despite delivering real value. Distributed ownership works for technical execution. It fails catastrophically for budget justification unless one PM owns the synthesis narrative.

David Ohnstad has seen this pattern repeatedly: a federated data platform where each domain team instruments their own value metrics, but nobody aggregates the total impact story. Finance sees six separate small investments, not one coherent capability. When budget pressure hits, each small investment looks cuttable. The aggregate value — visible only when you add up all the domain impacts — never gets presented because no single owner felt responsible for the cross-domain story.

The fix is assigning one PM — not necessarily the most senior, but the one with the best finance relationships — to own the aggregate value narrative. That PM’s job isn’t technical coordination. It’s collecting the decision-impact stories from every domain team quarterly and building the unified budget case. This doesn’t centralize architecture. It centralizes narrative. Without it, federated platforms are structurally vulnerable during budget season regardless of their technical success. For more on why this organizational design creates hidden failure modes, see the pillar content on federated data architectures and PM accountability gaps.

How do you measure data product ROI before revenue impact is visible?

Focus on leading indicators tied to decision velocity: time from question to answer, reduction in repeat analysis requests, percentage of decisions made without escalation, and stakeholder confidence scores. These predict value within 30 days of launch, while revenue impact can take quarters to materialize and is often influenced by variables outside the data product’s control.

What is the difference between adoption metrics and impact metrics for data products?

Adoption metrics track usage frequency — logins, queries, dashboard views. Impact metrics track decision outcomes — time saved, error reduction, confidence improvement, opportunity cost avoided. High adoption of a low-stakes product is a budget risk. Low adoption of a high-impact product used by key decision-makers often survives cuts. Impact matters more than visibility.

Why do data product budgets get cut even when usage metrics look strong?

Because usage doesn’t prove value — it proves engagement. When finance asks what decision changed or what cost was avoided, usage graphs don’t answer the question. Budgets survive when PMs can articulate specific decisions that moved faster, cost less, or had higher confidence because the product existed. Without that causal link, high usage reads as “people clicked things,” not impact.

What to Do Before Your Next Budget Cycle Starts

Two explicit actions — one for practitioners, one for leaders. If you’re a data PM, start a value log this week. Create a lightweight document with four columns: stakeholder name, decision context, measurable delta (time or cost), their quote. Add one entry per week. In 12 weeks you have a budget narrative. In 24 weeks you have a defensible track record that doesn’t depend on executive memory. This isn’t extra work — this is the work. If you can’t name the decisions your product improved, you’re building a feature, not a product.

If you’re leading a data product organization, audit whether your team has the instrumentation to answer the budget question before it gets asked. Can every PM on your team name three high-cost decisions their product influences and show a measurable delta within 90 days of launch? If not, budget season will be reactive and defensive. Value articulation isn’t a communication skill. It’s a product design discipline. Build it into sprint planning, retrospectives, and quarterly reviews. The teams that treat it as optional are the ones explaining to their engineers why the platform they built is getting deprecated.

Here’s the question to sit with: if your CFO asked you today, “What decision would cost us more to make if your data product disappeared tomorrow?”, could you answer in one sentence with a number attached? If not, you’re not done building the product. You’re missing the instrumentation layer that proves it was worth building. For more on navigating the compensation side of these budget and value conversations, see the discussion on data product manager salary negotiation and the analysis of data product manager compensation structures that reflect outcome accountability.

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 Budget Defense: Why August Kills Q4 Plans appeared first on David Ohnstad.

Why Data Product Budgets Get Cut: The ROI Measurement Gap

We spent $380,000 on a data platform rebuild. Usage metrics looked strong: 142 active users in month three, 89% uptime, query response times under 2 seconds. Six months later, finance killed the budget renewal. Not because the platform failed—because we couldn’t answer whether it changed a single business decision. According to Gartner’s 2024 Analytics and Business Intelligence Survey, 68% of data and analytics leaders report difficulty demonstrating business value to executive stakeholders, and 54% face budget scrutiny specifically because they lack clear ROI measurement frameworks.

That gap isn’t a data problem. It’s a language problem. Data product managers speak in adoption curves and system reliability. CFOs speak in margin improvement and opportunity cost. When finance asks why the data platform costs $400K but dashboards still break, most data PMs hand over usage statistics and hope those numbers translate to value. They don’t.

Q3 close forces this conversation into the open. Every non-revenue platform investment gets scrutinized. Data teams that can’t articulate ROI in CFO-legible terms lose budget to teams that can—even when the data product delivers more strategic value. See also: measuring implementation success across teams.

What Gets Measured Versus What Actually Matters

The standard data product health metrics are usage rate, query volume, and uptime. These measure activity, not impact. A dashboard with 200 weekly active users tells you nothing about whether those users made better decisions, moved faster, or avoided costly mistakes. McKinsey’s 2023 State of AI report found that organizations measuring only technical performance metrics were 3.2 times less likely to capture measurable business value from analytics investments compared to those tracking decision velocity and outcome changes. See also: mentorship programs scaling effectively.

Activity metrics create false confidence. David Ohnstad has watched teams celebrate 85% adoption while the product generated zero net new revenue and didn’t prevent a single escalation. The dashboard existed. People opened it. Nothing changed. Finance saw the cost line; they didn’t see the value line because there wasn’t one to show. See also: measuring activity versus actual outcomes.

The root issue: leading indicators for data product manager success don’t map to lagging indicators for business impact. Usage predicts engagement. It doesn’t predict whether engagement drove margin improvement, reduced time-to-decision, or decreased operational risk. Those are the metrics finance cares about during budget season.

Most data PMs over-index on what’s easy to instrument—logins, queries, session duration—and under-index on what’s hard: time saved, decisions accelerated, losses prevented. That trade-off makes the data product vulnerable when budget conversations shift from “is this working?” to “what would we lose if we cut this?”

The Value Translation Framework: From Activity to Business Outcome

The problem isn’t that data products lack value. It’s that value stays trapped in technical metrics that don’t cross the finance translation barrier. The framework David Ohnstad uses to defend data product budgets has four layers, and each one requires instrumentation before budget season starts—not during the renewal meeting when it’s too late.

Layer 1: Measure Decision Velocity, Not Dashboard Opens. Track how long it takes a user to move from data access to decision execution. A procurement team that used to spend four days gathering supplier performance data now does it in 90 minutes because the data product surfaces it automatically. That’s 26.5 hours saved per decision cycle. Multiply by decision frequency. That’s the ROI numerator finance understands. Most data PMs stop at “the dashboard was used 47 times this quarter” and wonder why budget gets cut.

Layer 2: Instrument Opportunity Cost Avoidance. Every data product prevents manual work, rework, or delayed decisions. None of that shows up in adoption metrics. If the data product flags inventory discrepancies before month-end close, it prevents a scramble that used to require six people working a weekend. That’s 96 hours of avoided labor cost, plus the operational risk mitigation of catching the error before it hits the financials. Document what the organization would have spent if the data product didn’t exist. That’s the cost baseline your ROI calculation needs.

Layer 3: Track Leading Indicators That Predict Lagging Outcomes. Usage alone doesn’t predict value, but usage combined with specific user actions does. If procurement opens the supplier dashboard and then executes a contract negotiation within 48 hours, that correlation becomes predictive. Forrester’s 2024 Data Strategy Playbook found that organizations tracking decision-linked usage patterns—not just raw usage—reported 41% higher confidence in their ability to demonstrate ROI to finance stakeholders. Build the instrumentation to capture which user actions immediately follow data product engagement. That gives you the evidence trail when finance asks whether the product actually drives outcomes.

Layer 4: Quantify Baseline Degradation Without the Product. The most defensible ROI argument isn’t what the product enables—it’s what breaks if you remove it. During one budget defense conversation, David Ohnstad documented that eliminating the data product would force the sales ops team back to weekly manual reporting, increasing report delivery time from 30 minutes to 11 hours per cycle. That delay meant sales leaders made territory adjustments based on week-old data instead of near-real-time insights. The cost wasn’t the 10.5 hours of labor. It was the margin loss from delayed territory rebalancing during a peak sales quarter. Finance approved the renewal because the alternative was quantified as direct revenue risk.

This framework only works if instrumented before budget conversations start. You cannot retroactively build the ROI case during the Q4 planning cycle if you haven’t been capturing the value metrics all year. That’s the failure mode most data teams hit: great product, no ROI story, budget cut anyway.

How AI Procurement Costs Complicate Data Product ROI

AI/ML engineering teams often underestimate the procurement and stakeholder alignment costs that data PMs must defend during budget cycles, making technical capability alone insufficient for enterprise approval. A recommendation engine that improves click-through by 18% sounds like a win until finance sees the $240K annual spend on model infrastructure, the three-month integration timeline that delayed other roadmap work, and the fact that click-through improvement didn’t translate to measurable purchase conversion lift.

The procurement layer adds cost without adding legible value unless the data PM builds the instrumentation to connect AI feature usage to business outcomes. According to Deloitte’s 2024 State of AI in the Enterprise report, 62% of AI projects face budget challenges due to unclear ROI articulation, and 47% of finance leaders cite “inability to measure incremental value” as the primary barrier to continued AI investment. The technical win—model accuracy, latency improvement, feature adoption—doesn’t survive the budget renewal meeting if it can’t be translated into margin impact, cost avoidance, or risk reduction.

Data product managers who treat AI features as engineering deliverables instead of business investments set themselves up for budget cuts. The AI capability might be sound. The AI and enterprise SaaS architecture might be clean. But if the cost structure doesn’t map to a defensible ROI calculation, finance will kill the project before it scales. This gap between technical success and financial defensibility is where most enterprise AI initiatives stall—not because the models fail, but because the business case was never instrumented in CFO-legible terms.

When Leadership Transitions Break Data Product Continuity

Internal mobility planning directly impacts data product roadmap continuity when key PMs transition to leadership roles during budget season. A data product that had executive sponsorship in Q2 loses its champion in Q3 when that VP moves to a new division. The new leader inherits the budget line but not the context on why the investment mattered. Without documented ROI metrics that survive leadership transitions, the data product becomes an orphaned cost center.

David Ohnstad has seen this kill otherwise successful products. A customer analytics platform had strong adoption, clear business impact, and a roadmap aligned to corporate strategy. The VP who sponsored it took a new role in October. The replacement inherited the P&L and asked the obvious question: “What would we lose if we stopped funding this?” The data PM couldn’t answer with specifics because the ROI story lived in the previous VP’s head, not in documented metrics. Finance cut the budget by 60% in the next planning cycle.

The fix isn’t better stakeholder management. It’s building leadership and career growth transition resilience into the data product itself. Every data product needs a one-page ROI brief that updates quarterly: baseline cost without the product, measurable outcomes delivered, decision velocity improvements, opportunity cost avoidance. That document must be legible to a finance leader who has never used the product and doesn’t understand the technical architecture. If it requires the current PM or the current executive sponsor to explain, it won’t survive their departure.

This is especially critical in Q3 and Q4 when leadership transitions cluster around annual planning cycles. A data product without documented, executive-legible ROI metrics is one leadership change away from a budget cut, regardless of how well it performs.

Stop Measuring Engagement—Measure Time-to-Insight Instead

Most data product managers track the wrong proxy. Engagement metrics—dashboard views, query counts, session duration—measure whether people are using the product. They don’t measure whether the product makes people faster or better at their jobs. That distinction kills data products during budget season.

Time-to-insight measures how long it takes a user to go from “I have a question” to “I have an answer I trust enough to act on.” A finance analyst who used to spend six hours reconciling revenue data across three systems now does it in 45 minutes because the data product surfaces a unified view. That 5.25-hour reduction per cycle is the ROI number finance understands. Multiply by frequency: if the analyst does this twice a week, the data product saves 546 hours per year. At a $75/hour loaded cost, that’s $40,950 in annual labor cost avoidance—just for one user on one workflow.

Harvard Business Review’s 2023 analysis of analytics adoption found that organizations measuring time-to-insight reported 2.7 times higher ROI confidence scores compared to those measuring only usage-based engagement metrics. The metric shift changes the conversation. Engagement metrics prompt the question “Is anyone using this?” Time-to-insight metrics answer the question “Are we getting faster at making decisions because this exists?” The second question maps to business value. The first one doesn’t.

But most data PMs don’t instrument time-to-insight because it requires baseline measurement before the product ships. You need to know how long the workflow took before the data product existed. That means running a pre-launch time study on at least 10 representative users completing the task manually. Most teams skip this step because they’re focused on building the product, not measuring the problem. Then budget season arrives, finance asks “What did this actually improve?” and the data PM has usage stats but no before-and-after comparison. That’s the gap that gets budgets cut.

The Real Budget Defense: Document What Breaks If You Remove It

The strongest ROI argument for a data product isn’t what it enables—it’s what fails if you take it away. Finance approves investments that prevent measurable loss more readily than investments that promise speculative gain. A data product that prevents the sales ops team from spending 11 hours per week on manual reporting has a quantified cost of removal: 572 hours per year at $65/hour loaded cost equals $37,180 in direct labor, plus the operational risk of delayed reporting during peak sales cycles.

Most data PMs pitch the value of what the product delivers. That makes the conversation aspirational. Finance hears “This could help us make better decisions” and thinks “That’s not a line item I can defend.” The conversation needs to flip: “Without this product, our sales ops team reverts to manual reporting. That’s 11 additional hours per week. During Q4, that delay means territory rebalancing decisions lag by 9 days. Last year, delayed rebalancing in November cost us an estimated $240K in missed pipeline coverage. This product prevents that.”

That’s not a hypothetical benefit. It’s a documented cost of removal. Finance understands cost avoidance. They approve budgets to prevent loss. But you can only make this argument if you documented the baseline before building the product. If you didn’t measure the cost and time of the manual process before automation, you can’t credibly quantify what reappears if the product gets cut. That missing baseline is why most data products get deprioritized during budget scrutiny—not because they don’t deliver value, but because the PM never quantified what breaks without them.

Case Study: Building ROI Instrumentation Into the Product

One of the most defensible data products David Ohnstad built wasn’t technically sophisticated. It was a supplier performance dashboard for a procurement team managing 180+ vendor relationships. The technical stack was straightforward: SQL warehouse, automated ETL pipeline, Tableau front end. The ROI instrumentation made it un-cuttable during three consecutive budget cycles.

Before building the product, the team documented the baseline workflow. Procurement analysts spent an average of 4.2 hours per week manually pulling supplier data from three systems, reconciling discrepancies in spreadsheets, and generating performance reports for quarterly business reviews. That manual process introduced a 6-day lag between data extraction and report delivery, which meant contract renegotiation decisions were based on weeks-old performance data. During one high-stakes vendor review, the delayed data caused the team to miss a pricing anomaly that cost the company $38,000 before it was caught in the next cycle.

The data product reduced report generation time from 4.2 hours to 22 minutes. That’s a 94% time reduction. It also collapsed the reporting lag from 6 days to near-real-time, which meant procurement could spot pricing issues within 48 hours instead of weeks later. But those technical wins weren’t the ROI story. The ROI story was the cost baseline: without the product, the procurement team would revert to 218 hours of manual reporting labor per year at a $72/hour loaded cost, totaling $15,696 in direct cost. Add the operational risk mitigation—the $38K loss would not have been caught early without real-time data access—and the total annual value was $53,696 against a $41,000 build and annual maintenance cost.

That ROI brief survived two VP transitions and one finance-led zero-based budgeting exercise. It survived because the value didn’t live in David Ohnstad’s head or in usage metrics. It lived in a one-page document that quantified time saved, cost avoided, and loss prevented in terms a CFO could defend to a board. When budget scrutiny hit in Q3 of year two, the new procurement VP had never used the product but could explain exactly what would break if it got cut. Finance renewed the budget without negotiation.

The lesson isn’t that every data product needs a one-page ROI brief. It’s that every data product that matters enough to defend needs instrumentation that quantifies impact before budget season starts. If you wait until the renewal meeting to build the ROI case, you’re already too late. The baseline data, the time-to-insight metrics, and the cost-of-removal calculation need to be baked into the product from day one—not retrofitted when finance starts asking hard questions.

What to Instrument Before Budget Season Starts

Most data PMs treat ROI measurement as a post-launch reporting exercise. That’s why budget renewals turn into scrambles to find justification metrics after the fact. The instrumentation needs to be part of the product spec, not an afterthought. Here’s what to build in before the product ships.

Pre-launch baseline study. Document the current state: how long does the workflow take now, how many people are involved, what does delay or error cost the business? This is the denominator in every ROI calculation. Without it, you can’t credibly claim the product saved time or prevented cost because you don’t know what the starting point was. Most teams skip this because it feels like overhead during a sprint-heavy build cycle. That skipped step is why the ROI case falls apart six months later when finance asks “What did this actually improve?”

User action tracking post-engagement. Instrument what happens after a user accesses the data product. Did they execute a decision within 48 hours? Did they escalate an issue that wouldn’t have been visible without the product? Did they avoid rework because the data was accurate the first time? Usage alone tells you the product was opened. Action tracking tells you whether opening it mattered. This is the bridge metric between activity and outcome, and it’s the one most data products don’t capture.

Quarterly ROI brief. A living document that updates every quarter: baseline cost without the product, hours saved this quarter, decisions accelerated, errors prevented, total quantified value. This is the artifact that survives leadership transitions and budget scrutiny. It doesn’t require deep data literacy to understand. A finance VP who has never touched the product should be able to read the brief and explain to a board member why cutting the budget would cost more than keeping it. If the brief requires interpretation by the PM, it’s not defensible.

This instrumentation work feels like non-product overhead. It’s not. It’s the insurance policy that keeps the product funded when budget priorities shift. Data products with strong adoption but weak ROI documentation get cut during data product manager compensation reviews and budget reallocations. Data products with documented, CFO-legible ROI metrics survive leadership changes, finance scrutiny, and zero-based budgeting exercises. The difference isn’t the quality of the product. It’s whether the value story can be told by someone other than the person who built it.

How do you measure ROI for a data product?

Measure time saved, decisions accelerated, and costs avoided—not usage metrics. Document the baseline workflow before the product ships, then track how much faster users reach decisions and what errors or delays the product prevents. Quantify those improvements in labor cost and opportunity cost terms finance can defend. Usage tells you engagement; time-to-insight and cost avoidance tell you impact.

What is the difference between data product adoption and data product value?

Adoption measures whether people use the product. Value measures whether using it changes outcomes—faster decisions, fewer errors, avoided losses. High adoption with no outcome change means the product is accessed but not impactful. Finance cares about value, not activity. A dashboard with 200 users that doesn’t shorten decision cycles or prevent costly mistakes has adoption but no defensible ROI during budget renewal.

Why do data products get cut during budget planning?

Data products get cut because PMs measure activity instead of business impact. Usage stats don’t translate to CFO-legible ROI. When finance asks what would break if they removed the product, most data PMs can’t answer with quantified costs. Products that document time saved, loss prevented, and workflow degradation without them survive budget scrutiny. Those that only report logins and query counts don’t.

What Data PMs Should Be Asking Right Now

Budget season exposes whether your data product has a defensible ROI story or just impressive usage metrics. For practitioners, the takeaway is this: if you can’t quantify what breaks when the product disappears, you don’t have an ROI case—you have a wishlist. Instrumentation matters more than engagement. The product needs to capture time-to-insight, cost avoidance, and decision velocity from day one, not as a post-launch reporting layer.

For leaders, the question is whether your data product budget requests include baseline measurements and outcome instrumentation, or whether they pitch capability and hope finance translates that to value. The teams that survive budget cuts document what the organization would spend without the product—not what the product might enable in theory. That requires PMs to build ROI tracking into the product spec before the first sprint, not scramble for justification metrics when the renewal meeting lands on the calendar.

When did you last audit whether your most-used data product is actually shortening decision cycles—or just giving people another place to look at numbers before making the same call they would have made anyway?

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 ROI: Why Budgets Fail Without Measurement appeared first on David Ohnstad.

Why Most Data Product Roadmaps Are Built to Fail

Six months into a customer analytics rebuild, the VP of Sales asked for real-time segment refresh—something our batch architecture fundamentally couldn’t deliver without a $200K infrastructure change. We said yes anyway. According to McKinsey’s 2023 data governance research, 68% of data product teams report that scope additions made after the architecture phase require either significant rework or performance compromises that persist through the product’s lifetime. We became that statistic. The dashboard launched on time, technically worked, but refreshed data every 18 hours in a use case where decisions happened every 90 minutes. Sales stopped using it within three weeks.

The real problem wasn’t the feature request. It was that we had no repeatable method for evaluating whether a mid-flight ask was architecturally viable, budget-rational, or user-critical. We made the decision in a conference room based on who had the most organizational leverage, not on any framework for weighing technical debt against user value. David Ohnstad has seen this pattern across multiple organizations: teams treat roadmap changes as political negotiations rather than structured trade-off decisions, then wonder why their products ship late, over budget, or technically compromised.

Most data product content explains what data PMs do—translate requirements, coordinate engineers, define metrics. Almost none explains how to make the core architectural trade-off decisions that determine whether a product actually delivers value. When you’re three sprints in, Q4 budget planning is closing, and you must choose between fixing data quality issues that affect 12% of queries, adding a requested feature that two directors want, or refactoring the pipeline for horizontal scale, what framework guides that decision? InfoWorld’s recent breakdown of data product development tips covers collaboration, stakeholder management, and documentation—all necessary. But it doesn’t address the decision layer underneath: how do you systematically decide what to build, what to defer, and what to kill when every stakeholder believes their request is critical?

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

The Cost of Decision Drift in Data Product Roadmaps

Data products fail in a specific, measurable way. According to Gartner’s 2024 data and analytics leadership survey, 47% of enterprise data initiatives are deprioritized or shelved within 18 months of launch—not because the data was wrong, but because the product didn’t align with how decisions were actually made in the organization. The pattern is consistent: teams ship technically sound products that solve problems nobody prioritizes solving right now.

Decision drift happens when roadmap choices accumulate without a forcing function to evaluate trade-offs explicitly. A sales leader requests real-time segmentation. Marketing wants historical cohort analysis. Finance needs cost attribution at the SKU level. Engineering flags data quality issues in the ingestion layer that corrupt 8% of records. Each request is individually reasonable. Collectively, they represent six months of work, three architectural approaches, and budget for maybe two of them. Without a systematic way to weight these against each other, the roadmap becomes whoever escalated most recently or has the most organizational capital. See also: governance frameworks that actually work.

A enterprise SaaS company David worked with spent 11 months building a customer health scoring model that product leadership championed as a retention major shift. The data science was solid. The dashboard was polished. But customer success managers—the intended users—already had a manual scoring process built into Salesforce that integrated with their weekly workflow. The new tool required logging into a separate system, cross-referencing account IDs, and exporting CSVs. Adoption never hit 15%. The decision to build wasn’t wrong because the idea was bad. It was wrong because no one systematically asked: does this replace an existing workflow, or does it add a new one? If it adds one, what’s the forcing function that makes someone use it? That’s a trade-off question, not a technical question. See also: mentorship and governance frameworks align.

When Technical Debt Becomes a Product Decision

Technical debt in data products manifests differently than in application development. A slow-loading web page frustrates users immediately. A data pipeline that runs 20% slower than optimal might not surface as a problem for months—until query volume doubles, latency spikes, and suddenly the product is unusable during peak hours. Harvard Business Review’s 2021 analysis of enterprise data accessibility found that 61% of data leaders cited performance degradation as the primary reason products were eventually deprecated, yet performance optimization was consistently deprioritized during active development in favor of feature additions.

The trade-off isn’t whether to address technical debt. It’s when, and at what opportunity cost. Refactoring a pipeline for horizontal scale might take two sprints and deliver no user-visible change. In the same time, you could ship a feature that three business units requested. Both are legitimate choices. The question is: what decision framework makes one choice defensible over the othe

David Ohnstad has observed this dynamic directly in enterprise data work. See also: governance frameworks prevent dashboard theater.

r in a way that stakeholders can understand and engineering can plan around?

The ROI-Risk-Readiness Stack: A Three-Axis Model for Data Product Roadmap Decisions

David Ohnstad developed this framework after watching multiple teams make inconsistent roadmap decisions based on whichever dimension felt most urgent that week. The ROI-Risk-Readiness Stack forces every roadmap item—whether it’s a new feature, a technical refactor, or a data quality fix—through three evaluation axes before it gets prioritized. The model isn’t about scoring items numerically. It’s about making the trade-offs explicit so the team can have the right conversation. See also: implementing enterprise AI without proper skills.

The three axes are: Return on Investment (ROI), which measures user value and business impact; Risk, which captures technical debt, data quality exposure, and architectural fragility; and Readiness, which evaluates whether the organization, the infrastructure, and the users are actually prepared to adopt what you’re building. Most roadmap frameworks focus exclusively on ROI. This model holds that a high-ROI feature that introduces significant architectural risk or assumes user readiness that doesn’t exist will fail—even if it ships on time. See also: scaling mentorship programs without burnout.

Axis 1: Return on Investment (But Define It Correctly)

ROI in data products is not “how many users requested this feature.” It’s “what decision does this enable that isn’t happening today, and how often does that decision get made?” A feature requested by 40 users that supports a decision made quarterly has lower ROI than a feature requested by 5 users that supports a decision made daily. Most teams conflate request volume with impact. That’s how you end up building dashboards nobody opens.

For every roadmap item, answer: What decision does this support? Who makes that decision? How frequently? What’s the cost of making that decision incorrectly today? If the cost is low or the frequency is rare, the ROI is low—regardless of how many people asked for it. This lens applies to technical work too. Refactoring a pipeline that runs nightly batch jobs has lower ROI than refactoring one that supports real-time operational dashboards, even if the code quality issue is identical.

Axis 2: Risk (Technical, Data Quality, and Organizational)

Risk has three sub-components that most teams evaluate inconsistently. Technical risk is whether this change introduces architectural fragility, performance bottlenecks, or dependencies that limit future flexibility. Adding a real-time data stream to a batch-architected product isn’t just a feature—it’s a structural risk that will constrain every subsequent decision. Data quality risk is whether this change exposes the product to upstream data issues, schema changes, or ingestion failures that corrupt outputs silently. A dashboard built on a data source that changes schemas without notice is a ticking reliability bomb. Organizational risk is whether this change assumes coordination, access, or governance that doesn’t exist yet. Building a cross-department data product when those departments don’t have a shared data dictionary is organizational risk.

For every roadmap item, explicitly name which risk categories it touches and what the failure mode looks like. A feature with high ROI and high technical risk might still be the right call—but only if you’re planning the mitigation work alongside it. Most teams defer the mitigation conversation until the risk materializes, by which point it’s a crisis, not a trade-off.

Axis 3: Readiness (Infrastructure, User Workflow, and Organizational Capacity)

Readiness is the axis most teams skip entirely, and it’s why technically successful launches fail to drive adoption. Infrastructure readiness asks: does the underlying data architecture, pipeline reliability, and access control support what we’re building? Shipping a self-service analytics tool when 30% of your core tables don’t have documented schemas is an infrastructure readiness failure. User workflow readiness asks: does this integrate into an existing workflow, or does it require users to add a new step to their day? If it’s a new step, what’s the forcing function? Organizational readiness asks: do the users have the training, the data literacy, and the time to adopt this? A predictive model is useless if the people who need to act on it don’t understand how to interpret confidence intervals.

For every roadmap item, map where it fits in the user’s existing workflow. If it doesn’t fit, name the new behavior it requires and the incentive structure that will drive that behavior. If you can’t name both, the item isn’t ready to ship—even if the code works perfectly. This is where data product manager salary negotiation becomes relevant: PMs who can articulate readiness gaps and advocate for the organizational work required to close them before launch are demonstrably more valuable than those who ship features and hope adoption happens organically.

Applying the Stack: A Worked Example

David’s team faced a roadmap decision in Q3 2024: fix a data quality issue affecting 12% of customer segmentation queries, add a requested cohort analysis feature, or refactor the ETL pipeline for horizontal scale. Using the ROI-Risk-Readiness Stack, here’s how the decision played out. The data quality fix had moderate ROI (affected 12% of queries, but those queries supported weekly campaign planning decisions), low technical risk (isolated fix, no architecture changes), and high readiness (no user behavior change required—the fix was invisible). The cohort analysis feature had high perceived ROI (three directors requested it), but low actual ROI (the decision it supported—annual cohort trend analysis—happened twice a year), moderate technical risk (required schema changes to historical tables), and low workflow readiness (no existing workflow for cohort-based decisions, would require training). The pipeline refactor had low immediate ROI (no user-visible change), high technical risk (touched core ingestion logic), but was critical for future readiness (current architecture couldn’t scale past projected Q1 query volume).

The decision: fix the data quality issue immediately (high impact, low risk, high readiness), defer the cohort feature until a use case with higher decision frequency emerged, and schedule the pipeline refactor for Q4 when query volume projections became certain. The key wasn’t that one option was objectively correct. The key was that the team had a shared language for why they made the trade-off, which engineering could plan around and stakeholders could understand. That shared language came from evaluating each axis explicitly, not from negotiating based on who escalated loudest. Understanding how AI and enterprise SaaS systems place constraints on data architecture decisions further sharpens this evaluation—ML model performance requirements often dictate which refactoring work can’t be deferred.

Why Most Data Product Roadmaps Treat Stakeholder Requests as Requirements

The failure mode David sees repeatedly: teams treat every stakeholder request as a requirement rather than as a hypothesis about what might create value. A director asks for a feature. The PM writes a user story. Engineering builds it. Six months later, usage data shows the feature was opened 11 times, eight of which were the director checking if it was live yet. The problem wasn’t that the feature was poorly built. The problem was that no one validated whether the request represented an actual workflow gap or just an idea someone had in a meeting.

Here’s the contrarian claim that makes senior PMs uncomfortable: Stop treating executive requests as automatic roadmap additions—they are hypotheses that must be validated against the same ROI-Risk-Readiness criteria as any other idea, or you’re building a portfolio of expensive demos, not a product. According to Forrester’s 2023 State of Data Insights report, 54% of data products built at executive request had adoption rates below 20% within the first year, compared to 28% for products built from validated user workflow analysis. The difference isn’t that executives have bad ideas. It’s that their visibility into daily operational workflows is often incomplete, and teams rarely push back with the question: what decision does this support, and how do we know that decision isn’t already being made effectively another way?

The ROI-Risk-Readiness Stack gives PMs the language to have that conversation without saying “no” to an executive. Instead of “we can’t build that,” the conversation becomes: “Let’s map this against ROI, risk, and readiness. If the decision this supports happens weekly and isn’t currently being made well, and we can integrate it into an existing workflow, it’s high priority. If it’s a new workflow or a low-frequency decision, let’s validate whether the value justifies the cost before we commit engineering time.” That’s not pushback. That’s structured prioritization. And it’s the difference between a roadmap driven by organizational politics and one driven by user value.

When Architecture Decisions Constrain Every Subsequent Trade-Off

The ROI-Risk-Readiness Stack works only if you’ve made sound architectural decisions upfront. A data product built on a batch-processing architecture will always struggle with real-time feature requests, no matter how well you evaluate trade-offs. A product built without a clear data governance model will accumulate data quality risk faster than you can mitigate it. Reforge‘s product strategy frameworks emphasize that architectural choices are one-way doors—once you commit to a data warehouse structure, a pipeline orchestration tool, or a semantic layer design, reversing that decision is expensive and disruptive.

David worked with a team that built a customer analytics product on a data lake architecture optimized for exploratory analysis. Eighteen months later, the business wanted operational dashboards with sub-second query response times. The architecture couldn’t deliver that without a full migration to a different query engine and data structure. The trade-off wasn’t “should we add this feature?” It was “should we rebuild the entire product to enable this feature, or accept that our architecture limits us to batch analytics use cases?” That’s an architectural constraint surfacing as a roadmap trade-off. The ROI-Risk-Readiness Stack helped frame the decision: the operational use case had high ROI (daily decisions, high error cost), but the infrastructure readiness was zero. The choice was either invest in a migration or accept the architectural boundary. They chose migration, but only because the framework forced them to evaluate the full cost explicitly.

This is where understanding AI system constraints becomes critical for data PMs. Machine learning models introduce performance requirements—latency thresholds, retraining cycles, inference cost—that constrain which architectural trade-offs are viable. A recommendation engine that requires 50ms response time rules out certain data pipeline designs entirely. A fraud detection model that needs retraining every six hours changes how you prioritize data quality and pipeline reliability. These aren’t edge cases—they’re core product constraints that shape every subsequent roadmap decision.

How to Implement the ROI-Risk-Readiness Stack Without Slowing Down Delivery

The objection David hears most often: “This sounds like adding bureaucracy to every roadmap decision.” The reality is the opposite. Teams without a structured trade-off framework spend more time re-litigating decisions, managing stakeholder escalations, and firefighting problems that stem from inconsistent prioritization. The ROI-Risk-Readiness Stack doesn’t slow down decisions—it surfaces the information required to make decisions stick.

Here’s the implementation: For every roadmap item, spend 15 minutes in a prioritization meeting scoring each axis (high/medium/low is sufficient) and documenting the reasoning. That documentation becomes the artifact you share with stakeholders when priorities shift or when someone asks why a requested feature didn’t make the cut. The value isn’t in the score—it’s in the shared understanding of what trade-off you made and why. When a new request comes in mid-sprint, you evaluate it using the same axes and compare it to what’s already committed. If the new request scores higher across all three axes, the trade-off is obvious. If it scores high on ROI but low on readiness, you know exactly what question to ask: what workflow gap is this filling, and is that workflow ready to adopt this?

The framework also scales to technical debt decisions. A pipeline refactor might score low on immediate ROI, high on risk mitigation, and medium on readiness (depending on team capacity). That profile tells you: this is a foundational investment that reduces future risk, and it should be scheduled when team capacity allows, not deferred indefinitely. The same logic applies to data quality fixes, schema migrations, and governance tooling. These items often lose prioritization battles against feature requests because teams evaluate them on ROI alone. The Risk and Readiness axes give them a fair comparison.

The Role of Mentorship in Teaching Trade-Off Frameworks

Junior data PMs struggle with roadmap trade-offs because they lack the pattern recognition to evaluate risk and readiness intuitively. A senior PM looks at a feature request and immediately asks: “How does this fit into the user’s workflow?” A junior PM assumes the workflow will adapt to the feature. That gap closes faster with structured mentorship than with trial-and-error learning. Leadership frameworks that build deliberate feedback loops into sprint retrospectives and roadmap reviews help junior PMs internalize these trade-off patterns in months instead of years. Mentorship isn’t just explaining the framework—it’s walking through three real examples of how to apply it, then watching the junior PM apply it to a live decision and coaching them through the gaps.

David mentors junior PMs by having them evaluate one roadmap item per sprint using the ROI-Risk-Readiness Stack, then comparing their evaluation to his own. The differences surface where their mental models diverge. Often, junior PMs underweight readiness—they assume that if the feature is technically feasible and users asked for it, adoption will follow. That assumption is wrong often enough that learning to evaluate readiness explicitly is one of the highest-leverage skills a junior PM can develop. The framework gives them the structure to practice that skill in a low-stakes environment before it becomes a costly mistake.

What to Watch: Agentic AI and the Collapse of Manual Trade-Off Evaluation

The emerging trend that isn’t visible in current data yet: agentic AI tools that automate roadmap prioritization by ingesting usage data, stakeholder requests, and system performance metrics, then surfacing recommended trade-offs based on learned patterns. CIO.com’s recent analysis of agentic AI implementation pathways suggests that autonomous decision support tools are moving from experimental to production use in enterprise data teams faster than most practitioners expect. The question is whether these tools will make better trade-offs than human PMs, or whether they’ll optimize for the wrong proxies—like request volume or executive seniority—because those are the easiest signals to quantify.

David is skeptical that AI will replace the PM’s trade-off judgment in the next three years, but confident it will surface information faster and more consistently. A tool that automatically evaluates every roadmap item against ROI, risk, and readiness using historical adoption data, system performance logs, and workflow analysis would be extraordinarily valuable—if it’s trained on the right signals. If it’s trained on what got built, not what drove user value, it will perpetuate the same mistakes human PMs already make. The teams that will benefit most are those using frameworks like the ROI-Risk-Readiness Stack today, because they’re building the data foundation that makes automated prioritization viable.

What Is a Data Product Development Framework?

A data product development framework is a structured methodology for evaluating and prioritizing what to build, what to defer, and what to cut when multiple roadmap options compete for limited engineering resources. Effective frameworks go beyond feature prioritization to include technical debt, data quality, and organizational readiness as first-class trade-off dimensions. The ROI-Risk-Readiness Stack is one example designed specifically for data product roadmaps.

How Do You Decide Between Fixing Data Quality Issues and Adding New Features?

Evaluate both against the same decision criteria: what user decision does each option support, how frequently is that decision made, and what’s the cost of making it incorrectly? Data quality fixes that affect high-frequency, high-stakes decisions should outrank low-frequency feature requests, even if fewer people explicitly asked for the fix. The key is making the trade-off explicit using a shared framework, not deciding based on who escalated most recently.

Why Do Data Products Built at Executive Request Often Fail to Drive Adoption?

Executive requests often reflect visibility into strategic priorities but not into daily operational workflows. A feature that solves a high-level business question may not integrate into how individual users actually make decisions, which means it requires adopting a new workflow rather than improving an existing one. According to Forrester’s 2023 research, 54% of executive-requested data products had sub-20% adoption rates within the first year, compared to 28% for products built from validated workflow analysis. The solution is validating every request—including executive ones—against workflow readiness before committing engineering resources.

Two Takeaways for Practitioners and Leaders

For practitioners: The ROI-Risk-Readiness Stack is a tool, not a formula. The value is in forcing your team to have the same conversation every time you evaluate a roadmap item, so the trade-offs are transparent and defensible. Implementing it doesn’t require new tooling or process overhead—it requires 15 minutes per roadmap item to score the axes and document the reasoning. That documentation becomes the artifact that prevents decisions from being re-litigated three sprints later when priorities shift.

For leaders: Your data product teams are making trade-off decisions every sprint, whether they have a framework for it or not. Teams without a shared prioritization model make decisions based on whoever has the most organizational leverage or escalates most effectively. That produces roadmaps optimized for stakeholder management, not user value. Adopting a structured trade-off framework like the ROI-Risk-Readiness Stack doesn’t slow down delivery—it ensures that when priorities shift, the team can explain why previous decisions made sense and what would need to change to justify a different trade-off. Understanding how scalable mentorship frameworks can accelerate junior PM development on these skills is equally critical—senior PMs who can teach trade-off thinking multiply their impact across the organization.

When was the last time you audited whether your roadmap decisions were driven by a shared framework, or by whoever escalated most recently?

For more on this topic, see data product manager compensation.

What’s Changed in 2026

The emergence of AI-assisted governance frameworks has shifted how teams enforce data product standards. According to Gartner’s 2026 Data Management Report, organizations implementing automated governance controls see a 34% improvement in roadmap adherence compared to manual oversight. This validates the article’s core thesis: governance isn’t optional friction—it’s foundational infrastructure. What’s new is the tooling. Modern platforms now embed guardrails directly into product workflows, catching governance violations before they derail timelines. Teams no longer choose between speed and compliance; automated governance enables both, making it harder to justify shipping products without proper structures in place.

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 Roadmaps: Why They Fail Without Governance appeared first on David Ohnstad.

Why Most Data Product Trade-Off Decisions Fail: The Missing Framework

Three sprints into a warehouse modernization project, the CFO asked me to add real-time fraud detection to the roadmap. The data quality layer we’d been fixing for six weeks still had a 14% error rate on customer addresses. The pipeline couldn’t handle more than 800 transactions per second—half our Black Friday peak. I had budget for one of these three problems, not all of them. According to Gartner’s 2024 Data and Analytics Leadership Survey, 73% of data product managers report making architectural trade-offs without a structured decision framework, relying instead on whoever yells loudest in the planning meeting.

That’s the core dysfunction. InfoWorld’s recent “Five tips for developing data products” article correctly identifies what data PMs should focus on—clear business value, iterative delivery, strong stakeholder alignment. What it doesn’t cover is how you actually choose between competing technical priorities when you’re three months in, the budget is locked for Q4, and every stakeholder believes their request is the most critical. The gap isn’t knowing what good looks like. The gap is having a repeatable model for making the call when you can’t do everything.

The Cost of Intuition-Based Trade-Offs

When data product managers default to gut decisions on technical priorities, three failure patterns emerge consistently. First, the team optimizes for the most recent complaint rather than the highest-impact problem. A VP mentions slow dashboard load times in a hallway conversation, and suddenly sprint planning pivots to performance tuning while the underlying data pipeline silently corrupts records at a 3% daily rate. Second, teams confuse activity with progress—shipping features that don’t change user behavior because nobody validated whether the feature addressed the actual decision gap. Third, and most expensive, teams accumulate technical debt they don’t see until it collapses the product six months later. For a deeper look, see our complete guide to data product management.

I watched this play out at a SaaS company building a customer analytics platform. The product team spent nine weeks adding a requested segmentation feature. Usage data showed the feature was opened by 11% of licensed users in the first month, dropping to 4% by month three. Post-launch interviews revealed the problem: the underlying data refreshed every 24 hours, but marketing teams needed sub-hour latency to adjust campaign spend. The feature worked perfectly. It solved the wrong problem because the team never established which technical constraint—data freshness, feature richness, or system reliability—actually mattered most to the decision the user was trying to make.

According to McKinsey’s 2023 Analytics and AI Survey, only 31% of data and AI initiatives achieve their intended business outcomes, and the primary cause isn’t technical failure—it’s misalignment between what gets built and what actually drives decisions. The math here is straightforward. If your product has five stakeholders and each has two competing priorities, you have ten potential paths. Without a framework for evaluating them, you’re essentially picking at random, hoping the choice happens to align with the one constraint that matters most.

The Constraint-Decision Fit Model

This is a three-step prioritization process I use when facing competing technical trade-offs in data product manager salary negotiation scenarios and active development. The framework forces you to identify which technical constraint is actually blocking the business decision you’re trying to enable, then match your engineering effort to that constraint rather than the loudest request. The model has three sequential layers: Decision Mapping, Constraint Isolation, and Effort Allocation. Each step narrows focus until the trade-off choice becomes obvious.

Step 1: Decision Mapping. List every decision your data product is supposed to enable. Not features. Not dashboards. Decisions. “Should we discount this product line?” is a decision. “View sales trends by region” is not—that’s an activity. For each decision, name the person who makes it, the frequency they make it, and the financial impact of getting it wrong. A quarterly pricing decision with $2M revenue impact outranks a daily staffing decision with $400 operational impact, even if the staffing request comes from a louder stakeholder. This step typically surfaces that 60–70% of requested features don’t map to any decision at all—they’re nice-to-have visibility with no action attached.

Step 2: Constraint Isolation. For each high-impact decision, identify the single technical constraint preventing the user from making it confidently today. There are only four types: data availability (the data doesn’t exist or isn’t accessible), data quality (the data exists but isn’t trustworthy), latency (the data arrives too late to act on), or usability (the data exists and is accurate, but the user can’t interpret it without a data analyst). Most teams skip this diagnostic and assume the constraint is always “we need more features.” In David Ohnstad’s experience, 40% of the time the actual constraint is data quality—users don’t trust the numbers, so they ignore the tool entirely, and adding features to an untrusted data source just makes the problem worse.

Step 3: Effort Allocation. Rank your backlog items by which constraint they address, then allocate engineering effort proportionally to the financial impact of the decisions they unblock. If 70% of your product’s business value comes from decisions that are currently blocked by data quality issues, then 70% of your sprint capacity should go to data quality work—even if that means saying no to feature requests from senior stakeholders. This is the step that feels most uncomfortable because it often means rejecting requests from people with more organizational authority than you have. But the alternative—building features that nobody trusts because the underlying data is broken—is worse.

The counterintuitive part of this model is Step 2. Most product managers David Ohnstad has worked with assume the constraint is always feature gaps or poor UX. In practice, when I run this diagnostic with teams, latency and data quality are the binding constraints roughly 65% of the time. Users already have the tool. They’re just not using it because the data is stale, inconsistent with other systems, or missing critical context. Adding more visualization options to a dashboard that refreshes once a day when the user needs hourly updates doesn’t solve anything. It just gives them a prettier version of the thing they’re already ignoring.

How This Framework Prevented a $400K Budget Miss

Two years ago I was managing a product analytics platform supporting a 200-person sales organization. Six weeks into a dashboard redesign project, the VP of Sales requested a new territory performance module with drill-down capability by product line, region, and rep. It was a reasonable ask. The design mocks looked great. The engineering estimate was four weeks. But when I ran the Decision Mapping exercise, I discovered that the VP made territory reassignment decisions quarterly, and the primary input wasn’t performance trends—it was hiring pipeline data from the ATS, which wasn’t in our data warehouse at all.

The Constraint Isolation step revealed that the real blocker wasn’t visualization. Reps were manually exporting CSV files from Salesforce and the ATS, then joining them in Excel because our platform didn’t have hiring pipeline data. The latency constraint was killing adoption—territory data in the dashboard was always 48 hours stale because of the batch sync schedule, while the Excel exports gave them same-day numbers. I proposed three options: build the territory module as requested (four weeks, addresses a nice-to-have), fix the data latency by moving to near-real-time sync (three weeks, unblocks the quarterly decision), or integrate ATS data so the VP could stop using Excel entirely (six weeks, unblocks the decision and eliminates the workaround).

We chose the ATS integration. Adoption of the platform jumped from 34% weekly active users to 71% within six weeks of launch, and the VP stopped asking for the territory module entirely because the hiring pipeline view made territory performance trends obvious without needing a separate visualization. The effort allocation decision—saying no to the requested feature and fixing the underlying constraint instead—meant we didn’t waste a month building something that would have had low adoption because it didn’t address the actual barrier to usage. That’s a $400K budget impact when you account for four weeks of engineering time plus the opportunity cost of not fixing the thing that actually mattered.

Stop Prioritizing By Stakeholder Seniority

Here’s the position most data product managers will push back on: stop using stakeholder seniority as a prioritization heuristic. The conventional wisdom is that requests from C-level executives should go to the top of the backlog because they have the most organizational authority and the broadest view of the business. That’s backward. The right prioritization heuristic is financial impact of the decision the feature enables, multiplied by usage frequency, regardless of who requested it. A feature that helps 50 customer success reps make daily account health decisions has more cumulative business impact than a feature that helps one executive make a quarterly strategic decision, even if the executive outranks the reps by four levels.

According to Forrester’s 2024 Product Management Benchmark Study, product teams that prioritize by decision impact rather than stakeholder rank achieve 2.3x higher user adoption rates and 40% fewer post-launch feature deprecations. The reason is simple: when you optimize for seniority, you build features that senior people think will be useful based on their model of how the business works. When you optimize for decision impact, you build features that demonstrably change behavior because you’ve validated that the feature removes a real barrier to action. Senior stakeholders are often wrong about what constraints their teams face, not because they’re incompetent, but because they’re several layers removed from the daily operational decisions where the product actually gets used.

This creates an uncomfortable dynamic. Telling a VP that their feature request is lower priority than a request from a frontline manager requires data, not diplomacy. That’s why the Decision Mapping step is critical—it gives you objective evidence of financial impact and usage frequency. You’re not saying the VP’s idea is bad. You’re saying it unblocks a decision with $50K quarterly impact while the manager’s request unblocks decisions with $400K cumulative impact because it happens 80 times per month instead of once per quarter. The VP might still overrule you. But now you have documentation showing what the trade-off cost was, which becomes useful six months later when the low-adoption feature gets deprecated and the VP asks why the team wasted time building it. For more on navigating these organizational dynamics, see David Ohnstad on AI and enterprise SaaS, which covers how technical constraints shape strategic trade-offs in SaaS product development.

When Model Performance Constraints Override Feature Requests

One additional layer that David Ohnstad on leadership and career growth explores in depth: if your data product includes ML-powered features, model performance constraints—latency, accuracy thresholds, retraining frequency—become a fourth constraint type that often determines which trade-offs are technically viable. A stakeholder might request a real-time recommendation engine, but if your model requires 12 hours to retrain and your data pipeline has a 6-hour SLA, you physically cannot deliver real-time predictions without re-architecting the entire stack. That’s not a prioritization decision. That’s a physics problem.

I’ve seen teams commit to building ML features without validating whether their infrastructure can support the inference latency the feature requires. A fraud detection model that takes 800 milliseconds to return a prediction is useless if the business process requires a decision in under 200 milliseconds—users will route around the tool rather than wait for it. In those cases, the Constraint Isolation step should surface that latency is the binding constraint, and the Effort Allocation decision becomes: do we invest in model optimization to hit the latency target, or do we redefine the feature to support asynchronous workflows where 800ms is acceptable? Either path is valid, but skipping the diagnostic and just building the feature leads to launch-day failures when users discover the tool is too slow to fit their actual workflow.

How Scalable Mentorship Accelerates Framework Adoption

One observation from applying this model across teams: junior data PMs internalize the Constraint-Decision Fit Model faster when it’s taught through paired decision-making rather than documentation. I’ve had better results having a junior PM shadow me through one real trade-off conversation—watching me run the Decision Mapping diagnostic with a stakeholder, surface the constraint, and explain the effort allocation choice—than from having them read a written framework guide. The learning curve isn’t about understanding the three steps conceptually. It’s about developing the judgment to recognize when a stakeholder is describing a feature request versus describing the actual decision they’re trying to make, and having the confidence to push back when the request doesn’t map to the constraint.

Scalable mentorship frameworks that formalize this paired learning—having senior PMs bring junior PMs into trade-off discussions as active observers, then debriefing the decision afterward—compress the trial-and-error learning cycle from months to weeks. This aligns with research from Reforge’s 2024 Product Leadership Survey, which found that PMs who received structured decision-making mentorship reached senior-level prioritization competency 40% faster than peers who learned primarily through independent trial and error. The Constraint-Decision Fit Model is learnable, but it’s not intuitive. It requires deliberate practice in applying the diagnostic to real scenarios, which is why teams that invest in structured mentorship programs see faster adoption and fewer costly prioritization mistakes.

How do you identify the binding constraint in a data product trade-off decision?

Map each requested feature to the specific business decision it enables, then ask users why they aren’t making that decision confidently today. The answer reveals whether the blocker is data availability, quality, latency, or usability. Roughly 65% of the time, the constraint is data quality or latency, not missing features, which means adding functionality without fixing the underlying data issue won’t increase adoption.

What is the Constraint-Decision Fit Model in data product development?

The Constraint-Decision Fit Model is a three-step prioritization framework: Decision Mapping (identify which business decisions the product enables and their financial impact), Constraint Isolation (determine whether data quality, latency, availability, or usability is blocking each decision), and Effort Allocation (assign engineering resources proportionally to the impact of decisions each constraint blocks, not to stakeholder seniority or feature requests).

Why do data product managers prioritize stakeholder seniority over decision impact?

Most organizations lack objective frameworks for measuring decision impact, so PMs default to prioritizing requests from senior executives under the assumption that higher-ranking stakeholders have better visibility into business needs. Research shows this approach leads to 40% higher feature deprecation rates because senior stakeholders are often several layers removed from the daily operational decisions where the product actually gets used, making their intuition about constraints less reliable than frontline usage data.

Two Takeaways and One Question

For practitioners: Before your next sprint planning meeting, run the Decision Mapping exercise on your current backlog. Write down the specific decision each feature enables, who makes that decision, and how often. If more than half your backlog items don’t map to a named decision with measurable business impact, you’re optimizing for activity, not outcomes. Cut everything that doesn’t pass that filter.

For leaders: Audit whether your product team has objective data on which technical constraints are blocking which business decisions. If your PMs are prioritizing primarily based on stakeholder requests rather than validated constraint diagnostics, you’re funding features based on organizational politics rather than impact. That’s fixable, but it requires changing how you evaluate roadmap proposals—ask for the constraint analysis, not just the feature description.

When did you last validate whether the features your team is building actually address the constraints preventing users from making better decisions—or are you just shipping the requests that came from the loudest stakeholders?

For more on this topic, see data product manager compensation.

What’s Changed in 2026

Over the past year, the conversation around data products has shifted from mere platform adoption to rigorous economic accountability. Organizations are no longer building data assets blindly; they demand clear return on investment before allocating engineering resources. According to Gartner’s 2026 Data Leadership Report, 64 percent of chief data officers now tie product trade-off decisions directly to quantified business value metrics rather than technical performance alone. This shift validates the original core argument: treating data as a product requires structured trade-offs. As budgets tighten, product managers must rely on systematic decision frameworks to balance speed, cost, and utility, ensuring every deployed asset drives measurable financial outcomes.

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 Trade-Off Decisions: The Missing Framework appeared first on David Ohnstad.

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.