Designing Data Products Beyond the “More Data” Myth

Designing Data Products Beyond the “More Data” Myth

Data product teams often begin with a growth assumption: more data will make the product better. More events, more attributes, more integrations, more dashboards, more model features. Klaus Hoeyer’s Data Paradoxes, based on its title, table of contents, and introductory excerpt, offers a necessary corrective: more data can create value, but it can also create paradoxes.

The book studies intensified data sourcing in contemporary healthcare, with Denmark as the primary case. Denmark is not chosen because it is average. It is chosen because it is advanced: digitized health services, integrated data infrastructures, and personal identity numbers that allow tracking across sectors and lifespans. This makes it a powerful test case for data-driven promises.

The excerpt describes those promises clearly. Data-driven healthcare is expected to predict disease, personalize regimes, replace some human interpretation with AI, make healthcare cheaper, and optimize governance through smart algorithms. These promises are familiar to anyone building data and AI products. They sound modern, rational, and inevitable.

But Hoeyer’s argument is that data promises collide with local practices. Data is not simply information waiting to be extracted. It is produced, categorized, cleaned, moved, interpreted, and used by different actors for different purposes. The same data can serve research, clinical care, administration, policy, governance, and commercial interests. That multiplicity creates tensions.

For technology consultants, this is a product design issue. If data is multiple, then a data product cannot be designed only around storage, pipelines, and models. It must be designed around use contexts. Who produces the data? Who bears the burden of data work? Who interprets the output? Who benefits? Who is exposed to risk? Which decisions will the product influence?

The table of contents suggests a useful product framework: promises, living, work, experiences, wisdom, and pandemic politics. Translated into product terms, every data product needs a promise layer, a user-context layer, an operations layer, an experience layer, a decision-quality layer, and a crisis or edge-case layer.

This is especially relevant for AI systems. Many AI failures are not model failures in the narrow sense. They are failures of data practice. The data may encode administrative convenience rather than reality. The categories may not match user experience. The collection process may create extra labor. The dashboard may create false certainty. The model may shift responsibility onto users who cannot meaningfully control the outcome.

At Ozycore, the lesson would be to design data products with “better data use” as the goal, not “more data” as the default. That means building governance into the product, supporting traceability, exposing uncertainty, and understanding the human workflow around the data. It also means asking the uncomfortable question Hoeyer foregrounds: better for whom, and according to which criteria?

A mature data strategy does not worship data volume. It treats data as infrastructure, practice, and power. Products built on that understanding will be more trustworthy, more useful, and more resilient.