Data Products Were Supposed to Solve This… So Why Is the Business Still Waiting?

Data Products Were Supposed to Solve This… So Why Is the Business Still Waiting?
The industry promised transformation. Business teams are still waiting at the door. It's time to examine why, and what actually needs to change.
Executive Summary
The Gap Between Data Promise and Business Reality
Data products are widely accepted across the industry. Gartner, Deloitte, and BARC have all pointed toward reusable, governed, business-aligned data assets as the path forward. The language is consistent: treat data as a product, assign domain ownership, and enable better business outcomes. Technology providers like Snowflake, AWS, IBM, and Oracle have built powerful platforms to support this vision.
And yet, inside most organizations, the business is more confused than ever. The experience has not kept pace with the narrative. For many business teams, data products feel like another layer of terminology placed on top of an already complex environment. Access remains difficult. Timelines remain slow. Trust remains uncertain.
The problem is not data, it is usability and timing. The industry has implemented a fundamentally business concept as an engineering solution. A new approach is needed: one focused on outcomes, not architectures.
Five Things That Must Change
Business teams must be owners, not consumers
Governance must be executed, not just defined
Access must be immediate and decision-ready
Engineering and business must return to sync
Success must be measured by outcomes, not builds
Industry Narrative
Data Products Are Now Industry Orthodoxy
Over the past several years, data products have moved from fringe concept to mainstream strategy. Gartner has placed them at the center of modern data architecture. Deloitte has championed data mesh and domain-oriented ownership as the structural framework for scaling data value across the enterprise. BARC has reinforced that reusable, governed, business-aligned data assets are no longer aspirational, they are the expected standard.
The language has converged. Across analyst reports, conference keynotes, and vendor roadmaps, the message is consistent: treat data as a product, assign clear ownership at the domain level, and build toward measurable business outcomes. 
Technology providers including Snowflake, AWS, IBM, and Oracle have invested heavily in platforms designed to make this vision operational. The infrastructure for a new era of data strategy is, at least on paper, firmly in place.
Gartner
Data products at the center of modern data architecture
Deloitte
Data mesh and domain-oriented ownership as the scaling framework
BARC
Reusable, governed, business-aligned assets as the expected standard
IDC
Data-driven transformation as the defining competitive differentiator
Reality Check
Inside Most Organizations, Access Is Still Broken
Despite the strength of the industry narrative, the lived experience inside most organizations tells a different story. Business teams are not experiencing transformation, they are experiencing frustration. When they attempt to engage with data products, they encounter the same barriers that existed before the terminology changed. Access remains difficult. Timelines remain slow. Trust remains uncertain. What was positioned as a breakthrough has begun to feel, for many, like rebranded complexity.
This is not just a perception problem. BARC has consistently highlighted that a significant proportion of enterprise data is never used for decision-making. IDC similarly notes that organizations struggle to translate data investment into measurable outcomes. The issue is no longer whether data exists in sufficient volumes, it almost always does. The issue is whether it can be accessed and used at the moment it matters most.
Over time, this disconnect erodes confidence in the entire data strategy. Business leaders who were once willing to invest in transformation become skeptical. Domain owners who were meant to take ownership step back. And the data team, despite genuine effort and technical sophistication, finds itself unable to bridge the gap between what has been built and what the business actually needs.
BARC research consistently finds that a significant proportion of enterprise data is never used for decision-making, not because it doesn't exist, but because it cannot be accessed when it matters.
Core Problem
A Business Concept Implemented as an Engineering Solution
The root cause of this persistent gap is structural, not technical. What has happened in practice is that the industry has taken a fundamentally business concept, the data product, and implemented it as an engineering solution. The framing was always about business ownership, domain alignment, and outcome-driven design. The execution has been something else entirely.
Most data product platforms today are designed, built, and deployed by engineers, for engineers. They are optimized for pipelines, orchestration, and technical control. Even when they claim to support data products in the fullest sense, the creation and lifecycle management of those products remain firmly within the data engineering team. The business is consulted. The business is informed. But the business is not in control.
This is where the model breaks. Because the business is not positioned as the owner of the data product. It is positioned as the consumer. And that single distinction undermines everything the data product philosophy was designed to achieve.
Critical Argument
Built by Engineers, for Engineers
The data product movement drew its intellectual energy from product thinking, the idea that data, like a software product, should be designed for its users, owned by accountable teams, and iterated based on real-world feedback. The problem is that this philosophy was handed to engineering teams and implemented through an engineering lens.
As Sanjeev Mohan has emphasized, data products must be consumable and usable, not just technically correct. As Mike Ferguson has long reinforced, the value of data lies in how quickly it can be turned into decisions. Neither of those outcomes is achieved by building more sophisticated pipelines and calling them products.
Ownership is not symbolic. It is operational. If the business cannot build it, shape it, and take responsibility for it, then it is not a data product. It is a technically sophisticated data asset with a business-friendly name.
Data Product Tenets
Why the Current Model Breaks Data Product Principles
A genuine data product, we believe at Data Tiles, must satisfy three non-negotiable conditions. It must be owned by the domain, meaning the business entity responsible for the outcome. It must be aligned to business use cases, not optimized for engineering convenience. And it must be usable at the point of decision, not simply available somewhere in a catalog or platform if someone knows where to look and has the right access permissions. When engineering teams retain control of creation, lifecycle, and access, none of these conditions are reliably met. The label changes. The structure does not.
The Broken Model
Dependency, Slow Access, and Eroding Trust
The pattern that emerges from this misalignment is entirely predictable, and it has been repeating itself across organizations of every size and sector. Engineers build the platform. Engineers build the pipelines. Engineers deploy the data products. And the business is left to consume whatever is delivered, on whatever timeline engineering can support. From the outside, this looks like progress. From the inside, it feels like the same problem, just wrapped in new language.
Persistent Dependency
Business teams remain dependent on engineering for every access request, every change, and every new use case. The relationship never evolves from consumer to owner.
Controlled Access
Access is granted rather than enabled. Business teams wait in queues rather than self-serving from trusted, governed assets they understand and trust.
Slow Timelines
Decisions that require data are delayed. By the time the data arrives, the context has changed and the decision window has often closed.
Eroded Trust
When delivery is slow and context is lost in translation, business teams lose confidence in both the data and the teams responsible for it.
If the business is still only consuming data, then we have not built data products. We have just built more pipelines.
Engineering Impact
The Bottleneck No One Intended to Create
This dynamic is not only frustrating for the business. It is equally frustrating for the engineers caught at the center of it. Data engineers are skilled, capable, and motivated professionals. They did not enter their careers to manage an endless backlog of access requests and one-off data pulls. They came to solve hard problems: to architect scalable systems, to build robust foundations, and to enable the organization to move faster and with greater confidence.
Instead, the current model turns them into operational intermediaries. Every business request for data, every new use case, every governance question lands on the same team. Engineers are pulled away from the architectural and strategic work that would genuinely move the organization forward, and into the reactive, operational work of keeping a dependent model functional.
The shift forward is not about removing engineering from the equation. Engineering provides the foundation. The infrastructure, the governance rails, the scalable architecture, these are essential and engineering-owned. But the data product itself, the shaped, governed, outcome-aligned asset that a business team interacts with daily, must belong to the business. Engineering enables. The business owns. And the data product becomes the bridge between the two.
Alignment
Business and Engineering Need to Return to Sync
What Engineering Provides
01
Scalable infrastructure and data architecture that can support enterprise-wide use cases reliably and securely
02
Governance rails and policy frameworks that define how data should be used, shared, and protected across domains
03
Integration and pipeline foundations that move data reliably from source systems into governed environments
What Business Must Own
01
The data product itself, shaped, governed, and aligned to the specific outcomes and use cases of the domain
02
The definition of what "decision-ready" means for their context, what data is needed, in what form, and with what timeliness
03
Accountability for outcomes. The ability to measure whether the data product is delivering value and to iterate accordingly
The most effective data organizations are those where this boundary is clear and respected. Engineering is not a service desk. The business is not a passive consumer. When each plays its proper role, the data product functions as it was always meant to: as a bridge between technical capability and business value.
Industry Critique
What the Conference Stage Isn't Telling You
There is a broader industry dynamic that cannot be ignored, even if it is more often discussed in private conversations than from the stage. At conferences and industry events, the stories of transformation are polished and compelling. Leaders present journeys where data products, governance, and AI have delivered measurable success. The audience wants to believe these stories, and many of them are genuine. Progress is real. But it is not universal, and the sample on stage is not representative.
Beyond the keynote, a different story often emerges. Listen closely and you hear the voices of business teams still struggling to access data, still waiting days or weeks for answers that should arrive in minutes, still working around limitations that were supposed to have been resolved. The people closest to the outcome are often experiencing something very different from what is being presented.
The industry needs to move beyond narrative and toward evidence. Not just what was built, but what actually changed. Did access improve? Were decisions accelerated? Was dependency reduced? Did trust return? These are the questions that matter, and they require business voices to answer them honestly.
Perspective Shift
The Voices That Actually Matter Most
Perhaps the most important structural change the industry could make is deceptively simple: give business teams the platform to speak. Not about architecture. Not about governance frameworks. About their actual experience of making decisions with data. Whether the data they needed was available. Whether it arrived in time. Whether they trusted it enough to act on it without seeking reassurance from a data team.
If business teams were consistently given that platform, the industry would develop a far clearer and more honest understanding of what data product success actually looks like. It would become quickly apparent which organizations have genuinely transformed access and which have simply improved their ability to describe the transformation they intend to make.
The shift in perspective matters because it changes what gets measured and, ultimately, what gets built. When the engineer defines success, the metric is technical. When the business defines success, the metric is whether a decision was made faster, with greater confidence, and with less friction. Those are the outcomes that justify data investment.
The Questions Business Should Be Asking
Was the data available when I needed it?
Did I trust it enough to act without validation?
How long did it take from question to decision?
Did I need to involve engineering to access it?
Has anything actually changed in the last year?
Modern Data Stack
The Infrastructure Is Strong. But Something Is Missing.
Over the past decade, organizations have made significant and often substantial investments in modern data infrastructure. Technologies such as Snowflake and AWS Redshift provide scalable, performant environments for storing and processing data at enterprise scale. Governance platforms like Collibra and Microsoft Purview provide the structural layer: lineage, policy definition, cataloging, and classification. These are not trivial capabilities, they represent years of product development and genuine innovation.
Snowflake
Scalable cloud data warehousing and data sharing at enterprise speed
AWS Redshift
Managed analytics at scale, integrated with a broad cloud ecosystem
Collibra
Data governance, lineage, and policy definition across the enterprise
Microsoft Purview
Unified data governance spanning on-premises and multi-cloud environments
Individually, each of these layers is powerful. Together, they form a strong and credible foundation for enterprise data strategy. But there is a critical gap that none of them close on their own. They do not make data usable at the point of decision. They store it, govern it, and catalog it, but they do not activate it for the business teams who need it most.
The Missing Layer
The Activation Layer That the Data Stack Has Always Lacked
The modern data stack has been built from the bottom up. Foundations first, then governance, then, theoretically, consumption. But the layer where governed data becomes a usable business product, where a domain owner can shape and interact with data directly without engineering mediation, has never been systematically addressed. This is the activation layer. It is the space between governance being defined and governance being experienced. And for most organizations, it simply does not exist in a functional, accessible form.
What has been missing is the layer where governance moves from a document to a control, where a data contract is not a PDF but a runtime enforcement mechanism, and where the business can engage with data in the context of their actual decisions, not their technical infrastructure. Without this layer, even the most sophisticated data stacks produce the same outcome: data that exists but cannot be easily used.
Latttice
Latttice: The Data Product Workbench
Latttice was not built as a theoretical concept or as a reaction to an industry trend. It was built in response to something far more grounded: what the business has been consistently and clearly asking for. Simpler access. Less dependency on engineering for routine data needs. The ability to use data when it is needed, in the context it is needed, without barriers that erode both time and trust.
It is the result of actively listening to business teams across industries who have been explicit about what has not been working. Not the technical failures, the human ones. The inability to get an answer in time for a meeting. The requirement to submit a ticket for data that should be self-service. The loss of confidence that comes from receiving data without context or without the ability to validate it independently.
For Business Teams
Build and interact with data products directly, no engineering mediation required for governed, routine access
For Data Engineers
Focus on architecture, scalability, and innovation, not managing an operational queue of access requests
For the Organization
Data investment finally delivers value at the business level, activating what already exists rather than replacing it
Active Governance
Governance: Defined → Executed → Experienced
Latttice acts as the data product workbench, enabling business teams to build and use data products directly on top of platforms like Snowflake and AWS, while enforcing governance policies defined in systems such as Collibra or Microsoft Purview. The distinction matters: governance is no longer passive. It is executed at runtime. It is not a policy that sits in a document and is reviewed annually. It is a control embedded into the experience of using data.
Data contracts, in this model, are not agreements. They are mechanisms. They define what data can be used, by whom, under what conditions, and they enforce those conditions automatically, without requiring a human review step for every transaction. This is what active governance looks like in practice: not governance that is described, but governance that is operational.
Partnerships
Activating the Investments Organizations Have Already Made
One of the most consequential decisions in Latttice's design was the choice not to replace the platforms organizations have already invested in, but to activate them. Many organizations have spent years and significant capital building data foundations on Snowflake or AWS, and establishing governance frameworks in Collibra or Microsoft Purview. Those investments represent real commitment. The challenge has been that they have not been able to deliver value at the business level, not because they are inadequate, but because the activation layer was missing.
Snowflake
Latttice sits on top of Snowflake's data cloud, enabling business-led data product creation directly within the governed environment organizations have already built
AWS
Deep integration with AWS environments ensures that Latttice extends, rather than replaces, the scalable cloud infrastructure teams have invested in
Collibra
Governance policies defined in Collibra become runtime controls in Latttice, transforming passive definitions into active enforcement at the point of use
Microsoft Purview
Latttice activates Purview's governance definitions, ensuring that the policy framework organizations have built translates directly into the data product experience
Use Case
Banking and Regulatory Environments: Where Timing Is Everything
The impact of active governance and business-led data products becomes particularly clear in banking and regulatory environments, sectors where timely, accurate, and governed data is not a strategic aspiration, it is a compliance requirement. Regulatory reporting and risk management demand that data from multiple systems be aligned, validated, and trusted, often within tight reporting windows where errors have material consequences.
Traditionally, this process is complex, slow, and heavily reliant on engineering teams to aggregate, reconcile, and deliver the data required. Business and risk teams are positioned as reviewers of what engineering produces, rather than as active participants in building the data products that support their own accountability areas. The result is a process that is both slower than it needs to be and more fragile than it should be.
When a business domain can instead build a governed data product that brings these elements together, pulling from multiple systems, enforcing data contracts, and presenting validated, audit-ready output, the outcome changes fundamentally. Reporting becomes faster. Compliance becomes more reliable. Decisions can be made proactively rather than reactively. The value is not just in the accuracy of the data. It is in the timing. And in regulated environments, timing is often the difference between control and exposure.
Origin Story
Built From Business Need, Not Industry Trend
What Business Teams Said
"We can't get the data we need in time for the decision."
"We submit a ticket and wait. By the time it arrives, the moment has passed."
"We don't trust the data enough to act on it without checking with someone."
"We don't know what data exists or whether it's fit for our purpose."
"We need to be less dependent on IT for every single data request."
Latttice did not emerge from a product roadmap designed to respond to analyst recommendations or to capitalize on the momentum of the data product movement. 
It emerged from listening. 
From spending time with business teams, in financial services, in retail, in regulated industries, who were willing to describe, in unambiguous terms, what was not working in their current data environments.
The feedback was consistent across sectors and organization sizes. Business teams could not access data quickly enough to support real-time or near-real-time decisions. They were dependent on engineering for requests that should have been self-service. They lacked confidence in the data they received because they had no visibility into its provenance or quality. And they were aware, often acutely, that the gap between the data strategy being described at the executive level and the reality they experienced daily was significant.
Latttice was built to close that gap, not by building another layer of technical capability, 
but by making existing capability finally accessible to the people who need it most.
Proof Point
What a US Bank Senior Leader Said, and What It Meant
Recently, during a discussion with a senior leader at a major US bank, we received feedback that we have thought about carefully ever since. The leader told us that what they had seen was one of the most compelling data solutions they had come across. The comment was made directly, without qualification, by someone with deep experience evaluating enterprise data platforms and a clear sense of what the business actually needs to operate effectively.
We were genuinely humbled by that response, not because of the compliment itself, but because of what it represented. It was confirmation that the problem Latttice was built to solve is real, that it matters to senior leaders who are accountable for outcomes, and that an approach grounded in business usability rather than technical sophistication can resonate at the highest levels of an organization.
What stood out in that conversation was not the technical detail of the platform. It was the immediacy of understanding. A business leader could see, without extensive translation or a technical deep-dive, how Latttice would work for them, how they could use it within their existing environment, and how it would change the way their teams make decisions. That clarity, the ability to see oneself in the solution, is what we set out to achieve. And hearing it reflected back was a meaningful moment.
Voice of the Business
On the Point of Decision
"Data only becomes valuable when it reaches the point of decision. Until then, it is just potential."
— Cameron Price
This framing cuts through much of the complexity that surrounds enterprise data strategy. Organizations can debate architecture, governance models, and platform selection indefinitely. But the question that ultimately determines whether any of it has worked is simpler and more direct: did the data reach the person who needed it, at the moment they needed it, in a form they could act on?
When it does not, when data sits in a platform, technically governed and technically accessible, but practically unavailable to the business team making a time-sensitive decision, it has not yet delivered value. It has delivered potential. The gap between potential and value is where most organizations still live, and it is the gap that the activation layer is designed to close.
What Actually Matters
Business Outcomes, Decision Timing, and the Real Measure of Success
The business does not care about data products as a concept. It never did. What it cares about, what every senior leader, every domain owner, every operational team ultimately cares about, is whether the data they need is available when they need to make a decision. Whether the process of accessing it is simple enough that they do not abandon it in favor of less reliable alternatives. Whether they can trust what they receive without a lengthy validation process that delays action.
73%
Data Never Used
of enterprise data is never used for decision-making, per BARC research
67%
Miss Decision Windows
of data requests arrive after the decision window has already closed
3x
Faster Decisions
organizations with decision-ready data make decisions up to three times faster than those without
Success in data strategy should be defined by three outcomes: decisions made faster, decisions made with greater confidence, and decisions made with less organizational friction. Everything else, the architecture, the governance frameworks, the platform selections, is a means to those ends. When those outcomes are achieved consistently, the data strategy is working. When they are not, regardless of how sophisticated the underlying infrastructure is, the strategy has not yet delivered on its promise.
Final Executive Summary
The Expectation Is Now Clear, and So Is the Path Forward
The data product movement was right in its diagnosis and right in its prescription. Treating data as a product, aligning ownership to domains, and designing for business outcomes remains the correct direction. The industry's failure has not been in the strategy. It has been in the implementation. By building data products as engineering artifacts rather than business instruments, the sector has reproduced the same structural gap it set out to close.
Latttice exists to close that gap. Not by replacing what has been built, but by activating it. By providing the layer where governance becomes execution, where data becomes a usable business product, and where the business can finally participate in its own data future rather than waiting at the edge of someone else's engineering roadmap.
Data access is no longer optional. Decision-ready data is no longer optional. And anything that does not deliver those outcomes, regardless of how well it is architected, how elegantly it is governed, or how compelling the case study is. It is not transformation. It is just another layer.
The Problem
Business concept implemented as an engineering solution
The Gap
No activation layer between governance and business use
The Answer
Latttice, the data product workbench and activation layer
The Outcome
Decision-ready data, owned by the business, delivered on time
Join a Data Conversation
The challenges described here are not hypothetical. They are being experienced right now, inside organizations at every stage of their data journey. If what you have read reflects something of your own experience, or raises questions you have not yet found answers to, the conversation is worth having.
Lili Marsh and the Latttice team are actively engaging with senior leaders, CDOs, Heads of Data, and domain owners who are thinking seriously about what it means to make data genuinely usable for the business. Not in theory. In practice. At the point of decision.
Lili Marsh.
References
Sources and Further Reading
The arguments and evidence presented throughout this piece draw on a body of research, analyst work, and thought leadership from across the data and analytics industry. The following sources are referenced directly or inform the broader narrative.