Somewhere on the road to becoming data driven, most organizations quietly assigned a business responsibility to a technical team. We asked data engineers to interpret business needs, define business meaning and build almost every data asset used for decisions. That created a costly translation layer between the people who understand the decision and the people asked to build the product. It worked, more or less, when the audience was a monthly report. It does not work now that AI is on top, because AI exposes the limits of that operating model with unusual speed and requires accurate meaning, ownership, policy and context at enterprise scale.
A model that no longer fits
Data engineers are exceptional at what they were hired to do. They build scalable, secure, reliable platforms, and they understand systems, architecture, performance, connectivity and observability at a depth that a business owner will rarely match. That is a genuine and specialized capability, and nothing in this article is an argument against it.
Business domain experts understand a different thing. They understand consequences. They know which customer exception matters, which operational delay is normal, which margin change requires action this week, and which business definition has quietly changed since the last steering committee. That context is dynamic. It cannot be completely captured in a requirements workshop, a data dictionary or a static specification, no matter how carefully those artifacts are written. Technical expertise and domain expertise are different capabilities, equally valuable, and the way most organizations are structured today asks engineers to carry both.
Zhamak Dehghani made this point sharply in her 2019 essay on moving from a monolithic data lake to a distributed data mesh, and expanded it in her 2020 piece on data mesh principles. Centralized data teams cannot hold the context for every domain they serve. Treating data as a product means putting ownership where the domain knowledge already lives, inside the business.
"To decentralize the monolithic data platform, we need to reverse how we think about data, its locality and ownership. Instead of flowing the data from domains into a centrally owned data lake or platform, domains need to host and serve their domain datasets in an easily consumable way."
Zhamak Dehghani, 2019.
The hidden cost of translation
Anyone who has watched an engineer led delivery cycle up close knows the pattern. The business explains a requirement. An engineer interprets it. A product or report is built. The business reviews it. Context or logic has been misunderstood in some small but material way. The work is revised, tested and released again. Sometimes the loop closes after two rounds. Often it takes many more, and by the time it does, the business question itself has moved.
The cost of that loop is not just the rebuild. It is the repeated discovery meetings, the requirements documentation, the clarification sessions, the duplicate products created by different teams that never quite agree on a definition, and the business leaders who spend more time advising a technical delivery queue than performing the work they were actually hired to do. Engineers, in parallel, spend their time interpreting business terminology rather than improving platform security, connectivity, reliability and performance where their expertise compounds. The cost is not only the cost of rebuilding a report or product. The larger cost is the value lost while the business waits to make the decision.
Decision latency is the cost nobody measures
Decision latency is the time between recognizing that a decision is needed and having trusted information available to make it. It rarely appears on a finance report, but it shapes almost every business outcome. A supply issue that waits for another product revision. A pricing decision that waits for the next engineering sprint. A regulatory submission that waits for a clarification cycle. A customer retention action that arrives after the customer has already left. In each case the technical work eventually completes, and in each case the value of completing it has been eroded by the time it takes to get there.
Business led data products compress this latency because the people closest to the decision can create and adjust the product without passing every contextual change through a technical delivery queue. This does not remove technical controls. Business freedom operates inside an approved, secured and governed platform. What changes is who is allowed to move first when the meaning of the business changes.
Context is the differentiator
A data product is only valuable if it answers the right question, at the right time, for the right person. Accurate data without business context can still produce the wrong decision. Finance knows whether a margin change is meaningful or temporary. Operations knows whether a delay is expected or requires intervention. Marketing knows whether an active customer definition still reflects the current strategy. Risk and compliance teams know which rules must be applied before data is shared or used, and they know when those rules have changed. That knowledge often shifts faster than a conventional technical release cycle can accommodate.
The distinction that matters is simple. Engineers understand how data moves. The business understands what the data means and what should happen next. Both are indispensable. Neither is a substitute for the other.
Why business led costs less
McKinsey has been documenting the economics of this shift for several years. In its 2022 article on managing data like a product, Desai, Fountaine and Rowshankish reported that organizations treating data as a product could deliver new use cases up to 90 percent faster and reduce total cost of ownership by up to 30 percent. The savings do not come from asking anyone to work faster. They come from reuse, reduced duplication, fewer interpretation cycles, clearer ownership and less rebuilding.
McKinsey extended the argument in its April 2025 piece on scaling data products. In one example, a reusable data product supporting five use cases was projected to cost approximately 30 percent less than building five separate pipelines. When the same product was expanded into another market, projected costs were approximately 40 percent lower. These are findings and projected examples reported by McKinsey, not guaranteed Latttice customer outcomes, but they describe the underlying economic pattern very precisely. Platform investment becomes reusable, while business logic is owned and evolved closer to the decision.
Engineers build the platform. The business owns the product.
This is a promotion for engineering, not a demotion. Business led data products increase the strategic value of the platform team, because engineers are no longer expected to act as permanent translators between technical systems and every business domain. Their time can be spent on platform reliability, security, connectivity, performance, observability, scalability, reusable services and the enterprise standards that determine what the whole organization can safely do next. That is where engineering expertise compounds, and where its cost per unit of value falls fastest.
Business teams, in turn, take responsibility for the things they already understand better than anyone else. They own the business definitions, the decision logic, the purpose of a product, its intended consumers, its quality expectations, its appropriate use and its ongoing evolution as the organization changes. This is a separation of responsibilities, not a separation of teams. Business teams should not be expected to become engineers, and engineers should not be expected to become experts in every business decision.
Governance must begin during the build
Most enterprise governance programs are, in practice, retrospective. They attempt to document, classify, certify or secure something after it has already been created, usually in a separate tool, with a separate team, on a cadence that lags the pace of the business. Active governance is different. It applies ownership, access, policy, quality expectations, lineage, business definitions and appropriate use while the product is being created, and again when it is consumed. Governance should not live in a document that becomes outdated the moment it is signed off. It should travel with the data product itself.
The National Institute of Standards and Technology takes the same broad position in its AI Risk Management Framework and in the 2024 Generative AI Profile that accompanies it. Governance is treated as a continual and intrinsic responsibility across the AI lifecycle, not a stage that happens once at the end. NIST does not endorse any particular product or operating model, but the underlying principle applies directly to enterprise data. Governance that is bolted on after the fact is governance that has already failed.
Why this is the future of decision making
A decision driven enterprise does not start from what data it happens to have. It starts from three questions. What decision are we making? Who owns it? What information must be trusted for that decision to be made responsibly? Business led data products are the unit that makes those questions answerable, because they are designed from the outset around a clear consumer, a defined business purpose and an intended action.
That is very different from a technical asset that happens to be accurate and available. A well built pipeline can deliver correct numbers to a dashboard that no one uses to make a decision, or that several teams interpret in incompatible ways. A business led product carries the definition of active customer, qualified opportunity or on time delivery once, agreed by the people who own the decision, and reuses it everywhere. Governance travels with the product rather than living in a separate document. When the business changes, the product changes where the change is understood, not at the end of a technical release cycle.
Why this is the future of AI
AI does not create missing business context. It consumes the definitions, relationships, permissions and quality conditions it is given. If those inputs are incomplete or ambiguous, AI can scale the ambiguity faster than any human reporting process. AI agents are a more demanding class of consumer than traditional analytics, because they may recommend actions, initiate workflows or interact directly with business systems. That raises the bar on ownership, policy, provenance, appropriate use and trusted business definitions, all at once.
McKinsey made the same point in its June 2025 work on seizing the agentic AI advantage. Organizations seeking to scale agentic AI have to move away from separate use case pipelines and toward reusable data products, and they have to extend governance to a broader range of enterprise data than they have historically touched. Its May 2025 article on the new economics of enterprise technology in an AI world reinforces the same direction of travel.
Gartner has put numbers to what happens when this foundation is missing. In July 2024, Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, rising costs and unclear business value. In January 2026, Gartner reported that at least 50 percent of generative AI projects had actually been abandoned by the end of 2025 for those same reasons. Not every failed AI project failed solely because it lacked business led data products. But the reported causes reinforce the need for owned, governed, reusable data foundations rather than one off extracts assembled beside the model.
AI cannot reliably determine which of several similar metrics represents the approved business definition unless that meaning and authority are carried with the data product. That is the core reason a business led data product acts as a trusted interface between enterprise data and AI. Call it, in shorthand, a Data Plugin for AI. In practical terms it means the product carries a named owner, a defined purpose, approved business meaning, access policies, quality expectations, lineage and provenance, and the conditions for its appropriate use. Business ownership is not a shortcut around governance. It is the mechanism by which governance stays close enough to the meaning of the data to remain accurate.
The best data product is the one that gets used by people and by AI, not the one that was coded in a silo.
Where Latttice fits
Latttice is a zero code Data Product Workbench. It lets business teams create, govern, share and use trusted, fit for purpose data products on top of the data platforms and systems the organization already operates. There is no rip and replace program. Engineers continue to own and improve the underlying platform. Business teams create products within the access, security and governance boundaries the organization has already approved. Governance is active during creation and during consumption, and products can support human decisions, reporting, analytics and AI from a single, consistently governed source.
Latttice does not claim that every product is automatically ready for every AI use case. It claims something more accurate and more useful. Products are created with the ownership, context and governance needed to support responsible use by people, by analytics and by AI. That is what the Data Plugin for AI idea means in practice. A product built in Latttice knows who owns it, what it means, who is allowed to use it, how its quality is measured and how it has been produced, and it carries all of that with it into every place it is consumed.
The previous era of enterprise data focused on centralizing and connecting. The next era will focus on putting trusted data products into the hands of the people closest to the decision, while maintaining enterprise governance and a strong technical platform underneath. Engineers build the platform. The business owns the product. Governance stays active across both. AI consumes governed products rather than ambiguous raw data. Competitive advantage in the next decade will not come simply from possessing more data. It will come from preserving better business context, turning that context into trusted data products, and making those products available at the point of decision.