What domain knowledge changes in product development
Knowing the process produces different invariants. Not more features — different failures you cannot afford.
In container-glass production a recipe is not a list of ingredients. It is a decision about temperature, redox, cost, and what the next shift will find. Model that as form fields and you lose the order in which reality hits.
Domain knowledge therefore changes the questions first. Not: which screen is missing? But: what must not silently disappear after weighing? What must one shift leave the next without a side calculation in someone’s head?
The technical consequences are unspectacular. Bookings become states. Calculations stay bound to versions. Validation is a step someone can see. Migrations and backups belong to the product, not to aftercare.
For technical decision-makers: put someone who can explain the process at the start of the architecture — not at the end of acceptance. The most expensive defect is the one the system allows because nobody treated it as domain.