• User asks "is this ready to ship?"
• Deciding between shipping now vs iterating more
• Evaluating if "good enough" is good enough
• Balancing technical debt vs shipping speed
• Preventing perfectionism paralysis

"Some decisions are like one-way doors - hard to reverse. Most decisions are like two-way doors - easy to reverse. Don't treat all decisions the same."

• Can be undone or changed easily
• Low cost to reverse
• Learning > being right
• Decision speed: FAST (hours/days)
• Process: Ship and iterate

• Hard or impossible to reverse
• High cost to undo
• Need to get it right
• Decision speed: SLOW (weeks/months)
• Process: Research, debate, decide carefully

Before shipping, ask:
1. "Can we reverse this decision?"
   - YES → Two-way door → Ship fast, iterate
   - NO → One-way door → Go slow, get it right

2. "What's the cost of being wrong?"
   - LOW → Ship and learn
   - HIGH → Research more

3. "Can we learn more by shipping?"
   - YES → Ship to learn
   - NO → Prototype/test first

TWO-WAY DOORS (Ship Fast):
✅ Button color
✅ Copy/messaging
✅ UI layout
✅ Feature flag experiments
✅ Pricing (for small customers)

ONE-WAY DOORS (Go Slow):
⚠️ Database schema (migrations expensive)
⚠️ API contracts (breaking changes hurt users)
⚠️ Brand decisions (hard to rebrand)
⚠️ Pricing (for enterprise customers)
⚠️ Architecture (refactoring expensive)

"Don't ship broken products. But also don't wait for perfect. Ship when it's good enough for real users to get value."

• Happy path functions end-to-end
• User can complete main job
• No critical bugs

• Not perfect, but handled gracefully
• Errors don't break experience
• User can recover

• Can we undo or iterate?
• Is this a two-way door?
• What's the rollback plan?

• Will shipping teach us more than building more?
• Do we need real user feedback to improve?
• Is hypothetical polish valuable without data?

• Critical failure modes addressed
• Monitoring in place
• Gradual rollout plan

5/5 checks → SHIP NOW
4/5 checks → SHIP TO SMALL GROUP
3/5 checks → ITERATE ONE MORE CYCLE
<3/5 checks → NOT READY

"Technical debt isn't inherently bad. It's bad when it slows you down. Ship fast, pay down debt strategically."

• Learning debt: Need user feedback to validate approach
• Temporary: Planning to refactor soon anyway
• Isolated: Debt doesn't affect other systems
• Value >> Debt cost: User value gained > refactor cost

• Compounding debt: Will make future changes harder
• Security/Privacy: User trust at risk
• Platform/API: Breaking changes expensive
• Team velocity: Slowing everyone down

Assess Tech Debt:
1. What's the carrying cost?
   - Slows future features?
   - Blocks other teams?
   - Creates bugs?

2. What's the payoff of fixing?
   - Unblocks work?
   - Reduces bugs?
   - Improves velocity?

3. What's the user value of shipping now?
   - Solves immediate problem?
   - Competitive advantage?
   - Revenue impact?

Decision:
IF (user value > debt cost) → SHIP
IF (debt blocks future) → REFACTOR
IF (uncertain) → SHIP TO SMALL GROUP

"The safest way to ship is gradually. Start small, monitor, expand."

• Team uses it daily
• Find obvious bugs
• Duration: 1-3 days

• Select forgiving users
• Eager for new features
• Provide feedback actively
• Duration: 3-7 days

• Larger sample size
• Monitor metrics closely
• Duration: 1-2 weeks

• All users
• Stable metrics
• Duration: Ongoing

// Feature flag implementation
if (isFeatureEnabled(user, 'new-feature')) {
  return newExperience();
} else {
  return oldExperience();
}

// Quick rollback = change flag, no deploy

• Happy path works end-to-end
• User can complete main job
• No critical bugs blocking core use Status: [Ready / Needs work]

• Error states handled gracefully
• User can recover from failures
• Edge cases don't break experience Status: [Acceptable / Needs improvement]

• Is this reversible? [Yes / No]
• Rollback plan: [describe]
• Two-way door? [Yes / No] Status: [Safe to ship / Risky]

• Will shipping teach us more? [Yes / No]
• Do we need real user feedback? [Yes / No]
• Is polish speculative without data? [Yes / No] Status: [Ship to learn / Build more first]

• Monitoring in place
• Gradual rollout plan
• Critical failure modes addressed Status: [Risks managed / Needs work]

• 5/5 → Ship to 5% immediately
• 4/5 → Ship to internal first
• 3/5 → One more iteration
• <3 → Not ready

• Internal (team): [date]
• Early adopters (5%): [date]
• Broader beta (25%): [date]
• General availability (100%): [date]

undefined

• Slows future features? [Yes / No / How much]
• Blocks other teams? [Yes / No]
• Creates bugs? [Yes / No / Frequency]
• Security/privacy risk? [Yes / No]

• Time to refactor: [X days]
• Would unblock: [list]
• Would improve: [list]

• User problem solved: [describe]
• Revenue/metric impact: [estimate]
• Competitive advantage: [Yes / No]
• User waiting for this: [Yes / No]

• Time: [X days/weeks]
• Money: [$X]
• User impact: [High / Medium / Low]
• Team impact: [High / Medium / Low]

• Core functionality tested
• Edge cases identified
• Rollback plan ready

1. Works? Core functionality end-to-end ✓
2. Acceptable? Edge cases handled gracefully ✓
3. Reversible? Can we undo or iterate? ✓
4. Learn? Shipping teaches us more than building? ✓
5. Safe? Risks mitigated, monitoring ready ✓

• 5/5 → Ship to small group now
• 4/5 → Ship internal first
• 3/5 → One more iteration
• <3/5 → Not ready yet

1. Internal (team)
2. Early adopters (5%)
3. Broader beta (25%)
4. General availability (100%)

• Two-way doors: Ship immediately
• Feature flags: Easy rollback
• Gradual rollouts: 1% → 5% → 25% → 100%

• One-way doors: Go slow (API, platform)
• Two-way doors: Still fast (UI, features)

• Treat API as contract
• Never break backwards compatibility
• Version all changes
• Support old versions forever

• Debt blocking growth → Refactor first
• Debt isolated → Ship, refactor later
• Uncertain → Ship to 5%, measure velocity

• strategic-build - For LNO framework (is this Leverage work?)
• quality-speed - For craft quality vs shipping speed
• zero-to-launch - For MVP scoping decisions
• exp-driven-dev - For A/B testing risky changes

"Some decisions are consequential and irreversible - one-way doors. Make those slowly. Most decisions are reversible - two-way doors. Make those fast."

"The best PMs know when 'good enough' is good enough. Ship to learn, not to be perfect."

"Technical debt isn't the enemy. The enemy is debt that compounds and slows you down."

"Trust is built on shipping what you promise. Ship early, ship often, ship small."

• references/reversible-decisions.md - One-way vs two-way doors guide
• references/shipping-checklist.md - Comprehensive readiness assessment
• references/gradual-rollout-guide.md - Feature flag implementation
• references/tech-debt-paydown.md - Strategic refactoring frameworks