Reversibility and Second-Order Decision Review
Match decision rigor to reversibility and trace the consequences that follow
- Difficulty
- Moderate
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 98%
This review combines reversibility with second-order thinking to determine how much rigor a product decision deserves. First ask whether the choice is a two-way door that can be changed cheaply or a one-way door that will constrain future options, users, policy, or infrastructure. Then map the direct effect and trace at least the next two levels of consequences across the ecosystem. Write the first principles the solution must preserve and add explicit second-order prompts to specifications or review documents. Let autonomous teams move quickly on reversible choices. Slow down foundational linchpins for broader feedback, debate, and leadership alignment before design and implementation harden them. The method protects speed where experimentation is safe while spending attention on choices whose downstream cost grows with adoption and system complexity.
Origin
Skarstad connected one-way versus two-way door decisions with second-order thinking. She used Airbnb's Experience standards and Etsy's definition of handmade as one-way doors, then recommended tracing system cascades and writing first principles into product documents before teams build.
Core principles
- 01Reversible decisions should move quickly and stay close to the team
- 02Hard-to-reverse decisions deserve broader discussion and deliberate review
- 03Today's product choice changes the options and costs available tomorrow
- 04System complexity magnifies downstream effects
- 05Early agreement on first principles prevents expensive late disagreement
How to run it
- 1
Classify reversibility
Ask how easily the team can undo the choice after users, content, policy, and infrastructure depend on it. Label cheap experiments as two-way doors and choices that constrain many future actions as one-way doors.
Pro tip Consider the cost after scale, not only the effort required to change the code today.
Watch out A small interface or data-field change can become irreversible once every participant relies on it.
- 2
Trace the cascade
Map the immediate effect, the behavior it encourages, and the later product, design, technical, policy, or operational changes that behavior creates. Follow the chain through at least two downstream levels.
Pro tip Use a team brainstorm for complex ecosystems and ask where the proposed change becomes a linchpin.
Watch out First-order benefits can hide expensive consequences that only appear after adoption.
- 3
Write first principles
State what matters, why it matters, what the solution must preserve, and what is less important. Align on these foundations before entering detailed design or technical implementation.
Pro tip Add a permanent second-order-effects field to product strategy and requirements templates.
Watch out Late disagreement about the problem is much more expensive than early disagreement about principles.
- 4
Route the decision
Delegate two-way doors so teams retain autonomy and speed. Give one-way doors more time, cross-functional feedback, leadership discussion, and explicit approval proportional to their downstream reach.
Pro tip Explain the classification so the review process feels proportional rather than bureaucratic.
Watch out Treating every choice as a one-way door prevents teams from learning quickly.
- 5
Recheck the long horizon
Compare the selected decision with the product vision and strategy. Confirm that the options it creates or removes are acceptable for the direction the organization intends to pursue.
Pro tip Use the long-term plan to distinguish deliberate constraints from accidental ones.
In the wild
Airbnb spent months articulating the standards an Experience needed to meet. The definition would shape the product, policies, and host education everywhere, making it difficult to revise after scale. Skarstad therefore treated it as a true one-way door rather than a quick local decision.
→ The foundational standard received review effort proportional to the many systems that would depend on it.
A seemingly simple change such as shortening home-listing titles affects existing host content, display design, and every surface that uses the field. Mapping those effects before implementation reveals whether the change creates host frustration or broader redesign work.
→ The team sees system-wide costs before committing to a locally convenient change.
Common mistakes
Judging by code size
A technically small change can be a one-way door when it alters policy, stored content, or behavior across a large ecosystem.
Reviewing every decision equally
Excess review on reversible choices removes team autonomy and slows learning without reducing meaningful risk.
Scaling before tracing effects
Founders focused on product-market fit can discover too late that early choices cannot support rapid growth without a rebuild.
Is it for you?
Best for
Product teams making policy, data-model, architecture, or marketplace choices that may propagate through a complex ecosystem.
Not ideal for
Trivial choices with negligible downstream impact or urgent incidents where immediate containment must precede a full review.
From the episode
Nickey Skarstad (Airbnb, Etsy, Shopify, Duolingo) on translating vision into goals, operationalizing product quality, second-order decisions, brainstorming, influence, and much more