This article was originally published on davidohnstad.com. I cross-post here to reach the Dev.to community.
Why Mid-Year Data Product Reviews Fail Before They Start
We canceled a quarterly business review thirty minutes before it started. Not because the deck wasn't ready—it was polished, seventy-three slides deep, color-coded by priority tier. We canceled because the VP asked a single question during the pre-read: "Which of these initiatives changed a business decision in Q1?" Nobody could answer. According to Gartner's 2024 Business Value of Data report, this tracks precisely with their finding that 68% of data products lack defined decision criteria at launch, and 71% of those never establish them retroactively.
The mid-year checkpoint—June's Q2 review season—exposes this gap faster than any other planning cycle. Teams scramble to justify what they built in H1 while proposing what to build in H2, but the connective tissue between delivery and business impact remains undefined. Microsoft's 2026 data council update and IBM's modern data team structure framework both acknowledge this: the structure matters, but the operational rhythm determines whether that structure produces value or just produces meetings.
What Goes Wrong When Planning Rituals Replace Strategic Thinking
Most data product managers treat quarterly reviews as reporting exercises: show what shipped, list what's next, get the nod, move forward. The failure mode isn't that this process exists—it's that it becomes the strategy. When the cadence replaces the thinking, teams optimize for slide aesthetics instead of decision clarity. They celebrate deployment velocity while usage stagnates. According to Forrester's 2025 Data Strategy report, organizations with quarterly review cadences but no between-quarter feedback mechanisms saw 42% lower adoption rates than those with continuous validation loops.
A concrete example: a Fortune 500 retailer built a customer lifetime value model that executives requested in January, approved in March, and reviewed in June. The model was technically sound—marketing science validated the methodology, engineering confirmed the pipeline accuracy, the dashboard loaded in under two seconds. But by the June review, nobody had changed a single campaign based on its output. Why? Because the January request never defined which campaign decision the model should inform. The team built what was asked for. They didn't build what was needed. The Q2 review became a post-mortem for a product that was dead on arrival, dressed up as a status update.
The stakes compound across organizations. When one data product ships without decision criteria, the pattern spreads. Teams learn that delivery earns praise, impact doesn't get measured, and the next quarterly cycle repeats the problem. IBM's structure guidance emphasizes product managers as "translators between business and technical teams"—but translation requires knowing what question you're answering, not just what data you're surfacing.
The Decision-First Review Stack
This is a four-layer quarterly review framework designed specifically for data product managers navigating mid-year checkpoints. Each layer answers a distinct question that traditional QBRs skip. The framework name matters—"Decision-First Review Stack" signals that decision clarity precedes roadmap prioritization, not the other way around.
Layer 1: Decision Inventory. Before reviewing what you built, list every business decision your products were supposed to influence in the previous quarter. Not "provide insights for marketing"—that's not a decision. "Determine which customer segments receive the retention offer" is a decision. If you cannot list three specific decisions your products supported in Q1, you don't have a product problem—you have a requirements problem. This layer usually surfaces that half your backlog is building dashboards for questions nobody asked.
Layer 2: Usage-to-Decision Mapping. For every decision identified in Layer 1, map which users accessed which product features and whether that access preceded a documented decision change. This is where most reviews stop at vanity metrics: "Dashboard had 847 views in Q1." That's activity, not impact. The question is: did any of those 847 views result in a budget reallocation, a campaign launch, a vendor selection, or a process change? If usage doesn't connect to decisions, you've built a reporting tool, not a product. According to McKinsey's 2024 Analytics ROI study, only 23% of data products with high usage scores could trace that usage to documented business outcomes—meaning 77% of "successful" products measured the wrong thing.
Layer 3: Structural Gap Audit. Identify where your team structure prevented decision support in Q1. This is the counterintuitive layer—most PMs assume structure is fixed and focus on execution within constraints. Wrong. The mid-year review is when you have budget attention and reorg windows. If your data engineers report to IT and your product priorities come from the business, you'll keep building pipelines that deliver data nobody trusts because the engineering team isn't accountable to the decision-makers. If your analytics team has no seat in planning meetings, you'll keep retrofitting insights onto decisions already made. David Ohnstad has seen this pattern repeatedly: the org chart predicts product failure faster than the roadmap does. Microsoft's data council approach directly addresses this—centralizing decision authority on data strategy instead of distributing it across siloed functions.
Layer 4: H2 Decision Backlog. Don't build a feature backlog for H2. Build a decision backlog. List the ten most important business decisions your organization will face in the next six months. Rank them by revenue impact or strategic priority. Then—and only then—work backward to define what data product capabilities would improve those decisions. This inverts the traditional process where PMs gather feature requests, prioritize by effort, and hope somebody finds them useful. A decision backlog forces clarity: if nobody can name a decision, the feature doesn't ship. Period.
What a Decision-First Q2 Review Actually Looks Like
David Ohnstad ran this framework at a SaaS company during a June planning cycle where the executive team wanted to double down on AI-powered features for H2. The conventional approach would have been to list AI capabilities the team could build—natural language querying, anomaly detection, predictive churn models—and prioritize by technical feasibility. Instead, the review opened with Layer 1: what decisions do executives need to make in H2 that they currently make with incomplete information?
Three decisions surfaced immediately. First, which customer accounts to target for upsell during the fall renewal cycle—currently a manual process driven by account manager intuition. Second, which product features to sunset in Q4 to reduce maintenance costs—currently delayed because nobody could quantify usage vs. engineering burden. Third, how to allocate the Q4 marketing budget across channels—currently based on prior year's spend with no attribution model.
Layer 2 revealed that the company already had a customer health score dashboard with decent usage (312 views in Q1), but zero documented cases where it influenced an upsell decision. Why? Because the score updated weekly, but upsell decisions happened in monthly account reviews where nobody pulled up the dashboard. The disconnect wasn't the model quality—it was the delivery cadence. The product was technically successful and operationally useless.
Layer 3 exposed a structural gap: the data engineering team reported to IT, which prioritized infrastructure stability over product iteration speed. When the PM requested a daily score refresh to align with account review schedules, it sat in a queue behind database migration work for eleven weeks. The mid-year review became the moment to escalate this—not as a complaint, but as a structural constraint preventing decision support. The VP of Sales, who actually needed the daily refresh, had budget authority the PM didn't. Within two weeks, a dedicated product data engineer was reassigned. The structure changed because the decision requirement was explicit.
Layer 4 built the H2 backlog entirely around the three decisions identified in Layer 1. No AI-powered natural language querying—nobody asked a question that required it. Instead: a daily customer health score refresh, an automated feature usage-to-cost dashboard for the sunset decision, and a channel attribution model integrated into the marketing budget planning tool. Fewer features. Clearer impact. Every backlog item traced directly to a named decision with a named decision-maker who committed to using it.
The Q2 review that resulted from this process took forty minutes, not two hours. Executives left with three commitments, not thirty ideas. And when the October review happened, each of the three products had documented decision outcomes: seventeen upsell targets identified early, four features sunset with cost savings quantified, and 22% of Q4 marketing budget reallocated based on attribution data. Not "insights delivered"—decisions changed.
Stop Measuring Output Velocity When You Should Measure Decision Latency
Most data product teams measure story points closed, pipelines deployed, dashboards launched—all output metrics. These numbers make quarterly reviews feel productive while masking the actual problem: how long does it take for your product to influence a business decision after it ships? Call this "decision latency." According to Deloitte's 2025 Data-Driven Enterprise study, the median decision latency for new data products is 87 days—meaning the average product takes nearly three months post-launch before anyone makes a business decision using it. For products with decision latency over 120 days, 68% were eventually deprecated without ever driving a documented decision.
This is the contrarian position most senior data PMs resist: velocity is a vanity metric when decision latency is high. Shipping faster doesn't matter if adoption takes three months and usage never connects to outcomes. The uncomfortable implication is that a team shipping four products per quarter with 90-day decision latency is underperforming a team shipping one product per quarter with 14-day decision latency. The latter is doing product management. The former is doing project management with a product title.
Decision latency also reveals structural problems output metrics hide. If your dashboards consistently take 60+ days to influence decisions post-launch, the root cause is usually one of three things: wrong decision-maker in the requirements process, missing integration into existing decision workflows, or no accountability mechanism for adoption. All three are PM failures, not engineering failures. The code works. The product doesn't.
Measuring decision latency requires changing what you track in quarterly reviews. Instead of "Q1: shipped customer segmentation tool," the review should state: "Q1: shipped customer segmentation tool on March 15; first documented decision using segmentation output occurred April 2 (18-day latency); decision was reallocation of $140K in targeted ad spend." The specificity forces honesty. If you can't name the decision, the latency is infinite.
How Mid-Year Reviews Intersect With Team Structure and Tool Selection
The timing of Q2 reviews matters beyond planning—it's when budget conversations reopen and team structures get reevaluated. Data product managers should consider how AI/ML engineering capabilities influence vendor selection decisions during mid-year strategic reviews, particularly when evaluating third-party risk management tools. If your H2 roadmap includes building predictive models in-house, but your team lacks ML engineering depth, the Q2 review is when you either hire for that gap or shift to vendor-supported solutions. Both are valid, but deciding in October is too late—vendors need 60–90 days for procurement and onboarding, and hiring ML engineers in a competitive market takes longer.
Similarly, mid-year mentorship and performance conversations with your teams directly inform structural decisions about roles, skill gaps, and team composition. If Layer 3 of your review—Structural Gap Audit—identifies that your analysts lack SQL fluency and it's blocking dashboard iteration speed, the June review is when you decide: upskill the current team, hire senior analytics engineers, or restructure so data engineering owns dashboard builds. Waiting until Q3 or Q4 means H2 roadmap commitments are built on a team capability that doesn't exist yet. David Ohnstad has learned this the hard way: the most polished H2 plan is worthless if the team can't execute it, and June is the last moment to fix that before the year runs out.
Cross-functional dependencies also surface during mid-year cycles in ways they don't during quarterly sprints. If your data product manager reporting structure has you reporting to IT but your roadmap priorities come from Sales, the Q2 review is when that misalignment becomes a C-level problem. Use it. The worst time to surface a reporting structure issue is in November when a product misses its deadline because the wrong executive had veto authority.
What to Watch: The Shift From Quarterly to Continuous Decision Validation
The pattern that doesn't show up in mid-year review data yet—but will define the next eighteen months—is the erosion of quarterly cadences in favor of continuous decision validation. The companies David Ohnstad watches most closely aren't running better QBRs—they're asking whether quarterly reviews are the right rhythm at all for data products. When decision latency drops below 30 days and product iteration cycles move to two-week sprints, a 90-day checkpoint becomes a lagging indicator. You're reviewing decisions made two months ago instead of validating the ones happening next week.
Snowflake's recent push to make data "AI ready" and Microsoft's emphasis on unified data strategy through councils both point in this direction: infrastructure that enables real-time decision support, not periodic reporting. The implication for product managers is that H2 planning might be the last cycle where quarterly reviews are the dominant rhythm. The teams experimenting with continuous validation—weekly decision retrospectives, automated impact dashboards, real-time usage-to-outcome tracking—are building the muscle that makes quarterly reviews obsolete. This doesn't mean planning disappears. It means planning becomes a continuous background process instead of a ceremonial event.
For practitioners in mid-2026, the question is whether your Q2 review process is preparing you for that shift or locking you into the old model. If your June review outputs a static six-month roadmap with phase gates and milestone checkpoints, you're optimizing for the past. If it outputs a decision backlog, a structural realignment, and a feedback mechanism that runs weekly, you're ready for what's coming.
How do you prioritize data product features during a mid-year review?
Prioritize by decision impact, not technical complexity. List the business decisions your organization will make in H2, rank them by revenue or strategic importance, then work backward to identify which product capabilities improve those decisions. Features that don't map to a named decision with a named decision-maker shouldn't ship, regardless of how technically impressive they are.
What is decision latency in data product management?
Decision latency is the time between when a data product launches and when it first influences a documented business decision. According to Deloitte's 2025 research, median decision latency is 87 days. Products with latency over 120 days have a 68% deprecation rate. Measuring decision latency reveals whether your product is actually being used for decisions or just generating reports.
Why do most quarterly business reviews fail for data product teams?
Most QBRs measure output velocity—features shipped, pipelines deployed—instead of decision impact. According to Forrester's 2025 analysis, 71% of data products launch without defined decision criteria and never establish them retroactively. Without clarity on which business decisions the product should influence, quarterly reviews become status updates instead of strategic checkpoints, and teams optimize for delivery speed over adoption.
Two Takeaways and One Question
For practitioners: your June review isn't about defending what you built in Q1—it's about proving what decisions changed because of it. If you can't name three decisions your products influenced, your H2 roadmap should start with decision clarity, not feature additions. For leaders: if your data product teams report output metrics but can't quantify decision latency, you're funding a reporting function, not a product organization. The fix starts with asking different questions in the review process.
Here's the question worth examining before your next quarterly checkpoint: when was the last time you canceled a product feature mid-sprint because you discovered the decision it was meant to support didn't actually exist? If the answer is "never," you're not validating decisions early enough—and your Q2 review is measuring the wrong thing.
To explore David Ohnstad's broader work on enterprise AI and SaaS strategy, visit David Ohnstad on AI and enterprise SaaS. For insights on his hands-on making and craft projects, see David Ohnstad's woodworking and making. His approach to Data Product Management emphasizes decision-first planning and continuous validation over quarterly reporting theater.
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.
Top comments (0)