Ship Decisions

🚪 Two-Way Doors (Reversible)

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

🚪 One-Way Doors (Irreversible)

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

How to Apply:

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

Examples:

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)

2. The Shipping Scorecard (Source: Shreyas Doshi)

Is It Ready?

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

The 5-Check System:

✅ 1. Core Functionality Works

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

✅ 2. Edge Cases Acceptable

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

✅ 3. Reversible Decision

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

✅ 4. Learning Value > Polish Value

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

✅ 5. Risk Mitigated

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

Scoring:

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

3. Technical Debt vs Shipping Speed (Source: Marty Cagan, Tobi Lutke)

The Tradeoff:

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

When to Ship with Tech Debt:

• 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

When to Pay Down Debt First:

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

Framework:

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

4. Gradual Rollout Strategy (Source: Modern tech best practices)

Don't Ship to Everyone at Once:

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

The Rollout Ladder:

Stage 1: Internal (1-10 users)

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

Stage 2: Early Adopters (1-5% users)

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

Stage 3: Broader Beta (10-25%)

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

Stage 4: General Availability (100%)

• All users
• Stable metrics
• Duration: Ongoing

Rollback Plan:

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

// Quick rollback = change flag, no deploy

Decision Tree: Ship or Wait?

FEATURE: Ready to evaluate
│
├─ Core functionality works? ───────NO──→ FIX CRITICAL BUGS
│  YES ↓
│
├─ Is this reversible decision? ────────┐
│  YES (two-way door) ──────────────────┤
│  NO (one-way door) → RESEARCH MORE    │
│                                        ↓
├─ Edge cases acceptable? ──────────────┤
│  YES ─────────────────────────────────┤
│  NO → FIX OR GRACEFUL DEGRADATION     │
│                                        ↓
├─ Can we learn from shipping? ─────────┤
│  YES ─────────────────────────────────┤
│  NO → TEST/PROTOTYPE MORE             │
│                                        ↓
├─ Risk mitigated? ─────────────────────┤
│  YES → SHIP GRADUALLY                 │
│  NO → ADD MONITORING/ROLLBACK         │
│                                        ↓
└─ SHIP ←───────────────────────────────┘
   Start: Internal → 5% → 25% → 100%

Action Templates

Template 1: Shipping Readiness Assessment

# Feature: [Name]

## Shipping Scorecard

### 1. Core Functionality Works
- [ ] Happy path works end-to-end
- [ ] User can complete main job
- [ ] No critical bugs blocking core use
**Status:** [Ready / Needs work]

### 2. Edge Cases Acceptable
- [ ] Error states handled gracefully
- [ ] User can recover from failures
- [ ] Edge cases don't break experience
**Status:** [Acceptable / Needs improvement]

### 3. Reversible Decision
- Is this reversible? [Yes / No]
- Rollback plan: [describe]
- Two-way door? [Yes / No]
**Status:** [Safe to ship / Risky]

### 4. Learning Value
- 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]

### 5. Risk Mitigated
- [ ] Monitoring in place
- [ ] Gradual rollout plan
- [ ] Critical failure modes addressed
**Status:** [Risks managed / Needs work]

## Score: [X / 5]

**Decision:**
- 5/5 → Ship to 5% immediately
- 4/5 → Ship to internal first
- 3/5 → One more iteration
- <3 → Not ready

## Rollout Plan
- [ ] Internal (team): [date]
- [ ] Early adopters (5%): [date]
- [ ] Broader beta (25%): [date]
- [ ] General availability (100%): [date]

Template 2: Tech Debt Decision

# Feature: [Name]

## Technical Debt Assessment

### Current Debt
[Describe shortcuts taken, code quality issues]

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

**Debt Impact:** [High / Medium / Low]

### Payoff of Fixing Now
- Time to refactor: [X days]
- Would unblock: [list]
- Would improve: [list]

**Refactor Value:** [High / Medium / Low]

### User Value of Shipping Now
- User problem solved: [describe]
- Revenue/metric impact: [estimate]
- Competitive advantage: [Yes / No]
- User waiting for this: [Yes / No]

**Shipping Value:** [High / Medium / Low]

## Decision

IF Shipping Value > Debt Impact:
→ **SHIP NOW, refactor later**
   Plan: [when to address debt]

IF Debt Impact > Shipping Value:
→ **REFACTOR FIRST, then ship**
   Plan: [how to refactor]

IF Uncertain:
→ **SHIP TO SMALL GROUP (5%)**
   Monitor: [specific metrics]

Template 3: One-Way vs Two-Way Door

# Decision: [Description]

## Reversibility Analysis

### Can we reverse this decision?
[Yes / No / Partially]

### Cost to reverse
- Time: [X days/weeks]
- Money: [$X]
- User impact: [High / Medium / Low]
- Team impact: [High / Medium / Low]

### Why hard to reverse?
[Technical, contractual, brand, user expectations, etc.]

## Door Type

**Two-Way Door (Reversible):**
→ Decide in: Hours/days
→ Process: Ship fast, iterate
→ Research: Minimal

**One-Way Door (Irreversible):**
→ Decide in: Weeks/months
→ Process: Research, debate, consensus
→ Research: Extensive

## Decision
Door type: [Two-way / One-way]
Decision timeline: [X time]
Process: [describe]

Quick Reference Card

🚢 Shipping Decision Checklist

Before Evaluating:

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

The 5 Questions:

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 ✓

Decision Rules:

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

Rollout Ladder:

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

Real-World Examples

Example 1: Facebook's "Move Fast" Philosophy

Approach: Ship fast, break things (early days)

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

Evolution: "Move fast with stable infrastructure"

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

Example 2: Stripe's API Versioning

Challenge: Changing API breaks customers

Decision: ONE-WAY DOOR

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

Result: Trust through stability

Example 3: Tech Debt at Airbnb

Challenge: Ship new features vs refactor

Decision Framework:

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

Result: Strategic debt paydown, maintained velocity

Common Pitfalls

❌ Mistake 1: Treating All Decisions Like One-Way Doors

Problem: Slow decision-making, perfectionism Fix: Identify two-way doors, ship fast on those

❌ Mistake 2: Shipping Broken Core Functionality

Problem: "Move fast and break things" gone wrong Fix: Core must work, edge cases can be rough

❌ Mistake 3: No Rollback Plan

Problem: Ship breaks, no way to undo Fix: Feature flags, gradual rollout

❌ Mistake 4: Ignoring Compounding Tech Debt

Problem: Short-term speed, long-term slowdown Fix: Strategic debt paydown

Related Skills

• 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

Key Quotes

Jeff Bezos (Amazon):

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

Shreyas Doshi:

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

Marty Cagan:

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

Tobi Lutke (Shopify):

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

Further Learning

• 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