Loading...
Loading...
Guides "ship or iterate?" decisions using Shreyas Doshi's frameworks, Marty Cagan's shipping philosophy, and Tobi Lutke's reversible decision-making. Use when deciding if feature is ready, preventing perfectionism paralysis, applying one-way vs two-way door thinking, or balancing technical debt vs shipping speed.
npx skill4agent add menkesu/awesome-pm-skills ship-decisions"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."
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 firstTWO-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."
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."
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."
// Feature flag implementation
if (isFeatureEnabled(user, 'new-feature')) {
return newExperience();
} else {
return oldExperience();
}
// Quick rollback = change flag, no deployFEATURE: 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%# 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]# 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]# 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]"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."