Why Is It Still So Hard to Turn Data Into Better Business Decisions?

Why is it still so hard to turn data into better business decisions?

For those of us who have spent our careers in data and analytics, I think the answer is uncomfortable. We have spent decades designing from the data forward. We centralized, integrated, modeled, governed, cataloged, moved to the cloud, decentralized ownership, turned datasets into data products, and now we are making those products available to AI. Every one of those advances solved a real problem, yet one thing has remained remarkably consistent: we still start with the data.

The decision remains downstream.

That was workable when the primary destination for enterprise data was reporting and analytics. A person sat between the information and the decision and supplied much of the context the architecture didn't. An experienced employee knew which definition mattered, which source to trust, which exception applied, what had happened previously and who to ask when something didn't make sense. Much of the knowledge required to make a good decision therefore existed in the organization, but not necessarily in the data architecture.

AI changes that assumption.

An AI agent cannot compensate for organizational fragmentation in the same way as an experienced employee. Unlike a human, it isn't able to spend three days asking six teams where the right information lives, and it doesn't inherently know which business definition is authoritative, which policy applies, what it is permitted to see or which evidence matters. That context has to be made available to it.

Giving AI access to more enterprise data doesn't solve the problem. In many cases, it amplifies it. If we want AI to reason and act closer to the point of decision, trusted context has to be available at the point of decision.

That requires us to change where we start.

Start with the decision. Work backwards to the data.

We designed from the data forward

There is a good reason the industry arrived here. Enterprise data architecture evolved to solve the problems immediately in front of it: integration, scale, quality, governance, access, ownership and reuse. The emergence of data products represented an important step forward because it encouraged organizations to think about data as something designed for consumption rather than simply something produced by a technical function.

Data mesh moved that thinking further by challenging centralized ownership and bringing responsibility closer to domains with the business knowledge required to understand the data. Thoughtworks has consistently connected that model with domain ownership, product thinking and federated governance. McKinsey has similarly argued for data products anchored to high-value business use cases and measurable outcomes rather than isolated technical assets.

These are important advances, but I believe AI now requires us to take the next step.

Instead of making the data product the organizing principle, make the decision the organizing principle.

The distinction sounds subtle, but it changes the questions we ask and therefore what we build. Starting with the data naturally leads us to ask what data we have, how it should be modeled, who owns it, how it should be governed and how it should be made available. Starting with the decision forces a different question: what does someone need to know to make this decision well?

That still takes us back to the data. The difference is that the data now has a purpose before we start building.

The decision changes the architecture

At the Industry Summit on Data Product-Oriented Architectures in Antwerp in September 2026, I presented this argument under the title Stop Building Data Products in the Data Team: Bringing Data Closer to the Decision. I used a deliberately simple example to demonstrate what changes when the decision, rather than the data, becomes the starting point.

At 10:17am, a claim lands on Sarah's desk. She has one decision to make: should this claim be investigated?

If we begin with the available claims data, the conversation naturally moves toward integration, modeling and presentation. If we begin with Sarah's decision, the conversation is very different. What happened? Has it happened before? What looks unusual? What does policy say? What evidence supports further investigation? What should happen next?

Those questions allow us to work backwards. What context does Sarah need? What evidence supports it? Which rules apply? Where does the information live? Which definitions are trusted? What is Sarah permitted to see?

Sarah doesn't need every piece of claims data the organization holds. She needs the complete, governed picture relevant to the decision she is accountable for making.

That is a fundamentally different design problem, and it exposes something important about the way enterprise data has traditionally been organized. We built sophisticated supply chains to move data from its source, through platforms, engineering, transformation and governance, into reports, applications and increasingly data products. Only then did it reach the person responsible for producing a business outcome.

We designed from the data forward. The decision became the last mile.

AI makes the last mile impossible to ignore

People have been remarkably effective at compensating for that last mile. They move between systems, interpret reports, apply experience, understand organizational language, recognize exceptions and ask colleagues for missing information. Much of what we call business judgment comes from combining formal evidence with context accumulated through experience.

AI changes the requirement because we are increasingly asking technology to operate much closer to the decision itself. The emerging discipline of context engineering reflects this shift. BARC's research into agentic AI identifies metadata, semantics, retrieval, integration and orchestration among the elements required to provide AI with reliable context. Its work also points toward an important evolution in metadata management: moving beyond catalogs as places where people discover information toward making context available when AI actually consumes that information.

This distinction matters at an executive level because access and context are not the same thing. An organization can invest heavily in connecting AI to enterprise information without giving AI enough understanding to use that information appropriately. Access tells an AI system what information exists. Context helps establish which information matters, what it means, how it relates to other information, which rules apply and whether it should be used for the decision in front of it.

The question for leadership therefore isn't simply whether enterprise data is available to AI. It is whether that data can arrive with enough context, meaning and governance to support a trusted decision.

Context, meaning and governance

When we design backwards from the decision, these three requirements become much clearer.

Context brings together what the decision actually requires: structured information, history, documents, external information and relevant business signals. The objective isn't to give someone, or an AI system, all the data. It is to provide the data relevant to the decision.

Meaning makes that information understandable: what does it mean, how is it related, which definition is trusted, and what does a particular value mean in this business context? These aren't questions we can assume every consumer will resolve independently. Meaning has to travel with the information.

Then there is governance. Who can see the information? What are they permitted to see? Which policies apply? Where did the information come from? Can we explain how it contributed to a recommendation or decision?

Governance cannot be a process sitting around the product. It has to operate when the product is created and when it is consumed. That becomes particularly important when the consumer isn't a person.

For boards and executive teams, this is an important distinction. Enterprise governance may be well defined at the policy level, yet the real test comes much further downstream: can those policies actually operate when a person, application or AI agent is using the information to make or support a decision?

One governed context. Many decision experiences.

Once context, meaning and governance travel with a data product, another opportunity appears. We shouldn't have to recreate the trusted foundation every time the organization wants to use the same information differently.

A human might use that context through one experience, while BI presents another. An application can consume it directly. An AI assistant can reason over it, and an agent can use it within a workflow. The experiences are different, but the governed context underneath them doesn't have to be.

This is where I believe the data-product and AI conversations need to converge. Rather than repeatedly building products around individual outputs, we can create trusted products around the business context required for a decision and make that context reusable across the experiences that support it.

Build once. Govern once. From BI to AI.

This isn't about forcing every consumer into the same interface or technology. It is about separating trusted business context from the experience through which that context is consumed. Interfaces will change. Models will change. AI capabilities will change. The decision provides a more durable organizing principle.

A data product is not a table

This also requires us to be more precise about what we call a data product. A table isn't a data product simply because we give it that label. Neither is a pipeline, a dashboard or a collection of fields.

A useful data product brings together what is required to serve a business purpose. A decision-centric data product goes further by bringing together the context, meaning, evidence and governance required to support a particular decision.

Return to Sarah. A decision product supporting claim investigation could bring together claim history, risk indicators, relevant policy, previous interactions and supporting evidence. That governed context could support Sarah directly, feed an application, provide evidence to BI or give an AI assistant or agent the context required to help with the investigation.

The interface isn't the product. The trusted, governed context assembled around the decision is the product.

That is also what makes genuine reuse possible. One governed context can support many decision experiences without requiring the organization to rebuild the meaning, evidence and governance every time a new consumption channel appears.

Stop asking the data team to build every answer

This brings me to the deliberately provocative part of the argument: stop building data products in the data team.

I don't mean remove the data team. Quite the opposite. I mean stop expecting the data team to independently determine every product the business needs and then build every answer for it.

The business understands the decision and its consequences. The data team understands the evidence, architecture and controls. The AI or application team understands how information will be consumed and acted upon. Design together around the decision.

This extends the logic behind domain ownership. The people closest to the business problem possess context that is difficult to capture if product design begins somewhere else. They understand the exceptions, trade-offs, terminology and consequences surrounding the decision. Bringing that knowledge into product design doesn't mean turning business users into data engineers.

The emergence of zero-code and AI-assisted development makes a different operating model increasingly possible. Business teams can participate directly in defining and creating the trusted information products they need, while data teams provide the architecture, governance, standards and foundations that keep those products secure, reliable and reusable.

That changes the role of the data team in an important way. Instead of being the factory responsible for building every answer, it becomes the capability that enables the enterprise to create trusted answers.

For senior leaders, this is not simply a technology question. It is an operating model question. If every new decision, use case or AI initiative has to enter the same centralized engineering queue before the business can act, the organization has created a structural constraint on the speed at which data can produce value.

The decision didn't change

Go back to Sarah. Her decision remains exactly the same: should this claim be investigated?

What changes is the distance between that decision and the information required to make it. Instead of Sarah assembling the picture herself from multiple systems, reports, documents and colleagues, the relevant history, risk, policy, previous interactions and evidence can come together around the decision.

Instead of the decision chasing the data, the context comes to the decision.

The decision didn't change. The distance to the information did.

And that gives leadership a much better way to determine whether investment in data is actually creating value.

Measure the decision, not the data product

The number of data products an organization has created is not a business outcome. Neither is the number published to a marketplace, the number of datasets connected to an AI platform or the number of employees with access to a new tool.

The more important question is: did the decision improve?

Did it take less time to prepare? Did the person making it need to visit fewer places? Were manual handoffs reduced? Did consistency improve? Did adoption improve? Did specialist dependency fall? Did the resulting business outcome change?

Those measures create a direct line between investment in data and business value.

Gartner has warned about data products becoming redundant when they fail to achieve sufficient consumer adoption. The broader lesson is that a technically excellent product that doesn't improve something the business cares about remains a product looking for a problem.

Starting with the decision reverses that logic because the outcome is defined before the product is built.

Four questions I would ask

None of this requires an enterprise-wide transformation program on day one. I would start with one recurring decision and ask four questions.

1. What decision? What specific recurring decision are we trying to improve?

2. What context? What does someone need to know to make that decision well?

3. What evidence? Where does that information live today, and what evidence should the decision be based on?

4. What outcome? How will we know the decision improved?

The decision needs to be specific. Not improve claims management, but should this claim be investigated? Not improve manufacturing, but should we intervene on this asset now? Not improve supply chain, but which late shipment needs intervention today?

If answering one recurring business question requires five systems, three reports and two manual workarounds, you've probably found a good place to start.

Build backwards.

From data-driven to Decision-Driven

For years, organizations have aspired to become data-driven. AI forces us to be more precise about what we're actually trying to achieve.

An organization doesn't create value because it owns more data, because more people can query it or because an AI model can access it. Value is created when trusted information contributes to a better decision and that decision produces a better outcome.

That's the shift from simply being data-driven to becoming Decision-Driven.

A Decision-Driven Enterprise doesn't replace its data platform or discard the investments already made in cloud, governance, catalogs, analytics or data products. It makes those investments work harder. The platform provides access to the data. Governance provides trust and control. Data products provide reusable business context. AI provides new ways to reason over and interact with that context. The decision gives all of it a purpose.

For a CEO or board, that brings the conversation back to where it should probably have been all along. The strategic question isn't how much data the organization has, how modern the architecture is or even how much AI has been deployed. Those things matter because of what they enable.

The more useful question is:

Which decisions are we trying to make better, and what is preventing us from making them better today?

Start there. Work backwards to the context. Find the evidence. Apply meaning and governance. Build the trusted data product. Then make that product available wherever the decision happens, whether the consumer is a person, an application, BI, AI, an agent or a workflow.

Build once. Govern once. From BI to AI.

Technology will continue to change.

The decision remains the organizing principle.

Because ultimately, the value of data isn't the data.

It's the decision it helps someone make.