Ask anyone who's spent time inside a large organisation how they get data from another team, and you'll hear some version of the same depressing ritual. You send an email. You wait. You get pulled into a call to "align on definitions." You send a follow-up because the file that finally arrived counts customers differently than yours does. Multiply that by every team, every quarter, for years. Nobody ever put a number on it, which is exactly why it never got fixed — the cost was real but it lived in calendars and Slack threads, not on any balance sheet.
I've watched this play out for the better part of two decades, mostly in banks, and the thing that always struck me is how *normal* everyone considered it. Data was something you owned, hoarded, and grudgingly shared. The idea that it might be packaged and handed over like a finished product would have sounded faintly absurd.
The story people tell about how that changed is half corporate legend by now. Around 2002, Jeff Bezos supposedly fired off a memo to Amazon's engineers: every team exposes its data and functionality through service interfaces, no exceptions, and anyone who doesn't gets fired. Whether the wording is accurate barely matters. What matters is what came out of it. The internal plumbing Amazon was forced to build — clean interfaces between systems that used to pass each other notes under the table — is more or less the thing that became Amazon Web Services. A discipline that started as engineering hygiene turned into one of the most profitable businesses on earth.
You already lean on this pattern constantly, you just don't see it. The one-time code your bank texts you almost certainly rides on API. The checkout box that behaves identically across a hundred unrelated shops is usually another API wearing different paint. The "continue with Google" button means an app borrowed an entire identity system rather than building its own and getting it wrong. None of these companies reinvented messaging or payments or login. They plugged into something that already worked, through an interface built to be plugged into.
That interface is the API — application programming interface, if you want the full mouthful. It did for software what standardised connectors eventually did for gadgets, turned a drawer full of incompatible cables into things that just fit.
The argument I want to make is that the same logic is now being aimed squarely at data, and that the term you'll keep hearing for it ,"data product" is, for once, jargon that earns its keep.
A data product is just a pile of records that someone has bothered to give a clear name, a definition, an owner, and a promise, this is what it means, this is who looks after it, and it'll be kept current and correct.
It sounds almost too dull to be worth a label, which is probably why so few people did it for so long.
Most of the data experiences you actually enjoy are data products in precisely this sense.
Spotify Wrapped is your own listening history, cleaned up and handed back to you with a bow on it. Netflix's "because you watched" row is a quiet bet on your next click, and Amazon's "customers also bought" is the same move. None of them survive contact with messy inputs — they work because someone did the unglamorous part first.
I'll register one note of skepticism here, because the field is allergic to admitting any. "Data product" is also a phrase that consultants love a little too much, and plenty of organisations have rebranded the same neglected spreadsheets and declared victory. Rebranding the file changes nothing on its own; what changes things is whether someone actually owns it and is willing to stand behind it.
Where the idea stops being theoretical is money. When something looks free and nobody's watching, people are wasteful with it — that's not a moral failing, it's just how free things get treated. So a growing number of companies have started making internal usage visible, when your team consumes a data product, you can see who's using it, how much, and what it costs, sometimes as an actual internal charge against your budget. The behaviour change is almost immediate, and it cuts both ways. The teams producing data suddenly have customers who complain when it breaks, so they keep it reliable. The teams consuming it quietly stop maintaining the duplicate copies they'd been hoarding, because there's finally no reason to.
Some organisations take the next step and sell the thing outward — wrap a data product in an API, put a price on it, and point it at the market.
The financial-information business was practically built this way. Bloomberg charges a fortune for terminals that are, underneath, exquisitely maintained data products, and the big exchange groups like LSEG runs enormous market-data operations on the same principle.There are companies whose entire product is weather data. In each of these, data has stopped being the exhaust the business gives off and become the thing it runs on.
You'd assume that if data gets this easy to move around, privacy is the first thing to die. In practice it tends to run the other way. You can't protect, restrict, or delete something you can't find, and organising data is most of what makes finding it possible. A properly described data product can carry its own rules with it , what's personal, what's restricted, who's allowed near it — so the controls travel with the data instead of living in one analyst's head. Regulators increasingly just assume you can do this, GDPR in Europe and India's DPDP Act both give people the right to ask what you hold on them and, in some cases, to demand you erase it. You cannot honour that request if you genuinely don't know where their data is sitting, and "we couldn't find it" is not a defence.
And then there's AI, which raises the stakes on all of it. A model is only as good as what you feed it, and the failure cases are already in the public record — two New York lawyers got sanctioned after an AI tool invented court cases they cited as real, and a parade of companies have since restricted staff from pasting confidential material into public chatbots after it started leaking out. Feed a model garbage or secrets and it oscillates between confidently wrong and quietly catastrophic. Feed it well-governed, clearly-defined data and it gets genuinely useful. The companies getting real value out of AI right now are, with almost no exceptions, the ones that did the tedious data work first.
That's the part nobody wants to hear, because the data work is dull and slow and gets no applause. But it's also the part that decides whether everything built on top of it is worth anything at all.
Article authored by Rohit Kumar, COO (Chief Operating Officer), SCIKIQ