Internal data products: a field guide to the teams and companies worth studying

Most writing on internal data products stays abstract: treat data like a product, assign ownership, measure usage. What gets skipped is who actually did it well, what it looked like in practice, and what the rest of us can learn from the wreckage or the success. This shortlist is organized by one criterion: demonstrated influence on how practitioners at other companies subsequently built their own internal data platforms. Revenue and company size are not the filter. Documented impact on the field is.

The shortlist

Airbnb and the Dataportal

Airbnb's internal data discovery tool, built and described publicly by its data infrastructure team between roughly 2017 and 2020, became one of the most referenced examples of internal data cataloging done at scale. The team published detailed engineering blog posts that other data teams used as direct blueprints. The single lesson: a data portal only works if the search and metadata quality are good enough that engineers actually prefer it over Slack. Airbnb proved that internal tooling adoption is a product problem, not a culture problem.

Spotify and the "golden path"

Spotify's internal developer platform work introduced the concept of a "golden path" to many data practitioners: a set of recommended, well-maintained tools and pipelines that teams default to, rather than being forced into. Spotify's Backstage, the open-source developer portal the company released publicly in 2020, operationalized this idea. For data platform teams, the lesson is that reducing optionality in the right places actually increases adoption. Backstage now has thousands of external contributors, which gives Spotify's original design decisions unusual staying power.

LinkedIn and the roots of data meshdata meshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.View full definition → thinking

Before "data mesh" became a consulting category, LinkedIn's engineering team published detailed write-ups on how it scaled data infrastructure across semi-autonomous teams using what it called "self-serve" data pipelines. These posts, some dating to 2013 and 2014, directly influenced Zhamak Dehghani's later articulation of data mesh principles. LinkedIn is worth knowing here not as a current exemplar but as an origin point. The concept of decentralized data ownership with centralized standards did not arrive fully formed from a consultancy.

Netflix and the priority of data contracts

Netflix engineering blog posts have consistently shaped how the industry thinks about data reliability. Its approach to schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → registries, data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → SLAs between producing and consuming teams, and the idea of treating data pipelines as having explicit producers and consumers with contractual obligations became standard vocabulary in the data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → conversation. The specific takeaway: Netflix framed internal data reliability as an engineering contract between teams, not a governance policy handed down from a central function. That framing changed how many CDO-level conversations get structured.

Zhamak Dehghani and the data mesh framework

Dehghani, formerly of ThoughtWorks, published the original data mesh concept in 2019 and expanded it into a book ("Data Mesh", O'Reilly, 2022). Whatever one thinks of data mesh as a prescription, its influence on how CDOs frame platform thinking is undeniable. The domain ownership model, the data-as-a-productdata-as-a-productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → principle, and the federated governance idea are now baseline vocabulary in CDO job descriptions and board-level data strategy conversations. Dehghani is worth knowing because she gave practitioners a shared language, and shared language changes what gets approved in budget cycles.

Uber and the Databook catalog

Uber built and documented Databook, an internal metadata platform that surfaced dataset ownership, quality metrics, and lineage at scale. The engineering posts published around 2019 to 2020 were notable for one specific reason: Uber showed how to attach institutional accountability to datasets by surfacing ownership information alongside the data itself. When a dataset has a named owner visible to every consumer, the quality conversation changes. That accountability mechanism is now considered a baseline feature of mature internal data platforms.

JP Morgan Chase and the quiet enterprise case

Unlike the tech companies above, JP Morgan Chase represents the large-enterprise proof point. The firm has been public about its internal data marketplace efforts and its investment in data engineering talent at a scale few organizations can match (the firm has disclosed spending billions annually on technology, though specific data platform budget breakdowns are not independently verified). The lesson from JP Morgan Chase is organizational rather than technical: it demonstrated that platform thinking for internal data requires dedicated product management headcount, not just engineering talent. Several of its data platform leaders have moved into CDO roles at other institutions, which is a reasonable proxy for influence.

The pattern: what these standouts share

Look across these seven entries and one thing is consistent. None of them treated internal data platform adoption as a communication or change management problem. They treated it as a product design problem. Airbnb optimized search quality. Spotify reduced decision fatigue by curating a default path. Netflix wrote contracts between teams. Uber put ownership information where consumers could see it. The companies that struggled (and there are many, though they publish less) typically built platforms that were technically complete but required too much effort from the people expected to use them.

The second pattern: every entry here published. Engineering blog posts, open-source releases, conference talks. That transparency is partly how they built influence, but it also reflects something about the organizational culture that allowed the platforms to exist. Teams that build well tend to be teams that think clearly enough to write it down.

The CDO lesson is not that you need to publish your architecture decisions. It is that the discipline required to write them down clearly enough to publish is the same discipline that tends to produce platforms people actually use.

Who to watch: the teams building internal data contract tooling, particularly those working on open standards rather than proprietary implementations, will define the next round of this conversation.

The companies that built durable internal data platforms did not do so by investing in governance frameworks first. They invested in making the experience of finding and trusting data good enough that engineers chose the platform without being told to. That is the design challenge that separates a data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition → project from a data product.