Data Products Do Not Scale Because You Build More of Them. They Scale Because the Business Reuses Them.

Since publishing its original work on scaling data products, McKinsey has continued to reinforce the same direction through its research on AI data readiness and enterprise technology. Gartner's latest research likewise emphasizes trusted data foundations, governance and organizational readiness as prerequisites for successful AI. Together these independent signals point toward the same conclusion: enterprise scale is achieved not by continuously creating new data assets, but by reusing trusted business knowledge across decisions, teams, applications and AI. The greatest return comes from reusable governed foundations rather than repeated technical delivery. (McKinsey & Company, 2025; McKinsey & Company, 2026; Gartner, 2026)

About the Original McKinsey Research

McKinsey opens its article with a simple and effective analogy drawn from the railway industry. A railway operator would never build a separate engine for every individual cargo car it needs to move. The value of a railway comes from a shared engine and a set of standardized connectors that can pull many different cars to many different destinations. Build the engine once, build the connectors once, and the system can support an almost unlimited number of routes and cargoes over time.

McKinsey's argument is that most organizations build data products the opposite way. A business unit needs an answer, a data team assembles a pipeline and a data set specifically for that request, the request is satisfied, and the effort effectively ends there. The next team with a related need starts again from scratch, often pulling from the same underlying sources, applying slightly different logic and producing a slightly different answer. The result is fragmentation rather than scale. Dozens or hundreds of narrow, single-purpose data assets accumulate across the enterprise, each one useful to exactly one team for exactly one purpose, and none of them designed to be reused.

The evidence presented by McKinsey suggests that this pattern is one of the primary reasons enterprise data programs struggle to scale despite years of investment. The fix is not to build more data products. It is to design a smaller number of well-built data products that, like the railway engine, are capable of supporting many high-value use cases rather than just the one that justified their creation. I will not dwell further on the analogy itself, but it is worth holding onto because it reframes the entire conversation. The question McKinsey wants leaders to ask is not "how many data products have we shipped this year." It is "how many valuable business cases does each of our data products now support."

What McKinsey Means by a Data Product

McKinsey is careful to define a data product as something considerably more substantial than a clean data set or a well-engineered pipeline. According to McKinsey, a mature data product brings together the elements required for information to become organized, managed, accessible, understandable, reliable, consumable, reusable and extendable. In other words, it is not simply data that has been prepared. It is data that has been packaged, documented, governed and made discoverable in a way that lets someone who was not involved in creating it use it with confidence.

This definition matters because it explains why so many technically competent data initiatives never scale. A data set can be perfectly accurate and still fail as a data product if nobody outside the original team knows it exists, if its meaning is not documented, if its quality cannot be trusted by a new consumer, or if it cannot be connected into the systems where decisions actually get made. McKinsey's five-component view of a data product, spanning accessibility, reliability, consumability, reusability and extendability, gives leaders a much more complete checklist than the traditional question of whether the data is clean.

At Data Tiles, we agree with the substance of McKinsey's definition, and we would not want to substitute our own terminology in place of it here. Where we place additional emphasis, and where the remainder of this article will spend more time, is on active governance, business purpose and the point of decision. A data product can meet every one of McKinsey's five components and still fall short if nobody has clearly defined why it exists, who it serves and what decision it is meant to improve. McKinsey's framework describes what a good data product looks like from the inside. Our experience with customers tells us that the harder and more decisive question is what that product looks like from the outside, from the perspective of the business person who is deciding, right now, whether to trust it and use it again.

A Deep Dive Into McKinsey's Five Lessons

Before looking at each lesson individually, it is worth highlighting one important point. McKinsey’s research provides an excellent framework for what organizations need to do to successfully scale data products, and we agree strongly with the principles they describe. In many ways, the challenge McKinsey outlines is exactly the challenge we set out to solve. Latttice enables organizations to create reusable, business-led data products that deliver trusted business context at the point of decision, using governed, trusted, fit-for-purpose enterprise data. Governance travels with every data product, allowing trusted business context to be reused, extended, fused and consumed wherever decisions are made, analytics are performed and AI is deployed. Rather than asking organizations to repeatedly translate business questions into technical delivery projects, Latttice enables reusable, governed business-led data products to be created, reused, extended and consumed wherever trusted business decisions, analytics and AI are required.

Lesson One: It Is About More Value, Not Better Data

McKinsey's first lesson is a direct challenge to how many data programs get started. The article argues that data-product initiatives should begin with a genuinely valuable business opportunity, not with an abstract ambition to improve data quality for its own sake. McKinsey's evidence points to organizations clustering related use cases together, identifying where several business problems could be served by the same underlying data asset, and securing leadership alignment before any engineering work begins. A single isolated use case, McKinsey suggests, rarely justifies the investment required to build a proper data product. Multiple valuable uses, clustered and prioritized together, make the business case far more compelling and make the resulting product far more durable.

McKinsey is equally direct about the risk on the other side. A program that sets out to make data better without tying that improvement to a specific business outcome tends to become an open-ended, difficult-to-fund initiative that never quite reaches a finish line, because "better" has no natural stopping point. Value does.

From where I sit, this lesson matches what customers tell us almost word for word. Customers rarely walk into a conversation asking for a data product as an end in itself. They need a decision made with more confidence, a process that runs faster, a customer outcome that improves, an operational bottleneck removed, or an AI capability that actually works because it has something trustworthy to reason over. When that underlying purpose is kept visible throughout the engagement, from the first scoping conversation through to the product's ongoing evolution, the team stays aligned. When the purpose gets lost somewhere between the business request and the technical backlog, the resulting asset tends to satisfy the letter of the original request while missing the value it was meant to create.

How Latttice removes the barrier: Latttice removes the barrier by enabling business teams to create reusable, governed data products around the decisions they need to make, rather than waiting for every business question to move through a traditional technical delivery process. Business context is captured when the data product is created, governance travels with the product wherever it is used, and trusted business data becomes immediately available for decisions, analytics and AI. This allows organizations to begin with business value exactly as McKinsey recommends while removing the delay between business intent and trusted data.

Lesson Two: Understand the Economics of Data Products

McKinsey's second lesson describes what it calls a flywheel effect. The initial preparation and quality work needed to build a data product carries a real, often significant, one-time cost. What changes the economics is what happens after that first investment. Each additional use case that draws on the same product incurs a much smaller incremental cost, because the heavy lifting of cleaning, structuring, documenting and governing the underlying data has already been done. McKinsey describes examples in which reuse across several analytical cases meaningfully reduced projected costs and accelerated time to value compared with building separate assets for each case. It is worth being precise here. McKinsey presents these as illustrative examples of what reuse can achieve, not as a universal or guaranteed outcome, and I want to be equally careful not to present them as a fixed benchmark that every organization should expect to replicate.

The broader implication McKinsey draws out is important regardless of the exact numbers involved. A data product should be evaluated across its useful life and across the full portfolio of use cases it eventually serves, not as a single project with a single delivery date and a single return on investment calculation. Judged as a one-time project, a data product will almost always look expensive. Judged as a compounding asset that gets cheaper to extend with every additional use case, the same product looks very different.

This is exactly the lens I try to bring to customer success. Delivery is not the finish line, it is the starting point for measurement. The questions I encourage teams to ask after go-live include whether the product is being reused beyond its original use case, whether adoption is growing or flattening, how long it now takes a new team to get value from data that used to require weeks of preparation, whether trust in the product is holding up as more people rely on it, how satisfied stakeholders are with the outcomes it supports, whether repeated data preparation work has actually gone down, and whether entirely new use cases have emerged that nobody anticipated when the product was first built. I want to be clear that I am not proposing invented benchmark percentages here. These are the categories of evidence that tell a customer success team whether a product is compounding in value or quietly stagnating.

How Latttice removes the barrier: Latttice removes the barrier by making every business-led data product reusable by design. Governance, business meaning and policy travel with every reusable data product, so organizations do not need to recreate trusted business context every time a new question arises. Business teams can discover, reuse, edit, fuse and extend existing governed data products rather than rebuilding them from scratch. Reuse therefore becomes the natural outcome of how data products are designed, allowing organizations to realise the economic benefits McKinsey describes while continuously expanding business value.

Reuse fundamentally changes the economics of enterprise data. A one-off analytical asset delivers value once. A reusable governed data product continues creating value every time another team, decision, application or AI capability consumes it. Over time the organization's knowledge compounds rather than fragments. The result is not simply lower delivery effort but a more consistent understanding of the business across the enterprise. This is precisely the operating model McKinsey now describes as essential for scaling AI successfully. (McKinsey & Company, 2025; McKinsey & Company, 2026)

Lesson Three: Build Data Products That Can Power the Flywheel

McKinsey's third lesson turns to the technical requirements that make the flywheel in lesson two actually possible. A data product capable of scaling needs the ability to evolve over time, a modeling approach that is simple enough to extend rather than rebuilt for every new case, standardized connectors that integrate with the systems the business already uses, straightforward access for the people who need it, discovery mechanisms that let consumers actually find what exists, automation across the DataOps lifecycle, security applied as code rather than as a manual gate, reliable lineage, and strong underlying data domains built on solid engineering foundations.

McKinsey makes a point in this section that I think deserves more attention than it usually gets. A technically excellent data product is worth very little if nobody uses it. Superb architecture, elegant modeling and rigorous engineering discipline are necessary conditions for a scalable data product, but they are not sufficient conditions for adoption.

This is precisely the point where my perspective as Head of Partner and Customer Success has the most to add. Discovery is part of value. If a business team cannot find a product that already answers their question, they will build a new one, whether or not it duplicates something that already exists. Ease of access is part of value. If getting permission to use a product takes longer than building a spreadsheet from scratch, most business teams will simply build the spreadsheet. Support is part of value, because the first time a user hits a question they cannot answer alone, the presence or absence of a responsive owner determines whether they come back. Clear ownership is part of value, because ambiguity about who is accountable for a product's quality erodes confidence quickly. Confidence itself is part of value, since a data product that is technically correct but does not feel trustworthy to the person using it will not get reused regardless of its underlying architecture. Consumption, in other words, has to be designed. It cannot simply be assumed to follow automatically from good engineering.

How Latttice removes the barrier: Latttice removes the barrier by activating governed enterprise data into reusable business-led data products that enable trusted business decisions. Governance, security, lineage and business meaning travel with every product wherever it is consumed. Rather than asking business users to navigate technical platforms, Latttice makes trusted business data immediately discoverable, reusable and consumable for decisions, analytics and AI while continuing to leverage the enterprise platforms organizations already own.

Lesson Four: Find People Who Can Run Data Products Like a Business

McKinsey's fourth lesson centers on the role of the data product owner, and it draws a distinction I think is one of the most important in the entire article. Managing a project to delivery is a fundamentally different discipline from owning a product to create continuing value. A project manager's job largely ends at go-live. A product owner's job is only beginning at that point.

McKinsey describes the capabilities a genuine data product owner needs, including a real understanding of the business problem, the ability to articulate value in terms that resonate with executives, skill at aligning stakeholders across functions that may not naturally collaborate, discipline in prioritizing a roadmap, ownership of adoption rather than just delivery, responsibility for securing ongoing funding, accountability for lifecycle management as the underlying business and data landscape changes, the ability to build and sustain trust, and enough cross-functional credibility to lead without formal authority over every team involved.

This is where I want to connect McKinsey's argument to a concept we talk about often at Data Tiles, which we call Purple People. I want to be careful about the order here. McKinsey's own analysis of the product owner role stands on its own and does not need our concept to be complete. What Purple People adds is a name for a pattern we see constantly in customer organizations. IT teams typically possess deep technical knowledge of systems, data structures and engineering practice. Business teams typically possess deep domain knowledge of customers, processes, regulation and strategy. The strongest data product owners we work with are neither purely technical nor purely business. They sit in the middle, understanding technology well enough to work credibly with engineering teams and understanding the business deeply enough to be trusted by the people who will actually use the product. Data products, in our experience, scale fastest when organizations deliberately develop and support people who can operate in that blended space, rather than leaving the product owner role to whichever team happens to hold the budget.

How Latttice removes the barrier: Latttice removes the barrier by allowing business experts to actively create, evolve and own business-led data products while governance remains embedded throughout the product lifecycle. Rather than relying on repeated technical hand-offs, organizations can continuously improve trusted data products as business needs change, ensuring ownership, reuse and business value continue long after the original product has been created.

Lesson Five: Integrate Generative AI Into the Data-Product Program

McKinsey's fifth lesson looks at how generative AI is already contributing to faster and more effective data-product development. The article points to areas including documentation, transformation logic, code generation, metadata creation, discovery and search, quality rule assistance, and modernization of legacy pipelines and schemas. McKinsey attributes meaningful productivity gains in these areas directly to generative AI tooling used by technical teams, and I want to attribute those claims accurately to McKinsey rather than restate them as established Data Tiles findings.

What we would add, as an interpretation rather than as an extension of McKinsey's own conclusion, is that generative AI's contribution does not have to stop at accelerating how technical teams produce data assets. With the right controls in place, AI paired with low-code or zero-code experiences can also change who is able to participate directly in defining a data product. Business experts can contribute business meaning, help define a use case, propose rules, supply context, adjust product configuration, explore available data and validate outputs, without needing to translate every contribution into a formal engineering ticket. To be clear, this is not a case for bypassing data engineering. It is a case for enabling business experts to safely participate in creating and evolving governed data products while preserving the trusted foundations required for enterprise analytics and AI.

How Latttice removes the barrier: Latttice removes the barrier by ensuring AI consumes the same governed, trusted business context as people. Because governance, business meaning and policy travel with every reusable data product, AI can safely use the same trusted foundation without recreating context for every new application. Business teams can continuously create, refine and extend trusted data products, allowing both people and AI to work from the same governed business understanding.

What These Lessons Look Like in Real Customer Conversations

It is one thing to read McKinsey's five lessons in the abstract. It is another to recognize them in the specific, slightly frustrating patterns that come up in real engagements. None of what follows is drawn from formal research or quantified benchmarking. These are recurring qualitative observations from customer and partner conversations, and I want to present them honestly as that.

A business team requests an outcome, and the engagement begins as a technical data request rather than a conversation about the decision the outcome is meant to support. Definitions that should have been agreed at the start, such as what counts as an active customer or how a region is defined, get agreed too late, sometimes after significant engineering work has already assumed a different definition. Governance shows up as an approval gate near the end of the process rather than as a set of rules embedded from the beginning. A product gets delivered with no clear pathway for the business to adopt it, so it sits available but unused. A product gets built to serve one sponsor's specific request rather than the broader cluster of related uses that McKinsey's first lesson recommends. Technical success gets celebrated internally, complete with a demo and a project closeout, while actual usage in the weeks that follow remains limited. The original delivery team moves on to the next engagement, and a new team, facing a related but slightly different need, rebuilds similar data from scratch because they cannot discover, or do not trust, the product that already exists. Partners are sometimes asked to recreate the same business context for every new project because nothing about the previous engagement was captured in a reusable form.

None of these patterns reflect bad intentions on anyone's part. They reflect the natural consequence of treating data products as one-time deliverables rather than as durable business assets, which is precisely the gap McKinsey's article is trying to close.

Where McKinsey and Data Tiles Align

It is worth being explicit about how much common ground exists between McKinsey's framework and the position we have developed at Data Tiles through customer and partner work. We see strong alignment on the idea that value should come before volume, that reuse should be pursued ahead of proliferation, that organizations should be building products rather than repeatedly running projects, that business ownership of a product's purpose and adoption matters as much as technical ownership of its engineering, that integration with the existing environment is essential rather than optional, that easy discovery and access are part of a product's design rather than an afterthought, that governance and lineage should be automated rather than manually policed, that lifecycle management has to continue well beyond go-live, that cross-functional teams outperform siloed ones, and that generative AI has a genuine role to play in accelerating development. On every one of these points, McKinsey's research and our own field experience point in the same direction.

The Signal We Are Seeing: The Data Product Movement Is Becoming a Business Operating Model

Read on its own, McKinsey's article is a set of five practical lessons for scaling data products. Read alongside what we are seeing across customers, partners, industries and regions, we believe it points to something larger. Data products are no longer just a data management technique. They are becoming the mechanism through which organizations connect business needs, enterprise data, governance, technology, analytics, AI, decisions and outcomes into a single coherent chain.

That reframing matters enormously for customer success. A customer should not simply receive a well-configured data product at the end of an engagement. The organization should come away with the capability to keep creating, governing, reusing and improving data products long after the initial engagement ends. Similarly, a partner's job should not be to deliver another bespoke data solution that only they can maintain. It should be to help the customer establish a repeatable business capability that the customer's own teams can run and extend on their own. Our position is that this shift in mindset, from delivering assets to building capability, is the real market signal sitting beneath McKinsey's five lessons.

We believe this is the broader market transition now underway. Data products are evolving from a data management practice into an enterprise operating model that connects business purpose, trusted data, governance, analytics and AI around the decisions organizations make every day. McKinsey's research explains how to scale the products. Our experience suggests the larger opportunity is scaling the reusable business capability they enable.

From Business Ownership to Business Participation

Business-led does not mean business-only. It means business expertise becomes part of the data product itself rather than being repeatedly translated through technical hand-offs. Every time a business-led data product is created, business meaning, governance and trusted context are captured as part of the product, allowing that knowledge to be reused wherever it is needed.

This changes how organizations work. Instead of repeatedly recreating business context for every report, dashboard, analytics initiative or AI project, teams continuously build on trusted, reusable data products that already exist. Governance, security and policy travel with each data product, allowing business teams to respond faster while maintaining enterprise trust. The result is not simply better collaboration. It is faster decisions, greater reuse and AI built on the same trusted business understanding as the people using it.

Business-led does not mean business-only. Engineering, governance and security teams keep their distinct accountabilities. What changes is that purpose, meaning, priority and intended outcome no longer get lost inside a purely technical delivery process. Business context flows directly into the product instead of being diluted along the way.

How Data Tiles Builds on These Principles

This is where the Data Tiles approach becomes relevant, and I want to introduce it carefully, in relation to McKinsey's lessons rather than as a substitute for them.

Throughout this article I have referred to business ownership, business participation and product ownership in the way McKinsey describes them. At Data Tiles we describe the practical implementation of those principles as business-led data products. That is our terminology rather than McKinsey's, but it builds directly on the same idea that business value, business context and ongoing ownership should remain at the center of every data product.

Latttice is designed to support business-led data product creation without requiring a rip and replace of existing enterprise platforms. It is built to connect to the systems organizations already run, provide governed access to the people who need it, help teams build products that are genuinely reusable across multiple business cases, carry business context alongside the data itself, apply what we describe as active governance, embedding governance policies directly into the creation, publication and ongoing use of each data product rather than treating governance as a late-stage approval process, support publication and discovery so that products can actually be found, enable consumption by analytics applications and AI systems, encourage collaboration between business, data and governance teams, and support the lifecycle evolution that McKinsey's second and third lessons describe as essential.

We describe Latttice as the Data Product Workbench, or as the business activation layer for enterprise data. Enterprise data platforms are extremely good at storing and processing data at scale. Latttice's role is to activate that data, helping teams turn what is already stored into trusted, governed, fit-for-purpose data products that decisions and AI systems can actually rely on.

Once trusted, reusable data products exist, they become the foundation upon which analytics, applications and AI can safely operate. Lenz is one example of this approach, enabling AI agents to use the trusted business context supplied through governed data products created in Latttice. I want to be direct about the sequencing here, because it matters. This article is about data products, not about Lenz, and Lenz is only interesting to the extent that it can draw on data products that are actually reusable, trustworthy and well owned. An AI agent built on top of fragmented, unreusable data products inherits every one of those weaknesses.

Customer Success Must Begin Before the Product Is Built

One of the convictions I bring most strongly to this work is that customer success is not a function that starts after implementation. For data products specifically, success begins the moment the organization starts identifying the decision the product is meant to improve, the person who will actually use it, the outcome that should result, the existing landscape of source systems it will need to draw from, the business meaning that has to be agreed before anyone writes a line of transformation logic, the policy requirements that will govern how it can be used, the future use cases that might reasonably reuse the same foundation, the person who will own it once it is live, the pathway through which the business will actually adopt it, and the evidence that will eventually demonstrate whether it created value.

These questions shape the product long before technical build work begins. When we skip them, or treat them as paperwork to complete after the real work has started, we end up with exactly the pattern McKinsey's article warns against, a technically sound asset that was never designed to be reused because nobody asked, at the outset, what else it could serve.

Partner Implications

McKinsey's argument carries direct implications for implementation and advisory partners, and it is a conversation I have often with the partners we work alongside. The questions worth asking on every engagement include whether the team is delivering a one-off solution or a genuinely reusable product, whether the product can support future cases beyond the one that funded it, whether clear business ownership has actually been established, whether users will be able to find and access the product once it exists, whether governance and lineage are active rather than promised, whether the customer will walk away with a repeatable capability or simply another asset only the partner understands, whether the product can support analytics and AI consumption as well as its original use case, and whether value can be demonstrated after go-live rather than only projected before it.

We see Data Tiles as an enabler for partners in this work, not a replacement for the domain expertise, delivery discipline and customer relationships that good partners bring. Latttice is designed to make it easier for partners to deliver on McKinsey's five lessons, not to remove the partner from the equation.

Cameron's Executive Contribution

Cameron Price, our CEO and Founder, has spent a great deal of time thinking about the funding logic that sits underneath everything described in this article, and I want to share that perspective here as a contributor's view rather than attribute a specific quotation to him.

The executive implication of McKinsey's research, as Cameron frames it, is a shift in investment logic rather than simply a cost reduction exercise. Organizations should stop funding every new data request as an isolated project with its own budget line and its own delivery team. They should instead invest in reusable business capabilities designed to support a portfolio of decisions, applications and AI use cases over time. That is not a subtle difference in language. It changes how a CFO evaluates a data investment, how a CIO prioritizes a roadmap, and how a business leader thinks about whether to fund a new request or reuse something that already exists. Cameron connects this directly to the broader idea of a reusable business capability, because a genuine shift in investment logic requires more than a new budgeting policy. It requires the governance, ownership and platform foundations described throughout this article to actually be in place.

Conclusion

Data products do not create value because they exist. They create value when people trust them, use them, reuse them and continuously improve them around business outcomes that actually matter.

McKinsey's five lessons give leaders a credible and practical roadmap for getting there, grounded in real evidence about value, economics, technical design, ownership and the emerging role of generative AI. What I hope to have added from the customer success side of the table is a sense of how those lessons show up, or fail to show up, in the everyday reality of business teams waiting for information, data teams trying to satisfy them, and partners trying to serve both at once.

For me, the most important message from McKinsey's research is that organizations should stop measuring success by how many data products they build and start measuring how often those products are trusted, reused and capable of improving business outcomes. That is the shift customers who successfully scale data products consistently make.

Ultimately, organizations are not simply reusing data. They are reusing trusted business context. That is what makes decisions faster, analytics more consistent and AI more reliable.

McKinsey has shown organizations what successful data products look like. Our experience is that organizations achieve those outcomes when business teams can continuously create, reuse and evolve governed data products whose trust, business meaning and governance travel with them wherever decisions are made. The strongest data product is not simply the one with the most sophisticated architecture. It is the one that becomes a trusted, reusable part of how the business makes decisions, supports analytics and enables AI. When trusted business context becomes reusable, organizations stop rebuilding knowledge and start compounding it. That is how data products ultimately scale.