Building a Data Product Organisation

The org chart problem behind most failed data mesh efforts

Data mesh initiatives rarely fail on architecture. They fail because nobody owns the outcome. A central data team builds a platform, domain teams are told to 'produce data products,' and six months later there are a dozen half-maintained datasets with unclear owners and no one accountable when quality drifts.

Building a data product organisation means designing roles and incentives deliberately, not assuming ownership will emerge naturally once the technology is in place.

Core roles that need to exist

Across successful data mesh rollouts, three roles consistently show up, whether or not they carry these exact titles:

• Data product owner — accountable for a specific product's contract, quality and roadmap, embedded in the domain that best understands the data
• Platform team — builds and operates the shared infrastructure (context layer, governance, discovery) that every domain's products run on
• Data product council — a lightweight cross-domain forum that resolves conflicts, sets shared standards and prevents domains from re-inventing incompatible patterns

Incentives: why 'produce data products' as a mandate fails

Domain teams are usually measured on their core business outcomes, not on the quality of a byproduct dataset. Without a specific incentive — inclusion in team OKRs, recognition tied to consumer adoption, or freed-up time explicitly allocated for product maintenance — data product work will always lose to the team's primary mandate when priorities compete, and quality will silently decay after launch.

The organisations that sustain data mesh treat data product ownership as a first-class part of a domain team's job description, with the same planning cadence and review rigor as their core deliverables — not an unfunded side project.

Starting small without staying small

The most durable rollouts start with two or three domains, a working platform, and a small number of genuinely valuable products — proving the operating model before scaling headcount or domain count. Each subsequent domain then adopts a proven playbook rather than reinventing governance, ownership and tooling decisions from scratch, which is what keeps the tenth data product as well-maintained as the first.