Data Product Adoption: Why Teams Build What Nobody Uses

Most Data Product Teams Are Building the Wrong Thing—On Purpose

David Ohnstad shipped a customer health scoring model at Veeam that took seven months to build, required sign-off from three VPs, and landed with full executive sponsorship. It was technically flawless. The data pipeline ran without errors. The dashboard loaded in under two seconds. And within 90 days, usage dropped to zero—not because the data was wrong, but because nobody on the customer success team could explain what decision it was supposed to change. According to Gartner’s 2024 Business Intelligence survey, 87% of organizations report low maturity in turning analytics into repeated business action. The problem isn’t the infrastructure. It’s that teams are optimizing for the wrong success metric: they’re building data products that get approved, not data products that get used.

This isn’t a tooling gap. It’s a strategic misalignment that starts in the requirements phase and compounds through every sprint review. Most data product managers are evaluated on whether they shipped on time and whether stakeholders attended the launch demo. Almost none are evaluated on whether the product changed a single decision 60 days after launch. The result is a portfolio of technically excellent dashboards, models, and pipelines that executives reference in all-hands meetings but practitioners ignore in their daily work. The gap between “shipped” and “adopted” is where most data product careers stall—and where most data teams burn budget without generating ROI.

The core issue is that stakeholders ask for analytics when what they actually need is decision support, and most PMs don’t challenge the distinction. A dashboard that shows customer churn rate is analytics. A workflow that flags at-risk accounts, surfaces the three highest-impact interventions, and tracks which actions were taken is decision support. The first one gets you a launch email and a Slack emoji. The second one changes how the business operates. But the second one also requires you to ask uncomfortable questions during scoping: What decision does this data change? Who makes that decision today without this data? What do they do differently once they have it? Most teams skip that conversation because it slows down approval. They trade long-term adoption for short-term velocity.

Why Decision-Free Data Products Survive Internal Review

The incentive structure inside most organizations actively rewards shipping over adoption. Product managers are measured on delivery milestones, not behavior change. Stakeholders are rewarded for requesting “data-driven decision-making” initiatives, not for using the outputs. Executives get credit for funding analytics infrastructure, not for ensuring the infrastructure connects to operational workflows. According to Harvard Business Review’s 2022 analysis of data transformation programs, 72% of executives report that their organizations struggle to connect insights to action—yet those same organizations continue to fund analytics projects using the same approval criteria that produced the disconnect in the first place.

Here’s what happens in practice: A sales leader requests a lead scoring model. The PM gathers requirements, builds a prototype, runs it past the stakeholder, and ships it. The stakeholder approves because the model looks sophisticated and the PM met the deadline. But nobody asked: What does the sales team do with a score of 78 versus a score of 42? Do we route high-scoring leads to senior reps? Do we trigger a different email sequence? Do we adjust outreach cadence? If the answer is “we’ll figure that out after launch,” the product is already dead—it just doesn’t know it yet. The model will get used for two weeks during the post-launch excitement phase, then quietly replaced by the same gut-feel prioritization process the team used before the model existed.

This dynamic is self-reinforcing. PMs who push back on vague requirements get labeled as “not collaborative” or “overthinking it.” PMs who ship fast without challenging the decision layer get promoted. The system optimizes for throughput, not for outcomes. And because most data products take months to build, the failure doesn’t surface until long after the PM has moved to the next project. By the time someone notices that the lead scoring model isn’t being used, the original stakeholder has moved roles, the PM is working on a completely different product, and there’s no accountability loop to surface what went wrong. The organization learns nothing. The next data product gets scoped the same way.

The Decision-First Scoping Framework

David Ohnstad uses a four-step scoping model for every data product at Veeam, and it has a 92% adoption rate 90 days post-launch—not because the data is better, but because the scoping process forces stakeholders to define the decision before approving the build. This framework is called the Decision-First Scoping Framework, and it works by inverting the traditional requirements process: instead of asking “What data do you need?” it asks “What decision changes if you have this data?” The difference is subtle in wording but significant in practice. Here’s how it works.

Step 1: Identify the decision, not the dashboard. Start every scoping conversation with one question: “What decision does this data change?” Not “What would you like to see?” or “What metrics matter to you?”—those questions produce wish lists, not products. If the stakeholder can’t name a specific decision that will change, the project stops here. No prototype. No roadmap. No build. This step eliminates 40% of incoming requests at Veeam, and every single one of those eliminations saves the team from building something that would have launched to applause and died in obscurity. A decision is binary or bound: “Should we renew this customer?” or “Which of these five leads do we call first?” If the answer is “I just want visibility,” that’s a reporting request, not a product—and it belongs in a BI tool, not on a product roadmap.

Step 2: Map the current decision process without data. Ask the stakeholder: “How do you make this decision today?” Most will say “gut feel” or “experience,” which is fine—that’s the baseline you’re improving. But push one level deeper: “Walk me through the last time you made this decision. What did you look at? Who did you ask? How long did it take?” This reveals the actual workflow you’re competing with. If a sales manager currently prioritizes leads by scanning a spreadsheet for company size and industry, your lead scoring model needs to integrate with that spreadsheet or replace it entirely—building a separate dashboard that requires the manager to check two systems means you’ve added friction, not removed it. According to McKinsey’s 2023 study on data governance, 68% of analytics tools fail adoption because they require users to change their workflow rather than augment it. This step surfaces that conflict before you build anything.

Step 3: Define the decision change, not the insight. Insights are interesting. Decision changes are measurable. “We discovered that customers with low engagement in the first 30 days churn at twice the rate” is an insight. “We now assign a dedicated CSM to any customer with fewer than three logins in the first 30 days” is a decision change. The scoping document must include the specific action that will be taken when the data says X versus Y. If the stakeholder says “We’ll use this to inform our strategy,” push back: “What specifically will you do differently?” If they can’t answer, the project isn’t ready. This is the most uncomfortable step in the framework, and it’s also the most important. It forces stakeholders to commit to using the output before you commit to building it. At Veeam, this step alone improved post-launch adoption rates from 34% to 81% across a portfolio of 19 products built between 2022 and 2024.

Step 4: Build the feedback loop into the product, not as a follow-up. Adoption tracking isn’t a post-launch activity—it’s a scoping requirement. Before the first sprint starts, define: What does “used” mean for this product? How will we measure whether the decision is changing? Who reviews that metric, and how often? For the customer health scoring model at Veeam, “used” means: a CSM took an action (logged a call, escalated to leadership, adjusted renewal strategy) on an at-risk account within 48 hours of the score changing. That’s tracked automatically. Every Monday, the team reviews a report showing how many flagged accounts got action versus how many were ignored. If the ignore rate trends up, that’s a signal the model is losing trust—and the PM investigates immediately, not six months later during a retrospective. This closed-loop measurement is what separates products that survive from products that get quietly deprecated.

When Stakeholder Consensus Kills Product Clarity

David Ohnstad worked on a pricing optimization model for a SaaS renewal team that had eight stakeholders across finance, sales, customer success, and product. Every stakeholder had a different definition of what “optimized” meant. Finance wanted to maximize margin. Sales wanted to maximize close rate. Customer success wanted to minimize churn risk. Product wanted to increase upsell attach rates. The PM spent four months building a model that balanced all four objectives using weighted scoring—and it was technically brilliant, won an internal innovation award, and was used exactly zero times in production. Why? Because when the model recommended a price, nobody knew which objective it was optimizing for in that specific case, so nobody trusted it enough to override their own judgment. The team had optimized for stakeholder consensus during the build and produced a model too complex to be specific.

This is the pathology of requirement gathering by committee. When you try to satisfy every stakeholder’s definition of success, you end up with a product that satisfies none of them. The solution isn’t better communication or more alignment meetings—it’s forcing a single decision owner to take accountability for the output. One person who will be measured on whether the product changes their behavior. One person who has to explain to their VP why they’re still using the old process if the new one is supposedly better. That person becomes the filter for every requirement: if it doesn’t help them make their specific decision faster or better, it doesn’t go in the build. This is uncomfortable, because it means telling seven other stakeholders that their input is secondary. But it’s also the only way to build a product anyone will actually use. At Veeam, every data product now has a named decision owner in the scoping doc, and that person has veto authority over feature requests that don’t serve their core decision. Adoption rates went up. Scope creep went down. Stakeholder satisfaction stayed the same, because the products that shipped actually worked.

The mistake most PMs make is treating “decision owner” as the same thing as “executive sponsor.” They’re not. An executive sponsor approves funding and removes roadblocks. A decision owner uses the product daily and is measured on the outcome it’s supposed to improve. Sometimes they’re the same person—usually they’re not. If your executive sponsor won’t use the product themselves, find the person who will and make them the decision owner. If nobody on the team will commit to using it, don’t build it. This is the clearest signal you’ll ever get that the project is a political deliverable, not a business need. And political deliverables don’t survive contact with reality—they get demoed once, celebrated in a slide deck, and quietly retired when nobody’s paying attention. Meanwhile, you’ve spent six months of engineering time on something that generates zero ROI.

Stop Measuring Shipped Features—Start Measuring Changed Decisions

Most data product teams track story points completed, sprint velocity, and release cadence. Almost none track decision velocity: how many decisions were made faster, better, or more consistently because the product exists? This is the metric gap that explains why so many analytics initiatives get funded year after year despite producing no measurable business impact. According to Forrester’s 2024 Enterprise Data Fabric report, organizations that measure data product success by “business decisions influenced” see 3.2x higher ROI than organizations that measure by “dashboards delivered.” The shift isn’t semantic—it’s operational. When you measure decisions, you have to define what a decision looks like, who makes it, and whether the data changed the outcome. That forces clarity at every layer of the product.

Here’s what decision-based measurement looks like in practice. For the customer health scoring model at Veeam, the success metric isn’t “CSMs log in to the dashboard.” It’s “percentage of at-risk accounts that receive outreach within 48 hours of score deterioration.” That’s a decision metric. It tells you whether the product is changing behavior, not whether it’s getting traffic. The team tracks this weekly. When the percentage drops below 70%, the PM investigates: Is the scoring model losing accuracy? Is the threshold too sensitive? Are CSMs seeing the alerts but not trusting them? This feedback loop surfaces problems while they’re still fixable, not six months later during an annual review. Contrast this with a dashboard-based success metric like “monthly active users.” A CSM can log in, glance at the dashboard, and log out—that counts as usage, but it didn’t change a single decision. It’s a vanity metric that makes the product look successful while delivering zero business value.

Switching to decision-based metrics also changes what you build. If you’re measured on logins, you optimize for visual polish and ease of access. If you’re measured on decisions, you optimize for actionability and integration with existing workflows. The former gets you a beautiful dashboard that looks great in screenshots. The latter gets you a Slack alert that tells a CSM exactly which customer to call and exactly what issue to address. One is a reporting tool. The other is a decision support system. And only one of those survives past the launch quarter. The uncomfortable truth is that most data PMs have never worked in an environment where they’re held accountable for decision velocity, so they don’t know how to design for it. They design for stakeholder approval, then act surprised when adoption flatlines. This is a skill gap, not a data gap—and it’s fixable, but only if you’re willing to redefine what success looks like.

Why Federated Data Architectures Demand Decision-First Scoping Even More

David Ohnstad’s team at Veeam operates in a federated data architecture, where domain teams own their own data products and the central data team provides infrastructure and governance. This is the model most enterprises are moving toward, and it makes decision-first scoping even more critical—because in a federated model, there’s no central PM who can enforce consistency or catch scope creep before it spirals. Each domain team is building for their own stakeholders, and if those stakeholders don’t define the decision upfront, you end up with 15 different customer health scores that measure different things, integrate with different systems, and produce conflicting recommendations. Nobody trusts any of them, so everyone defaults back to gut feel. The architecture was supposed to increase agility. Instead, it increased fragmentation.

The failure mode in federated architectures isn’t technical—it’s definitional. When the sales team builds a lead scoring model and the marketing team builds a separate lead scoring model using different features and different thresholds, the problem isn’t that the models are bad. It’s that nobody scoped them with a shared understanding of what decision they were supporting. Sales defines a “qualified lead” as someone likely to close this quarter. Marketing defines it as someone likely to engage with content. Both models work for their stated purpose, but when a lead gets scored differently by each system, the rep in the field doesn’t know which score to trust—so they ignore both. This is the predictable outcome of letting teams build in isolation without forcing alignment on the decision layer first. And it’s happening at scale across organizations that adopted federated models without updating their scoping discipline.

The fix isn’t to recentralize—it’s to standardize decision scoping across domain teams while leaving execution federated. At Veeam, the central data team maintains a decision registry: a shared document that lists every major decision the business makes, who owns it, and which data products currently support it. Before a domain team builds a new product, they check the registry. If someone else is already supporting that decision, they either extend the existing product or justify why a separate solution is necessary. If the decision isn’t in the registry, they add it—along with the decision owner, the current process, and the intended change. This prevents duplication and forces clarity before the first sprint starts. It’s not governance for governance’s sake—it’s a forcing function that ensures every product has a clear reason to exist beyond “the stakeholder asked for it.”

What is the difference between a data product and a report?

A report shows you what happened. A data product changes what happens next. Reports are retrospective—they summarize historical data for analysis or compliance. Data products are operational—they integrate into workflows, trigger actions, and influence real-time decisions. A sales dashboard showing last quarter’s pipeline is a report. A lead scoring system that routes high-value leads to senior reps is a data product. The former informs. The latter decides.

How do you measure data product adoption effectively?

Measure decision changes, not logins. Track how many times the product influenced a specific action: a lead contacted, a customer escalated, a price adjusted. Define “used” as “caused a measurable behavior change” and instrument the product to capture that metric automatically. Review it weekly. If the decision rate drops, investigate immediately—don’t wait for a quarterly review. Adoption is a leading indicator of value, but only if you measure the right thing.

Why do most data products fail after launch?

They solve the wrong problem. Teams build what stakeholders ask for instead of what changes their decisions. A dashboard gets approved because it looks useful in a demo, but it doesn’t integrate into the daily workflow, so it gets ignored. The failure happens during scoping, not during execution. If you don’t define the decision the product supports before you build it, you’re designing for applause, not for adoption. And applause doesn’t generate ROI.

The Accountability Gap Between Shipped and Used

The hardest part of decision-first scoping isn’t the framework—it’s the accountability. Most organizations don’t have a forcing function that connects product usage to PM performance. A PM can ship a dashboard that nobody uses, move to the next project, get promoted based on delivery velocity, and never answer for the fact that their last three products are gathering dust. According to Reforge’s 2023 Product Leadership survey, only 22% of product organizations formally track whether shipped features are still being used six months post-launch. The rest measure success at the release gate and move on. This is why data product portfolios are full of zombie dashboards—products that were celebrated at launch, never deprecated, and quietly ignored by everyone except the PM who occasionally checks the login metrics to make sure they’re not literally zero.

The fix is simple but uncomfortable: tie PM performance reviews to post-launch adoption metrics, not just delivery milestones. If a product isn’t being used 90 days after launch, the PM should have to explain why and either fix it or kill it. No exceptions. No “we’ll revisit this next quarter.” This creates the accountability loop that most teams are missing. It also changes what PMs prioritize during scoping. If you know you’ll be measured on whether the product changes decisions, you ask harder questions upfront. You push back on vague requirements. You insist on a named decision owner. You don’t ship products that look good in demos but fall apart in production. And you stop optimizing for stakeholder consensus and start optimizing for stakeholder impact, which are not the same thing.

For teams operating in a modern SaaS or enterprise AI environment, this accountability shift is even more urgent, because AI-powered data products fail faster and more visibly than traditional dashboards. A predictive model that makes bad recommendations gets turned off within days—there’s no grace period where users politely ignore it. Either it works or it doesn’t. And “works” means “changes decisions for the better,” not “produces technically accurate outputs that nobody acts on.” This is the standard every data product should be held to, whether it uses machine learning or not. But most teams won’t adopt it unless leadership changes the incentive structure. As long as PMs are rewarded for shipping and not penalized for building things that don’t get used, the pipeline of unused data products will keep growing.

What This Means for Product Teams and Leaders

For practitioners: stop treating scoping as a requirements-gathering exercise. Treat it as a decision-mapping exercise. Before you write a single user story, name the decision the product changes, identify who makes that decision today, and define what “used” means in measurable terms. If the stakeholder can’t answer those questions, don’t build the product. If leadership pressures you to build it anyway, document the decision gap in the scoping doc so there’s a record of why it failed when adoption metrics come up six months later. This is not being difficult—it’s being responsible. You are the PM. You own the success of the product, not just the delivery. And success is measured by whether it changes the business, not whether it shipped on time.

For leaders: if your data product team is shipping on schedule but adoption is inconsistent, the problem isn’t execution—it’s scoping discipline. Audit your last ten data product launches and ask: How many are still being used? How many influenced a measurable decision in the last 30 days? If the answer is fewer than half, you have a process problem, not a people problem. Implement decision-based scoping and decision-based success metrics. Tie PM performance to post-launch adoption. And be prepared to kill products that don’t meet the standard, even if they were expensive to build and launched with fanfare. Every zombie dashboard in your portfolio is a signal that the system is optimizing for the wrong thing. Fix the system, and the outcomes will follow. When did you last audit whether your team is building data products that get used, or just data products that get approved?

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.