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. I now want its health model tied to the decision it exists to support: adoption without a named outcome is usage theatre, while a composite quality score without an escalation or retirement rule is monitoring without ownership. A metric should change funding, remediation, versioning, or decommissioning—or it is only catalog decoration.

The standard rises further as agents become consumers. The product must answer machine questions about freshness, quality, semantics, access, and version compatibility through contracts and metadata interfaces because there is no analyst in the loop to compensate. Its owner also needs a machine-consumer change policy: which contract break blocks release, which degraded state forces abstention, and which successor proves that retirement will not strand automated decisions. That is the 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. Lifecycle discipline cannot rescue a product no one needed, and no amount of SLO dashboards will manufacture demand. The corpus is also vendor-adjacent, so its prescriptions skew toward platforms that sell the operating model. The boundary of my claim is a product with a real consumer and decision to support; once those exist, launch must begin the governed operating loop rather than end the delivery project. Fund the boring half. That is where the product lives or does not.