Data people do their best work close to the teams that create the data. This is what I learned moving them closer to the product, and why the things every team shares, like a customer, still need one design.
Most of my career has been doing data in scale-ups. You start with a handful of people who do everything, all sitting together. That works for a while. Then the product splits into more teams, and the central data team becomes the queue everyone waits in.
That's the problem data mesh set out to solve. Zhamak Dehghani first described it in 2019, and later set it out as four ideas. The teams who create data should own it. Data should be treated as a product, with an owner and a standard it has to meet. A self-serve platform should save each team rebuilding the plumbing. And governance should be shared and automated, rather than run by a gatekeeper.
I agree with most of that, and the part I've leant on most is putting data people into the product teams, in the same planning sessions as the engineers. It's the fix for most of the pitfalls I've seen, in teams that were good at what they were asked to do.
The data you need isn't captured.
I've lost count of the features that shipped without the data to measure them. Someone asks whether it's working, and nobody can say. Going back round the product team to add it is slow and expensive.
How to get past it: put a data analyst in the team. They work out what's needed to measure the feature while it's being designed, so the data is there on the day it ships.
Changes break things downstream.
Nobody would rename a field in a public API without telling the people who depend on it, but the same change to the data goes out quietly, and a report breaks weeks later.
How to get past it: treat the data a feature produces as a contract, like its API. An analytics engineer in the team sees the change coming and fixes what it would break before it ships.
The data has users the team never meets.
Analysts, finance, clients' own reporting, and more and more often a model. The team rarely meets them, so it rarely builds for them.
How to get past it: before a feature goes into design, answer three questions. What data do we need, and where does it come from? What data will it produce, and who'll use it? How will we know it's working?
The shared tables feel like someone else's job.
Teams see the customer table as something the data team builds after they've shipped. A person reading a dashboard will notice a strange number, but an AI agent reading the same table won't.
How to get past it: when a feature adds something about a customer, it goes on the customer table in the same piece of work, so the table stays right for everyone reading it.
The next product doesn't get built.
Product teams are busy building what's on the roadmap. The data their product creates often holds the start of something new, and nobody's looking for it. A team that manages devices in the field, for example, holds the data to spot one that's about to fail, so an engineer can fix it before the customer notices.
How to get past it: make it someone's job. A data person in the team knows the product and its data, so they're best placed to spot these and make the case for building them.
None of this is because teams are careless. They're doing what they're measured on, which is shipping features that work. Most sit at Feature-Focused or Data-Aware on the maturity curve I described in Stop guessing at your data maturity, and moving up takes the product team as much as the data team. Putting data people in the team helps because it puts responsibility for the data and the skill to look after it in the same place.
Data mesh organises data around the domain that owns it. Where data needs combining, that becomes a product of its own, which Dehghani calls aggregate domain data. She's wary of big ones that try to serve everyone, like a customer 360, because they can grow unwieldy, and she'd rather each consumer build the view it needs. That's the one place I'd lean the other way. Most analytical questions cut across domains. How many live customers have a balance? Whether a customer is live sits with one team, and their balance with billing. Even with well-made data products, that leaves the hard part with whoever asks. They need to know which domains hold the pieces, and how to join them without counting anything twice. Most analysts don't know every domain that well, and an AI tool knows less. It's slow too, because every new question starts with that work before anyone gets an answer. When each consumer builds its own view, I've seen the reporting teams and now the AI tools each do it their own way. That can add up to hundreds of overlapping tables. Each one costs money to process. Two reports soon give two answers, and people lose track of where to find the data they need.
What I've seen work best is a gold layer designed consistently, and modelled on the business. It takes a concept like a customer and brings in data from every domain, rolled up or down to the customer's level. If the customer table already carries whether each customer is live and their balance, the question becomes a simple count, with no joins for AI to get wrong. It's the layer most analysts use, and it answers questions nobody has asked yet, because the data is already there. Kept to one concept at one grain, with an owner for every column, it stays manageable. Smaller or more mature organisations can have the domains build these tables together. Otherwise, each domain builds its own, and a thin platinum layer only joins them and rolls the data up or down to the level the business needs.
Embedding data people doesn't give you that on its own. It takes one design, and someone who owns each table as a whole. The strategy piece covers how, with the team structure at each stage and when a platinum layer is the better route.