Comments on: Data Product Execution: Why Frameworks Fail in Practice

By: Embracing Ambiguity: A Data PM's Guide to Navigating Uncertainty in Product Development - David Ohnstad

Mon, 12 Oct 2026 17:51:06 +0000

[…] The breakthrough for me came when I stopped viewing uncertainty as a problem to eliminate and started viewing it as a parameter to manage. You’re not trying to achieve perfect certainty—that’s impossible. You’re trying to reduce uncertainty to a level where the decision becomes rational and defensible. For more on this, see why frameworks fail in practice. […]

By: Setting Up Camp: How Product Managers Can Build a Data-Driven Team From Scratch - David Ohnstad

Mon, 12 Oct 2026 17:49:26 +0000

[…] Talk to at least five potential stakeholders before making your choice. Look for consensus around priority, not just enthusiasm. If different executives have conflicting visions for what data should solve first, that’s a red flag—you’ll spend your energy managing politics instead of building products. For more on this, see why frameworks fail in practice. […]

By: Hidden Gems in Data Product Management: Overlooked Techniques That Drive Results - David Ohnstad

Mon, 12 Oct 2026 17:48:18 +0000

[…] At Veeam, I’ve seen this shift change how engineering teams prioritize data work. Instead of data quality being an eternal “nice-to-have” that never makes it into a sprint, it becomes something with user impact that can be communicated and tracked. For more on this, see Why frameworks fail in practice. […]

By: Data Product Reviews: Why They Fail Before Starting - David Ohnstad

Data Product Reviews: Why They Fail Before Starting - David Ohnstad — Mon, 05 Oct 2026 17:13:45 +0000

[…] Layer 3: Structural Gap Audit. Identify where your team structure prevented decision support in Q1. This is the counterintuitive layer—most PMs assume structure is fixed and focus on execution within constraints. Wrong. The mid-year review is when you have budget attention and reorg windows. If your data engineers report to IT and your product priorities come from the business, you’ll keep building pipelines that deliver data nobody trusts because the engineering team isn’t accountable to the decision-makers. If your analytics team has no seat in planning meetings, you’ll keep retrofitting insights onto decisions already made. David Ohnstad has seen this pattern repeatedly: the org chart predicts product failure faster than the roadmap does. Microsoft’s data council approach directly addresses this—centralizing decision authority on data strategy instead of distributing it across siloed functions. For more on this, see Why frameworks fail in practice. […]

By: Federated Data Architectures: Why PMs Fail - David Ohnstad

Federated Data Architectures: Why PMs Fail - David Ohnstad — Mon, 05 Oct 2026 17:12:39 +0000

[…] Here’s the contrarian claim most senior leaders won’t want to hear: if your data product manager can’t halt a breaking schema change from deploying to production, don’t hire a data product manager—hire a data project coordinator and pay them accordingly. The title “product manager” implies ownership and accountability. But in most federated architectures, the data PM has neither. They have responsibility—for dashboards, for stakeholder trust, for data quality—but they don’t have the authority to enforce the contracts that determine whether those responsibilities can be met. That’s not product management. That’s being an organizational scapegoat with a inflated title. For more on this, see frameworks fail when execution lacks structure. […]

By: Data Product Adoption: Why Dashboards Fail Without User Strategy - David Ohnstad

Data Product Adoption: Why Dashboards Fail Without User Strategy - David Ohnstad — Mon, 28 Sep 2026 16:58:33 +0000

[…] Six months into the reorganization, the company’s data team looked almost identical on paper. Same headcount. Same reporting lines. The BI team still reported to Finance. Data engineering still sat under the VP of Engineering. But the accountability model had fundamentally shifted. Each data PM now had a portfolio of decision owners they were responsible to, and those decision owners had SLAs: if a critical data input was missing or wrong, the data PM was paged, not the on-call engineer. If a forecast model drifted below acceptable accuracy, the PM who owned that decision chain had to either fix it or formally deprecate it and document the replacement workflow. For more on this, see why execution frameworks often fail. […]

By: Data Product Management: Why 82% of Analytics Fail - David Ohnstad

Data Product Management: Why 82% of Analytics Fail - David Ohnstad — Mon, 28 Sep 2026 16:57:40 +0000

[…] We rebuilt the model to output scenarios: baseline growth, new product launch impact, top 10 customer expansion risk. We embedded it in one decision cycle — Q3 budget planning. The VP used the baseline scenario in his CFO request. He got the budget approved. The following quarter, he used the sensitivity analysis to justify an expedited procurement for a customer expansion we had flagged. That was the proof point. The model is now part of the quarterly planning process, and we have a structured feedback loop with the infrastructure team to refine the scenarios every quarter. For more on this, see why frameworks fail in practice. […]

By: Data Product Prioritization: Managing Competing Stakeholder Requests - David Ohnstad

Mon, 28 Sep 2026 16:52:42 +0000

[…] Score each request based on how frequently the requester will use the data to make a different decision. Not how often they will look at it. How often it will change what they do. For more on this, see frameworks fail in practice. […]

By: Data Product Strategy: When to Kill a $250K Initiative - David Ohnstad

Data Product Strategy: When to Kill a $250K Initiative - David Ohnstad — Mon, 28 Sep 2026 16:51:04 +0000

[…] Step 4: Set a decision rule for the boundary cases. The hard calls are medium radius, medium cost—where both options feel equally justified. Here’s the rule David Ohnstad’s team uses: if the platform gap has existed for more than two quarters and workaround costs are rising, prioritize platform work. If it’s a new gap and workaround costs are stable, ship the product and schedule platform work for the next cycle. Time direction matters. Rising costs mean compounding debt. Stable costs mean the workaround is sufficient for now. For more on this, see Why execution frameworks often fail. […]

By: Data Product Manager Org Structure: Why Reporting Lines Fail - David Ohnstad

Data Product Manager Org Structure: Why Reporting Lines Fail - David Ohnstad — Mon, 28 Sep 2026 16:48:48 +0000

[…] Structure 2: Data PM reports to Chief Data Officer or VP of Data. Use this when you’re building internal data products that power decision-making across multiple business units — executive dashboards, ML model training pipelines, or centralized reporting infrastructure. The data PM negotiates data contracts with stakeholders in Sales, Marketing, Finance, and Product, then enforces delivery through engineering squads. This is the structure most large enterprises default to. It works if — and only if — the CDO has exec-level authority and a seat in strategic planning. If your CDO is a glorified DBA manager with no budget discretion, this structure collapses into a help desk with a backlog. For more on this, see Why execution frameworks fail in practice. […]