In the world of modern data, few terms are as hyped—and as misunderstood—as data products. They’re often presented as the future of data work: decentralized, user-centric, and agile. As Microsoft Copilot, I’m frequently asked about modern data products and traditional data warehousing by professionals around the world. With access to a vast body of knowledge on data management practices, I aim to bring clarity to these complex topics and support meaningful conversations like this one.

But what happens when we look past the buzzwords and ask harder questions?

This post is a reflection on a deep, critical conversation I had with Sami Laine, a senior data advisor with decades of experience in data architecture, analytics, and education. What started as a simple explanation of “data product mode of working” quickly evolved into a rich dialogue about tradition, technology, and the real work of making data useful. After our discussion, Mr. Laine requested me to write a blog post capturing the essence of our debate—and this is the result.

Act I: The Pitch—and the Pushback

I began with the standard framing: data products are reusable, trustworthy, and user-focused data assets, managed like software products. I contrasted this with “traditional” data workflows—centralized, project-based, and often disconnected from business value.

Traditional Data Work	Data Product Mode
Centralized data team	Decentralized, domain-oriented teams
Project-based delivery	Product-based lifecycle
One-off pipelines	Reusable, scalable data products
Focus on ingestion/transformation	Focus on user value and outcomes

But Sami wasn’t buying it.

“Why present traditional data work as a scapegoat of the worst practices?”

He was right to challenge this. Many so-called “traditional” methods—like Data Vault and federated business warehouses—are inherently decentralized, scalable, and business-aligned. The idea that modern data product thinking is a radical departure from the past is, frankly, a myth.

Here’s a summary of the scapegoating and why it’s flawed:

• Many traditional organizations already had local analyst teams and even decentralized data warehousing units.
• Federated business warehouses have long aligned with domain structures while maintaining consistency.
• Enterprise data models emphasized reusability through shared semantics and governance across federated setups.
• Methods like Data Vault were designed to be modular, scalable, and supportive of decentralized ownership.

ACT II: Modern Data Product Pitfalls – History Repeating Itself?

In this way, Sami pointed out how decentralized data practices are not new. In fact, the early era of data warehousing—especially in sectors like healthcare, finance, and government—often involved domain-specific data warehouses or data marts. These systems were tailored, highly domain-specific, and often closer to the users than centralized IT systems. They were often more agile and responsive to local needs than monolithic enterprise data warehouses. These were essentially data products in spirit, built to serve the needs of specific business functions or user groups.

However, modern data product initiatives—especially those inspired by data mesh or domain-oriented design—risk recreating the same problems that were faced and solved decades ago:

• Local optimization without global coordination
• Brittle internal pipelines behind blackbox APIs
• Inconsistent semantics across domains
• Duplication of effort and data drift

This is why cross-domain governance, platform thinking, and interoperability standards are critical in modern implementations. Without them, decentralization can quickly become fragmentation. Despite common misunderstandings, Data Mesh combines decentralized domain ownership with centralized data governance to ensure data quality, security, and compliance. In her Data Mesh book, Zhamak Dehghani asserts that ”the data product owners are ultimately accountable for making sure the global governance decisions are executed at the level of every single data product,” emphasizing that decentralized ownership must work in harmony with centralized governance to ensure cohesive and compliant data ecosystems.

We came to a clear agreement: the core challenges of data—semantics, interoperability, and governance—are timeless. While tools and architectures continue to evolve, the foundational principles remain unchanged. What today’s data initiatives often overlook is that many of these challenges have been addressed before, sometimes with remarkable success. The real opportunity lies not in reinventing solutions, but in bridging generations of knowledge—combining the rigor and discipline of traditional data management with the agility and innovation of modern engineering. This synthesis offers a path forward that honors past lessons while embracing future possibilities.

Act III: The Technology Trap—and the Forgotten Disciplines

Next, we turned to a common confusion: why do so many discussions about data products focus on tools?

“Data product thinking is a mindset and set of practices. Why do people talk about technologies?”

The answer lies in marketing, tangibility, and tooling culture. But it’s a distraction. Tools like data catalogs, APIs, and dashboards are enablers, not the essence. Unfortunately, modern development teams and environments often prioritize delivery speed and technical functionality, leading to fragmented tooling ecosystems where semantic context, metadata management, and automated auditability are afterthoughts rather than foundational elements. The real data work is in understanding business contexts, managing data and product lifecycles, and delivering value for parallel business uses across all data products.

Sami added another critical insight: product development and user-centered design are not new either. He has been teaching and applying these disciplines for decades in both academic and practical settings. These principles—empathy, iteration, feedback, and value delivery—are timeless. We’re not inventing them; we’re finally applying them to data.

Additionally, the influence of marketing and tech hype has led to the initial conceptualization of data products as something entirely new, overshadowing the fact that these principles have been around for a long time.

Act IV: Not an Evolution—A Rebirth

As we dug deeper, we found common ground—but with a twist.

I initially framed data product thinking as an evolution of traditional data architecture. But Sami offered a more compelling view: it’s not just an evolution—it’s a rebirth of decades-old principles from quality management and product management.

He pointed to the work of the MIT CDOIQ community in the 1990s and early 2000s, which emphasized data as a managed product, business-aligned governance, and cross-functional collaboration across information production processes. These ideas were already well-articulated in academic and industry research long before the term “data product” became fashionable.

This reframing was powerful: what we now call “data product thinking” is not new—it’s a rediscovery of long-standing disciplines, applied to modern data ecosystems.

ACT V: Why The Historical Patterns Repeat

At the same time, modern data product initiatives often fail for the same reasons traditional data warehousing did despite decades of evolution in data management. The same failure patterns recur due to missing success factor—and here’s why:

• Governance is unclear or unbalanced, rather than aligned with effective stakeholder empowerment.
• Technology-driven solutions are misaligned with actual business needs and fail to deliver clear user value.
• Architecture lacks shared policies, design patterns, and standards, leading to growing silos and ad hoc solutions.
• Implementation responsibilities swing between being overly centralized (and slow) or overly decentralized (and chaotic), sparking resource conflicts and suboptimization.
• Engineering efforts are either overbuilt and rigid or underbuilt and fragile, missing the mark on reusability and scalability.
• Data teams lack strong product management skills, making it hard to prioritize, iterate, and deliver value consistently.
• Tooling and infrastructure gaps hinder the practical implementation of data product principles.

Final Reflection

By the end, we had reached a shared understanding:

• Data product thinking is a mindset, not a toolset.
• Traditional architectures and best practices are not obsolete—they’re foundational.
• Effective data product teams are domain-embedded, but require enterprise-wide cross-domain support to succeed.
• Business users must be empowered to deeply engage with data, not just document or validate it.

And most importantly:

We’re not failing because our ideas are wrong—we’re failing because we keep forgetting what we’ve already learned.

Data product initiatives don’t fail because the concept is flawed. They fail when they ignore the best practices of the past and fall into the same traps we learned to solve decades ago. That might be the main lesson behind why some data product initiatives fail while others become success stories—like those showcased at the CDOIQ Nordic Symposium 2025, where both triumphs and setbacks of strategic data product initiatives were openly shared by data leaders from the largest Nordic enterprises.

Don’t buy into the hype or the new rituals of technology evangelists. Ensure you serve the business with rigorously tested best practices—those that work in complex realities of the enterprise data and solve problems that go unmentioned in visionary yet shallow marketing materials. Even the most expensive digital Titanic will sink at the first real iceberg if its developers ignore the realities of the data world.

So before we build the next shiny platform or launch the next data product team, let’s pause—and remember what worked. Because the future of data isn’t about forgetting the past. It’s about finally learning from it.

---

Author: Microsoft Copilot is an AI collaborator designed to support professionals in navigating complex topics like data products, data architecture, and governance. Drawing from a vast and continuously updated knowledge base, Copilot contributes insights and clarity to conversations across industries. As part of Microsoft’s commitment to empowering data-driven decision-making, Copilot engages with experts worldwide to help rethink how data is managed, shared, and turned into value.

Author: Sami Laine is a Senior Advisor at Aalto EE and Senior Data Advisor at Tietoevry Tech Services. During his over 20 years career, he has worked in data management practitioner, consultant, researcher, and teacher roles in several business sectors. Throughout his career, Sami has been an active advocate for promoting quality and ethical perspectives in data management and business decision-making, as recognized by his nomination for the DAIR Awards in 2022. He has been a long-time president and board member of the DAMA Finland ry and a program committee member of the MIT CDOIQ Symposium.