Data products need retirement metrics before portfolios become data swamps

Data products need retirement metrics before portfolios become data swamps. Teams are usually better at approving a new product than proving an old one should continue. The result is not merely catalog clutter: every abandoned output port, stale contract, duplicate metric, and ownerless pipeline consumes trust while appearing to expand platform capability.

Data products fail at lifecycle, not design. The missing stage is often a real end-of-life decision. Product mode is supposed to replace project mode, but “products are long-lived” easily mutates into “products never die.” A useful portfolio must be able to distinguish an enduring decision interface from a historical artifact that still happens to run.

Usage alone is an inadequate test. A table may receive thousands of automated queries from one forgotten job and create no current business value. Another product may serve a small number of critical risk decisions. Retirement evidence therefore needs several dimensions: unique active consumers, reuse across domains, self-service adoption, decisions or workflows enabled, SLO adherence, support burden, unit cost, contract violations, and overlap with successor products. The metric is not popularity; it is value relative to operating obligation.

I would give each product an operating envelope at birth and a retirement review date. The envelope names its customer, decision, owner, output ports, quality objectives, and expected adoption signals. The review asks whether those signals still exist, whether the underlying use case drifted, and whether another product now covers the same need. Without a date, decommissioning competes forever with new delivery and always loses.

Retirement must be a governed workflow, not a deletion ticket. Lineage identifies consumers; owners receive a migration window; telemetry distinguishes active use from scheduled noise; contracts publish deprecation state; replacement mappings explain where users should move. Read access can be observed before writes stop. A final snapshot and provenance record preserve auditability without preserving a live pipeline. Metadata becomes the control plane when it can drive this sequence rather than merely document it.

The portfolio itself should expose health. Count products with named consumers, products beyond their review date, duplicate business metrics, ownerless assets, deprecation windows in progress, and operating cost per consequential decision. These measures counter the vanity metric of catalog size. A platform with eighty well-owned products and an active retirement discipline is healthier than one advertising eight hundred entries nobody is authorized to remove.

Ownership must include the authority to stop. If a product owner can approve features but cannot retire an output because no cross-domain decision process exists, the role is custodial rather than product-led. A lightweight portfolio council should resolve shared dependencies, approve deprecation exceptions, and put a price on indefinite support. That makes continuation a funded choice instead of the unexamined default.

There is one precise concession: regulatory, forensic, or contractual retention may require data to remain accessible after active use ends. That requirement justifies archival preservation, not an indefinitely running product interface. Separate retention from operation — preserve immutable evidence at the required fidelity while retiring refresh jobs, support promises, and discoverability as a current product.

A data swamp is often described as raw data without metadata. Product sprawl creates a more deceptive version: well-described assets with no remaining reason to exist. The catalog looks governed while consumers navigate obsolete choices and operators maintain dead obligations. Retirement metrics close the lifecycle by making subtraction legitimate. If a data product cannot state the evidence that will keep it alive — or the evidence that will let it die — it was launched without a complete product model.