菜单
Before deliberating over a decision, ask if it's a one-way door (costly to undo) or two-way (cheap to undo) — decide two-way doors fast, and look for moves that make one-way doors reversible.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
| name | thinking-reversibility |
| description | Before deliberating over a decision, ask if it's a one-way door (costly to undo) or two-way (cheap to undo) — decide two-way doors fast, and look for moves that make one-way doors reversible. |
Jeff Bezos distinguishes between Type 1 (irreversible, one-way door) and Type 2 (reversible, two-way door) decisions. The key insight: most decisions are Type 2 but get treated as Type 1, causing analysis paralysis. Match your decision process to the reversibility of the decision.
Core Principle: Reversible decisions should be made quickly by individuals. Irreversible decisions deserve deliberation. Most decisions are more reversible than they appear.
Decision flow:
Decision to make?
→ Is it easily reversible? → yes → DECIDE QUICKLY (Type 2)
→ Is it hard/impossible to reverse? → yes → DELIBERATE CAREFULLY (Type 1)
→ Unsure of reversibility? → ANALYZE REVERSIBILITY FIRST
Before deliberating over a decision:
If the decision is forced by an external constraint with no optionality, reversibility doesn't change the available move. If an irreversible action is genuinely required and the upside justifies it, name it and proceed.
Characteristics:
Examples:
Process:
Characteristics:
Examples:
Process:
| Factor | Question | Impact on Reversibility |
|---|---|---|
| Technical cost | How hard to undo technically? | High cost = less reversible |
| Time cost | How long to reverse? | Months = less reversible |
| Financial cost | How expensive to change? | High cost = less reversible |
| Reputation cost | Will reversal damage trust? | Yes = less reversible |
| Learning cost | Will we lose the learning? | Critical learning = more complex |
| Dependency cost | Have others built on this? | Many dependents = less reversible |
Reversibility Score:
- Can undo in days with minimal cost: TYPE 2 (two-way door)
- Can undo in weeks with moderate cost: TYPE 2 with monitoring
- Can undo in months with significant cost: TYPE 1.5 (evaluate carefully)
- Cannot realistically undo: TYPE 1 (one-way door)
| Decision Type | Process | Effort | Who decides |
|---|---|---|---|
| Type 1 | Full analysis, argue the alternative, document | High | Surface to human owner before committing |
| Type 1.5 | Structured analysis, document rationale | Moderate | Flag to owner if stakes are high |
| Type 2+ | Quick analysis, note rationale | Low | Decide and proceed |
| Type 2 | Just decide | Minimal | Decide and proceed |
Decision: Which logging library to use
Common mistake: Extensive evaluation, committee decision, weeks of analysis
Reality: Can swap libraries in a day; dependencies are isolated
Correct approach: Engineer picks one, team evaluates after 2 weeks
Cost of over-deliberation: Weeks of productivity lost
Decision: Database technology for core product
Common mistake: Quick decision because "we can always change later"
Reality: Changing databases means rewriting queries, data migration, retraining
Correct approach: Thorough evaluation, prototype, stakeholder alignment
Cost of under-deliberation: Months of migration pain later
Some seemingly irreversible decisions are actually reversible:
"We can't change our API because clients depend on it"
Reality: Versioning makes this reversible
v1 continues, v2 adds improvements
"We can't change the architecture"
Reality: Strangler pattern enables gradual change
Migrate piece by piece
Some seemingly reversible decisions lock you in:
"It's just a prototype, we can rewrite later"
Reality: Prototypes often become production
"Temporary" code lives for years
"We can always switch cloud providers"
Reality: Deep integration creates massive switching cost
Proprietary services create lock-in
Turn Type 1 into Type 2 through limited rollout:
Type 1: "Adopt new framework for entire codebase"
Piloted: "Use new framework for one service"
→ Now it's Type 2: Can abandon pilot with limited impact
→ If successful, expand incrementally
Create reversibility through interfaces:
Type 1: "Choose between Postgres and MySQL"
With abstraction: "Define data layer interface, start with Postgres"
→ Can swap implementation later
→ Cost of reversal dramatically reduced
Make long commitments into short experiments:
Type 1: "Commit to vendor for 3 years"
Time-boxed: "Start with 6-month pilot"
→ Can exit at known cost
→ Full commitment only after validation
Deploy with reversibility built in:
Type 1: "Launch new pricing model"
With flags: "Launch to 5% of users, flag-controlled"
→ Can disable instantly
→ Expand only when confident
# Reversibility Analysis: [Decision]
## The Decision
[What we're deciding]
## Reversibility Assessment
| Factor | Assessment | Score (1-5) |
|--------|------------|-------------|
| Technical effort to reverse | [Details] | |
| Time to reverse | [Duration] | |
| Financial cost to reverse | [Cost] | |
| Reputation impact of reversal | [Impact] | |
| Dependencies affected | [Count/scope] | |
| Learning lost if reversed | [Value] | |
Average: [X]
- 1-2: Clear Type 2
- 3: Type 1.5
- 4-5: Type 1
## Decision Type: [Type 1 / 1.5 / 2]
## Appropriate Process
- Analysis depth: [Minimal / Moderate / Extensive]
- Surface to human owner before committing? [No / Yes if high-stakes / Yes]
- Documentation: [None / Brief / Full]
## Can We Increase Reversibility?
- Pilot: [Option]
- Abstraction: [Option]
- Time-box: [Option]
- Feature flag: [Option]
## Decision
[The choice made]
## Reversal Plan (if needed)
[How we would reverse if this proves wrong]
"Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation."
"But most decisions aren't like that – they are changeable, reversible – they're two-way doors. If you've made a suboptimal Type 2 decision, you don't have to live with the consequences for that long. You can reopen the door and go back through."
"As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention."
Speed matters. Most decisions are reversible. Decide, learn, adjust.