The Product Cycle extends proven software engineering practices—TDD, OOP, and DDD—from code to the full product lifecycle. Understanding these foundations reveals why structured, reflexive artifacts matter.
TDD introduced a simple, powerful loop: Red → Green → Refactor. Write a failing test, make it pass, then improve the code without changing behavior.
Write a test that expresses the desired behavior. It fails because the behavior doesn't exist yet. The failing test is an assertion about what should be true.
Write the minimum code to make the test pass. Don't optimize or generalize—just satisfy the assertion. The test now documents working behavior.
Improve the code's structure without changing its behavior. The passing tests give you confidence to reshape. Clean code emerges incrementally.
TDD inverts the traditional sequence: instead of writing code then testing it, you express intent first (the test), then implement. The test is a specification. The code is the implementation of that specification. This pattern—assertion before implementation—is the seed of the Product Cycle.
OOP taught us to model systems as collaborating objects with clear responsibilities. DDD extended this to focus on the problem domain: speak the language of the business, and let that language shape the code.
OOP and DDD move modeling upstream. Before writing code, understand the domain. Name the concepts. Define their relationships. This Concept Inventory → Data Model step in the Product Cycle comes directly from DDD's emphasis on modeling the problem space before the solution space.
The Product Cycle applies these engineering practices to the entire product lifecycle—not just code, but the artifacts that inform code.
Use cases are the "tests" for product behavior. They assert what should happen before implementation begins. Acceptance criteria become executable specifications. Analytics validate whether assertions hold in production.
Personas establish bounded contexts for user needs. Concept inventories create ubiquitous language. Data models formalize the domain. The Product Manager is the domain expert facilitating shared understanding.
| Engineering Practice | Product Cycle Analog |
|---|---|
| Red (failing test) | Use case with unmet acceptance criteria |
| Green (passing test) | Working software that satisfies criteria |
| Refactor | Analytics-informed iteration |
| Domain model (DDD) | Concept Inventory & Data Model |
| Ubiquitous language | Shared vocabulary across artifacts |
| Bounded context | Persona-scoped use cases |
TDD's red/green/refactor loop operates at the scale of minutes. The Product Cycle operates at the scale of weeks or months. But the pattern is the same: assert, implement, learn, improve.
The fractal nature of feedback loops — The same pattern repeats at every scale. TDD keeps code correct. CI keeps builds healthy. The Product Cycle keeps products aligned with users. Each loop informs the others.
See how the Product Cycle puts these principles into practice.