Data products fail at lifecycle, not design
The data-product idea is sound and the design literature is rich: anatomy of ports and contracts, source-aligned versus consumer-aligned taxonomies, DATSIS characteristics, even a "Figma for data products" design philosophy. Yet most data-product initiatives quietly become what they were meant to replace — datasets nobody owns. The failure is rarely in the design phase. It's in everything after: no owner past launch, no deprecation path, no consumer feedback loop, no metrics anyone reads. The design stage gets the workshops. The lifecycle gets nobody.
The canonical lifecycle has four stages — design, develop, deploy, evolve — and organisational energy is distributed almost exactly inversely to where value accrues. Design and develop are bounded projects with visible artifacts; they attract sponsors. Evolve is unbounded, invisible, and permanent — and it's where a data product actually earns the word "product." This is the old distinction between product mode and project mode: a project ends at deployment, a product begins there. Data teams overwhelmingly run project mode with product vocabulary. When the project closes, the "product" enters its real life — schema drifting, consumers accumulating undocumented dependencies, quality decaying compound-interest style — with no one on rotation.
What an operating model actually requires
The operational literature is blunt about what's missing, and it enumerates cleanly:
- An owner who survives launch. A named data product manager or owner accountable for the thing in year two, not just quarter one. The DPM/DPO split matters less than the continuity — someone whose calendar still contains this product after the launch party.
- Honest adoption metrics. Reuse rate across domains and self-serve rate, not raw query counts — vanity usage and true adoption diverge quickly, and only one of them justifies the product's continued existence and budget.
- Versioning and an exit. Explicit version mechanics, a defined inflection point where a change becomes a new product, and a decommissioning path. A product that can't be retired becomes the banana peel the next generation slips on.
- A feedback loop with consumers. Without one you get use-case drift — the product still serves the question of two years ago — and unchecked proliferation curdles into data product sprawl, a mesh of a hundred products where thirty are load-bearing and nobody knows which.
None of this is glamorous, which is precisely why it's skipped. But strip it away and what remains of a "data product" is a dataset with a logo — same governance gaps, same orphaned tables, better branding. And the standard rises from here: as agents become consumers, the product must answer machine questions about its own freshness, quality, and semantics through contracts and metadata interfaces, because there's no human in the loop to compensate — the same operational substrate an AI flywheel quietly presumes.
The honest counter-case: design failures do exist, and one is fatal — building the technically correct wrong product. The lifecycle discipline "find the customer before developing" can't rescue a product no one needed, and no amount of SLO dashboards will manufacture demand. I'd also note the corpus this thinking draws from is vendor-adjacent, so the prescriptions skew toward platforms that sell the operating model. But the pattern survives the discount: I've seen well-designed products die of neglect far more often than well-operated products die of bad design. Fund the boring half. That's where the product lives or doesn't.