selamy-labs 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
- 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).
- 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.