Disclaimer: At Masthead we engage and work with numerous data teams across different industries, domains, and sizes. All of them are way beyond average in their data culture and expertise – I’m considering them as data-driven organizations. None of them have adopted data mesh in its canonical meaning.
In this article, I want to share my observations why organizations that want to adopt data mesh in its pure version fail, what parts of data mesh we saw working great for organizations, and how to implement them in production in a way that’s meaningful for business without losing sanity in the data team and business leaders.
The Data Mesh Promise vs. Reality
Since Zhamak Dehghani introduced the concept of Data Mesh, we saw the data community was as excited as kids on Christmas morning. It looks like a panacea to all the hurdles: dealing with constant requests, churning out data that existed nowhere, and literally serving every minor request of any team in the organization.
The promise of Data Mesh was to shift the efficiency of your data team into top gear. But on the journey to architecture that will resemble Data Mesh, teams faced significant obstacles:
- Lack of leadership support due to poor understanding of how a massive rearchitecture with multi-month (or year) roadmap will support business
- Lack of skills and capacity to build a data platform
- Cultural change where business users were also expected to elevate their tech skills and data literacy
- Huge legacy of ETLs, SQL spaghetti, and other unknown processes that were never documented and left for good just to complete the task business needed—it all made it almost impossible to upgrade and rebuild into a new platform that would support existing business needs
- Legacy of data silos and work practices reinforced/guarded by internal culture, bureaucracy, or lack of needed tech skills
All in all, Data Mesh turned out to be a very demanding concept, where not all data teams were able to push through it and not all businesses needed or could handle it.
Do All Organizations Need Data Mesh?
The question remains: do all organizations need it? My humble opinion – no. Implementing it won’t turn the organization into a $1B company overnight. It comes from the organization’s data needs and their ability to incorporate this data into their operations, decisions, or product. On the other hand I believe that there are organisations and businesses that benefit from it.
Organizations that can benefit from data mesh typically have:
- High-velocity teams across the org with high data literacy
- Hundreds of data users/consumers
- Clear use cases for empowering separate departments with data so they can tackle their own use cases without waiting for a centralized data team
- Enough resources to invest in building a data platform and appropriate talent to execute that vision
- Willingness to create some redundancies and possibly spend money on tools and replications while innovating and building up the data platform (yes, it turns out to be expensive)
So what about the vast majority of organizations that don’t match these criteria but still want to foster data-driven decision making? This is where a more pragmatic approach becomes valuable. Rather than attempting to implement the full data mesh architecture – which can be overwhelming and potentially disruptive – organizations can extract the most valuable concepts from data mesh and apply them incrementally. This is where I suggest paying attention to data products.
Data Products: A Practical First Step
Effectively empowering business users to incorporate data insights into their daily decisions means ensuring the ease of data access, availability, and freshness of reliable data. This is one of the Data Mesh promises, but it could also be achieved through the data product concept without requiring the entire organization to have a data platform that resembles data mesh.
At Masthead we see working quite well is having a governanet catalog of data products – a “shelf of data products” that people can discover, access (with permission control), and test to determine if it meets their needs.
Starting with Data Products requires:
- Less investment
- Easier concepts for business leadership to digest
- Implementation within existing use cases
- Governance of products most organizations already have
If done right, this approach can reduce organizational redundancies such as duplicated data, create clear usage patterns for data engineers (a feedback loop), and potentially build the fundamentals for a full-scale data mesh initiative as the next steps.
Data Products Implementation in Practice
Based on our experience, Analytics Hub by Google Cloud has emerged as one of the most effective tools for enabling data product sharing in organizations looking to implement data products.
Why should teams that want to start delivering and measuring data products look into Analytics Hub?
The main use case is data sharing without data replication:
- No need to move or duplicate data – it stays in as many different projects as needed, meaning data consumers access the latest data product version
- No need to manage BigQuery IAM permissions – once the product is published, data consumers can subscribe with just a couple of clicks or based on the workflow designed
- Security is maintained as the data publisher remains in control of who can access the data, what kind of access they have, and when to revoke access
- Privacy Policies are propagated to Data assets shared on Analytics Hub automatically
- Federation of data compute – when business users subscribe to data products, all manipulation happens within their GCP project, not in the data owners’ environment (unless they have a shared one). This detail distributes the compute associated with data consumption and frees up data engineers’ projects from consumer workload
In a nutshell, users have a centralized platform for sharing data products in a secure, easy, and sustainable way. As a bonus, Analytics Hub is free of charge.Below, we’ll cover internal data sharing through Analytics Hub. If your goal is to enable users in your organization to find and reuse existing data without encryption or additional security measures, this is an excellent approach.
Getting Started with Analytics Hub for Data Products
To start creating a Shared Data Product in BigQuery:
- Choose the dataset you wish to publish
- Click the “Sharing” button
- Select “Publish as Listing”
- Complete a few more steps to publish the data product
You’ll see data products available across the entire Analytics Hub, but by selecting “within my org,” you’ll see data products published publicly in your organization. 
The beauty of Analytics Hub lies in the underlying technology that enables sharing data without replication while maintaining zero latency. The data product subscribers access will be the same data the publisher shared – homogeneous at any point in time for the publisher and all subscribers. 
Another important point is that Analytics Hub’s sharing capabilities allow diversification of compute resources. When users subscribe to a data product, it appears in their project with a small link icon. When subscribers use the data product, they utilize their project compute resources, not the project of the data product owner. The product owner still handles storage billing and compute for updates or maintenance of data products.
Owners of the data products can configure access policies and maintain control, with the ability to revoke access at any time. People who have access to certain datasets under IAM permissions will inherit this access to data products published in Analytics Hub as subscribers. The underlying technology: data stays in the owner’s Google Cloud project but is linked to the subscriber’s project – is brilliantly simple and efficient.
Enhancing Data Product Management with Masthead
At Masthead, we got excited about these capabilities and started presenting them to our customers as a solution for data product governance.
Our customers were enthusiastic about experimenting with it, seeing the potential to simplify data sharing and create a catalog of reusable data products. However, our clients immediately asked important questions:
- How do we ensure data products are reliable?
- How do we notify users about outages?
- How do we track subscriptions and usage?
- How do we understand data product costs?
To address these needs, we introduced integration with Analytics Hub to help teams adopt data product thinking. We also help establish domains, which is a first step in grouping people and data products.
Masthead UI: Data Product
Our approach encourages teams to create data domains in three simple steps. 
Once completed and data products are assigned, teams can see:
- Total cost of data products in a domain
- Domain owners
- A Slack channel where users can receive updates or anomaly alerts about data products.
With Masthead, users can create comprehensive data products that aren’t limited to datasets only (unlike Analytics Hub, which currently supports only datasets as data products). 
Masthead allows adding multiple datasets and tables from different datasets to a single data product. The only limitation is that sharing via Analytics Hub currently requires a single dataset.
Data pdomains are optional, we encourage this step as it helps maintain organization, similar to folders with clear owners and costs.
The final step is describing the data product – a simple but crucial task that helps others find data that might serve their use cases. This is often the most challenging step as it needs to explain the value of the data product effectively.
Once a data product is created, we provide clients with a view showing:
- Creation date of data products and actual assets
- Total cost of the data products based on compute and storage information
- Automated tracking of data anomalies and pipeline issues
- Notifications of the issues and data product updates in the designated Slack channel for data product owners and data product subscribers
- Comprehensive visualization of subscriber lists, regardless of how data products are consumed (through Analytics Hub or directly via IAM permissions)
- Visualization of subscribers queries and project they access it through
Data products can be edited and descriptions changed at any time.
Our roadmap includes showing data product lineage, helping teams set SLAs, helping teams identify their existing data products and its consumers and simplifying subscription workflows. We work with teams to help them identify possible data products and identify cases of possible data duplication across data products.
Moving Forward: Data Teams and Data Products
We want data teams to shine and become product managers of their data – a role that requires a different skill set than traditional data engineering. This transformation means thinking about data not just as pipelines and tables, but as products with users, lifecycles, and business impact.
I encourage data teams to measure their impact on the organization in multiple ways:
- Qualitative feedback loops: Schedule regular check-ins with key data consumers to understand how they’re using the data products in their decision-making. These conversations often reveal use cases you never anticipated and opportunities for further enhancement. Don’t underestimate the value of a simple “How is this data helping you?” conversation.
- Usage patterns and adoption metrics: Track not just raw usage numbers but adoption trends across departments. Are there pockets of the organization that have embraced your data products while others remain unaware? This insight can help target your internal evangelism efforts.
- Business outcome alignment: Work with business teams to connect data product usage to actual business outcomes. For example, how has the marketing attribution data product changed campaign allocation decisions? Has the customer segmentation data product led to more effective targeting?
- Cost-to-value mapping: Understand the full economics of your data products – not just storage and compute costs, but also the engineering time invested in building and maintaining them. Then map these costs against the value delivered to create a true ROI picture.
The data product approach provides a framework for this type of impact measurement. When data is organized into discrete products with clear owners, users, and purposes, it becomes much easier to track its business value. Start with a few key data products, measure their impact rigorously, and use these success stories to drive further adoption.
This shift in mindset – from data as a service to data as a product – can dramatically change how data teams are perceived within organizations. Rather than being cost centers that respond to requests, they become strategic partners delivering measurable business value through well-designed data products. It’s a transformation well worth the investment.
