The Shipping Decision Matrix

When This Skill Activates

Claude uses this skill when:

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

Core Frameworks

1. Reversible vs Irreversible Decisions (Source: Jeff Bezos, applied by Shreyas Doshi)

One-Way vs Two-Way Doors:

"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."

The Framework:

🚪 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:

Works? Core functionality end-to-end ✓
Acceptable? Edge cases handled gracefully ✓
Reversible? Can we undo or iterate? ✓
Learn? Shipping teaches us more than building? ✓
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:

Internal (team)
Early adopters (5%)
Broader beta (25%)
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

ship-decisions