Data products people use were the goal. AI needs products it can trust at the point of decision.

Executive Summary

The data product conversation is moving quickly.

For several years, the goal has been to move beyond datasets, pipelines, and dashboards toward reusable data products designed around genuine business needs. That shift matters. But AI is now raising the standard again.

It is no longer enough for a data product to be technically complete, well governed, discoverable, or even regularly used. The more important question is whether it carries enough trusted business understanding for a person or AI system to depend on it when a real decision needs to be made.

That means the data product needs more than data. It needs business context, meaning, ownership, quality, policy, lineage, appropriate-use rules, and governance that remains active through to the point of consumption.

This is becoming increasingly important in the conversations we have with customers and partners at Data Tiles. Organizations are under enormous pressure to move AI from experimentation into real business use, but the traditional enterprise data delivery model was never designed to operate at AI speed.

A business team identifies what it needs. Requirements are documented and interpreted. A technical team interprets them again. Data is sourced and engineered. A product is built. It returns to the business for testing. The business determines whether its original meaning survived the translation. Changes go back to the technical team, refinements are made, and the cycle continues.

That process can produce excellent data products. The problem is the time, repeated interpretation, and dependence on technical teams to translate business knowledge into something usable.

AI makes that increasingly difficult to sustain.

As Cameron Price argues in Building Intelligent Organizations, most enterprises can now build AI faster than they can explain themselves to it. Models and agents can be created remarkably quickly. The harder problem is supplying them with the approved definitions, business rules, ownership, context, policies, lineage, and accumulated judgment required to operate appropriately.

The bottleneck is shifting from the intelligence of the model to the ability of the enterprise to make its own business understanding available at the speed AI requires.

That is why we believe the data product itself is evolving.

A modern data product should increasingly be a context-rich, actively governed, reusable piece of trusted business understanding, built around a real decision and capable of serving people, applications, analytics, and AI.

Critically, the people who understand that decision should not have to remain downstream consumers waiting for technical teams to interpret their knowledge and build something for them. They need a practical way to participate directly in creating the trusted product, without becoming engineers themselves.

This is what we mean at Data Tiles by moving from a data-driven enterprise to a Decision-Driven Enterprise. The starting point is not the data available. It is the decision that needs to improve. From there, the organization works backward to the data, context, meaning, governance, and controls required to make that decision faster, better, and defensible.

A recent article by Hazel Saunders, Business Editor at The Ritz Herald, brought this direction into particularly sharp focus. How Enterprises Can Design Data Products That Business Teams Actually Use argues that technical completion is not success and that enterprises should ultimately be looking for workflow dependency: whether real business work has come to depend on the product.

That is an important argument.

Our Market Signal is that AI now takes it further.

The market is moving from data products people can discover and use, to data products the business can depend on, and now toward products carrying enough trusted business understanding for people and AI to depend on them at the point of decision.

That is a much higher standard.

And it is becoming urgent.

The Signal: Technical Success Is Not Business Success

Saunders begins with a useful challenge to the way organizations think about technical success. A data product can pass every technical review and still deserve to be retired if it has no dependable place in anyone's work. When the forecast begins, the pricing review starts, the campaign decision arrives, or a service intervention is required, people may still return to the spreadsheet, report, or analyst they already trust.

That distinction between technical completion and business usefulness is important because the market is clearly moving into broader data product adoption while still struggling to prove commensurate value. BARC and Actian report that operational use of data products increased from 48% in 2024 to 69% in 2026. Their research also found organizations with company-wide data products were 3.4 times more likely to successfully move AI projects into production.

KPMG's research provides another side of the picture. Its survey of 250 executives found that only 35% reported achieving extensive value from their data product initiatives.

In other words, enterprises are becoming more successful at having data products than they are at proving what those products changed.

Saunders' practical test is therefore stronger than another technical maturity measure. Does the product remove work from a recurring decision? If the user still has to search for information, interpret unfamiliar fields, request access, reconcile definitions, and rebuild the answer themselves, then the technical work may have moved, but the business problem has not really been solved.

This is exactly the kind of issue we see in customer and partner conversations. There is often no shortage of data. There is usually no shortage of platforms either. Enterprises may already have warehouses, lakehouses, governance platforms, catalogs, BI environments, cloud platforms, analytics tooling, and increasingly AI infrastructure. Yet the person responsible for a decision can still be waiting.

The infrastructure is not necessarily failing. The gap is between that infrastructure and the moment somebody actually needs to decide.

That is where the data product conversation becomes much more important.

Start With the Decision, Then Work Backward

One of the strongest arguments in the original article is its recommendation to reverse the normal design sequence. Many organizations begin with available data. They inventory tables, clean fields, create semantic structures, assign ownership, build catalog entries, and make the data discoverable. The user often enters the process after many of the important design choices have already been made.

The alternative is to begin with the recurring business task. Who is doing the work? What are they trying to decide? Which inputs do they gather? Which definitions create arguments? Which manual steps consume time? Which exceptions force another team to become involved? Which information arrives too late?

The example Saunders uses makes the difference clear. “Sales analytics” is vague. Giving regional sales leaders a trusted view of renewal risk before a Monday pipeline review is specific enough to design against because it identifies the user, timing, purpose, and consequence of failure.

This is closely aligned with the Data Tiles point of view.

In the Decision-Driven Enterprise, work begins with a named decision and a named owner, not with a dataset or dashboard request. If nobody can say which decision should improve, there is a legitimate question about why the work should begin at all.

That changes the sequence completely. Instead of starting with what data the organization has and hoping value eventually emerges, we begin with what someone needs to decide. Then we work backward to what they need to know, which information supports that understanding, what business context gives it meaning, what quality threshold is appropriate, which policies apply, who owns it, and how that understanding should be delivered at the point of work.

It moves the purpose of data from supply to decision.

AI Makes the Speed Requirement Impossible to Ignore

This is where the argument moves directly into the here and now.

Enterprises have spent years accepting a delivery model based on translation and handoff. The business identifies a need. Requirements are written. An analyst interprets them. A data team interprets them again. Engineering builds something. The product returns to the business. The business tests whether the technical implementation reflects the original intent. If it does not, the cycle starts again.

That cycle can work when the organization has time.

AI changes the time available.

Business leaders are being asked to identify AI opportunities now. Agents are being assembled now. New use cases are appearing faster than traditional engineering backlogs can absorb them. The cost and complexity of creating AI capability have fallen rapidly, which means demand for trusted enterprise information is increasing faster than the traditional delivery model was designed to handle.

Cameron Price gets to the heart of this in Building Intelligent Organizations. The constraint is increasingly not whether an organization can access an AI model. It is whether the organization can articulate its own business understanding in a form AI can reliably consume.

AI can process information at machine speed, but the enterprise still has to explain which definition of revenue applies, which customers are in scope, what constitutes risk, which policies restrict use, who owns the number, whether the source is current, and whether the information is appropriate for the question being asked.

Those things are not model capabilities.

They are enterprise knowledge.

If every AI use case has to rediscover and reinterpret that knowledge through another lengthy business-to-technical handoff, the organization will repeatedly hit the same wall.

Speed is therefore no longer simply a productivity issue.

It is becoming an AI-readiness issue.

The Handoff Model Does More Than Slow Things Down

The problem with the traditional delivery cycle is not only time. It is the loss of business meaning through translation.

Business knowledge is nuanced. An experienced supply chain manager knows that one supplier delay is ordinary while another is a genuine operational warning. A finance leader understands why two measures that appear almost identical are approved for very different uses. An operations manager may know that a small movement in one particular metric is more significant than a much larger movement somewhere else. A customer team understands why two customers with the same apparent numbers require completely different actions.

Much of that understanding never lives cleanly in a database.

It sits in people's experience, local spreadsheets, documentation, conversations, policies, business glossaries, and sometimes simply in the sentence:

“That is technically correct, but that is not how it works here.”

Traditional delivery models ask technical teams to interpret this context and convert it into a product. The business then tests whether that interpretation was correct. The process is effectively a long feedback loop attempting to reconstruct business understanding after it has been separated from the people who possess it.

That was inefficient before AI.

At AI speed, it becomes structural friction.

Business-Led Changes Who Can Participate

This is why business-led data products matter to us at Data Tiles.

Business-led does not mean technical teams disappear. It does not mean business users suddenly become engineers. And it does not diminish the importance of architecture, integration, security, governance, reliability, performance, or the platforms enterprises have already invested in.

It changes who can participate directly in creating the product.

Technology teams continue to provide and operate the trusted enterprise foundation. Governance teams establish policies and controls. But the people who understand the business decision do not have to remain passive consumers waiting at the end of an engineering queue.

They can participate directly in defining what the product means, which data matters, what context is important, what quality is appropriate, which policies apply, and what needs to be visible when the product is used.

That reduces the number of times business understanding has to be translated.

The Decision-Driven Enterprise describes this shift explicitly: from engineer-led delivery, where the business raises a ticket and waits for a queue, to business-led delivery, where the people who own the decision can build and own the data product without code.

Zero-code therefore matters for a much deeper reason than convenience.

Business knowledge should not have to be translated into code before it can become enterprise capability.

Code still matters enormously. Engineering still matters enormously.

But a finance expert should not need to become an engineer before finance knowledge can become reusable. A supply chain specialist should not need to become an engineer before supply chain context becomes reusable. And a customer leader should not need to become an engineer before customer understanding can become consumable by AI.

That is the opportunity business-led creation opens.

Data Alone Is Not AI-Ready

AI makes another distinction increasingly important.

Access to data and understanding data are not the same thing.

A model can be given access to a hundred tables and still not know which definition applies to the decision in front of it. It can retrieve customer records without knowing which classification is authoritative. It can see a sensitive field without understanding whether policy permits that field to be used in a particular action. It can retrieve supplier performance without understanding which exceptions actually matter operationally.

Enterprise AI therefore consumes far more than information. It depends on business meaning, governance, context, semantics, ownership, lineage, and demonstrated trust. Taken together, these form what we describe at Data Tiles as trusted business understanding.

That is the difference between data the organization stores and knowledge the organization can safely act on.

And it is exactly why context-rich data products become so important.

A modern data product should increasingly carry not only the relevant data but enough approved enterprise understanding to explain what that data means, who owns it, how it can be used, how current it is, which definitions apply, where it came from, and what governance remains attached to it.

That is what makes the product useful to a person.

It is also what makes the product useful to AI.

Context Is More Than a Technical Relationship

There is a lot of discussion across the market now about context, semantics, and semantic layers. That is encouraging, but those terms can mean very different things.

Technical relationships are important. Schemas are important. Entity relationships are important. Catalog metadata is important. Ontologies can be important.

But enterprise context is often much richer than any of those things.

Why does the business use this particular definition? Under what circumstances does it change? Which exceptions matter? Who is accountable for the measure? Which policy governs its use? How fresh must it be? What is it allowed to inform? Which interpretation would an experienced business owner reject even if it looked technically plausible?

Those answers are business understanding.

And the people who know them are often not technical specialists.

This is why the enduring enterprise asset in AI is not simply the model or agent. Models will change. Agents will change. The accumulated business understanding of the enterprise is far more specific and far harder to reproduce.

Cameron's argument in Building Intelligent Organizations is that competitive advantage will increasingly come from organizations that can capture that understanding once and allow people, applications, analytics, and AI to reuse it.

A context-rich data product is one practical way of turning that understanding into reusable enterprise infrastructure.

Active Governance Has to Reach the Point of Decision

The second major requirement is governance.

It is no longer enough for a data product to have been governed at some point before publication. If the product is going to support a real human or AI decision, governance needs to remain attached when the information is consumed.

This is what Data Tiles means by active governance.

Ownership, quality, sensitivity, policy, and controls become attributes of the product itself rather than information held separately in documentation. Governance travels with the product whether it is consumed in a report, an API call, an application, or an AI agent.

That distinction becomes especially important with AI.

A human user may encounter ambiguity and stop. They may call another person, check a policy, question a definition, or decide something does not look right.

An AI agent can act repeatedly and at machine speed.

The governance therefore cannot simply describe what should happen.

It increasingly needs to shape what can happen.

For AI, that is not a nice-to-have.

It is part of making the resulting decision traceable and defensible.

From Workflow Dependency to Decision Dependency

One of Saunders' strongest ideas is the distinction between discovery, repeat use, and workflow dependency. At the highest level, a recurring business process or decision relies on the product, and removing it would create visible friction, delay, or risk.

We think that progression can now go one step further:

Discovery → Repeat Use → Reuse → Workflow Dependency → Decision Dependency

A product reaches decision dependency when an important human or AI decision can repeatedly rely on the trusted business understanding it carries.

That gives enterprises a much stronger test than product count or monthly active users.

Take a data product and imagine switching it off tomorrow.

What decision becomes harder? What workflow slows down? What manual reconciliation returns? What business risk increases? Which customer outcome deteriorates? Which AI agent loses a trusted input?

If the answer is essentially nothing, then usage alone may be telling us very little about value.

Gartner has arrived at a closely related conclusion from a measurement perspective. Its May 2026 research argues that technical indicators alone do not demonstrate the business impact of data products and recommends outcome-driven metrics tied to realized value.

The industry is moving from asking whether we built the product, to whether somebody used it, to whether the business can actually depend on it.

The Economics Come From Reuse, Not Product Count

Decision dependency should not mean creating a separate bespoke product for every individual decision.

The value of the product model comes from reuse.

McKinsey makes this point clearly in The Missing Data Link: Five Practical Lessons to Scale Your Data Products. Its work argues that the objective is not simply better data but greater business value, and that the economics improve as trusted products support additional use cases. McKinsey describes a flywheel in which reuse lowers incremental cost and accelerates value capture.

McKinsey's examples illustrate the point. At one telecommunications company, it estimated that 60% to 80% of the initial data team's effort spent finding, preparing, and quality-assuring data was one-time work that did not need to be repeated for subsequent use cases. At an international consumer company, a reused data product supporting five use cases had projected costs approximately 30% lower than building five individual pipelines.

That changes how leaders should think about product portfolios.

The objective is not maximum product count. It is maximum trusted reuse.

Build the understanding once. Govern it properly. Make the context explicit. Make it reusable. Then let more decisions inherit that work.

That is where the economics begin to compound.

AI Makes Reuse Even More Valuable

AI amplifies this because enterprises cannot afford to rediscover the same business knowledge every time another agent or use case appears.

Yet this is exactly what often happens today.

A new AI initiative begins. Business experts are pulled into another workshop. Definitions are debated again. Policies are rediscovered. Ownership is clarified again. The same context is encoded in another prompt, application, or project. Then a different team begins another initiative and repeats much of the same work.

That does not scale.

The better model is to capture business understanding in a form that can be reused across people, applications, analytics, and AI.

The BARC and Actian findings are therefore particularly interesting. Organizations with company-wide data products were 3.4 times more likely to successfully move AI projects into production.

Correlation is not proof of causation, but the direction makes sense. Organizations that already know how to package data with ownership, reliability, quality expectations, and reusable structure are better positioned to support AI than organizations rebuilding trusted inputs for every new project.

The next step is making those products richer still by carrying the business context, semantic understanding and active governance AI needs to reason and act appropriately.

This Is What We Built Latttice For

This is the practical problem behind Latttice.

Most enterprises do not need another initiative that begins by replacing the platforms they already own. They already have warehouses, lakehouses, governance systems, catalogs, BI tools, cloud infrastructure, and analytical platforms.

The gap often appears after all of that investment.

A business owner still has a question.

A decision still needs to be made.

And somebody still has to assemble the trusted understanding required to answer it.

Latttice is our zero-code Data Product Workbench. It allows business and domain teams to work alongside data and governance teams to assemble governed, reusable data products across the existing enterprise environment without writing code.

The important point is not simply that Latttice is easier to use.

The point is that the person who understands the business decision can remain much closer to the creation of the product.

That reduces interpretation. It reduces waiting. It captures context while it is still in the hands of the people who understand it. Active governance is applied to the product and travels with it. And the resulting trusted understanding can be reused rather than rebuilt for every new requirement.

This is how the Decision-Driven Enterprise moves from a philosophy into software.

Explore Latttice

Lenz Extends That Trust Into AI

Once trusted products exist, the next question is what can consume them.

That is where Lenz fits.

The Decision-Driven Enterprise deliberately moves away from a model where AI is pointed at whatever data can be reached and trust is assumed. Instead, AI can be built around governed data products so the resulting decision has a trusted foundation.

Latttice creates the trusted, governed data product.

Lenz allows AI agents to work from those trusted products.

That sequencing matters because we do not believe the enterprise should begin by connecting AI indiscriminately to everything and asking it to infer what the organization means.

Start with the decision.

Assemble the trusted business understanding required for that decision.

Apply active governance.

Make the product reusable.

Then let AI inherit that trust.

That is a much more practical route to enterprise AI.

The Path Is Becoming Clear

This is why Saunders' article felt worth responding to.

Its argument would have been relevant several years ago.

In the AI era, it has become urgent.

Enterprises cannot continue waiting months every time a new AI use case exposes another missing piece of business context. They cannot indefinitely rely on technical teams to reinterpret business meaning for every build. And they cannot reasonably expect AI to infer enterprise-specific definitions, judgment, governance, and policy from raw information.

The path is becoming clearer.

Start with the decision. Bring in the people who understand that decision. Let them participate directly in defining and building the trusted product. Capture the context and semantic understanding that make the data meaningful. Apply governance actively so it remains attached through to consumption. Make the product reusable. Then let people, applications, analytics, and AI consume the same trusted understanding.

That is the shift from supplying data to serving decisions.

And it is the foundation of the Decision-Driven Enterprise.

The Market Signal

Hazel Saunders asks how enterprises can design data products that business teams actually use.

We think it is exactly the right question.

But AI is raising the standard.

The market now needs data products that are business-led, context-rich, semantically meaningful, actively governed, reusable, and trusted through to the point of decision.

The organizations that achieve that will not need to reconstruct business knowledge every time another AI initiative starts. Their AI will inherit understanding the enterprise has already created. Their people will spend less time reinterpreting the same definitions. Their governance will remain attached to the product rather than disappearing at consumption. And every new decision will be able to begin from a stronger foundation than the last one.

This is what Cameron means when he describes intelligent organizations as organizations where trusted business understanding becomes reusable enterprise infrastructure rather than something repeatedly reconstructed around individual projects.

So the next generation of data products will not be judged simply by whether people use them.

They will be judged by whether people and AI can confidently depend on them to decide.

And organizations still relying on months of business requirements, technical reinterpretation, engineering build, business testing, adjustment, and rebuild for every new use case will increasingly find that AI demand is moving faster than their delivery model.

That is the signal we took from Saunders' article.

And it is one we see repeatedly in conversations with customers and partners across APJ.

Data products people use were the goal. AI needs products it can trust at the point of decision.

The Executive Test

There is a simple way to test whether a data product strategy is moving in this direction.

Do not begin by counting products, datasets, dashboards, agents, or catalog entries.

Bring one important decision that is currently slow.

Ask who owns it. Ask what that person needs to know. Ask which definitions matter. Ask what context an experienced employee applies without thinking. Ask which policies govern the decision. Ask how long it currently takes to move from question to trusted answer. Ask how many technical handoffs are required. Ask whether the same work will have to be recreated when the next team or AI agent needs it.

Then ask the harder question.

Could that trusted understanding be created directly by the people who know the business, actively governed, made reusable, and available to people and AI in hours rather than months?

If the answer is yes, the enterprise is beginning to move beyond simply being data-driven.

It is becoming decision-driven.

And that is increasingly the infrastructure AI actually needs.