Before You Build the Data Product, Sit With the Person Who Has to Decide

AI Summary

Better data products begin with understanding the business decision, not simply identifying available data. Lili Marsh explores how observing the people responsible for decisions helps organizations create trusted, governed data products that combine business context, evidence and active governance to support human judgment and AI.

Executive Brief

Organizations invest considerable time in data platforms, architecture, integration, governance and AI, yet often overlook the person responsible for making the business decision. Understanding how that person works, what information they trust, where they encounter uncertainty and what evidence they need can reveal requirements that traditional data discovery misses.

Building on Cameron Price's decision-first approach, Lili Marsh explains why effective data product design should begin with the decision-maker. Using a claims investigation example, she examines how business knowledge, technical expertise and governance come together to create trusted context that supports both people and AI. The practical lesson is straightforward: before deciding what data product to build, understand who makes the decision, how they make it and what would help them make it better.

Start with the person, not the data

There is one question I keep coming back to when talking with customers and partners: who actually has to make the decision? It sounds simple, especially when you consider how much time we spend discussing data platforms, architecture, governance, AI, data quality and integration before anyone stops to think about the person at the end of it all. What are they trying to decide? What information do they need? What makes them hesitate? What do they trust? And what happens when something doesn't look right? These are the questions that interest me most because, ultimately, all that investment in data and technology should be helping someone make a better decision.

Cameron Price raised this very issue in his recent article, Why Is It Still So Hard to Turn Data Into Better Business Decisions?, and it's something I see regularly in conversations with customers and partners. In his presentation at the Industry Summit on Data Product-Oriented Architectures in Antwerp, and in his subsequent article, Cameron challenged an approach the industry has followed for decades: starting with the data and working forward, leaving the business decision somewhere downstream. His argument is that we need to reverse that thinking. Start with the decision. Work backwards to the data. I agree, but from my perspective, working with customers and partners, there's an important practical step before we start building anything. We need to sit with the person who has to make that decision.

Start with Sarah, not the claims system

Cameron used a deliberately simple example in Antwerp. At 10:17 a.m., a claim lands on Sarah's desk. She has to decide whether it should be investigated. The information that could help her is spread across claim history, customer or beneficiary information, previous interactions, policy, risk indicators and supporting evidence. From an architecture perspective, that's a useful way to demonstrate why we should work backwards from the decision. From my perspective, it's also where the really interesting conversation begins.

If Sarah were our customer, I wouldn't start by asking her which datasets she wants. I'd ask her to show me what she actually does. Why did this claim get her attention? What would make her look more closely? What would reassure her that nothing further is required? Which information does she check first? Which source does she trust when two pieces of information disagree? What has experience taught her to notice that isn't immediately apparent in the data? When does she need another person involved? And what evidence does she need before she's comfortable taking the next step? Those conversations reveal things a list of data requirements rarely does.

There is a well-established principle behind this approach. The UK Government's Service Manual recommends observing people in their everyday working environments to understand how they complete tasks, what information they rely on and where they encounter difficulties. Its guidance on contextual research and observation recognizes the value of understanding real working practices rather than relying entirely on what people say they do. If we only ask someone what information they need, we may get a list of systems or reports. If we watch how they actually make a decision, we begin to understand the relationships, exceptions, judgment and workarounds that a useful data product needs to support. Sarah doesn't experience her job as a collection of datasets. She experiences it as a series of decisions.

A risk signal is the beginning of the decision, not the end

This distinction becomes particularly important when AI enters the process. An AI model might identify an unusual billing pattern, an analytics system might flag a claim as higher risk, or an agent might bring several indicators together and recommend that Sarah look more closely. These are useful capabilities, but a risk signal is not a decision. Sarah still needs to understand why the claim was surfaced, what evidence sits behind that recommendation, whether there is relevant history, which policy applies and whether there is another perfectly reasonable explanation for what she's seeing.

That distinction isn't theoretical. In a 2026 report, the U.S. Government Accountability Office examined how the Centers for Medicare & Medicaid Services (CMS) uses data analytics to identify anomalous Medicare billing patterns and generate leads for investigation. The report described how CMS suspended payments to, and later revoked the enrollment of, 15 providers involved in a scheme that allegedly billed Medicare for more than $4 billion in urinary catheters that were never supplied. CMS also estimated that administrative actions prevented $11.9 billion in potentially fraudulent Medicare payments across fiscal years 2022 to 2024. The $4 billion relates to alleged billings; the $11.9 billion is CMS's estimate of potentially fraudulent payments prevented, as reported by GAO. The allegations should not be confused with proven fraud. Nevertheless, the example illustrates the importance of analytics in identifying potentially significant issues requiring further examination.

The important point for me isn't simply that analytics can find unusual patterns. It is what happens next. The signal has to become an investigation, the investigation needs evidence, the evidence needs context, and ultimately an authorized person has to determine what action is appropriate. That's much closer to how customers actually experience AI, and it highlights why access to information alone is not enough.

What would Sarah's data product actually contain?

Once we understand Sarah's decision, we can work backwards. She may need claim history and provider information, eligibility and authorization details, or payment history. Relevant policy or program rules might change how something should be interpreted, while previous investigations or interactions could provide valuable context. The evidence supporting a risk indicator needs to be available, not hidden behind a score that simply tells Sarah to trust the system. Suddenly, the data product becomes much easier to define. It isn't simply "claims data." It is the trusted context Sarah needs to decide whether this claim warrants investigation.

That's exactly the distinction Cameron makes when he argues that the interface isn't the product; the product is the trusted, governed context assembled around the decision. Sarah knows things the data team may not know. She understands which exceptions matter, which indicators frequently turn out to be irrelevant, what needs to be checked before escalation and where judgment is required. The data team brings an equally important understanding of the information, architecture, quality and controls. Neither perspective is sufficient on its own, and the product gets better when the people who understand the decision and the people who understand the evidence design it together.

This thinking is consistent with the direction the industry has been moving. Thoughtworks' work on data mesh emphasizes domain ownership and treating data as a product, bringing responsibility closer to those who understand the business domain. McKinsey's research on scaling data products similarly emphasizes business needs, adoption and measurable value. For me, sitting with the decision-maker takes that thinking one step further. Domain knowledge matters, but we also need to understand how that knowledge is used in a real decision, under real operational pressures. That is where the requirements for a genuinely useful data product become clear.

Governance has to reach the person making the decision

Understanding how Sarah makes a decision also tells us something important about governance. It isn't enough to have the right policies documented somewhere in the organization. Those policies need to remain effective when information is brought together, when AI accesses it and when Sarah uses it to decide what happens next.

If an AI system recommends that Sarah investigate a claim, she needs confidence in what information contributed to the recommendation, where it came from, which definitions were used, which policies apply and what she is permitted to see. If the information is sensitive, those restrictions still need to apply when AI accesses it. If access depends on role or business purpose, the rule cannot disappear because the consumer has changed from a person opening a dashboard to an AI agent retrieving information. And if Sarah is accountable for what happens next, she needs to be able to examine the evidence behind the recommendation.

NIST's AI Risk Management Framework reinforces the importance of governance across the AI lifecycle. Its approach encompasses identifying, measuring and managing risks, alongside appropriate accountability and human oversight. For Sarah, that translates into a practical requirement: she must be able to understand why a claim has been prioritized, examine the supporting evidence and exercise the authority and judgment appropriate to her role. A recommendation should help her make an informed decision, not replace her responsibility for making it.

This is why governance needs to be part of the data product itself, applied when it is built and remaining active whenever it is used. For customers, this isn't an abstract governance debate. It determines whether people and AI can use information appropriately, and whether the person responsible for the outcome can trust the evidence behind a recommendation.

Don't give AI everything. Give it what the decision needs.

When customers start exploring AI, one of the first questions is often some version of: how do we connect AI to our enterprise data? I think there is a better question: what governed context does AI need to help this person make this decision well? Those are very different starting points. Giving an AI system access to everything places the burden back on the technology to determine what matters, which definition is authoritative, which policy applies and what information it should be permitted to use.

Starting with Sarah's decision narrows the problem. We know the purpose, we can identify the relevant evidence, establish the meaning, apply the appropriate governance and make the same trusted context available to Sarah and to the AI assisting her. That creates a much healthier relationship between human judgment and AI. AI can help find patterns, assemble information, surface anomalies and explain why something deserves attention. Sarah brings professional judgment, understands consequences and remains accountable for the decision. AI assists. People decide.

What this looks like in practice with Latttice

We've built this same decision-first principle into our Latttice Medicare industry solution. The starting point isn't "connect all the Medicare data." It is a specific decision such as: which claims require investigation first? From there, governed data products can bring together relevant claims, provider, payment, eligibility and authorization information. AI can use that trusted context to help surface patterns and evidence contributing to a risk signal. An investigator can then review the evidence, apply professional judgment and decide what happens next.

The important part is how that trusted context is created. Latttice is a zero-code Data Product Workbench that enables business teams to define and build data products around the information a decision requires. It brings business meaning and definitions together with technical metadata describing the underlying sources, relationships and lineage. Governance, including access permissions and policy, is applied as the product is built and remains active when it is consumed. This matters because the result isn't simply another disconnected view of claims data. It's a governed data product designed around an investigation decision, which can support an investigator, an analytical application or an AI-assisted workflow without each having to reconstruct the meaning and evidence independently. And it doesn't require replacing the organization's existing data platforms.

Importantly, the risk indicator isn't treated as a fraud determination. The Latttice Medicare industry solution demonstrates an approach in which authorized people retain responsibility for claims actions and can review the evidence supporting AI recommendations. It is an industry solution demonstration, not a claim of a deployed Medicare customer implementation or independently measured fraud detection results. This is Sarah's example taken from a presentation and turned into an operating principle.

And it doesn't only apply to claims. A maintenance manager might ask whether to intervene on an asset now. A workers' compensation case manager might ask what is preventing someone's recovery and what support to consider next. A supply chain manager might ask which late shipment needs intervention today. Different industries, different evidence and different consequences, but the design discipline is the same.

The question I would ask your team tomorrow

Cameron finishes his thesis with four questions: What decision? What context? What evidence? What outcome? From a customer-success perspective, I would add one more: who actually makes the decision? Find that person and sit with them. Ask them to show you the real process, not the process diagram. Watch where they look for information, where they leave one system and open another, what they write down, who they call, what they don't trust and where they have to rely on experience because the context they need isn't available.

Then ask Cameron's four questions. What decision are we trying to improve? What context does this person need to make it well? What evidence should support it? What outcome would tell us that we actually made things better? That conversation will tell you far more about the data product you need than starting with a list of available datasets.

Bring the context to the decision

For me, this is what being Decision-Driven looks like in practice. It isn't about diminishing the importance of architecture, engineering or governance. Those things become even more important as AI moves closer to consequential business decisions. It's about making sure all that capability eventually reaches the person it was meant to help.

Cameron's argument is to start with the decision and work backwards. My addition is a very practical one: go and find the person responsible for making that decision. Understand how they decide, what gets in their way and what evidence they need. Bring the right information together around the decision, make its meaning clear and keep governance attached. If AI is going to help, give it the same trusted context and make sure the person responsible for the outcome can examine the evidence behind its recommendation.

Because the best data product isn't the one containing the most data. It's the one that gives someone the trusted context they need, when they actually have to decide.

Join a Data Conversation,

Lili Marsh

Lili Marsh

Head of Partner & Customer Success, Data Tiles

Lili works with customers and partners across industries to help organizations operationalize trusted, business-led data products for decision-making and AI. Her focus is enabling practical adoption, stronger collaboration between business and data teams, and helping partners deliver measurable customer outcomes through repeatable operating models.

At Data Tiles, we see the same challenge from both sides. Customers need trusted, business-ready data products that can support AI and decision-making with confidence. Partners are being asked to help deliver that capability in a practical, repeatable way. Latttice brings those worlds together by giving business teams, data teams, and partners a shared way to create, govern, measure, and activate data products that are ready for real use.

Connect with Lili on LinkedIn