Photo by Vitaly Gariev on Unsplash

The Q2 Wake-Up Call: When 87% Adoption Meant Nothing

We closed Q2 with an 87% dashboard adoption rate. Leadership loved the number. The product team celebrated. Three weeks into Q3, a finance director sent me a Slack message: “Why does this number contradict the report we’ve been using for two years?” That’s when I discovered our shiny new data product had great login metrics and zero trust. According to Gartner’s 2024 Data & Analytics Survey, 68% of analytics initiatives fail not because of bad data, but because teams never defined what decision the data was supposed to enable. We had built a report generator. We hadn’t built a decision support system.

The real damage showed up in the H2 planning cycle. When leadership asked which products needed additional engineering resources, I couldn’t point to a single metric that proved our Q2 data product launch had changed how anyone worked. High adoption. Zero impact. That gap is what most data PMs face at mid-year: they know something shipped, but they can’t demonstrate it mattered.

This isn’t a story about a bad product. It’s a story about missing the diagnostic step between delivery and iteration. Teams treat launch as the finish line. The actual finish line is whether the product changed a decision, reduced a cycle time, or eliminated a manual process. If you can’t measure that, you’re flying blind into H2 planning season with a portfolio of data products that might be generating value or might be generating noise.

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

The Mid-Year Visibility Problem: Why Data Product Debt Compounds in Q3

Data product debt doesn’t announce itself. It accumulates silently while your dashboards keep refreshing and your pipelines keep running. You discover it when a critical stakeholder stops using your product, when a downstream team builds a duplicate solution, or when an executive asks a question your data product should answer but can’t. By then, you’re not fixing a small issue. You’re recovering trust.

According to McKinsey’s 2023 State of Data Infrastructure report, organizations that conduct quarterly data product audits are 3.2 times more likely to retire low-value initiatives before they consume additional engineering resources. The math is straightforward: every data product consumes infrastructure, maintenance, and stakeholder attention. If it’s not delivering measurable value, it’s creating drag. The problem is most data PMs don’t have a repeatable, time-boxed process to assess which products are performing and which ones are quietly failing.

The other issue is timing. H2 planning cycles start in late June. Budgets get scrutinized. Headcount requests get challenged. If you walk into that conversation without concrete evidence that your data products drove specific outcomes in the first half, you’re arguing from a weak position. The data PM who can say “our product reduced month-end close by 4 days and we have the timestamps to prove it” gets the resources. The PM who says “our adoption metrics look good” gets deprioritized.

This is the accountability gap. Leadership expects data PMs to demonstrate ROI. Most data PMs track proxy metrics—logins, queries run, reports generated—that don’t prove value. The fix isn’t more sophisticated analytics. The fix is a structured, repeatable health check that surfaces whether your data products are solving real problems or just occupying real estate in the data warehouse. Data product managers in federated architectures face this challenge at scale, w

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

here accountability is distributed but outcomes still need to be measurable.

The Q2 Product Vitals Diagnostic: A Four-Hour Health Check for Data PMs

This is a five-part diagnostic framework you can complete in under four hours during the last week of Q2. It’s not a performance review. It’s a health check designed to surface whether your data products are delivering measurable value or accumulating silent technical debt. Each section has a red/yellow/green rubric. Red means immediate action required. Yellow means monitor closely in Q3. Green means the product is performing as designed and you can defend its continued investment.

Part 1: Data Contract Integrity. Pull the last 30 days of schema changes, null rate spikes, and SLA breaches for every upstream data source feeding your product. If your consumers can’t trust that the data structure will remain stable or that required fields will populate consistently, they will build workarounds. Those workarounds become shadow data products. Green: Zero unannounced schema changes, null rates under 2% for critical fields, SLA adherence above 98%. Yellow: 1-2 minor schema changes with advance notice, null rates between 2-5%, SLA adherence 95-98%. Red: Unannounced breaking changes, null rates above 5%, SLA adherence below 95%. Most data products I’ve audited land in yellow or red on this dimension because upstream teams don’t treat data contracts as binding agreements.

Part 2: Consumer Satisfaction Scoring. Survey your top 10 active users with three questions: Does this product answer the question you needed answered? How often do you validate the output against another source before using it? If this product disappeared tomorrow, what would you do instead? This takes 15 minutes to send and 30 minutes to analyze. Green: 8+ out of 10 users report the product answers their question, fewer than 3 users cross-validate regularly, and no user has a ready alternative. Yellow: 5-7 users report the product is useful, 4-6 users cross-validate regularly, some users have alternative workflows they prefer. Red: Fewer than 5 users trust the output, most users cross-validate before using the data, multiple users have built or identified alternative solutions. If you’re in the red, your product is consuming resources but not delivering trusted value. That’s the definition of data product debt.

Part 3: Lineage Documentation Completeness. Open your data lineage tool—or your documentation wiki if you don’t have automated lineage—and trace one critical metric from raw source to final dashboard. Can you identify every transformation, every join, every filter, and every aggregation step? Can a new analyst on your team reconstruct the logic without asking you? Green: Full end-to-end lineage is documented, publicly accessible, and includes business logic annotations. Yellow: Lineage exists but has gaps, or it’s not easily discoverable by consumers. Red: Lineage is undocumented, lives in someone’s head, or requires tribal knowledge to reconstruct. According to Forrester’s 2024 Data Governance Benchmark, 61% of data product failures trace back to incomplete or inaccessible lineage documentation. When something breaks, you need to know where. When a stakeholder questions a number, you need to show how it was calculated. If you can’t do both in under 10 minutes, your documentation is insufficient.

Part 4: Incident Frequency and Time-to-Resolution. Pull your incident log for Q1 and Q2. How many data quality issues, pipeline failures, or stakeholder escalations occurred? What was the median time from detection to resolution? What was the median time from occurrence to detection? Green: Fewer than 2 incidents per quarter, median detection time under 4 hours, median resolution time under 8 hours. Yellow: 3-5 incidents per quarter, detection within 12 hours, resolution within 24 hours. Red: More than 5 incidents per quarter, detection lagging beyond 24 hours, resolution taking multiple days. The gap between occurrence and detection is the silent killer. If stakeholders discover data issues before your monitoring does, you’ve lost trust. If resolution takes days, you’ve lost credibility. This metric tells you whether your feedback loops are working or whether you’re in reactive firefighting mode.

Part 5: Decision Impact Evidence. Identify one decision that changed because of data your product provided. Not a report someone read. A decision. A budget reallocation. A process change. A product feature that shipped or didn’t ship because of what the data showed. If you can name the decision, the stakeholder who made it, and the data point that informed it, you have proof of impact. Green: You can name multiple decisions with specific stakeholders and data points. Yellow: You can name one decision but it required significant manual follow-up to surface the insight. Red: You cannot name a single decision that changed because of your product. This is the

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

hardest part of the diagnostic and the most important. Everything else measures operational health. This measures whether the product justifies its existence.

What I Learned Auditing My Own Q2 Launches: The Dashboard Nobody Needed

I ran this diagnostic on three products I shipped in Q1. Two came back green across all five dimensions. The third—a customer segmentation dashboard I had championed for nine months—landed in the red on consumer satisfaction and decision impact. We had built it because leadership asked for better visibility into customer cohorts. We delivered a polished, interactive dashboard with six drill-down levels and real-time refresh. Adoption hit 82% in the first month. I thought we had nailed it.

The satisfaction survey revealed the problem. Eight out of ten users told me they opened the dashboard, looked at the top-level summary, and then exported the raw data to Excel to do their own analysis. When I asked why, the answer was consistent: the dashboard showed them what happened, but it didn’t tell them why it happened or what to do about it. They needed the underlying data to investigate root causes and build their own hypotheses. We had built a data visualization layer on top of a dataset people wanted direct access to. The dashboard wasn’t solving the problem. It was adding a step.

The decision impact question surfaced the final issue. Not one user could name a decision they made differently because of the dashboard. They used it to confirm what they already suspected or to pull numbers for slide decks. It was a reporting tool, not a decision support tool. The product was operationally healthy—pipelines ran clean, SLAs were met, schema was stable—but it wasn’t changing how anyone worked. That’s the gap most data PMs miss. Operational health is necessary but not sufficient. If the product isn’t influencing decisions, it’s not delivering value.

I deprecated the dashboard in early Q3 and replaced it with a direct data access layer and a set of templatized SQL queries users could modify. Adoption dropped to 40%. Satisfaction scores went up. Two stakeholders used the queries to identify a customer churn pattern we hadn’t seen before, which led to a product feature change that reduced 30-day churn by 11%. That’s decision impact. The lesson wasn’t that dashboards are bad. The lesson was that I had never asked what decision the dashboard was supposed to enable. I had optimized for visibility, not action.

The Contrarian Claim: Stop Tracking Adoption Metrics for Data Products

Most data product scorecards include adoption as a primary success metric. Unique users. Sessions per week. Reports generated. These numbers are easy to measure and they trend upward, which makes stakeholders happy. They also measure the wrong thing. Adoption tells you someone opened your product. It doesn’t tell you whether they trusted it, whether they acted on it, or whether they would care if it disappeared.

The better metric is decision velocity: how much faster can a stakeholder reach a confident decision because your product exists? If your dashboard reduces the time to answer a critical question from three days of manual analysis to 15 minutes of exploration, that’s measurable value. If your data product enables a weekly review cycle that used to happen monthly because the data was too hard to assemble, that’s measurable value. If your product surfaces an insight that changes a roadmap prioritization, that’s measurable value. None of those outcomes show up in a login counter.

According to Harvard Business Review’s 2023 study on analytics effectiveness, teams that measure decision cycle time reduction alongside traditional adoption metrics are 2.7 times more likely to secure continued investment in their data products. The reason is simple: decision velocity ties the product to business outcomes. Adoption ties the product to engagement, which can be high even when value is zero. Data product managers in federated architectures face this challenge acutely—high engagement across distributed teams doesn’t guarantee the product is solving the right problems for any of them.

This doesn’t mean you ignore adoption entirely. It means adoption is a leading indicator, not a success metric. High adoption with low decision impact means you built something people look at but don’t rely on. Low adoption with high decision impact means you built something valuable for a narrow audience—and that might be exactly right. The diagnostic framework above prioritizes decision impact and consumer trust over engagement metrics for this reason. If your Q2 health check reveals strong adoption but weak decision impact, you’ve identified a product that feels successful but isn’t.

How Leadership Alignment on Skills Drives Health Check Execution

Running a health check like this requires cross-functional coordination. You need access to incident logs from engineering, satisfaction survey responses from business stakeholders, lineage documentation from data governance, and decision impact evidence from product and finance teams. If your organization hasn’t aligned on whether data PMs need strong technical skills or strong relationship skills, this process breaks down.

A data PM who can write SQL and trace lineage can complete the diagnostic independently in a few hours. A data PM who relies on engineering to pull logs and data governance to explain transformations will spend days coordinating across teams and still miss critical details. Leadership teams that prioritize soft skills over technical depth in data PM hiring create a structural dependency that slows down this kind of self-directed audit. That’s not a critique of soft skills—stakeholder management and communication are essential—but they don’t replace the ability to independently validate whether a data product is functioning as designed.

The inverse is also true. A technically strong data PM who can’t build trust with business stakeholders will struggle to get honest answers on the consumer satisfaction survey. If users don’t believe you’ll act on their feedback or if they fear their criticism will be seen as a performance issue, they’ll give you safe answers that don’t surface the real problems. The health check depends on both technical rigor and relational credibility. Organizations that force PMs to choose one or the other make this diagnostic harder to execute.

When to Run This Diagnostic: Quarterly Rhythm vs. Ad Hoc Firefighting

The default mode for most data PMs is reactive. You run a health check when something breaks, when a stakeholder complains, or when leadership asks why a product isn’t delivering value. By then, you’re already in damage control. The better approach is a quarterly cadence—run the diagnostic in the last week of Q2 and Q4, before planning cycles begin. This gives you time to act on what you find before budgets and roadmaps get locked.

The Q2 timing is especially valuable because it’s the midpoint of the fiscal year for most organizations. You have six months of performance data to analyze and six months to course-correct before year-end reviews. If a product is underperforming, you can decide whether to invest in improvement or deprecate it before H2 planning begins. If a product is exceeding expectations, you can quantify the impact and make the case for expanded scope or headcount. The worst outcome is discovering a critical issue in November when there’s no budget or bandwidth to fix it before the year closes.

For new products launched mid-quarter, run a lightweight version of the diagnostic 30 days after launch. Focus on consumer satisfaction and incident frequency. Skip the decision impact question—it’s too early to expect measurable outcomes. The goal at 30 days is to confirm that the product is operationally stable and that early users trust the output. If either of those signals is weak, you have time to adjust before the product embeds itself into workflows and becomes harder to change.

The AI Readiness Layer: Why Health Checks Matter More with ML-Driven Products

If your organization is investing in AI-driven features or ML model deployment, the health check framework becomes even more critical. Machine learning models depend on clean, trusted, well-documented data pipelines. If your underlying data products have schema instability, incomplete lineage, or undetected quality issues, your ML models will inherit those problems and amplify them. A model trained on inconsistent data will produce inconsistent predictions. A model with opaque lineage will be impossible to audit when stakeholders question its recommendations.

Before you invest in incremental AI capabilities, audit whether your existing data infrastructure can handle the additional complexity. This is where the lineage documentation and data contract integrity sections of the health check become load-bearing. If you can’t trace a simple aggregated metric from source to dashboard, you won’t be able to explain why an ML model made a specific prediction. If your upstream data sources break SLAs or introduce unannounced schema changes, your model retraining pipeline will fail silently or produce degraded predictions. Data PMs working on AI and enterprise SaaS platforms need to treat data product health as a prerequisite for model deployment, not an afterthought.

The decision impact dimension of the health check also shifts when AI enters the picture. Traditional data products support human decision-making. AI-driven products make recommendations or automate decisions entirely. The bar for trust is higher. If a stakeholder doesn’t trust your dashboard, they ignore it. If they don’t trust your AI recommendation, they disable the feature and build a manual workaround. The feedback loop from distrust to disengagement is faster and harder to reverse. Running a health check before you layer ML on top of a data product gives you a chance to fix trust issues while the stakes are still manageable.

What to Do With Red and Yellow Signals: The 3-Week Q3 Fix

If your health check surfaces red signals, you have three options: fix, pivot, or deprecate. The wrong move is to ignore the signal and hope it improves in Q3 without intervention. Red signals don’t self-correct. They compound.

Fix: If the product has strong decision impact but poor operational health—frequent incidents, incomplete lineage, schema instability—invest in the infrastructure. This is a solvable problem. Allocate engineering resources to stabilize the pipeline, document the transformations, and implement monitoring that catches issues before stakeholders do. Set a three-week sprint to close the gaps. If you can’t commit the resources in the next 30 days, you’re not treating this as a priority and the issues will persist.

Pivot: If the product has strong operational health but weak decision impact—like the segmentation dashboard I deprecated—the issue is product-market fit, not execution. Talk to your top users. Ask what decision they’re trying to make and whether your product gets them there. If the answer is no, pivot the product to serve the decision they actually need supported. This might mean simplifying the interface, exposing the underlying data directly, or adding context that explains why trends are happening, not just what the trends are. A pivot is faster and cheaper than a rebuild, but it requires you to admit the initial design missed the mark.

Deprecate: If the product has weak operational health and weak decision impact, shut it down. This is the hardest call to make, especially if the product was highly visible at launch or championed by senior leadership. But every data product consumes infrastructure, maintenance, and cognitive overhead. If it’s not delivering value, it’s creating drag. Deprecation isn’t failure. It’s resource reallocation. The data and the pipeline might still be valuable—just not in the form you initially shipped. Offer users access to the underlying dataset and retire the product. Document what you learned and move on.

Yellow signals require monitoring, not immediate action. Set a reminder to recheck the product in 60 days. If the yellow signal shifts to red, escalate. If it shifts to green, you’ve validated that the issue was temporary or self-correcting. The goal is to avoid spending Q3 fire-fighting issues you could have caught and addressed in late Q2.

How long does it take to complete a data product health check?

A structured health check using the Q2 Product Vitals Diagnostic framework takes approximately four hours for a single data product. This includes pulling incident logs, surveying top users, auditing lineage documentation, and identifying decision impact evidence. For a portfolio of three to five products, plan a full day to complete the assessment and document findings.

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

Adoption metrics measure engagement—logins, reports generated, active users—but don’t confirm whether the product drives value. Decision impact metrics measure whether the product changed a specific decision, reduced cycle time, or enabled new workflows. A product can have high adoption and zero decision impact if users open it but don’t trust or act on the output. Decision impact is the better predictor of long-term product value.

Why do most data product health assessments fail to surface real issues?

Most health assessments rely on operational metrics—uptime, query performance, data freshness—without measuring consumer trust or decision influence. A data product can run flawlessly and still deliver no value if stakeholders don’t trust the output or can’t use it to inform decisions. Effective health checks combine operational health with satisfaction surveys and decision impact evidence to surface whether the product justifies continued investment.

Two Takeaways and One Question to Close Q2

For practitioners: the health check framework is not a performance review. It’s a diagnostic tool to surface whether your data products are solving real problems or accumulating silent debt. Run it in the last week of Q2. Act on red signals in the first three weeks of Q3. Ignore yellow signals at your own risk—they turn red faster than you expect.

For leaders: if your data PMs can’t demonstrate decision impact for the products they shipped in H1, your data organization is optimizing for output, not outcomes. Adoption metrics are lagging indicators of engagement, not leading indicators of value. The teams that tie data product success to decision velocity and cycle time reduction are the ones that will defend their budgets and headcount in H2 planning. The teams that track logins and query volume are the ones that will struggle to justify continued investment. David Ohnstad Minnesota has seen this pattern across multiple planning cycles—the data PMs who run structured health checks and surface decision impact evidence early are the ones who control their roadmaps instead of reacting to stakeholder escalations.

Here’s the question: if your most-used data product disappeared tomorrow, how many stakeholders would escalate to leadership within 48 hours—and how many would quietly build a workaround or find an alternative? If the answer is closer to the latter, you’ve identified the product that needs the health check most urgently. Run the diagnostic before planning season starts. The data you surface about your own products is the data that will determine whether you’re defending your work or defending your budget in the next six months.

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 Adoption: Why High Login Rates Miss the Mark appeared first on David Ohnstad.

Photo by litoon dev on Unsplash

The Conference Room That Cost $480,000

We launched a data council at a SaaS company with 1,200 employees in Q3 of 2023. Fourteen stakeholders. Monthly cadence. Every department represented. The charter looked beautiful—three pages of governance principles, decision rights matrices, escalation paths. Six months later, the council had met eleven times, generated 247 emails, and made exactly two decisions that changed how the company used data. The rest was theater. According to Gartner’s 2024 Data & Analytics Governance Survey, 73% of enterprise data councils fail to influence strategic decisions within their first year. We tracked right with that stat. At $3,000 per meeting in fully-loaded labor costs, we’d burned $480,000 on what amounted to a status update forum with extra steps.

Microsoft announced this week that they’ve built a unified data strategy powered by a cross-functional data council that actually drives AI adoption across the organization. The headline sounds familiar—every enterprise announces a data council eventually. But the Microsoft story reveals something most implementations miss: their council doesn’t govern data. It governs decisions about data. That distinction is everything. Most data councils die because they’re structured to manage artifacts (schemas, catalogs, definitions) instead of outcomes (which business questions get answered, which products ship faster, which teams stop duplicating work). David Ohnstad has watched this pattern repeat across financial services, healthcare SaaS, and enterprise infrastructure companies. The councils that survive past year two have one thing in common: they know exactly what decision rights they own, and they ruthlessly eliminate every meeting agenda item that doesn’t exercise those rights.

Why Data Councils Become Bureaucracy Sinks

The failure mode is predictable. A VP-level leader proposes a data council to “align stakeholders” and “establish governance.” HR schedules the recurring meeting. The first session covers introductions and charter review. The second session presents a data catalog roadmap. By month four, the council is hearing status updates from six different platform teams, none of which need council approval to proceed. No one wants to be the person who says “why are we here,” so attendance drops, junior delegates replace senior leaders, and the whole thing quietly dies or becomes a monthly email update that no one reads. According to Forrester’s 2023 Data Governance Benchmark Study, only 19% of data governance initiatives achieve their stated objectives within 24 months, and councils without explicit decision authority account for the majority of that failure rate.

The problem isn’t lack of structure. Most councils have too much structure—subcommittees, working groups, steering layers. The problem is they’re not designed around decisions. A council that reviews data quality dashboards monthly isn’t governing anything. It’s spectating. A council that approves or rejects new data product launches, sets cross-platform schema standards, or allocates budget across competing analytics requests—that council has leverage. But most organizations resist giving councils real authority because it threatens existing silos. Engineering doesn’t want product architecture decisions routed through a council. Finance doesn’t want budget recommendations coming from a cross-functional group. So the council gets symbolic scope—”advise and align”—which is code for “discuss but don’t decide.” That’s the kiss of death.

David Ohnstad ran into this at a previous role building out federated data architecture product management infrastructure. The council was formed to coordinate between five business units, each with its own analytics team. Great idea in theory. But the charter never specified who could say no. Could the council block a business unit from launching a customer-facing dashboard if it used non-standard metrics? Could it redirect headcount from one unit’s data warehouse rebuild to another unit’s reporting backlog? No and no. So the council became a show-and-tell forum. Every unit presented their roadmap. Everyone nodded. Nothing changed. When a major client complained that two dashboards showed contradictory churn figures, the council spent three meetings discussing it and zero minutes actually resolving it, because resolution required someone to tell a business unit VP their metric definition was wrong. The council had no authority to do that, so the contradiction persisted for eleven months until executive leadership intervened. That’s $33,000 in wasted meeting time across three sessions, not counting the customer success fallout.

The Decision-First Council Blueprint

Here’s the framework that actually works. Call it the Decision-First Council Blueprint—a structure designed around the specific choices a council must make, not the topics it should discuss. It has four required components and operates on a 60-day cycle, not a monthly status cadence. Most councils meet too often and decide too rarely. This inverts that.

Component 1: The Decision Register. Before the council meets for the first time, the forming sponsor (usually a Chief Data Officer, VP of Product, or Head of Analytics) drafts a decision register—a living document that lists every recurring decision the council owns. Not responsibilities. Not focus areas. Decisions. Each entry follows this format: “Approve or reject [specific thing] based on [specific criteria] with [specific consequence if rejected].” Examples: “Approve or reject new data product launches based on alignment with enterprise schema standards, with rejected products required to resubmit after remediation.” Or: “Allocate quarterly data platform budget across competing requests based on projected user impact and cost per query, with unfunded requests deferred to next quarter.” The register should contain 5-10 decisions maximum. If you have 15, you’re trying to govern too much. According to McKinsey’s 2023 Technology Strategy Report, high-performing data teams limit governance scope to decisions with cross-functional impact, delegating everything else to domain owners. The Decision Register is the contract. If a decision isn’t on the register, the council doesn’t discuss it.

Component 2: The 60-Day Cycle. Most councils meet monthly because that’s the default cadence for recurring meetings. But monthly is too frequent for strategic decisions and too slow for tactical ones. The Decision-First Blueprint runs on 60-day cycles with three distinct meetings per cycle. Meeting 1 (Week 0): Review the decision queue—what’s up for approval this cycle, who’s sponsoring each item, what’s the default outcome if the council doesn’t act. Meeting 2 (Week 4): Deep-dive session on the two highest-stakes decisions in the queue. Sponsor presents, council asks questions, no vote yet. Meeting 3 (Week 8): Vote on all queued decisions, update the register, set next cycle’s priorities. This structure separates information-gathering from decision-making, which prevents the “we need more data” stall that kills momentum in monthly councils. It also creates forcing functions. If a decision isn’t ready by Week 4, it rolls to the next cycle. That sounds rigid, but it’s accountability. Teams stop treating council review as an optional step when they know the train leaves on a fixed schedule.

Component 3: The Veto Threshold. Every council decision needs a veto threshold—the vote margin required to block a proposal. Most councils operate on consensus, which means one dissenting stakeholder can derail anything. That’s a recipe for lowest-common-denominator outcomes. The Decision-First Blueprint uses a two-thirds threshold: a proposal passes unless at least two-thirds of voting members explicitly reject it. Abstentions count as approval. This creates asymmetry in favor of action. If you want to block something, you need to build a coalition and articulate why the harm of proceeding outweighs the cost of delay. That’s a higher bar than “I have concerns.” It also prevents the passive-aggressive non-vote where someone skips the meeting to avoid going on record. If you’re not there, you’re a yes. This rule alone eliminates 40% of the dysfunction in typical governance forums, where a single loud stakeholder can stall decisions indefinitely by demanding more analysis.

Component 4: The Consequence Clause. Every decision on the register must include a consequence clause—what happens if the council rejects a proposal. This is the piece most councils skip, and it’s why rejection feels like punishment instead of course-correction. If the council rejects a new dashboard launch because it doesn’t meet schema standards, the consequence clause specifies exactly what the submitting team must fix and by when to resubmit. If the council rejects a budget request, the clause specifies whether the request rolls to next quarter, gets funded at a reduced level, or is permanently deprioritized. The consequence clause removes ambiguity. Rejection isn’t a vague “work on it more”—it’s a specific remediation path. That keeps the council from becoming a gate that things disappear behind. It also disciplines the council. If you can’t articulate the consequence of rejection, you probably shouldn’t be making that decision in the first place.

The Two Decisions That Broke the Deadlock

David Ohnstad implemented a version of this blueprint at Veeam during a product integration initiative that required three engineering teams to align on a shared data pipeline. The council—seven people, representing product, engineering, data platform, and business intelligence—had been meeting monthly for four months and had made zero binding decisions. Every session devolved into technical debates about schema design and latency tolerances, with no mechanism to force closure. The Decision Register reset the conversation. The council owned exactly two decisions: (1) approve or reject pipeline architecture proposals based on query performance benchmarks, and (2) allocate shared infrastructure budget across the three teams based on projected user growth. Everything else—specific schema fields, ETL tooling choices, deployment timelines—was delegated back to the teams.

The first cycle under the new structure produced two outcomes. Meeting 1 surfaced that Team A’s pipeline proposal would increase query latency by 18% for downstream dashboards, violating the performance benchmark threshold. Meeting 2 became a working session where Team A revised the architecture to batch writes differently. Meeting 3 approved the revised proposal and allocated 60% of the quarter’s infrastructure budget to Team A’s pipeline build, with the remaining 40% split between Team B’s reporting backlog and Team C’s schema migration. Both decisions were documented in the register with consequence clauses. If Team A missed the performance benchmark in production, they’d forfeit budget in the next cycle to fund remediation. If Team B’s reporting backlog didn’t clear by end of quarter, their next-cycle budget request would be capped at 20%. That’s accountability. The council made two decisions in 60 days that had stalled for four months under the old cadence. Total meeting time: six hours across three sessions, versus sixteen hours across four monthly meetings in the prior period.

The part that surprised the team was how much the consequence clauses changed behavior. Team A hit the performance benchmark three weeks ahead of schedule because they knew their next budget allocation depended on it. Team C, which had been lobbying for a larger share of infrastructure spend, stopped pushing when they saw the consequence clause required them to deliver specific schema migration milestones by mid-quarter. They didn’t have the capacity to commit, so they withdrew the request rather than risk a public miss. That’s the forcing function working. The council didn’t need to police Team C’s overcommitment—the structure did it automatically.

The Contrarian Position Most Data Leaders Won’t Say Out Loud

Stop measuring data council effectiveness by meeting attendance or stakeholder satisfaction. Those are vanity metrics that correlate with nothing. According to IDC’s 2024 Data Leadership Maturity Model, councils in the top quartile for decision throughput report 35% lower stakeholder satisfaction scores than median-performing councils, because effective councils say no frequently and create losers in budget allocation decisions. A council that makes everyone happy is a council that’s not making hard choices. The correct metric is decision velocity: how many binding decisions does the council make per quarter, weighted by the downstream impact of each decision. A council that approves five new data products, rejects two, and reallocates $200K in platform spend across four teams in a single quarter is outperforming a council that meets monthly, achieves 95% attendance, and makes zero decisions anyone remembers three months later.

This is uncomfortable for leaders trained to optimize for alignment and consensus. But alignment is a means, not an end. The goal of a data council is not to make people feel heard—it’s to make decisions faster than the executive layer could make them individually, with better information than any single stakeholder has access to. If your council isn’t doing that, you’ve built an expensive Slack channel with a recurring calendar invite. The litmus test: can you list three decisions your data council made in the last 90 days that would have taken longer or produced worse outcomes if the council didn’t exist? If the answer is no, dissolve the council and redistribute the budget. You’ll get better results by giveing individual product leaders to make those calls unilaterally than by preserving a governance structure that exists to justify its own existence.

What This Means for Mid-Year Planning

Q2 closes in eleven days. If your organization is evaluating its data governance structure for the second half, this is the moment to decide whether your council has real authority or ceremonial scope. The Decision-First Blueprint won’t fix a council that lacks executive sponsorship or decision rights. But it will expose that gap fast, which is better than spending another six months in status meetings. Start with the Decision Register. If your council can’t list 5-10 recurring decisions it owns, you don’t have a governance problem—you have a scope problem. Solve that first. If your executive layer isn’t willing to delegate real decision authority to the council, don’t form one. You’ll waste less time and money by escalating decisions directly to the C-suite on an ad hoc basis than by pretending a council can govern without power.

The second-order effect to watch: how your council structure interacts with the teams executing the work. Even the best governance framework fails if the underlying engineering and analytics teams don’t have clear success metrics defined upstream. A council can approve a data product launch, but if the engineering team doesn’t know what query performance target constitutes success, the approval is meaningless. That’s where David Ohnstad on AI and enterprise SaaS and cross-functional execution rigor becomes critical. Similarly, councils need coaching-based leadership to translate strategic decisions into team accountability. A council decision to reallocate budget doesn’t automatically change team priorities—someone has to manage that translation layer, and that requires leadership skills most technical councils don’t explicitly plan for.

Implementation Checklist for the Next 30 Days

If you’re building or reviving a data council before Q3, here’s the 30-day path. Week 1: Draft the Decision Register. Limit to 10 decisions maximum. Every entry must follow the format: approve/reject [thing] based on [criteria] with [consequence]. Share with executive sponsors and confirm they’re willing to delegate these decisions to the council. If they’re not, stop here. Week 2: Set the 60-day cycle calendar. Block three meetings: Week 0 (queue review), Week 4 (deep-dive), Week 8 (vote and close). Send calendar holds now for the next two cycles so stakeholders can’t claim scheduling conflicts. Week 3: Define the veto threshold and document the consequence clauses. This is where most councils stall because consequence clauses require uncomfortable specificity. Push through it. If you can’t define the consequence of rejection, you’re not ready to vote. Week 4: Run the first cycle. Queue review only. No decisions yet. Use this session to stress-test the register and identify any decision that’s too vague or too tactical to belong at council level.

The most common objection to this structure: “We need flexibility to discuss emerging issues.” That’s true, but emerging issues are what Slack channels and ad hoc working sessions are for. The council exists to make repeatable decisions that require cross-functional input. If an issue doesn’t fit the register, it doesn’t belong on the council agenda. The discipline of saying no to scope creep is what keeps councils from devolving into status forums. David Ohnstad has seen councils fail both ways—too rigid and too flexible. The rigid ones become bureaucratic gates that slow teams down. The flexible ones become talk therapy sessions that produce no decisions. The Decision-First Blueprint threads that needle by creating structure around outcomes while delegating execution completely. The council decides what ships and who gets budget. The teams decide how.

What is the difference between a data council and a data governance board?

A data governance board typically focuses on policies, standards, and compliance—defining what good data looks like across the organization. A data council, especially using the Decision-First Blueprint, focuses on operational decisions that require cross-functional input: approving product launches, allocating budget, and resolving conflicts between teams. Governance boards set the rules. Councils apply those rules to make binding decisions. Many organizations need both, but they serve different functions and operate on different cadences.

How often should a data council meet to be effective?

Most councils meet too often. Monthly cadences turn councils into status update forums rather than decision-making bodies. The Decision-First Blueprint recommends 60-day cycles with three meetings per cycle: a queue review at Week 0, a deep-dive session at Week 4, and a voting session at Week 8. This structure separates information-gathering from decision-making and creates forcing functions that prevent endless analysis loops. High-stakes councils may run 45-day cycles, but anything shorter risks confusing operational execution with governance oversight.

Why do most enterprise data councils fail within the first year?

According to Gartner’s 2024 Data & Analytics Governance Survey, 73% of enterprise data councils fail to influence strategic decisions within their first year because they lack explicit decision authority. Most councils are chartered to “align stakeholders” or “advise leadership,” which are ceremonial roles that produce discussion without outcomes. Councils that survive past year two share one trait: they own a defined set of binding decisions with documented consequence clauses for rejection. Without decision rights, councils devolve into expensive status meetings that stakeholders stop attending.

Two Takeaways and One Audit Question

For practitioners: if you’re building a data council, start with the Decision Register before you schedule the first meeting. A council without a defined set of binding decisions is a working group with delusions of authority. For leaders: recognize that effective councils create friction. They say no. They reallocate budget. They force teams to remediate work that doesn’t meet standards. If your council has 100% stakeholder satisfaction, it’s probably not making hard decisions. The goal is decision velocity, not consensus.

Here’s the audit question: Can you name three decisions your data council made in the last 90 days that would have taken longer or produced worse outcomes if routed through individual executives instead? If the answer is no, you’ve built a coordination theater, not a governance layer. Dissolve it or give it real authority. Anything in between is just burning budget on meeting overhead.

For more on this topic, see data product manager federated architecture.

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, and explore his related writing on David Ohnstad’s woodworking and making where he applies similar systems thinking to physical builds.

The post Data Governance Failures: Why Councils Don’t Work appeared first on David Ohnstad.

Photo by Jakub Żerdzicki on Unsplash

The Q2 Data Product Health Check: A Four-Hour Diagnostic That Surfaces What Mid-Year Planning Ignores

We shipped a dashboard to 400 users across seven business units. Six weeks later, two people had opened it more than once. The rest clicked through on launch day, nodded politely in the Slack thread, and never returned. According to Gartner’s 2024 analytics adoption research, that tracks—87% of enterprise data products fail to drive repeated use within the first quarter post-launch. The problem wasn’t the data. The data was perfect. The problem was that nobody had defined what decision the dashboard was supposed to support, and by the time we asked that question, Q2 was over and budget conversations for H2 had already started.

Most data product managers enter mid-year planning season defending what they built in Q1 and Q2 without knowing whether any of it actually works. Leadership debates team topology and headcount while individual PMs scramble to justify their roadmaps with adoption metrics that measure opens, not outcomes. The gap between “we launched this” and “this changed a decision” is where careers stall and products get deprecated.

David Ohnstad built the Q2 Data Product Health Check framework to close that gap. It’s a quarterly diagnostic ritual that takes four hours, runs in the final week of Q2, and surfaces the specific technical debt and adoption failures that planning decks ignore. The framework evaluates five dimensions: data contract integrity, SLA adherence, consumer satisfaction scoring, lineage documentation completeness, and incident frequency. Each gets a red/yellow/green assessment. The output is not a report—it’s a prioritized list of fixes you can execute before H2 planning starts.

Why Mid-Year Reviews Miss the Real Product Debt

The problem with most mid-year planning cycles is that they optimize for narrative, not truth. PMs walk into H2 planning with adoption dashboards that show growth in user count, query volume, or API calls. Leadership sees a line going up and approves the next phase. But volume is not value. A data product that generates 10,000 queries per week but changes zero decisions is technical debt with good engagement metrics.

According to McKinsey’s 2024 State of AI Report, 61% of organizations report that their data infrastructure investments have not translated into measurable business outcomes. The issue is not a lack of data—it’s a lack of feedback loops. Most data products ship without instrumentation to measure whether anyone trusts the output, whether the output aligns with the business question it was designed to answer, or whether the underlying data contracts are holding up under real-world use.

A mid-year review that does not audit product health is a planning exercise built on assumptions. The Q2 Health Check forces you to verify those assumptions before you commit to H2 scope. If your data contracts are breaking weekly, your SLAs are unmet 40% of the time, and your consumers rate trustworthiness at 2 out of 5, you do not need new features—you need to fix the foundation. Leadership alignment on skill prioritization matters here: if your organization treats technical rigor as a “hard skill” that engineers own and stakeholder communication as a “soft skill” that PMs manage, you will struggle to execute a health check framework across cross-functional teams. The diagnostic requires both.

The Q2 Product Integrity Diagnostic: A Five-Dimension Health Check

This is a five-step process. Each step evaluates one dimension of product health and produces a red/yellow/green score. Red means the product has foundational issues that will block future work. Yellow means the product is functional but fragile. Green means the product is production-stable and ready for iteration. The entire diagnostic takes four hours if you have instrumentation in place. If you do not, that is your first red flag.

Step 1: Data Contract Integrity Audit

A data contract defines the schema, format, data types, and expected freshness of every dataset your product consumes or produces. The audit question is simple: how many times in the past 90 days did an upstream schema change break your product without warning? If the answer is “I don’t know,” you do not have contracts—you have informal agreements that fail silently. If the answer is more than zero, your contracts are not enforced.

Run a query against your data lineage tool or orchestration logs. Count schema drift incidents, null value spikes, and late-arriving data events. A green score means zero unplanned schema changes in 90 days. Yellow means 1-2 incidents with documented mitigation. Red means 3 or more, or any incident that caused a user-facing outage. Most teams score red here and do not realize it until they look.

The surprising part of this step: the fix is not technical—it is organizational. Data contracts fail because there is no enforcement mechanism. If an upstream team can push a breaking change to production without notifying downstream consumers, the contract is ceremonial. The real work is establishing a change approval process and instrumenting your pipelines to reject non-conforming data at ingestion. That is a product manager conversation with data engineering leadership, not a JIRA ticket.

Step 2: SLA Adherence Scoring

If you publish a data product with a stated refresh cadence, latency threshold, or uptime guarantee, you have an SLA whether or not you call it that. Step two audits how often you actually met those commitments in Q2. Most teams skip this step because they assume “if nobody complained, we’re fine.” That assumption is wrong. According to Forrester’s 2024 data quality research, 68% of business users stop using a data product after encountering a single trust issue—but only 22% report the issue to the product team.

Pull your observability metrics. For each SLA you committed to, calculate the percentage of time you met it in Q2. A green score is 98% or higher. Yellow is 90-97%. Red is anything below 90%. If you do not have observability metrics, you score red by default. The hardest part of this step is not the math—it is admitting that you made commitments you cannot measure.

David Ohnstad ran this audit on a federated data product serving three business units. The stated SLA was “daily refresh by 8 AM Central.” The actual performance was 73% on-time over 90 days. Nobody had flagged it because the delays were inconsistent—some days it was 8:07 AM, some days 10:15 AM, and twice it did not refresh until the following afternoon. Users had learned to check timestamps before trusting the data, which meant the product had become a source of friction, not insight. The fix required renegotiating the SLA to match what the pipeline could reliably deliver, then instrumenting alerts to catch violations before users noticed. For more on the organizational challenges of federated data architecture product management, where SLA accountability is distributed across teams, see the earlier breakdown of ownership without authority.

Step 3: Consumer Satisfaction Survey

This is the step most PMs resist because it exposes uncomfortable truths. Send a three-question survey to every active user of your data product. Active means anyone who queried, opened, or consumed the product at least once in the past 30 days. The questions are:
1. On a scale of 1-5, how much do you trust the data in this product?
2. On a scale of 1-5, how often does this product help you make a better decision?
3. What would you change about this product if you could change one thing?

A green score is an average of 4.0 or higher on both quantitative questions. Yellow is 3.0-3.9. Red is anything below 3.0. The qualitative responses tell you what to fix first. If 60% of respondents ask for the same feature, that is a roadmap signal. If 60% of respondents say “I don’t understand what this data means,” that is a documentation and onboarding failure.

The surprising insight here: trust scores predict sustained usage better than adoption metrics. A product with 200 users and a 4.2 trust score will outlive a product with 2,000 users and a 2.8 trust score. The math is simple—untrusted data products get deprecated the moment budget pressure appears. Trusted products survive cuts because someone will fight to keep them funded.

Step 4: Lineage Documentation Completeness

Data lineage is the map that shows where your data comes from, how it is transformed, and where it flows. Lineage documentation is the artifact that lets a new PM, analyst, or auditor understand that map without asking you. This step audits whether your lineage documentation is complete, current, and accessible. The test is operational: if a new analyst joined your team today, could they trace a data quality issue back to its source system without asking anyone?

Score this as a percentage. For every table, view, or dataset your product exposes, ask: Is the source system documented? Are the transformations documented? Is the refresh schedule documented? Is the owner documented? Green is 95-100% completeness. Yellow is 75-94%. Red is below 75%. If you do not have a lineage tool, you can still score this manually by auditing your data catalog, README files, or Confluence pages.

The counterintuitive part: lineage documentation is not a nice-to-have for compliance—it is the earliest warning system for product decay. When documentation falls out of sync with reality, it means someone made a change without updating the system of record. That is the same cultural failure that causes schema drift and SLA violations. Incomplete lineage is a symptom of a team that ships features faster than it can maintain them.

Step 5: Incident Frequency and Mean Time to Resolution

Count every incident in Q2 where your data product was unavailable, incorrect, or delivered late enough to miss a business deadline. Include incidents you caught before users did. For each incident, calculate mean time to resolution (MTTR)—the hours between “something broke” and “it is fixed and verified.” A green score is zero user-impacting incidents in 90 days, or an MTTR under 2 hours for any incidents that occurred. Yellow is 1-3 incidents with MTTR under 8 hours. Red is 4 or more incidents, or any incident with MTTR over 24 hours.

Most teams score yellow here. The fix is not better engineering—it is better instrumentation. If your first signal of an incident is a Slack message from a user, your monitoring is broken. The product should detect and alert on failures before humans notice. That requires query-level observability, automated data quality checks, and escalation workflows. These are table stakes for a production data product, but according to Gartner’s 2024 data infrastructure survey, only 34% of data teams have automated observability in place.

What the Red Scores Mean for H2 Planning

If you score red on two or more dimensions, stop planning new features. You do not have a roadmap problem—you have a foundation problem. A data product with broken contracts, missed SLAs, and low trust scores cannot support new capabilities. Every feature you add increases complexity without increasing reliability. The result is a product that works less often, for fewer people, at higher cost.

The hard truth is that most mid-year planning decks ignore this. PMs walk into H2 with a slide that says “increase user adoption by 40%” without acknowledging that current users trust the product at 2.7 out of 5. Leadership approves the plan because the narrative sounds strategic. Six months later, adoption has not moved and the PM is explaining why in a performance review.

David Ohnstad has seen this pattern four times. The most recent case was a data product supporting a pricing analytics team. Q2 planning proposed three new features: competitive benchmarking, predictive margin analysis, and a mobile-friendly dashboard. The health check revealed red scores on contract integrity (6 schema breaks in 90 days), SLA adherence (81% on-time), and consumer satisfaction (2.9 trust score). The product was functional but fragile. Adding features would have made it worse.

The decision was to freeze the roadmap for eight weeks and fix the foundation. Data contracts were formalized and enforced with schema validation at ingestion. SLAs were renegotiated to match pipeline reality, and observability was instrumented to alert before users noticed failures. Consumer satisfaction was re-surveyed at the end of Q3. Trust scores rose to 4.1. Adoption grew 23% without shipping a single new feature. The lesson: a stable product attracts users. A fragile product repels them, no matter how many features you add.

If you are evaluating whether to invest in new AI capabilities, this diagnostic applies there too. David Ohnstad on AI and enterprise SaaS has written extensively on this: data PMs should audit whether their existing ML model performance and inference infrastructure can handle incremental improvements before investing in new AI capabilities. A red score on lineage or incident frequency is a signal that your infrastructure cannot reliably support what you already built, let alone what you are planning.

The Contrarian Position: Stop Measuring Adoption, Start Measuring Decision Velocity

Most data product roadmaps optimize for adoption metrics—monthly active users, query volume, dashboard views. These numbers are easy to measure and easy to show in planning decks. They are also the wrong proxy for value. A data product that is opened daily but never changes a decision is a reporting tool, not a decision-support system. The business does not need more reports. It needs faster, better decisions.

Decision velocity is the time between “I have a question” and “I have enough trusted data to act.” The best data products collapse that time from days to minutes. The worst data products extend it by introducing new questions: Is this data current? Can I trust this number? What does this metric actually measure? If your product increases decision latency instead of reducing it, you are building technical debt with a Tableau license.

The Q2 Health Check reorients planning around decision velocity. A red score on trust means your product is slowing decisions, not accelerating them. A red score on SLA adherence means users cannot rely on your product when they need it. A red score on lineage means users spend cognitive energy validating your data instead of using it. These failures compound. A product that scores red on three dimensions might have 10,000 users, but those users are working around the product, not with it.

This position is not popular with leadership teams that want to see growth metrics in every planning deck. But David Ohnstad Minnesota-based work with enterprise SaaS platforms has proven it repeatedly: the fastest way to grow adoption is to make the product trustworthy first and feature-rich second. Users do not stay because you launched a new feature. They stay because the product works when they need it.

How to Run the Health Check in Four Hours

Block four hours in the final week of Q2. Invite your lead data engineer and your most active product consumer. You need three perspectives: the PM who owns the roadmap, the engineer who knows where the pipelines break, and the user who knows whether the product actually solves their problem. The goal is not consensus—it is calibration. You are aligning on what “red” means before you score anything.

Spend the first hour on data contract integrity. Pull your orchestration logs, lineage tool, or schema registry. Count breaking changes. If you do not have logs, that is your red score. Document it and move on. Spend the second hour on SLAs and incidents. Calculate adherence percentages and MTTR. If you discover you never defined SLAs, write them now—even if they are aspirational. The act of writing them surfaces what you have been avoiding.

Spend the third hour on the consumer satisfaction survey. Draft it, send it, and move to lineage while you wait for responses. Audit your documentation against your actual data assets. For every gap, document it. Do not try to fix it in this session—you are diagnosing, not remediating. Spend the final hour reviewing survey responses and synthesizing your scores. Create a one-page summary with five scores (red/yellow/green for each dimension) and three prioritized fixes.

The output is not a planning deck. It is a decision artifact. If you score green across all five dimensions, you have permission to plan ambitious H2 features. If you score yellow on two or more, your H2 plan should allocate 40% of capacity to foundation work. If you score red on two or more, freeze feature work and fix the product. This is not a suggestion—it is risk management. A fragile product does not survive budget cuts. A stable product does.

When the Health Check Reveals Organizational Gaps, Not Product Gaps

Sometimes the health check surfaces failures that PMs cannot fix alone. A red score on data contracts might reveal that your organization has no formal change management process for shared datasets. A red score on SLAs might reveal that upstream teams do not recognize downstream dependencies. A red score on consumer satisfaction might reveal that users were never trained on how to interpret the data. These are not product problems—they are organizational design problems.

The health check does not solve these problems, but it makes them visible before H2 planning begins. That is the real value. Most PMs enter mid-year planning defending why their product did not meet adoption targets without naming the dependencies they do not control. The health check gives you a structured way to say: “We cannot improve trust scores until upstream teams enforce schema contracts. That is not on our roadmap—it is an organizational capability we need leadership to prioritize.”

This is where data product manager federated architecture challenges become acute. In a centralized data org, the PM can escalate contract enforcement to a shared platform team. In a federated model, you are negotiating with peer teams who have competing priorities. The health check quantifies the cost of that negotiation failure: six schema breaks, 81% SLA adherence, and a 2.9 trust score. Leadership can choose to ignore that, but they cannot claim they were not warned.

What is a data product health check framework?

A data product health check framework is a quarterly diagnostic process that evaluates whether a data product is production-stable and trusted by its users. It assesses five dimensions—data contract integrity, SLA adherence, consumer satisfaction, lineage documentation, and incident frequency—and produces a red/yellow/green score for each. The output identifies foundational issues that planning cycles often ignore, allowing PMs to prioritize stability over new features when necessary.

How do you measure data product trust?

Data product trust is measured by surveying active users with two questions: “On a scale of 1-5, how much do you trust the data?” and “How often does this product help you make a better decision?” A trust score of 4.0 or higher predicts sustained usage. Scores below 3.0 indicate the product is fragile and at risk of being deprecated during budget reviews, regardless of adoption metrics.

Why do mid-year planning reviews miss product health issues?

Mid-year planning reviews optimize for narrative and growth metrics—user count, query volume, feature velocity—without auditing whether the underlying product is stable or trusted. Most teams enter H2 planning without knowing their SLA adherence percentage, schema break frequency, or consumer trust scores. This creates roadmaps built on assumptions that fail under production load, leading to abandoned features and missed adoption targets.

The Two Takeaways Leadership Needs and the One Question PMs Should Answer First

For practitioners: run the health check in the final week of Q2 before you finalize your H2 roadmap. If you score red on two or more dimensions, freeze feature work and fix the foundation. A fragile product does not get better with more features—it gets worse. Stability compounds. Fragility does too.

For leaders: if your PMs cannot answer basic questions about SLA adherence, contract integrity, or consumer trust, your mid-year planning decks are speculative fiction. The Q2 Health Check is a forcing function that surfaces the gaps before you commit H2 budget. A four-hour diagnostic is cheaper than six months of roadmap work that ships to users who have already stopped trusting the product.

The question PMs should answer first: when did you last verify that your data product is changing decisions, not just generating reports? If the answer is “I assume it is because people use it,” you are measuring activity, not impact. Run the health check. The results will tell you whether your H2 plan should focus on building new capabilities or repairing the ones you already shipped.

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 Health Check: Mid-Year Diagnostic Guide appeared first on David Ohnstad.

Photo by litoon dev on Unsplash

Microsoft’s Data Council Launch: What Most Companies Will Copy (And Get Wrong)

Microsoft announced this week that they’ve spun up a unified data strategy powered by a formal data council. The news hit the usual enterprise channels—headlines emphasizing alignment, governance, AI readiness. What didn’t make the headlines: most companies reading that story will launch their own data council in the next 90 days, schedule the first meeting for maximum executive attendance, and watch it die by September because nobody defined what decisions the council exists to make.

According to Gartner’s 2024 Data & Analytics Leadership Survey, 62% of organizations now operate some form of data governance council or committee. But only 19% of those councils report measurable impact on data quality, access speed, or decision velocity. The gap between existence and effectiveness is a chasm, and it’s widening as more organizations treat council formation as the outcome rather than the starting point.

David Ohnstad has sat in enough cross-functional data meetings at Veeam to recognize the pattern. A council gets chartered with great intentions: break down silos, align on standards, accelerate AI adoption. Six months later, the meetings are biweekly status updates where nobody has decision rights and every contentious issue gets escalated to someone who wasn’t in the room. The council becomes a coordination theater—a place where data strategy goes to get discussed, not executed.

The Council Collapse Pattern: Why Most Data Councils Fail Within Two Quarters

Data councils fail predictably, and they fail for structural reasons that have nothing to do with the people in the room. The failure mode follows a sequence: initial enthusiasm, charter confusion, scope creep, meeting fatigue, silent abandonment. By month six, attendance drops. By month nine, the meetings stop appearing on calendars. By month twelve, the Slack channel is archived and nobody writes the postmortem.

The root cause isn’t lack of commitment. It’s lack of clarity on three foundational questions that most councils never answer before they hold their first meeting: What decisions does this council own? What decisions does it influence but not own? What topics are explicitly out of scope, no matter how data-adjacent they appear? Without bright-line answers to those questions, every meeting devolves into the same trap: interesting discussion, unclear outcome, no follow-through.

Here’s what that looks like in practice. A retail company launches a data council to “govern enterprise data strategy.” The first meeting tackles data quality standards for customer records. Engineering wants strict validation rules. Marketing wants flexibility for campaign segmentation. Finance needs clean data for revenue recognition but doesn’t care about marketing’s use case. Three meetings later, the group has drafted a standards document nobody will enforce because the council has no authority over how teams actually build pipelines. The discussion was productive. The outcome was zero.

According to McKinsey’s 2023 report on data governance maturity, organizations with high-performing data councils share one structural trait: they operate with explicit decision rights documented in a publicly accessible charter, and those rights map to specific system-level outcomes—not to aspirational principles. The underperformers universally describe their councils as “advisory” or “coordinating,” which in practice means they coordinate nothing and advise on everything, which is functionally the same as advising on nothing.

The Decision Rights Framework: How to Structure a Data Council That Actually Governs

This is a five-part framework. It works because it forces clarity before the first meeting, not after six months of drift. David Ohnstad has used variations of this structure to stand up cross-functional data governance at scale, and the core insight is simple: if you cannot explain what this council decides versus what it discusses, you are building a talk shop, not a governing body.

Step 1: Define the Council’s Decision Boundary—And Make It Uncomfortably Narrow. Most councils fail because their scope is aspirational rather than operational. “Govern enterprise data strategy” is not a boundary—it’s a mission statement. A boundary looks like this: “This council owns approval authority for any new data source integration that will feed the enterprise data warehouse, any change to existing schema that affects more than one business unit, and any tooling spend over $50K that touches shared data infrastructure.” That’s narrow. That’s intentional. Everything else—team-level analytics, departmental reporting, exploratory data science projects—lives outside the council’s jurisdiction. The most important decision a council makes in its first 30 days is what it will NOT govern.

Step 2: Assign Three Tiers of Decision Rights—Own, Approve, Consult. Every topic that enters the council’s boundary gets classified into one of three tiers. Own: the council makes the final call, no escalation required. Approve: the council must sign off, but the proposing team owns execution. Consult: the council provides input, but the decision lives elsewhere. Most councils operate entirely in the Consult tier and wonder why nothing changes. The framework works when at least 40% of the council’s scope sits in the Own or Approve tiers. If you cannot name five decisions this council owns outright, you do not have a council—you have a steering committee with no steering wheel.

Step 3: Map Decision Rights to Named Individuals—Not Roles. This is the step that surprises people, and it is the step most councils skip. A decision rights matrix that says “Engineering Lead” or “Data Owner” is worthless because it does not tell you who to call when a pipeline breaks at 3 a.m. The matrix must name people: Jane Chen owns schema changes for customer data. Raj Patel approves tooling spend for the analytics platform. When decision rights live with roles, accountability evaporates. When they live with people, execution accelerates. David Ohnstad learned this the hard way when a major architecture decision stalled for six weeks because “the data owner” was on leave and nobody knew who had signing authority in their absence.

Step 4: Schedule Decision Meetings, Not Update Meetings. Most councils meet biweekly for 60 minutes and spend 50 of those minutes on status updates that could have been an email. The Decision Rights Framework inverts that structure. The council meets monthly for 90 minutes. The first 30 minutes are pre-reads: no verbal updates allowed, every agenda item requires a one-page memo circulated 48 hours before the meeting. The next 45 minutes are decision time: each agenda item gets 15 minutes for discussion and a recorded decision. The final 15 minutes are action review: who owns what follow-up, what is the decision deadline, what escalation path exists if the deadline slips. If a topic does not require a decision, it does not belong on the agenda.

Step 5: Publish a Decision Log Within 24 Hours of Every Meeting. This is the accountability mechanism that separates governing councils from talking shops. Every decision made in a council meeting gets logged in a public document with five fields: decision summary, rationale, owner, deadline, and escalation contact. The log lives in a location accessible to every employee who touches data—not buried in a SharePoint folder that requires three levels of permissions to access. The log is the council’s work product. If the log does not grow by at least two decisions per meeting, the council is not governing—it is coordinating, which means it is failing.

What Senior PMs Get Wrong About Data Council Participation

There is a widespread belief among senior product managers that data councils are where strategy gets set, so the goal is to attend, represent your domain, and influence the roadmap. That belief is expensive. It costs time, credibility, and execution speed. The reality is that data councils are where decisions get made or blocked, and the PMs who treat councils as influence forums rather than decision forums consistently lose to the PMs who show up with a pre-read, a specific ask, and a fallback position.

David Ohnstad has watched this play out repeatedly: a PM brings a data integration request to the council, frames it as strategic alignment, and spends 20 minutes building context for why the business needs this capability. The council nods. The discussion meanders. Someone raises a concern about schema compatibility. Someone else asks whether this overlaps with another team’s roadmap. The clock runs out. The decision gets tabled for the next meeting. Two months later, the integration still hasn’t shipped because the PM treated the council as a stakeholder to persuade rather than a decision body to navigate.

The PMs who succeed in council-governed environments do three things differently. First, they submit a decision memo 48 hours before the meeting that states the ask in one sentence, the business case in three bullets, and the fallback option if the ask gets rejected. Second, they pre-wire the decision by talking to key council members before the meeting to surface objections early and adjust the proposal accordingly. Third, they ask for a specific decision type—Own, Approve, or Consult—so the council knows what action is required. That approach treats the council as a governing body with finite decision bandwidth, not as an audience for a product pitch.

This distinction matters more as organizations scale AI and ML capabilities. According to Forrester’s 2024 AI Governance Report, 73% of enterprises now require some form of council-level approval for production AI deployments, up from 51% in 2023. The councils that handle those approvals efficiently operate with the Decision Rights Framework. The councils that do not are creating a bottleneck that slows AI adoption without improving AI quality, because the approval process checks for governance compliance but not for model effectiveness. That is the gap David Ohnstad on AI and enterprise SaaS explores in depth—councils that govern structure but not outcomes produce process overhead, not risk reduction.

The Three-Meeting Test: How to Know If Your Council Will Survive

By the third meeting, a data council reveals whether it will last or collapse. The pattern is consistent. High-performing councils make at least two recorded decisions per meeting by month three. They publish those decisions in a shared log within 24 hours. They enforce pre-read requirements and cancel meetings when no decisions are on the agenda. Low-performing councils spend meeting three litigating whether they need a mission statement revision, debating whether the charter should include more stakeholders, or discussing whether the council should meet weekly instead of biweekly. Those are symptoms of structural failure, and they are visible by meeting three.

Here is the test David Ohnstad uses to evaluate whether a council is on track or doomed: Can you name three decisions this council made in its first 90 days, who owned execution for each decision, and what measurable outcome changed as a result? If the answer is no, the council is already failing. It may continue meeting for another six months, but it is not governing—it is performing governance theater, which is worse than having no council at all because it creates the illusion of coordination while consuming senior leadership time.

The surprising part of the three-meeting test is that councils do not fail because they make bad decisions. They fail because they defer decisions. A council that approves a controversial schema change in meeting two and reverses it in meeting four is still governing. A council that tables the schema discussion for three consecutive meetings while gathering more input is not. Speed of decision-making is a better predictor of council longevity than quality of decision-making, because councils that move fast build credibility, and credibility attracts the decision rights that matter.

The Leadership Trap: Why Councils Need Coaching, Not Just Charters

Even councils with clear decision rights and strong charters collapse if the leader treats their role as facilitation rather than execution. The failure mode is subtle. The council chair runs efficient meetings, ensures every voice is heard, and maintains neutrality on contentious issues. The meetings feel productive. The decision log grows. But six months in, nothing has changed at the system level because the chair never pushed a decision through resistance, never escalated a blocker to the executive team, and never told a stakeholder that their concern was noted but would not delay the decision.

Effective council leadership is not neutral. It is opinionated, directive, and willing to make people uncomfortable in service of decision velocity. That does not mean dictatorial—it means the chair arrives at each meeting with a perspective on what the council should decide, advocates for that position, and calls the question when discussion reaches diminishing returns. The best council chairs David Ohnstad has worked with all shared one trait: they were willing to make a decision with 70% of the information rather than wait for 90%, because they understood that delayed decisions compound into organizational drag faster than imperfect decisions do.

This is where the intersection with leadership execution becomes critical. Data councils need coaching-based leadership to translate strategy into team accountability rather than relying on governance structures alone. A council can define decision rights perfectly, but if the chair cannot hold decision owners accountable for follow-through, the framework collapses. That accountability layer is what separates councils that govern from councils that coordinate, and it requires leadership skills that most organizations do not assess when selecting council chairs. The technical expertise to understand data architecture is table stakes. The willingness to drive decisions through friction is the differentiator.

When to Kill Your Data Council

Most organizations treat data council formation as a one-way door. Once you stand one up, the default is perpetual operation. That is a mistake. Councils should have explicit success criteria and sunset clauses. If the council has not made a decision that materially changed system behavior in the past 60 days, the council should be paused or disbanded. Governance infrastructure that exists without governing is organizational debt, and it accumulates interest in the form of meeting overhead and stakeholder fatigue.

Here is the contrarian claim that senior data leaders push back on: stop treating data councils as permanent governance structures—they are temporary forcing functions that should dissolve once decision rights are embedded in line roles. The goal of a high-performing data council is not to exist indefinitely. The goal is to clarify decision authority so thoroughly that the council itself becomes unnecessary. When schema approval authority is clearly documented, when tooling spend thresholds are widely understood, when cross-team data integration follows a published playbook, the council has succeeded by making itself redundant. Councils that operate for more than 18 months without evolving their scope or disbanding are usually solving a problem that no longer exists, or solving a problem that should have been solved by hiring decisions and org design rather than by coordination committees.

David Ohnstad has seen this pattern in woodworking projects and in data governance: the best structures are the ones you build once, use hard, and then dismantle when the need changes. He built bookshelves for his daughters’ rooms because they needed storage. When they no longer need those bookshelves, he will dismantle them and use the wood for something else. The same principle applies to councils. They are tools, not institutions. When the problem changes, the tool should change with it. Organizations that treat councils as permanent fixtures end up with governance structures that outlive their utility, which is how you end up with five councils that all claim authority over the same decision and none of them can tell you when they last made one.

The Measurement Problem Nobody Talks About

Even well-structured councils fail if they do not define what success looks like before the first meeting. Most councils track inputs—number of meetings held, attendance rate, topics discussed—but not outcomes. A high-performing council tracks decision velocity (average time from topic submission to decision), decision durability (percentage of decisions that remain unchanged after 90 days), and system impact (measurable change in data quality, access speed, or adoption resulting from council decisions). Those metrics are hard to instrument, which is why most councils do not track them. But without them, the council has no mechanism to know whether it is governing effectively or just meeting efficiently.

According to IDC’s 2024 Data Governance Benchmark, only 27% of organizations with active data councils measure decision velocity, and fewer than 15% track system-level impact of council decisions. The gap is not a measurement problem—it is a clarity problem. Councils that cannot define what outcome they are driving cannot measure whether they are succeeding. The fix is not better dashboards. The fix is defining success criteria in week one: by the end of Q2, this council will have approved or rejected at least 12 data integration requests with an average decision time of 10 days or less. That is a measurable outcome. “Improve data governance maturity” is not.

This measurement discipline also prevents councils from drifting into scope creep. When a council is accountable for decision velocity, members push back on agenda items that do not require decisions. When a council is accountable for system impact, members prioritize decisions that unblock high-leverage work over decisions that resolve minor process friction. The metrics create guardrails that keep the council focused on governing, not discussing. And when the metrics stop improving, the council has a forcing function to ask whether the structure still serves its purpose or whether it is time to disband and move decision rights into line roles.

The Integration Layer: Why Councils Fail Without Engineering Alignment

Data councils that operate in isolation from ML engineering teams create decisions that sound good in principle but collapse in practice. The failure mode is predictable: the council approves a data quality standard, engineering builds pipelines that meet the standard, and the ML team discovers six weeks later that the standard optimized for reporting accuracy but broke model training because it stripped out the variance the models needed to detect anomalies. The council made a decision. The decision was executed. The outcome was negative because the council did not have line of sight into how the data would actually be used.

This is why even the best data council structure fails without ML engineering teams having clear, aligned success metrics defined upstream. Councils govern data access, quality, and integration. Engineering teams build the pipelines and models that consume that data. If those two layers are not aligned on what success looks like, the council will make technically correct decisions that produce operationally wrong outcomes. The fix is not to expand the council to include ML engineers in every meeting—that creates the coordination bottleneck the council was designed to avoid. The fix is to define shared success metrics that both layers optimize for, and to require every council decision to include an engineering validation step before it gets logged as final.

David Ohnstad has seen this gap close when councils adopt a simple rule: no decision is final until an engineering lead confirms it is feasible within the current architecture and does not introduce latency, cost, or accuracy regressions. That validation step adds 48 hours to the decision cycle. It also prevents councils from approving changes that sound strategic but are structurally unshippable. The councils that skip this step end up with decision logs full of approved initiatives that engineering quietly deprioritizes because they would break production systems. That is governance failure masquerading as governance success, and it erodes trust faster than making no decisions at all.

FAQ: How to Run a Data Council That Drives Decisions

What is the most common reason data councils fail?

Data councils fail most often because they never define what decisions they own versus what they discuss. Without explicit decision rights mapped to specific outcomes, councils become coordination forums where topics get discussed but nothing changes. The fix is assigning Own, Approve, or Consult tiers to every topic in the council’s scope before the first meeting.

How do you measure whether a data council is effective?

Effective data councils track decision velocity (time from submission to resolution), decision durability (percentage unchanged after 90 days), and system impact (measurable improvement in data quality or access speed). Councils that only measure attendance or meeting frequency are tracking inputs, not outcomes, which means they cannot tell whether they are governing or just meeting.

When should a data council be disbanded?

A data council should be paused or disbanded if it has not made a decision that materially changed system behavior in the past 60 days. Councils exist to clarify decision authority and drive action. Once decision rights are embedded in line roles and operational playbooks, the council has succeeded by making itself unnecessary. Councils that operate indefinitely without evolving are organizational debt.

Two Takeaways and One Question

For practitioners: your data council will fail if you treat it as a forum to discuss strategy rather than a body to make decisions. Submit decision memos, not status updates. Ask for specific decision types—Own, Approve, or Consult—so the council knows what action you need. Pre-wire contentious decisions by talking to key members before the meeting. That approach treats the council as a governing body with finite bandwidth, which is what it is.

For leaders: councils are temporary forcing functions, not permanent institutions. Define success criteria before the first meeting, track decision velocity and system impact, and disband the council when decision rights are embedded in line roles. Governance structures that outlive their utility become coordination theater, and theater is expensive. The best council is the one that solves the problem so thoroughly it makes itself redundant.

When was the last time your data council made a decision that someone disagreed with, you moved forward anyway, and the outcome proved the decision was right? If you cannot name one, you are not governing—you are building consensus, which is not the same thing.

For more on this topic, visit David Ohnstad’s woodworking and making.

For more on this topic, see federated data architecture product management.

For more on this topic, see data product manager federated architecture.

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 Council Strategy: Why Most Companies Get It Wrong appeared first on David Ohnstad.

Photo by Houston SEO Directory on Unsplash

Why Federated Data Architectures Set PMs Up for Accountability Without Authority

Three weeks after launch, a VP asked David Ohnstad why the revenue attribution dashboard showed conflicting numbers between marketing and sales. The answer: two source systems, two definitions of “closed deal,” and zero enforcement mechanism to make either team change their schema. According to Gartner’s 2025 Data & Analytics Summit research, 68% of federated data initiatives fail within 18 months—not because the architecture is wrong, but because accountability lives with product managers who have no authority over the data contracts that determine success.

The Henkel case study published in CDO Magazine this April reveals the structural flaw most organizations ignore when they adopt decentralized analytics models. Henkel built governance-aligned data products across business units, celebrated the federated architecture as a win for agility, and then watched data product managers become scapegoats when cross-functional dashboards returned inconsistent results. The governance framework existed. The decentralized teams had autonomy. But nobody owned enforcement—the layer between policy and execution where data contracts either hold or break.

This is the accountability trap: data product managers are responsible for delivering trusted insights, but they don’t control the upstream data quality, the engineering sprint priorities that fix schema drift, or the governance mechanisms that enforce standard definitions across teams. When a dashboard shows conflicting revenue numbers, leadership blames the PM who shipped it—not the sales engineering team that changed a field definition without documentation, or the governance board that wrote a policy with no enforcement tooling.

The Failure Pattern: Responsibility Without Remediation Rights

Most federated data architectures fail at the same point: the moment a downstream data product needs to enforce a contract with an upstream source system. The organizational design gives PMs accountability for outcomes (accurate dashboards, trusted metrics, repeatable insights) while giving them zero formal authority over the systems that produce the data. When source data changes without warning—a field gets deprecated, a calculation changes, a new ETL pipeline introduces duplicates—the PM discovers the break only after users report incorrect results.

According to McKinsey’s 2024 State of Data & Analytics report, 73% of enterprises now use some form of federated or decentralized data architecture, up from 41% in 2022. The adoption curve is steep. But the same report found that only 28% of those organizations have implemented automated contract enforcement between data producers and consumers. The gap between architectural ambition and operational reality is where data product managers get crushed.

Here’s the specific failure mode David Ohnstad has seen play out across three organizations: a data product team builds a multi-source dashboard, defines clear data contracts with each upstream system, documents the schema requirements, and launches successfully. Six weeks later, an upstream team makes a “minor” change to improve their own reporting—renaming a field, adjusting a timestamp format, changing how nulls are handled. That change breaks the downstream dashboard. Users see errors or, worse, silent data corruption that produces plausible but incorrect results. The PM is held accountable for the broken product, but they have no standing to block the upstream change, no automated validation to catch the break before users see it, and no organizational mandate to enforce contract compliance across teams they don’t manage.

The traditional response is “better communication” or “tighter governance documentation.” Both are necessary. Neither solves the enforcement gap. A Slack thread asking an upstream team to please revert their schema change is not an enforcement mechanism. A governance wiki page documenting field definitions is not a contract that prevents breaking changes. The PM is accountable, but powerless to prevent the exact failures they’ll be blamed for.

The Contract Enforcement Layer Framework

Most organizations treat data contracts as documentation artifacts—Wiki pages, Confluence entries, or spreadsheet tabs that define what each field means and how it should be structured. That model assumes compliance is a cultural problem solved by clarity and goodwill. It’s not. Compliance is a tooling problem. If breaking a data contract doesn’t trigger an automated alert and block a deployment, the contract is a suggestion, not an enforceable agreement. David Ohnstad built a solution for this gap using a five-layer enforcement model he calls the Contract Enforcement Layer Framework—a system that moves data quality accountability from PMs to the pipeline itself.

Layer 1: Contract Registration. Every upstream data source must register a formal schema contract before a downstream product can depend on it. This is not documentation—this is a versioned API-style contract stored in a central registry that both producer and consumer teams reference. The contract defines field names, data types, null handling, expected ranges, update frequency, and the contact owner for each source. If a field isn’t in the registered contract, the downstream pipeline rejects it. This forces upstream teams to make schema changes explicit and visible, not silent and discovered later.

Layer 2: Automated Validation Gates. Every data ingestion pipeline runs contract validation before processing begins. If the incoming data violates the registered schema—wrong data type, unexpected null values, missing required fields, values outside expected ranges—the pipeline halts and triggers an alert to both the producer and consumer teams. This is the enforcement step most organizations skip. Without automated validation, a contract is just a document someone can ignore. With validation gates, breaking a contract stops the pipeline, surfaces the issue immediately, and prevents bad data from reaching downstream products.

Layer 3: Version-Controlled Schema Changes. When an upstream team needs to change a field definition, they must submit a schema change request through the contract registry. The request triggers notifications to every downstream consumer that depends on that field, includes a mandatory migration window (typically 30 days), and requires explicit acknowledgment from each consumer before the change can be deployed. This is the step that feels bureaucratic to agile-minded teams, but it’s the step that prevents the “I didn’t know that would break your dashboard” failure mode. Schema changes are treated like breaking API changes in a microservices architecture—documented, versioned, communicated, and coordinated.

Layer 4: Consumer-Side Escape Hatches. Even with contracts and validation, production systems sometimes need flexibility. The framework includes a temporary override mechanism: a downstream PM can accept schema violations for a defined period (maximum 7 days) to avoid blocking critical reporting, but the override triggers daily escalation alerts to leadership and must include a documented remediation plan. This prevents the contract from becoming a bureaucratic bottleneck while maintaining visibility and urgency around the compliance gap. The override is not a permanent workaround—it’s a bridge to a fix, and the escalation ensures it doesn’t become permanent technical debt.

Layer 5: Enforcement Dashboards and SLA Tracking. The final layer is observability. Every contract violation, schema change request, override activation, and pipeline halt gets logged in a centralized enforcement dashboard that tracks compliance by team, source system, and time period. This dashboard becomes the accountability mechanism leadership actually needs: instead of asking why a PM’s dashboard broke, they can see which upstream team violated a contract and how long the violation persisted. The PM is no longer the scapegoat—the enforcement layer makes accountability transparent and data-driven. According to Forrester’s 2025 Data Governance Trends report, organizations that implement automated contract enforcement reduce data quality incidents by 64% within the first year and cut mean time to resolution by 52%.

The counterintuitive step here is Layer 4—the escape hatch. Most governance frameworks try to make contracts rigid and absolute, which leads to teams bypassing the system entirely when they face production pressure. The escape hatch acknowledges reality: sometimes you need to ship a critical report even when upstream data is imperfect. But it makes the tradeoff visible, time-bound, and escalated so it doesn’t become a permanent workaround that erodes the entire contract model.

How David Ohnstad Built This at Scale Using arr-guardian

When David Ohnstad joined Veeam’s data product organization, the team was running a classic federated architecture: multiple business units owned their own data pipelines, a central analytics team provided shared infrastructure, and data product managers were responsible for building cross-functional dashboards that stitched together insights from sales, marketing, customer success, and product usage data. The model worked well for localized reporting within a single business unit. It failed catastrophically for any dashboard that needed consistent definitions across teams.

The breaking point came during a quarterly business review when the CEO asked why ARR (annual recurring revenue) numbers differed between the sales dashboard, the finance dashboard, and the customer success dashboard. Three teams, three source systems, three slightly different definitions of what constituted a “closed deal” and when revenue should be recognized. The discrepancies were small—2-3% variance—but the credibility damage was massive. Leadership questioned whether any of the data products could be trusted. The data product managers took the heat, even though they had documented the definitional differences and escalated the issue months earlier. Documentation without enforcement meant the issue persisted until it became a crisis.

David Ohnstad responded by building an enforcement layer using a tool he called arr-guardian—a contract validation system that sat between upstream source systems and downstream analytics pipelines. The tool implemented all five layers of the Contract Enforcement Layer Framework. Every source system that fed ARR data had to register a schema contract that defined exactly which fields contributed to the ARR calculation, how nulls were handled, what timestamp formats were required, and who owned the data quality for that source. The contract wasn’t a Wiki page—it was a JSON schema stored in a version-controlled repository that both the source system and the analytics pipeline referenced.

When the sales engineering team needed to change how they tracked renewal dates—a reasonable operational improvement—they submitted a schema change request through arr-guardian. The system automatically identified that the downstream ARR dashboard depended on that field, triggered notifications to the data product team and the finance analytics team, and required explicit acknowledgment before the change could deploy. The 30-day migration window gave downstream teams time to adjust their pipelines, test the new logic, and validate that the change wouldn’t break existing reports. The change still happened, but it happened with coordination and visibility instead of as a surprise that broke production dashboards.

The escape hatch layer proved essential during an end-of-quarter reporting crunch when a customer success data pipeline failed validation because an upstream CRM export changed a timestamp format. The pipeline would normally halt and block the report. The data product manager activated a 7-day override, allowing the report to proceed with a documented caveat, and escalated the timestamp issue to the CRM team with daily reminders until it was fixed. The override prevented a reporting crisis, the escalation ensured the issue didn’t get ignored, and the enforcement dashboard gave leadership full visibility into both the problem and the remediation plan. Three days later, the CRM team fixed the timestamp format, the override was deactivated, and the contract was back in compliance.

Within six months of deploying arr-guardian, the data product team reduced schema-related dashboard failures by 71%, cut mean time to detect data quality issues from 11 days to 4 hours, and shifted accountability conversations from “why did your dashboard break” to “which team violated the contract and when will it be fixed.” The tool didn’t eliminate all data quality issues—upstream systems still had bugs, requirements still changed, and edge cases still surfaced. But it moved enforcement from the PM’s Slack DMs to an automated system with clear accountability, documented exceptions, and transparent tracking. Leadership stopped blaming data product managers for breaks they didn’t cause and couldn’t prevent. Instead, they started holding source system owners accountable for maintaining the contracts their downstream consumers depended on.

Stop Treating Data Contracts as Documentation

Most organizations treat data contracts as a governance documentation exercise—something to fill out during planning sessions and reference when things break. That model assumes the problem is awareness: if everyone knows what the contract says, compliance will follow. That assumption is wrong. Compliance doesn’t fail because teams don’t know the rules. It fails because breaking the rules has no immediate consequence, and following the rules has no immediate reward. A downstream PM discovering a broken dashboard three weeks after an upstream schema change is not an enforcement mechanism—it’s a delayed failure signal that punishes the wrong person.

The contrarian claim David Ohnstad makes is this: data contracts without automated enforcement are worse than no contracts at all, because they create the illusion of accountability while systematically setting data product managers up to fail. A documented schema that nobody validates is a lie the organization tells itself—a promise of data quality with no mechanism to keep that promise. When the dashboard breaks, leadership points to the contract and asks the PM why they didn’t enforce it. But the PM has no enforcement authority. They can’t block an upstream deployment. They can’t require schema change notifications. They can’t automatically halt a pipeline when validation fails. The contract gave them accountability without giving them the tools to deliver on it.

According to IDC’s 2025 Data Trust and Quality Survey, 82% of enterprises report having documented data contracts or schema definitions, but only 19% have automated systems that validate those contracts before data enters production pipelines. The 63-point gap between documentation and enforcement is where data product managers get trapped. They’re responsible for delivering trusted insights using data they don’t control, from systems they don’t manage, with contracts they can’t enforce. When the inevitable failure happens, the documented contract becomes evidence of the PM’s negligence rather than evidence of a broken enforcement model.

The solution is not better documentation. The solution is treating data contracts like API contracts in a microservices architecture: versioned, validated, and enforced automatically. When a microservice tries to call another service with an incompatible request format, the API gateway rejects the call immediately—before bad data enters the system. The same model applies to data pipelines. When an upstream system sends data that violates the registered schema, the pipeline should reject it immediately and alert both teams. That’s enforcement. Everything else is just paperwork.

What is the difference between a data contract and a schema definition?

A schema definition describes the structure of a dataset—field names, data types, and formats. A data contract is a versioned, enforceable agreement between a data producer and consumer that includes the schema plus validation rules, update frequency, ownership, and what happens when violations occur. Contracts add accountability; schemas just document structure.

How do you enforce data contracts in a federated architecture?

Enforcement requires automated validation gates that run before data enters downstream pipelines. When incoming data violates the registered contract, the pipeline halts and triggers alerts to both producer and consumer teams. This prevents bad data from reaching production and makes contract violations immediately visible rather than discovered weeks later through broken dashboards.

Why do data product managers get blamed when upstream data changes break dashboards?

Because most organizations give PMs accountability for data quality outcomes without authority over upstream systems or enforcement mechanisms. When source data changes without coordination, PMs discover the break only after users report it. Without automated contract validation, the PM has no way to prevent or catch the failure before it impacts production reporting.

For more on how AI agents complicate this enforcement layer when they autonomously generate insights without validation checkpoints, see David Ohnstad on AI and enterprise SaaS. For perspectives on building leadership structures that support federated teams without requiring managers to be technical experts, explore David Ohnstad’s woodworking and making where similar principles of clear contracts and enforcement mechanisms apply to physical builds.

Two Takeaways and One Question

For practitioners: If you’re a data product manager in a federated architecture, your first priority is not building dashboards—it’s building the enforcement layer that makes data contracts real. Document the schema, yes. But also implement automated validation gates, version-controlled change management, and observability dashboards that track contract compliance by team. Without enforcement tooling, you’re accountable for failures you can’t prevent. Build the tooling or escalate the gap to leadership as a blocker to trusted data products.

For leaders: Stop holding data product managers accountable for data quality issues caused by upstream teams that violate undocumented or unenforced contracts. If your organization has adopted a federated data architecture, you must invest in the enforcement layer—automated validation, schema registries, change notification systems, and compliance tracking. Accountability without authority is a recipe for scapegoating. Either give PMs the enforcement tools they need, or restructure accountability to include the source system owners who control the data quality you’re demanding.

When did you last audit whether your data contracts are actually enforced—or just documented in a Wiki that nobody checks until a dashboard breaks in production?

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 Federated Data Architectures: Accountability Without Authority appeared first on David Ohnstad.

Photo by Helcim Payments on Unsplash

Why Data Product Managers Are Being Set Up to Fail in Federated Architectures

Henkel’s data product team spent eighteen months building a governance-aligned, decentralized analytics platform that shipped on schedule, under budget, and met every stakeholder requirement documented at kickoff. Nine months after launch, the platform was generating reports nobody trusted. The culprit wasn’t bad data or poor UX—it was an organizational design that gave the data product manager accountability for outcomes without authority over the upstream systems that determined data quality. According to Gartner’s 2024 Data and Analytics Leadership Survey, 68% of federated data initiatives fail to deliver sustained business value within two years, and the failure pattern is consistent: responsibility without enforcement power.

This isn’t a Henkel problem. It’s the structural flaw in how most organizations are adopting federated data architectures in 2026. The model sounds rational: decentralize analytics ownership to the teams closest to the business context, centralize governance to maintain standards, and assign a data product manager to orchestrate the whole system. But here’s what that actually means in practice—the PM owns the quality promise to stakeholders, but doesn’t control the engineering backlog that fixes upstream data issues, can’t enforce schema contracts on source systems owned by other teams, and has no recourse when a domain team decides their local priorities matter more than platform-wide data integrity. You’re accountable for a product built on infrastructure you don’t control, fed by pipelines you can’t prioritize, governed by standards you can’t enforce.

David Ohnstad saw this exact failure pattern play out at scale while building cross-functional data products at Veeam. A core analytics pipeline depended on event data from twelve microservices, each owned by a different engineering team. When a breaking schema change shipped in one service without coordination, the downstream reporting layer silently started dropping 30% of events. The data product manager discovered the issue six weeks later—not through automated validation, but because a finance analyst noticed revenue reconciliation numbers didn’t match. The PM escalated. The service team acknowledged the issue. And then the fix sat in their backlog for eleven weeks because their VP prioritized feature velocity over cross-team data contracts. The PM had accountability to finance stakeholders, but zero authority to move that ticket up the priority stack. That’s not a process failure. That’s an org design failure masquerading as a coordination problem.

The Authority Gap: Why Federated Models Systematically Undermine Data Product Managers

The promise of federated data architectures is distribution of ownership—domain teams know their data best, so let them own the products built on it. The reality is distribution of accountability without distribution of enforcement mechanisms. When a centralized data team owns the warehouse, they control schema evolution, pipeline SLAs, and quality gates. When you federate that ownership, those controls fragment across teams with conflicting priorities. The data product manager becomes the coordinator, but coordination only works when all parties have aligned incentives. In practice, the incentives are misaligned by design.

Consider the classic federated setup: a marketing domain team owns customer event tracking, a sales domain team owns CRM pipelines, and a centralized data product manager builds a unified customer 360 view. Marketing ships a new tracking schema to support a campaign launch. Sales updates field definitions to match their new territory structure. Both changes are rational within their domain context. Both break the customer 360 product. The data product manager finds out when the executive dashboard shows duplicate customer records and missing attribution data. Who fixes it? Marketing’s backlog is driven by campaign deadlines. Sales engineering prioritizes deal flow tooling. The data PM can file tickets, attend standups, and escalate to leadership—but unless there’s a forcing function that makes data contract compliance more important than local team velocity, those fixes don’t ship until the next planning cycle. Meanwhile, the PM owns the apology to stakeholders and the damage to the product’s credibility.

This isn’t a coordination problem you solve with better Slack communication or more detailed runbooks. It’s a structural problem: federated architectures distribute data ownership but leave enforcement centralized in a role with no enforcement authority. According to McKinsey’s 2025 report on data mesh adoption, organizations that successfully scale federated models share one characteristic—they pair decentralized ownership with enforceable data contracts, and they give data product managers the tooling and organizational backing to halt pipeline changes that violate those contracts. The ones that fail treat governance as a set of guidelines and coordination as the PM’s job. Guidelines without enforcement are suggestions. And suggestions don’t stop breaking changes from shipping.

The Enforcement Layer Framework: Four Gates Every Federated Architecture Needs

If you’re running a federated data architecture and your data product manager can’t block a breaking change from reaching production, you don’t have governance—you have documentation. Real governance requires an enforcement layer that operates before changes hit downstream consumers, not after stakeholders discover the breakage. This is a four-gate model: contract definition, pre-deployment validation, automated rollback, and accountability escalation. Every gate must be automated and non-negotiable. If any gate is optional or subject to “we’ll fix it later,” the framework collapses.

Gate one: contract definition at the interface level. Every data source feeding your federated platform must publish a versioned schema contract—not in a wiki, in a machine-readable format that downstream consumers can programmatically validate against. This isn’t an API spec buried in Confluence. It’s a YAML or JSON schema file committed to version control alongside the service code, with mandatory fields, types, and deprecation timelines. If a domain team wants to change a field from string to integer, the contract update gets reviewed by every downstream consumer before the change ships. Not after. Before. This requires tooling—David Ohnstad built enforcement automation using arr-guardian specifically to catch contract violations before they reached production pipelines—but more importantly, it requires organizational mandate. The contract file is the source of truth. If the code doesn’t match the contract, the code doesn’t deploy.

Gate two: pre-deployment validation that runs in CI/CD before any schema-impacting change merges. This is where the enforcement actually happens. Every pull request that touches a data-producing service gets automatically scanned against the published contract. If the change breaks backward compatibility without a coordinated deprecation plan, the build fails. Not a warning. A hard failure. This is the gate that prevents the “we shipped a breaking change and didn’t realize it” scenario. The challenge here isn’t technical—contract validation libraries exist for every major data format—it’s political. Engineering teams will push back. They’ll argue that blocking deploys slows them down, that they can coordinate manually, that the data team is imposing bureaucracy on their velocity. This is where the data product manager’s authority matters. If the PM can’t hold the line here—if leadership sides with feature velocity over data contract compliance—the gate becomes a suggestion, and the enforcement layer fails.

Gate three: automated rollback with downstream consumer notification. When a breaking change does make it to production despite gates one and two—and it will, because someone will manually override a validation or exploit a gap in the contract spec—the system must detect the violation and roll back the change automatically. This requires continuous validation in production, not just at deployment time. Monitor schema conformance at the pipeline ingestion layer. When a field that’s supposed to be non-null starts returning nulls, or an enum starts accepting values outside the defined set, the pipeline halts ingestion from that source and triggers an alert to both the upstream producer and the downstream data product manager. The producer gets thirty minutes to acknowledge and fix. If they don’t, the pipeline reverts to the last known good state and pages the on-call engineering lead. This is the safety net for catastrophic failures. It doesn’t prevent all breakage, but it prevents silent data corruption—the scenario where bad data flows downstream for weeks before anyone notices.

Gate four: accountability escalation with executive visibility. When gates one through three fire repeatedly for the same upstream team, that’s not a technical problem—it’s a prioritization problem. The enforcement layer must surface this pattern to leadership, not as a ticket in Jira, but as a metric on the executive dashboard. Track contract violation frequency by domain team. Track median time to resolution. Track downstream impact in terms of broken dashboards, delayed reports, and stakeholder complaints. Make it visible. The data product manager shouldn’t have to escalate manually every time a team deprioritizes a data fix—the system should escalate automatically when a team crosses a threshold. This is what makes the framework sustainable. Without executive visibility, enforcement becomes a negotiation every single time. With visibility, enforcement becomes a policy.

What This Looks Like When It Fails: The Silent Corruption Scenario

David Ohnstad watched a version of this fail at a SaaS company running a federated analytics platform across five business units. Each unit owned their domain data. The centralized data product team built cross-functional dashboards for executive reporting. The contract: domain teams would maintain backward compatibility for any field used in executive dashboards, and they’d provide thirty days’ notice before deprecating a field. The enforcement: a monthly coordination meeting where the data PM reviewed upcoming changes with domain leads. No automated validation. No CI/CD gates. Just a meeting and a shared spreadsheet.

Three months in, the customer success team rebuilt their ticketing schema to support a new case escalation workflow. They deprecated four fields and added six new ones. The change made sense for their domain—it improved how support managers tracked escalations. They mentioned it in the coordination meeting. The data PM flagged that two of the deprecated fields fed the executive customer health dashboard. Customer success acknowledged it and said they’d back-fill the data using the new schema. The change shipped. The back-fill script ran. The dashboard looked fine in QA.

Six weeks later, the CFO asked why the customer health score had improved 14% quarter-over-quarter when revenue and churn were both flat. The data PM investigated. The back-fill script had worked—technically. But the new schema tracked escalations at a different granularity than the old one, and the conversion logic introduced a subtle bias that inflated the health score for customers with frequent low-severity tickets. The old schema counted each ticket. The new schema counted each escalation event, and a single ticket could generate multiple events if it escalated through multiple tiers. The dashboard was summing events, not tickets, and interpreting higher event counts as higher engagement. Nobody caught it because the schema change didn’t break anything—it just quietly changed what the data meant.

That’s the failure mode when enforcement is manual. The customer success team didn’t act maliciously. They coordinated in good faith. The data PM reviewed the change. The back-fill worked. But without automated contract validation, there was no forcing function to surface that the semantic meaning of the field had changed even though the data type and field name stayed the same. The dashboard kept running. The executive team made decisions on inflated data for six weeks. When the error surfaced, the customer success team was already three sprints past the change, and rolling it back would have broken their internal escalation workflows. The data PM owned the apology. The CFO lost trust in the dashboard. And the customer success team learned that data contract violations have no consequences—because by the time the consequences surfaced, the violating team had already moved on.

The Tooling Gap: Why Most Organizations Can’t Enforce Even If They Want To

The enforcement layer framework above assumes you have tooling that can validate contracts, halt pipelines, and surface violations automatically. Most organizations don’t. They have data catalogs that document schemas after the fact. They have observability platforms that detect outages. They have governance committees that review policies quarterly. What they don’t have is enforcement infrastructure that operates in real time, at deployment, before breaking changes reach production. This is the tooling gap, and it’s why federated architectures fail even when leadership agrees that data contracts should be enforceable.

Building that tooling in-house is a six-to-twelve-month engineering effort if you’re starting from scratch. You need contract schema validation libraries for every data format your organization uses—JSON, Avro, Protobuf, Parquet, whatever. You need CI/CD integrations that run validation on every pull request that touches a data-producing service. You need runtime monitoring that continuously checks whether production data conforms to published contracts. You need alerting and rollback automation that triggers when violations are detected. And you need executive dashboards that surface violation patterns so leadership can see which teams are systematically deprioritizing data quality. That’s not a side project for the data PM. That’s a dedicated platform engineering team.

Most organizations don’t fund that team because the failure mode is slow and silent. When a product feature breaks, customers complain immediately. When a data contract breaks, the downstream impact doesn’t surface for weeks—by which time the violating team has shipped three more features and nobody wants to roll back. So leadership prioritizes feature velocity, the enforcement tooling never gets funded, and the data PM is left coordinating manually with Slack messages and spreadsheets. According to Forrester’s 2024 study on data governance adoption, only 23% of organizations running federated data architectures have automated contract enforcement at the CI/CD layer. The rest rely on documentation, training, and coordination meetings. And 71% of those organizations report that data quality issues are their top barrier to analytics adoption.

This is why David Ohnstad built arr-guardian as an open-source enforcement toolkit specifically for federated architectures—it’s the tooling layer that most organizations need but won’t fund internally until after a major data quality incident forces the conversation. The tool validates schema contracts in CI/CD, monitors runtime conformance, and surfaces violations with automated rollback triggers. It’s not a replacement for organizational discipline—you still need executive buy-in and clear accountability structures—but it removes the excuse that enforcement is too hard to automate. If your data PM is manually tracking contract violations in a spreadsheet, the problem isn’t that they’re not coordinating hard enough. The problem is that you’re asking them to enforce a policy without giving them enforcement tools.

Why This Model Fails at Scale: Incentive Misalignment by Design

Even with perfect tooling, federated architectures systematically undermine data product managers because the incentive structures are misaligned by design. Domain teams are measured on feature velocity and domain-specific outcomes. The marketing analytics team gets promoted for shipping campaign attribution dashboards that drive ad spend efficiency. The sales engineering team gets rewarded for improving CRM pipeline visibility that shortens deal cycles. The centralized data product manager is measured on cross-functional data quality and stakeholder trust in shared platforms. These incentives don’t just diverge—they actively conflict.

When the marketing team needs to ship a new attribution model to support a product launch, and that model requires a schema change that breaks backward compatibility with the cross-functional customer 360 dashboard, what happens? If the PM blocks the change, they’re seen as slowing down a revenue-driving initiative. If they let it through, they own the broken dashboard and the stakeholder complaints. The marketing team isn’t acting badly—they’re optimizing for their incentives, which prioritize domain impact over platform stability. The PM is optimizing for platform stability, which requires domain teams to slow down and coordinate. These incentives don’t resolve through better communication. They resolve through organizational design that makes data contract compliance a first-class metric in how domain teams are evaluated.

This is the core problem with most federated models: they distribute ownership without distributing accountability for cross-functional impact. Domain teams own their data products, but they’re not accountable for how breaking changes affect downstream consumers outside their domain. The data PM is accountable for downstream impact, but doesn’t own the systems that create it. According to a 2025 Harvard Business Review analysis of data mesh failures, the single strongest predictor of success was whether data contract compliance appeared in domain team performance reviews. Not whether governance policies existed. Not whether tooling was in place. Whether individual contributors and engineering managers were held accountable for cross-functional data quality in their promotion packets and performance evaluations.

If your organization runs a federated data architecture and “maintains backward compatibility for shared data contracts” isn’t a line item in your domain engineering teams’ quarterly goals, you don’t have a federated architecture—you have a coordination theater. The data PM can escalate, negotiate, and coordinate all they want. But without accountability structures that make data contract compliance matter to domain teams’ career progression, those teams will rationally prioritize local velocity over platform stability every single time. And the PM will keep owning failures they can’t prevent.

Stop Hiring Data Product Managers to Be Scapegoats

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.

Real product ownership means you control the levers that determine product quality. For a feature PM, that’s the backlog, the design, and the engineering priorities. For a data product manager in a federated architecture, the equivalent levers are schema contracts, pipeline priorities, and deployment gates. If you don’t control those, you don’t own the product—you own the apology when it breaks. And the breakage is inevitable, because you’re running a system where local incentives favor velocity over coordination, and enforcement is optional. According to Pragmatic Institute’s 2024 product management benchmarks, data PMs in federated organizations report 43% lower role satisfaction and 31% higher turnover compared to PMs in centralized data architectures. The reason isn’t workload or compensation—it’s the mismatch between accountability and authority.

Organizations keep making this mistake because the failure is slow. You hire a talented data PM, give them ownership of cross-functional analytics platforms, and expect them to coordinate across domain teams to maintain quality. For the first six months, it works—momentum from the initial build, stakeholder excitement, and goodwill from domain teams carry the product forward. Then the first breaking change ships. The PM coordinates a fix. Then another. Then three in one quarter. The coordination overhead grows. The domain teams start to see the PM as a bottleneck. The PM escalates to leadership, who tells them to “work more closely with engineering.” The PM builds runbooks, hosts coordination meetings, sends weekly emails about upcoming changes. And the product slowly degrades because coordination scales linearly with team count, but breaking changes scale exponentially with integration surface area.

Eighteen months in, the PM either leaves for a role with real ownership, or they accept that their job is to manage decline and apologize to stakeholders. The organization blames the PM for “not being technical enough” or “not building strong enough relationships with domain teams,” when the actual problem is that they were set up in a role with responsibility but no enforcement authority. If you’re designing a federated data architecture and you’re not prepared to give your data PM automated contract enforcement, executive backing to halt violating deployments, and accountability structures that make domain teams care about cross-functional impact—don’t hire a product manager. Hire a coordinator, pay them less, and stop pretending the role has ownership.

What is the biggest mistake organizations make when setting up federated data architectures?

The most common mistake is distributing ownership of data products to domain teams without implementing enforceable schema contracts and giving the central data product manager the authority to block breaking changes before deployment. This creates accountability without enforcement power, setting the PM up to fail when domain teams prioritize local velocity over cross-functional data quality.

How do you enforce data contracts in a federated architecture?

Effective contract enforcement requires four automated gates: machine-readable contract definitions versioned in source control, pre-deployment validation in CI/CD pipelines that blocks non-conforming changes, runtime monitoring with automated rollback when violations reach production, and executive dashboards that surface contract violation patterns by team. Manual coordination through meetings and documentation fails at scale.

Why do data product managers have higher turnover in federated organizations?

Data PMs in federated architectures often have accountability for data quality and stakeholder outcomes but lack authority over the upstream systems, engineering backlogs, and deployment processes that determine whether quality standards can be met. This mismatch between responsibility and control leads to role frustration and burnout, especially when breaking changes from domain teams create failures the PM can’t prevent but must own.

The path forward isn’t abandoning federated architectures—decentralized ownership has real benefits when domain teams are close to the business context. But it requires organizational honesty about what enforcement actually takes. If you’re building a federated data platform, fund the enforcement tooling before you hire the PM. Embed data contract compliance in domain team performance metrics before you distribute ownership. And make it clear to leadership that coordination is not a substitute for authority—if the PM can’t block a bad deployment, they can’t own the product quality.

For practitioners navigating this right now: audit whether you actually have enforcement authority or just coordination responsibility. Can you halt a schema change that violates a published contract? Can you escalate a pattern of violations and get engineering priorities changed? If the answer is no, you’re not a product manager in this role—you’re a coordinator with an accountability problem. Renegotiate the scope, get the tooling and org backing you need, or find a role where ownership and authority actually align. For leaders: if your data PM is spending more than 20% of their time coordinating manual fixes for upstream breaking changes, your architecture has an enforcement gap. Close it with tooling and accountability structures, or accept that your data products will slowly degrade until stakeholder trust collapses.

When was the last time you checked whether your data product manager can actually prevent the failures they’re held accountable for—or are you just measuring how well they apologize when coordination inevitably fails?

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

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 Federated Data Architectures: Why PMs Fail appeared first on David Ohnstad.

The Growing Concern Over AI and Data Privacy

AI relies heavily on vast amounts of data to function effectively. Machine learning algorithms improve their accuracy and efficiency by analyzing user interactions, preferences, and behaviors. While this process enhances digital experiences, it also raises significant privacy risks. Users often feel uncomfortable when they realize how much personal information is being tracked and processed without their explicit consent.

Major data breaches, algorithmic biases, and instances of AI misuse have only heightened public skepticism. Consumers are no longer satisfied with vague assurances of security—they expect clear policies, control over their data, and ethical AI implementation. For product teams, the challenge is to balance the benefits of AI-driven personalization with the need to protect user privacy.

Transparency as the Foundation of Trust

One of the most effective ways product teams can build trust with users is through transparency. When users understand what data is being collected, why it is needed, and how it will be used, they are more likely to feel comfortable engaging with AI-driven products. Companies must move beyond dense privacy policies and legal jargon, instead providing clear, concise explanations that are easily accessible.

Privacy dashboards are a powerful tool for improving transparency. Giving users the ability to review and manage their data settings fosters a sense of control. Allowing them to opt out of specific data collection practices or adjust personalization settings can strengthen trust while still enabling AI to deliver valuable insights.

Ethical AI: Prioritizing Fairness and Accountability

AI has the potential to reinforce biases if not properly managed. Biased training data can lead to discriminatory outcomes, affecting hiring decisions, lending approvals, and content recommendations. Product teams must take responsibility for ensuring that AI models are fair, unbiased, and aligned with ethical guidelines.

One approach to mitigating bias is through diverse and representative datasets. Ensuring that AI systems are trained on inclusive data sets helps prevent discriminatory patterns from emerging. Regular audits and algorithmic transparency initiatives can further enhance accountability, making it easier to identify and correct biases before they cause harm.

Another critical aspect of ethical AI is explainability. Users should have insight into how AI-driven decisions are made, particularly in high-stakes scenarios such as healthcare, finance, and law enforcement. When AI recommendations impact people’s lives, they deserve to know the reasoning behind those decisions. Providing explanations in a user-friendly manner builds credibility and trust.

Data Minimization: Collecting Only What’s Necessary

Many privacy concerns stem from the excessive collection of user data. In an effort to maximize AI capabilities, companies often gather more information than they actually need. This not only increases privacy risks but also creates unnecessary liabilities in the event of a data breach.

A privacy-first approach to AI development involves data minimization—collecting only the data that is essential for delivering the intended service. By reducing the volume of personal information stored, companies can mitigate risks while demonstrating a commitment to responsible data handling.

Techniques such as anonymization and differential privacy can further enhance security. Anonymized data removes personally identifiable information, making it more difficult to trace data back to an individual. Differential privacy introduces mathematical noise into datasets, preserving patterns while preventing specific user information from being extracted.

User Consent: Making Privacy a Shared Decision

One of the most important principles in data privacy is consent. Users should have the ability to make informed choices about how their data is used. This means implementing clear, opt-in mechanisms rather than relying on default data collection practices.

Granular consent options allow users to customize their preferences based on their comfort levels. Some may be willing to share anonymized data for product improvement, while others may prefer strict privacy settings. By offering flexible choices, product teams can respect individual privacy preferences while maintaining functionality.

Beyond one-time consent, companies should regularly update users on changes to data policies and AI usage. Sending notifications about policy updates and giving users an opportunity to review their settings reinforces the idea that privacy is an ongoing priority.

Security as a Cornerstone of AI Development

Even the most ethical AI practices can be undermined by weak security measures. Data breaches not only expose sensitive user information but also erode trust in a company’s ability to protect its customers. To safeguard AI-driven products, security must be an integral part of the development process.

End-to-end encryption ensures that data remains protected during transmission and storage. Multi-factor authentication (MFA) adds an extra layer of security, preventing unauthorized access even if login credentials are compromised. Regular security audits, penetration testing, and vulnerability assessments help identify weaknesses before they can be exploited.

AI itself can be leveraged to enhance security. Machine learning algorithms can detect unusual patterns in user behavior, identifying potential fraud or cyber threats in real time. Automated threat detection allows companies to respond proactively to emerging risks, preventing data breaches before they occur.

Regulatory Compliance: Navigating Global Privacy Standards

Governments and regulatory bodies are tightening their grip on data privacy, imposing stricter compliance requirements for companies that handle user information. Regulations such as the General Data Protection Regulation (GDPR) in Europe and the California Consumer Privacy Act (CCPA) in the United States set clear guidelines for how businesses should manage user data.

Product teams must stay informed about evolving privacy laws and ensure that their AI-driven products align with legal standards. Compliance should not be treated as an afterthought—it should be built into the product development process from the outset.

Data sovereignty is another consideration for global businesses. Some regulations require that user data be stored and processed within specific geographic regions. Understanding and adhering to these requirements is essential for maintaining compliance and avoiding legal complications.

The Future of AI and Data Privacy

As AI continues to advance, the conversation around data privacy will only intensify. Emerging technologies such as federated learning and homomorphic encryption hold promise for preserving privacy while still allowing AI models to learn from data. These innovations enable machine learning without requiring direct access to raw user information.

The role of AI ethics committees and privacy advocates will also become more prominent. Companies that proactively engage in ethical discussions and collaborate with regulators, researchers, and user advocacy groups will be better positioned to earn consumer trust.

Ultimately, the success of AI-driven products depends on maintaining a delicate balance between innovation and responsibility. Product teams must remain committed to ethical AI, solid security, and transparent data practices to foster trust in an era where digital privacy is a growing concern.

Conclusion

Data privacy in the age of AI is one of the most pressing challenges for product teams. While AI offers unparalleled opportunities for personalization and efficiency, it also introduces significant risks if privacy is not adequately protected. Companies that prioritize transparency, ethical AI, and user control will not only comply with regulations but also build stronger relationships with their customers. Trust is the foundation of successful digital products, and by integrating privacy-first strategies, businesses can navigate the evolving AI landscape while respecting the rights and expectations of their users.

More from David Ohnstad: David Ohnstad on AI and enterprise software

The post Data Privacy in the Age of AI: How Product Teams Can Build Trust with Users appeared first on David Ohnstad.

The Complexity of Cross-Platform Development

Cross-platform digital product development is inherently more challenging than building for a single platform. Each operating system has its own specifications, frameworks, and user interface guidelines, which means developers must account for multiple sets of technical requirements. A feature that works flawlessly on iOS may require significant modifications to perform equally well on Android. Similarly, web applications may behave differently on various browsers due to inconsistencies in how HTML, CSS, and JavaScript are rendered.

The diversity of screen sizes further complicates development. A layout optimized for a large desktop monitor may not translate well to a mobile device with limited screen real estate. Developers must create responsive designs that adapt dynamically to different screen sizes and resolutions while maintaining usability. This requires meticulous planning and testing across a wide range of devices and configurations.

Choosing the Right Technology Stack

Selecting the right development framework is crucial when building cross-platform digital products. Native development offers the best performance and deep integration with device capabilities but requires separate codebases for each platform. This approach increases development time and costs but provides superior performance and user experience.

Hybrid frameworks such as React Native, Flutter, and Xamarin allow developers to write a single codebase that runs across multiple platforms. While this approach reduces development effort and ensures faster time-to-market, it can come with trade-offs in performance and access to platform-specific features. Businesses must carefully weigh the pros and cons of each approach to determine the best fit for their product requirements.

Ensuring a Consistent User Experience

User experience is one of the most critical factors in cross-platform development. Consistency in design, navigation, and functionality is essential to ensure that users can smoothly transition between devices without confusion. However, achieving this consistency requires more than just copying the same interface across platforms. Each platform has its own design principles that must be respected.

For instance, Android and iOS have distinct navigation patterns, gestures, and UI components. A successful cross-platform product must feel native on both operating systems while maintaining a cohesive brand identity. This means adhering to platform-specific guidelines while using a unified design language that ties the experience together.

Another key consideration is performance optimization. A product that loads quickly and responds smoothly on one platform should offer the same experience on others. Developers must optimize code to reduce lag, improve load times, and ensure smooth animations across devices. This often requires platform-specific optimizations to achieve the best possible performance.

Managing Platform-Specific Limitations

Even with modern cross-platform frameworks, platform-specific limitations remain a significant challenge. Certain hardware features, such as biometric authentication, NFC, or advanced camera functionalities, may be available on one platform but not another. Developers must implement fallback solutions or alternative features to ensure that users do not experience functionality gaps.

Additionally, some platforms impose restrictions on data storage, security, and permissions that may not align with other ecosystems. Compliance with different privacy regulations across platforms adds another layer of complexity. Businesses must carefully navigate these limitations while maintaining security and performance standards.

The Role of Testing and Quality Assurance

Testing is a crucial component of cross-platform development. Unlike single-platform applications, cross-platform products must undergo extensive testing across multiple devices, operating systems, and network conditions. Automated testing frameworks help identify inconsistencies, but manual testing is still necessary to catch subtle usability issues that automated scripts may overlook.

User acceptance testing (UAT) plays an essential role in ensuring that real users have a positive experience. Beta testing on diverse devices allows product teams to gather feedback and identify platform-specific issues before the full release. This iterative testing approach helps refine the product and address issues that could negatively impact the user experience.

Performance testing is equally important. Different devices have varying hardware capabilities, meaning an application that runs smoothly on a flagship smartphone might struggle on an older device with limited processing power. Load testing, stress testing, and network simulation tests help optimize the application for a broad range of scenarios.

Optimizing for Scalability and Future Growth

Cross-platform digital products must be built with scalability in mind. As user bases grow, the infrastructure supporting the product must be capable of handling increased demand. Cloud-based architectures enable smooth scaling by distributing workloads dynamically based on traffic patterns. Serverless computing and containerization further enhance scalability by ensuring efficient resource allocation.

Additionally, future-proofing a cross-platform product requires ongoing updates and optimizations. Emerging technologies such as augmented reality (AR), artificial intelligence (AI), and voice interfaces are reshaping user expectations. Companies must anticipate these trends and build products with flexibility to integrate new features as technology evolves.

Addressing Security and Compliance Challenges

Security is a top priority in cross-platform development. Each platform has its own security guidelines, and failing to adhere to them can lead to vulnerabilities that expose user data. Secure authentication methods, end-to-end encryption, and compliance with global data protection laws must be integrated into the development process from the outset.

Regulatory compliance varies across regions, adding another layer of complexity. The General Data Protection Regulation (GDPR) in Europe and the California Consumer Privacy Act (CCPA) impose strict guidelines on data handling and user privacy. Cross-platform products must comply with these regulations while maintaining smooth functionality.

Security patches and updates must also be deployed efficiently. With multiple platforms in play, ensuring that all users receive security fixes simultaneously is essential. A well-coordinated release strategy minimizes risks and ensures that users remain protected across devices.

The Future of Cross-Platform Development

The landscape of cross-platform development is continuously evolving. Advances in AI-driven development tools, improved frameworks, and more powerful cloud infrastructure are making it easier to build high-performance cross-platform products. Low-code and no-code platforms are also gaining traction, allowing businesses to accelerate development cycles while maintaining quality.

The demand for smooth multi-device experiences will only continue to grow. As the Internet of Things (IoT) expands, products will need to function across an even broader ecosystem of devices, from smartwatches to connected home appliances. Businesses that invest in cross-platform development strategies today will be better positioned to meet the digital expectations of tomorrow.

Conclusion

Building cross-platform digital products requires a strategic balance of technology selection, user experience optimization, performance tuning, and security enforcement. While challenges such as platform-specific limitations and scalability concerns remain, modern frameworks and best practices make it possible to deliver high-quality, consistent experiences across devices. Companies that embrace these challenges with a forward-thinking approach will be well-equipped to create innovative, user-friendly products that thrive in an increasingly interconnected digital world.

More from David Ohnstad: David Ohnstad on AI and enterprise software

The post Building Cross-Platform Digital Products: Challenges and Best Practices appeared first on David Ohnstad.

The Role of Qualitative Data: Understanding the Customer Experience

Qualitative data plays a foundational role in shaping product strategies. By engaging directly with customers through interviews, surveys, or focus groups, product managers can uncover nuanced insights that go beyond numbers. This data provides a window into the emotional and experiential side of product use. It answers critical questions such as: What do users love about the product? Where do they experience friction? What unmet needs do they express?

This form of data is crucial for humanizing product development. It allows teams to step into the shoes of their users, understanding the motivations and frustrations that can’t be captured through hard metrics alone. While customer feedback is invaluable, relying solely on qualitative data presents risks. Personal biases, vocal minorities, or anecdotal evidence can lead to decisions that skew toward the most outspoken users rather than reflecting the entire user base.

Thus, the value of qualitative data lies in its ability to highlight areas for deeper exploration. It can identify potential opportunities for innovation, pinpoint pain points, and generate hypotheses. However, these insights must be validated and prioritized using quantitative data, ensuring that product development remains grounded in actual usage patterns and broader market trends.

The Power of Quantitative Data: Aligning with Market Trends

Quantitative data provides the other half of the equation, offering a more objective, scalable view of how products are performing. This type of data includes analytics from user behavior, feature usage statistics, and metrics such as churn rates, customer satisfaction scores, and return on investment (ROI). By tapping into this wealth of information, product managers can better understand which features are driving engagement and which might need further improvement.

One of the major benefits of quantitative data is its ability to uncover trends at scale. While qualitative data might reveal why a particular feature is important to certain users, quantitative data shows how widely that feature is used across the entire customer base. This distinction is critical when deciding how to allocate resources. A feature that a small group of vocal customers love may not be the best candidate for prioritization if the larger user base doesn’t engage with it as heavily.

In addition to tracking current usage, quantitative data can help product teams anticipate future needs. Market research, which looks at industry trends, competitor movements, and emerging technologies, provides valuable insight into where the market is headed. By combining this macro-level data with the micro-level insights from user behavior analytics, product teams can develop a product roadmap that positions them ahead of competitors.

Striking a Balance: The Interplay of Qualitative and Quantitative Data

The real power of data-driven product development lies in the interplay between qualitative and quantitative data. When used together, these two types of data provide a comprehensive picture that allows product managers to make informed, well-rounded decisions.

For example, let’s consider a scenario where customer interviews reveal dissatisfaction with a particular feature, while quantitative analytics show that the feature is used by a significant portion of the user base. In such a case, the qualitative data serves as an early warning sign that, despite high engagement, the feature might not be meeting customer expectations. This situation would call for further investigation to determine whether the feature needs optimization, reworking, or even removal from the product.

Conversely, there might be situations where qualitative feedback suggests a high demand for a new feature, but quantitative data from market research or competitive analysis reveals that investing in this feature may not align with broader trends. In this case, it would be prudent to reconsider the request, balancing the potential for innovation against the long-term viability of the feature in the marketplace.

The challenge for product managers is to weigh these competing forms of data without letting one dominate. A product team overly focused on qualitative feedback may miss critical insights that would come from broader data sets, while an overreliance on quantitative data could lead to overlooking the human aspect of product development.

Driving Innovation Through Data-Informed Decisions

Product innovation thrives when teams embrace a balanced, data-informed approach. By integrating customer feedback with market research, product managers can prioritize features that not only solve immediate user problems but also align with long-term strategic goals. This balanced approach also mitigates risk by ensuring that decisions are backed by both the voice of the customer and the broader trends driving the industry forward.

Data-driven product development is ultimately about creating a feedback loop. Each feature or iteration released to the market generates new data, which then informs the next stage of development. Customer feedback drives incremental improvements, while market research ensures that the product remains competitive in a rapidly changing environment.

As product management continues to evolve in response to technological advances and shifting consumer behaviors, the importance of balancing qualitative and quantitative data will only increase. Those who successfully integrate these two data types will be well-positioned to lead their products—and companies—toward sustained success.

The Road Ahead for Product Managers

The future of product management lies in data, and more specifically, in the ability to balance qualitative insights with quantitative evidence. In this data-rich environment, product managers must become adept at interpreting various data sources, from customer interviews to market research reports, to drive feature prioritization and innovation.

By maintaining a steady focus on both the needs of the customer and the broader market landscape, product teams can ensure that they are not only meeting current user expectations but also positioning themselves to stay ahead of future demands. David Ohnstad emphasizes that product managers who can master this balance will be the innovators driving tomorrow’s most successful products.

The post Data-Driven Product Development: Balancing Customer Feedback with Market Research appeared first on David Ohnstad.

Laying the Foundation for Growth

Scalability begins at the conceptual stage of a product. Startups with exponential growth potential prioritize architecture and infrastructure designed to support future needs. This requires product managers to anticipate not just current user demands but also the potential for exponential growth. It’s about creating a vision for the product that aligns with long-term business objectives while leaving room for flexibility and iteration.

At this stage, simplicity often proves to be the strongest ally. Overengineering in the name of scalability can bog down development, delay launches, and waste resources. Instead, startups that succeed in scaling start with a minimal viable product (MVP) focused on a core feature set. From there, they iterate, guided by user feedback and data, ensuring they address pain points and deliver value without unnecessary complexity.

The early foundation of scalability isn’t only technical; it’s cultural. Startups that embed scalability into their ethos encourage a mindset of adaptability and problem-solving across all teams. This shared vision allows them to react quickly and effectively to unforeseen challenges or opportunities during growth.

Designing for Flexibility

One hallmark of scalable products is their adaptability. Startups that succeed in high-growth environments often rely on modular design principles. By breaking a product into independent, manageable components, teams can address specific issues or add features without overhauling the entire system. This flexibility not only supports scalability but also accelerates innovation, as teams can experiment with new ideas without disrupting core functionality.

Flexibility extends to team structures and workflows. Agile methodologies are often embraced by startups for their iterative approach, allowing for rapid responses to changes in market demand or customer expectations. Empowering cross-functional teams to collaborate and pivot when necessary ensures that scalability remains an integral part of the development process, not just an afterthought.

This modularity also applies to the technological stack. Choosing scalable technologies—such as microservices over monolithic architectures—provides the agility needed to grow smoothly. The ability to independently scale components means that as demand increases, resources can be directed to the areas that need them most, avoiding unnecessary strain on the system.

Leveraging Data as a Growth Catalyst

Rapid-growth startups understand the critical role of data in scaling products effectively. By leveraging data analytics, these organizations can track user behavior, identify bottlenecks, and optimize performance in real time. Proactive monitoring enables teams to anticipate issues before they escalate, ensuring a smooth experience even as user numbers grow.

Data also drives personalization, a key factor in user retention and satisfaction. Scalable products adapt to individual user needs without compromising performance. Achieving this requires solid data infrastructure capable of handling and analyzing vast amounts of information without lags or interruptions.

Additionally, data product reviews serve as a compass for decision-making. Startups that succeed at scaling often use data not just reactively but proactively, to predict trends and adjust their strategies before problems arise. Predictive analytics and machine learning algorithms can be leveraged to optimize resources and anticipate future growth needs, ensuring scalability remains ahead of the curve.

Balancing Costs and Performance

As startups grow, cost management becomes a vital part of scaling. Many rapid-growth businesses achieve scalability by leveraging cloud-based solutions, which provide the flexibility to adjust resources based on demand. This model allows startups to avoid the upfront costs of physical infrastructure while maintaining the ability to scale operations almost instantaneously.

However, managing cloud costs effectively requires constant vigilance. Startups must strike a balance between performance and expenses, ensuring they allocate resources to areas that deliver maximum value to users. Automation tools and cost-monitoring platforms can help optimize these decisions, allowing teams to focus on growth rather than logistics.

Cost-effectiveness doesn’t mean cutting corners. It means investing in scalable solutions that deliver long-term benefits. Startups that thrive in scalability understand when to automate, when to outsource, and when to develop in-house solutions. This strategic approach ensures resources are used where they have the most significant impact.

Building with the User in Mind

One of the most important lessons from rapid-growth startups is the emphasis on the end user. Scalable products are not only solid and efficient; they are also intuitive and engaging. Startups that excel in scalability maintain a user-centric approach, prioritizing design and functionality that resonate with their target audience.

Regularly collecting and acting on user feedback is essential to this process. Whether through surveys, analytics, or direct interactions, understanding how users engage with a product provides the insights necessary to improve and scale effectively. Iterative design informed by real-world usage ensures that the product evolves in ways that matter most to its users.

Moreover, understanding the user journey helps product teams anticipate future needs. Scalability is about more than handling larger volumes of users; it’s about providing consistent value regardless of scale. Companies that invest in usability testing and user research early can adapt to growth without sacrificing the quality of the experience.

The Role of Leadership in Scalability

Leadership plays a pivotal role in driving scalability. Founders and product managers must align teams around a shared vision, ensuring that everyone understands the importance of scalability and how it relates to broader business goals. Strong leaders foster an environment of innovation and collaboration, empowering teams to solve complex challenges creatively.

Equally important is the ability to communicate effectively with stakeholders. Scaling a product often requires additional investment in technology, talent, and infrastructure. Leaders who can articulate the value of these investments build the trust and support necessary to scale successfully.

Leadership isn’t just about steering the ship; it’s about building a culture of growth. Teams that feel supported and aligned are more likely to innovate and collaborate effectively, creating the conditions for scalable success.

Sustaining Momentum

The work of scalability doesn’t end when a product reaches a larger market. Rapid-growth startups that sustain success understand the need for constant iteration and optimization. This involves monitoring performance metrics, analyzing trends, and continuously improving the product to meet evolving user needs.

Growth is never linear, and unexpected challenges are inevitable. The ability to adapt quickly and learn from setbacks is a defining characteristic of scalable startups. Resilience, paired with a commitment to innovation, ensures that scalability becomes a core strength rather than a fleeting success.

Final Thoughts

Scalability is the backbone of success for rapid-growth startups, enabling them to meet growing demands while maintaining efficiency and user satisfaction. By focusing on flexibility, data-driven decisions, cost management, and user-centric design, startups can create products that thrive in dynamic markets. The journey from idea to scalable success requires not only technological foresight but also cultural alignment and strong leadership. Startups that embrace these principles set themselves up for long-term growth and enduring impact.

The post Building Scalable Products: Lessons from Rapid-Growth Startups The Essence of Scalability appeared first on David Ohnstad.