Product Judgment and Delivery
Turn evidence into outcomes, assumptions, testable slices, executable specifications, measurement plans, and owned feedback loops.
#LessonPhaseTimeRequirementOpen
01Define the Outcome Before You Choose the OutputFast implementation increases the penalty for choosing the wrong problem. Shape the outcome first so speed points in the right direction.Phase 1460 minRequired↗ Official lesson02Discover the Workflow People Actually PerformRequirements are not waiting in a meeting to be collected. They are scattered across actions, workarounds, records, and disagreements.Phase 1470 minRequired↗ Official lesson03Map Assumptions and Resolve the Riskiest One FirstA roadmap hides uncertainty inside features. An assumption map exposes what must be true before those features deserve to exist.Phase 1465 minRequired↗ Official lesson04Choose the Smallest Slice That Can Change the DecisionSmall is useful only when it proves something important. A tiny build that cannot change the next decision is merely incomplete.Phase 1465 minRequired↗ Official lesson05Write Specifications That Preserve JudgmentA useful specification fixes invariants and evidence while leaving reversible implementation choices open. It is a decision boundary, not a screenplay.Phase 1475 minRequired↗ Official lesson06Design Success Metrics Before the Result ExistsMeasurement should answer a decision, not decorate a dashboard. Start with the goal, derive questions, then choose the smallest metrics that answer them.Phase 1470 minRequired↗ Official lesson07Choose Prototype, Pilot, or Production DeliberatelyThese are different learning environments, not levels of polish. Choose the stage that answers the current unknown with the least unnecessary consequence.Phase 1470 minRequired↗ Official lesson08Build a Feedback Ratchet with Ownership and RetirementShipping closes one build loop and opens the learning loop. Evidence must change the system or it becomes telemetry nobody owns.Phase 1475 minRequired↗ Official lesson