Product loss descent

Product Loss Descent (PLD)

Develop a product the way you train a model: as a loss-minimizing loop. Each sweep over the work is an epoch; every epoch must decrease the loss; you stop when the loss plateaus.

The loss function

Define product loss as a measurable, observable quantity — the sum of what's wrong with the product right now:

loss = open_bugs
     + missing_required_features
     + UI/UX_roughness
     + regressions            # ← weighted heavily; see the hard rule

Pick a concrete proxy for each term so the number is real, not a vibe (e.g. failing/missing test count, open issues, a rubric score for UI roughness, broken user journeys). You don't need precision — you need a number that moves in the right direction and that you measure the same way each epoch.

The two hard rules

1. Monotonic, no-regression. An epoch may never introduce a new bug or break a working feature. A change that fixes 3 things but breaks 1 is a failed epoch — the regression term dominates. Working behavior is sacred; protect it with tests before you touch it (this is the regression-ratchet, made continuous).
2. Stop at the plateau. When an epoch yields only diminishing returns — loss barely moves — stop the session. Plateaued effort is wasted effort and a source of accidental regressions. Resume in a later session with fresh scope.

The loop

1. MEASURE loss (baseline for this epoch — the same metrics each time)
2. Pick the highest-loss term and reduce it
3. VERIFY: re-measure. Did loss go DOWN? Did any term go UP? (no-regression check)
4. If a term went up → revert/fix until it doesn't, before moving on
5. Repeat until loss plateaus → STOP for the session

Why this works / when to use it

• It makes "are we done?" measurable instead of a judgment call — done = plateau, not "feels finished".
• It forbids the most common failure: shipping a fix that quietly breaks something else.
• It bounds session length rationally (stop at diminishing returns) instead of grinding.

Use it for any sustained build/improve/polish effort. It composes with: process-aware completion (loss is the evidence), test-driven development (tests define the bug/regression terms), and behavior-evidence audits (the no-regression check). It is not for one-shot tasks with a single obvious endpoint.

Anti-patterns

• A "loss" you don't actually measure → you're guessing, not descending.
• Tolerating a small regression "for now" → the regression term is the one you weight most; never.
• Grinding past the plateau → diminishing returns + rising regression risk.
• Adding new features while bugs are open and loss is high → reduce existing loss first.