Data products are often launched as though they were complete: dashboards go live, models are deployed, metrics are formalised. This framing is convenient — and false.
A data product begins to change the moment it is used.
Use Is a Form of Mutation
Once a data product enters the world:
- Users adapt their behaviour
- Incentives shift
- Feedback loops form
These changes alter the data the product receives, which in turn alters its outputs. The product evolves — whether or not its designers are paying attention.
Completion Is a Myth
Traditional product development aims for stability: defined requirements, fixed outputs, controlled releases. Data products resist this logic. Their correctness depends on context, and context is never stable.
Treating a data product as finished leads to:
- Metric ossification
- Model drift
- Loss of trust over time
Designing for Ongoing Stewardship
Mature organisations treat data products as living systems that require stewardship rather than maintenance. This includes:
- Continuous monitoring of behavioural impact
- Periodic reassessment of assumptions
- Willingness to deprecate and redesign
Ownership does not end at deployment.
Evolution Over Optimisation
Optimisation assumes a fixed objective. Evolution assumes changing conditions. Data products must be designed to adapt — not to converge on a single “optimal” state.
This requires:
- Modularity rather than monoliths
- Feedback-aware governance
- Explicit mechanisms for change
The Responsibility of Continuity
Declaring a data product finished absolves its creators of responsibility for its future effects. Recognising it as unfinished does the opposite — it acknowledges ongoing accountability.
A data product is not a tool that delivers truth.
It is a system that shapes behaviour over time.
The question is not when a data product is done.
It is who remains responsible for what it becomes.
Leave a Reply