iteration

a product learns only when each change's effect is attributable. invariant: one question per change — a small step that names its question, ships with risk matched to blast radius, judged by before/after evidence. batched changes make movement unattributable: which change helped, which hurt, what to revert — the next decision is a guess. small verified steps turn each release into one unit of learned truth, not a bundle of hypotheses.

change the product in small, coherent, verified steps — same forward-only discipline as code. every change:

• names the product question it moves
• ships behind a feature flag when its blast radius warrants
• is judged afterward by verification evidence: did the question move, did nothing else regress?

1. pick from the prioritized list (prioritization) — one question at a time.
2. design the smallest change that could move it.
3. ship dark or flagged when risky; direct when small.
4. verify at the live boundary (deployment and UAT).
5. judge by evidence: the analytics question's before/after, error rates, feedback themes.
6. record the outcome next to the question — moved, didn't move, moved the wrong thing — and let it re-rank the list.

• batch many questions into one change; evidence cannot attribute movement.
• ship without recording which question the change claims to move.
• judge by effort spent or shipped count; judge by the question's movement.
• let a failed change linger half-alive behind a flag — kill it and record the learning.

• pick the last three shipped changes: each names its question, its flag state, its post-ship evidence.
• a change that cannot show its evidence is unjudged — a defect in the loop, not just the change.
• confirm the outcome notes re-ranked the next iteration's list.

bad

v2.1 release:
  - redesigned editor UI (visual polish)
  - added real-time analytics dashboard (power-user feature)
  - new navigation sidebar (discovery improvement)
  - updated billing page copy (clarity)
  - added dark mode support

result: shipped 2026-08-15
metrics after: engagement +18%, first-run completion +22%, support tickets +7%

all four changes shipped together. engagement +18% — which change drove it? editor polish or the new dashboard? did dark mode retain power users, or the sidebar? support tickets rose — did one feature introduce bugs? movement cannot be attributed, so the next iteration's list is guessing. revert one change — you might lose the real win. add similar — you might replicate the bug. evidence trail broken.

good

v2.1.0: remove optional settings screen before first workflow run
  question: can a new visitor reach a first valuable moment?
  flag: direct (low blast radius)
  before: 32% first-run completion
  after: 48% first-run completion
  shipped: 2026-08-15

v2.1.1: add real-time analytics dashboard (flagged: beta_analytics)
  question: do power users engage more when they can see live metrics?
  flag: experiment (50% of returning users > 100 workflows)
  before: 3.2% visit analytics section (when it existed)
  after: watching...
  shipped: 2026-08-16

each change names its question, its risk level, its evidence. the team ships small and knows which change moved what. dark mode ships next — isolated, effect clear. over a sequence of releases this compounds: every question carries its measured before and after, failed changes get killed and learned from in days, the next prioritization decision argues from attribution, not narrative.

prioritization · feature flags · deployment and uat · verification evidence · analytics