No product starts with a complete and final definition. Products are discovered, tested, and refined. The problem is not that decisions change. The problem is that they become scattered across roadmaps, tickets, documents, specifications, and conversations.

A product rule is agreed and delivered. Later, it changes. Some teams update their work, while other specifications, tests, and assumptions still reflect the previous decision. That is how features are built and rejected, requirements are misunderstood, and work is refined repeatedly or rebuilt from scratch.

AI and coding agents make this happen faster. Spec-Driven Development adds useful discipline by defining each increment before implementation, but it does not by itself prevent a growing set of specifications from repeating, reinterpreting, or contradicting product decisions.

This talk presents Product Definition as Code as a recently proposed, open framework for maintaining an evolving product definition that delivery work can cite instead of recreate. It shows how explicit product changes, connected decisions, and stale-reference detection help Product, Engineering, and QA stay aligned as the product evolves.

The goal is not to return to waterfall or freeze requirements. It is to make changing the product cheaper, reduce rework, and let teams develop faster because they are defining and verifying better.