menkesu 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