Data Product Strategy: When to Kill a $250K Initiative

The Night We Killed a Quarter-Million Dollar Data Product to Save the Platform

Three weeks before quarterly planning in Q2 2024, our team at Veeam had to make a call: ship a customer-facing analytics product six months in development, or redirect that engineering capacity to rebuild the metadata registry that every domain team depended on for data discovery. The product had executive sponsorship, a committed launch date, and would directly impact a revenue target. The registry rebuild had none of that—just a growing list of silent failures, duplicate pipelines, and teams building workarounds because they couldn’t trust what data existed or where it lived. We killed the product. According to Gartner’s 2023 Chief Data Officer survey, 68% of data and analytics leaders report that platform governance issues directly stall or kill downstream product delivery—and most wait until a visible product failure forces the conversation instead of making the tradeoff proactively.

That decision saved us from three additional quarters of compounding technical debt, but it also exposed the core tension nobody writes about when they publish data mesh case studies: how do you decide when to build new data products versus when to invest in the federated platform architecture that makes those products possible? Both consume the same engineering capacity. Both have advocates. Both feel urgent. And the frameworks most teams use to prioritize—business value scoring, RICE, weighted shortest job first—break down because platform work delivers its value indirectly, across multiple future products, in ways you cannot model in a sprint-level backlog tool.

The Fannie Mae data mesh implementation that AWS published this month is a legitimately impressive piece of work: domain-oriented ownership, Redshift data sharing as the interoperability layer, self-service tooling for federated teams. But here’s what the case study doesn’t tell you—and what every practitioner who’s tried this at scale already knows: the mesh itself becomes a product you have to maintain, evolve, and prioritize against every other product in your portfolio. And the moment you treat it like infrastructure you set up once and walk away from, the entire architecture starts to calcify. Domain teams stop trusting the discovery layer. Data contracts drift. Governance becomes manual exception-handling instead of automated enforcement. You end up with federated architecture and centralized bottlenecks—the worst of both models.

Why Traditional Product Prioritization Frameworks Fail for Data Mesh Tradeoffs

Most product teams prioritize using some variation of impact versus effort scoring. You estimate business value, multiply by confidence, divide by engineering cost, and rank everything by ROI. It works reasonably well when you’re deciding between Feature A and Feature B—both deliver discrete value to identifiable users, both have measurable outcomes, and both compete for the same type of work.

But when you’re deciding between shipping a new analytics dashboard (high visibility, clear stakeholder, direct revenue tie) and refactoring your data catalog’s lineage-tracking logic (invisible to end users, benefits every future product, nearly impossible to quantify), the math collapses. The dashboard scores a 9 out of 10 on every impact dimension. The lineage work scores a 3—maybe a 4 if you’re generous—because the value is diffuse, the beneficiaries are hypothetical future teams, and the executive sponsor doesn’t exist yet because the need hasn’t surfaced as a crisis.

According to McKinsey’s 2023 research on data governance, organizations that treat platform capabilities as discrete product initiatives—with dedicated ownership, roadmaps, and success metrics—see 3.2x higher data reuse rates and 40% faster time-to-insight for new analytics products compared to teams that manage platform work as reactive maintenance. The difference isn’t technical architecture. It’s whether you have a decision-making framework that accounts for platform investments as first-class products that compound value over time, not just cost centers that support “real” products.

David Ohnstad has seen this pattern repeat across three different platform buildouts: teams using RICE scoring will systematically deprioritize platform work until a product launch fails because the underlying mesh couldn’t support it. Then they over-correct, pause all product work to “fix the foundation,” burn six months rebuilding things that didn’t need rebuilding, and oscillate back to product-only mode. The result is a sawtooth delivery pattern—bursts of product launches followed by long platform-stabilization phases—instead of continuous, compounding progress.

The Tradeoff Severity Matrix: A Prioritization Framework for Mesh vs. Product Decisions

Here’s the framework David Ohnstad’s team built to navigate these decisions without either abandoning product delivery or letting platform debt spiral out of control. It’s called the Tradeoff Severity Matrix, and it evaluates every platform-versus-product decision across two dimensions: failure radius (how many future products does this platform gap affect?) and workaround cost (how much duplicated effort are teams expending to avoid the gap?).

Step 1: Map the failure radius. For every platform capability gap—missing data contracts, broken lineage, incomplete metadata—identify which domain teams currently depend on it and which planned products in the next two quarters require it. If the gap affects one team and one product, it’s a localized issue. If it blocks three domain teams and affects five planned products, it’s systemic. Use a simple count: 1-2 products = low radius, 3-5 = medium radius, 6+ = high radius. Do not estimate hypothetical future impact. Count only committed work.

Step 2: Quantify the workaround cost. Teams will route around platform gaps. They’ll build one-off pipelines. They’ll manually validate data. They’ll skip lineage documentation entirely. Calculate how many engineering hours per sprint are being spent on workarounds that would disappear if the platform capability existed. If teams are spending fewer than 10 hours per sprint on workarounds, the gap is annoying but not severe. If they’re spending 40+ hours per sprint, the gap is eating your capacity whether you acknowledge it or not.

Step 3: Plot the decision on the matrix. High failure radius + high workaround cost = platform work takes priority. Low radius + low cost = ship the product, address the platform gap later. High radius + low cost = monitor closely—the workaround is masking a problem that will surface later. Low radius + high cost = investigate why one team is burning so much effort—either they’re solving the wrong problem, or you’ve misidentified the failure radius.

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.

Step 5: Revisit the matrix every planning cycle. Failure radius and workaround costs both change as new products launch, domain teams mature, and platform capabilities evolve. A low-radius gap in Q1 can become a high-radius blocker in Q3 if three new domain teams onboard and all depend on the missing capability. Treat the matrix as a living artifact—update it at the start of every quarterly planning cycle, and use it to explain why priorities shifted when stakeholders ask why the roadmap changed.

What We Learned by Killing the Product

When we decided to deprioritize the customer analytics product in favor of the metadata registry rebuild, the initial reaction from leadership was predictable: “We already committed this to customers. Why are we discovering platform problems now, three weeks before planning?” Fair question. The honest answer: we had been discovering the problems for six months, but we kept routing around them because each individual workaround felt manageable in isolation. One team rebuilt a pipeline manually. Another team skipped lineage documentation because the tooling was too brittle. A third team built their own metadata store because they couldn’t trust the central registry’s data freshness.

None of those workarounds triggered an alert. None of them blocked a product launch. But when we added up the engineering hours being spent on manual work that should have been automated, we were losing 120 hours per two-week sprint across four domain teams—nearly three full-time engineers’ worth of capacity. The registry rebuild would take eight weeks and require two backend engineers and one data platform engineer. The ROI was obvious once we calculated it, but it took a product manager walking every domain lead through their sprint backlogs and tagging every task that was a workaround for a platform gap to make the case visible.

Here’s what changed after we made the call. We shipped the registry rebuild in nine weeks (one week over, which is reasonable). Domain teams immediately redirected 60% of their workaround effort to new product work. The analytics product we deprioritized got back on the roadmap for Q3, and when we finally built it, the development timeline was 40% shorter because the platform capabilities it needed—reliable lineage, accurate metadata, automated contract validation—were already in place. The compounding benefit: every subsequent product that quarter launched faster because we weren’t debugging platform gaps mid-sprint.

But here’s the part that surprised us: the registry rebuild itself became a product. We gave it a product manager. We defined success metrics—metadata accuracy rate, time-to-discovery for new datasets, percentage of pipelines with documented lineage. We ran user interviews with domain data engineers to understand what made the old registry unusable. We shipped iterative improvements based on feedback. The moment we stopped treating platform work as a one-time infrastructure project and started treating it as a product with users, adoption, and measurable outcomes, the quality of the work and the speed of delivery both improved dramatically.

The Governance Trap: Why Most Mesh Roadmaps Treat It as Setup Instead of Product Work

Most data mesh implementations fail at the governance layer, and the failure follows a predictable pattern. Teams spend months designing the federated model—defining domain boundaries, assigning ownership, building data contracts, setting up access controls. They treat governance as a configuration phase: something you design once, implement, and then move on from. The assumption is that once the structure is in place, domain teams will follow the rules, contracts will stay up to date, and the mesh will self-regulate.

That assumption is wrong. Governance in a federated architecture is not a one-time setup. It’s continuous product work. Data contracts drift the moment business logic changes. Domain ownership gets murky when teams reorganize. Access policies become stale when roles shift. And if you don’t have a team actively maintaining, evolving, and enforcing governance as a living product—with a backlog, a roadmap, and someone accountable for adoption and quality—the mesh degrades into a collection of isolated data silos with a thin interoperability layer that nobody trusts.

According to Forrester’s 2024 State of Data Governance report, 72% of organizations with federated data architectures report that governance enforcement is manual, reactive, and inconsistent across domains. The top complaint from domain teams: “We don’t know what the rules are, and they seem to change depending on who we ask.” The top complaint from platform teams: “We built all the tooling, and nobody uses it correctly.” Both are symptoms of treating governance as a phase you complete instead of a product you maintain.

Here’s the contrarian stance David Ohnstad will defend: Stop calling it governance. Start calling it the data product operations team, and staff it like you would any other product team. Governance sounds like compliance and policy enforcement—activities that developers route around or ignore when they’re under deadline pressure. Product operations sounds like the team that makes your life easier by automating quality checks, surfacing lineage automatically, and keeping contracts in sync with actual data shapes. Same underlying work. Completely different relationship with domain teams. One feels like an audit. The other feels like a service.

When to Invest in Platform Work: A Diagnostic Checklist

Here’s a practical checklist David Ohnstad uses to decide whether platform work should take priority over shipping another domain-aligned product. If you answer yes to three or more of these, you have a platform debt problem that will cost you more in delayed product velocity than the opportunity cost of pausing new product work for one cycle.

Are domain teams building duplicate pipelines for the same data source? If two teams are independently ingesting the same external dataset because they can’t discover or trust the existing ingestion, your metadata and discovery layer is broken. This is a failure radius problem—every new domain team will repeat the same work.

Are data contracts being documented after the fact instead of validated automatically? If contracts exist in Confluence or a wiki but aren’t enforced in code, they’re documentation, not contracts. Real contracts fail the build when they’re violated. If your contracts are aspirational, your governance layer isn’t a product—it’s a wishlist.

Are domain teams spending more than 20% of sprint capacity on manual data quality checks? If teams are writing custom validation scripts, manually reconciling row counts, or running ad hoc queries to verify data freshness, your quality tooling is insufficient. That 20% is capacity you’re losing every sprint, forever, until you fix the platform capability.

Has a production data product failed in the last two quarters because of a platform gap? If you’ve shipped a product that was technically correct but unusable because users couldn’t trust the underlying data, couldn’t trace lineage, or couldn’t get access in a reasonable time frame, that’s not a product problem—it’s a platform problem. The next product will fail the same way unless you address the root cause.

Are you onboarding a new domain team in the next quarter? New teams expose every rough edge in your platform. If you can’t confidently say “yes, they can self-serve and be productive in two weeks,” your platform isn’t ready to scale. Prioritize platform work before the onboarding, not after they’ve spent six weeks frustrated and built workarounds.

How David Ohnstad on AI and enterprise SaaS Thinks About AI’s Role in Mesh Prioritization

One underexplored angle in the data mesh conversation: AI and ML workloads are uniquely sensitive to platform gaps. A dashboard can survive with slightly stale metadata. A model training pipeline cannot. If your lineage tracking is incomplete, you can’t reproduce a model. If your data contracts aren’t enforced, your feature engineering breaks silently when upstream schemas change. If your access controls are slow, your ML engineers spend days waiting for permissions instead of experimenting.

David Ohnstad’s team learned this the hard way when they tried to onboard a machine learning product onto a data mesh that had been optimized for BI and reporting workloads. The ML team needed sub-hour data freshness. The platform guaranteed daily refreshes. The ML team needed automated lineage for regulatory compliance. The platform had manually maintained lineage docs that were 60% accurate. The ML team needed programmatic access to raw data for feature engineering. The platform exposed only aggregated views through a semantic layer designed for business users.

The lesson: if you’re planning to support AI/ML workloads on your data mesh, prioritize platform capabilities that enable reproducibility, auditability, and low-latency access—even if your current BI products don’t require them. Don’t wait until the ML team is blocked. The operational maturity required for reliable ML is higher than for traditional analytics, and retrofitting a BI-optimized mesh to support ML is significantly harder than building those capabilities in from the start. For teams navigating this, understanding the operational maturity of the infrastructure layer is critical—something David Ohnstad on leadership and career growth explores in the context of cross-functional team execution.

How do you prioritize between building new data products and fixing the data mesh platform?

Use a two-factor model: failure radius (how many future products are affected) and workaround cost (how much effort teams spend avoiding the gap). High radius and high cost mean platform work takes priority. Low radius and low cost mean ship the product. Revisit this every quarter as team needs evolve.

What is the biggest mistake teams make when implementing a data mesh?

Treating governance as a one-time setup instead of ongoing product work. Data contracts drift, ownership gets murky, and access policies go stale. Without a dedicated team maintaining governance as a living product with measurable outcomes, the mesh degrades into isolated silos with a broken interoperability layer.

When should platform work take priority over shipping a new data product?

When domain teams are spending more than 20% of sprint capacity on workarounds, when duplicate pipelines are being built for the same data, or when a production product has failed due to a platform gap in the last two quarters. Time direction matters—if workaround costs are rising, prioritize platform work immediately.

Two Takeaways and One Question

For practitioners: Build a shared artifact that tracks platform gaps, their failure radius, and the workaround costs domain teams are paying. Update it every sprint. Use it to make prioritization tradeoffs visible and defensible. The moment platform work is invisible in your backlog, it becomes invisible in your roadmap—and you’ll only address it reactively, after a product fails.

For leaders: Staff your governance layer like a product team, not an operations team. Give it a PM, a roadmap, success metrics, and accountability for adoption. Governance that feels like compliance gets ignored. Governance that feels like a service gets adopted. The framing determines the outcome. And when coaching cultures enable better decision-making under competing prioritization demands, teams navigate these tradeoffs with greater clarity and alignment.

Here’s the question to ask yourself: When was the last time you calculated the engineering hours your teams spend per sprint on workarounds for platform gaps—and compared that cost to the effort required to fix the platform capability permanently? If you don’t know the answer, you’re making prioritization decisions without half the data you need.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Connect on LinkedIn or read more at davidohnstad.com.