Two-Way Door Decisions: 5 Questions Founders Use to Move Faster
A founder's guide to two-way door decisions: five quick reversibility questions, rollback tactics, and a decision journal to log bets.

On this page
- What separates a two-way door from a one-way door
- Bezos’s Type 1 and Type 2 framework and the 70% rule
- A checklist to test whether a decision is reversible
- When it pays to wait before deciding
- How to build reversibility into a two-way door decision
- Who decides, how confidence gets recorded, and how reviews work
- Following one bet from hypothesis to post-mortem
- Where teams go wrong even when they know the framework
- Three habits worth changing this week
- How a decision journal turns this playbook into a habit
- Sources
- FAQ
A two-way door decision is one you can walk back through if it goes wrong, and the right move is to make those decisions fast, with a lightweight process and a clear rollback path, rather than treating them like permanent commitments. One-way door decisions, the ones you can’t undo, deserve the opposite: more deliberation, wider input, slower movement. The clearest guide for telling the two apart comes from Amazon’s own shareholder letter, which introduced the idea that most reversible calls should be made with partial information rather than waiting for near certainty.
TL;DR:
- Most reversible decisions, such as pricing adjustments or feature toggles, can be made quickly with limited input and a clear rollback plan.
- Misclassifying reversible decisions as irreversible leads to slow processes and stifles experimentation, while treating irreversible decisions as reversible risks unforeseen costs.
- Using a simple checklist—considering rollback feasibility, artifacts, affected parties, and migration effort—guides appropriate process and escalation for each decision.
- Building infrastructure like feature flags, staged rollouts, and automated rollback scripts enables fast correction of reversible choices and minimizes risk.
- Recording hypotheses, confidence levels, and decision outcomes in a decision journal improves calibration, learning, and decision quality over time.
What separates a two-way door from a one-way door
Reversibility isn’t a binary switch. It’s a spectrum that runs from “undo it in an afternoon” to “there is no path back,” and where a decision sits on that line should determine how much process it gets. A pricing test you can revert with a config change sits near the reversible end. A decision to shut down a product line, sign a multi-year lease, or lay off half your team sits near the other.
The practical failure mode is misclassification, usually in one direction: treating a reversible decision as if it were permanent. That habit shows up constantly as organizations grow, with leaders defaulting to heavyweight review on choices that were never that risky in the first place, which produces slow decisions and stalled experiments without actually reducing risk.
Examples help make the line concrete:
- Product: shipping a new onboarding flow behind a feature flag is reversible; removing a core API that partners depend on often isn’t.
- Hiring: a 90-day contract trial is reversible; a senior full-time hire with a long notice period and team dependencies is much closer to one-way.
- Pricing: adjusting a monthly subscription price for new signups is reversible; retroactively changing terms for existing enterprise contracts is not.
- Infrastructure: switching a feature’s database table is often reversible with a migration script; switching your core cloud provider is a multi-year commitment.
- Partnerships: a pilot integration with an opt-out clause is reversible; an exclusive multi-year distribution deal usually isn’t.
Getting this classification wrong in either direction costs you: too cautious on reversible calls and you lose speed and morale, too casual on irreversible ones and you absorb risk you never priced in.
Bezos’s Type 1 and Type 2 framework and the 70% rule
Amazon’s shareholder letter split decisions into two categories: Type 1 decisions are the one-way doors, consequential and hard or impossible to reverse, and they deserve careful, deliberate process. Type 2 decisions are the two-way doors, and the letter argues most decisions fall into this bucket even though large organizations tend to apply Type 1 rigor to everything.
Waiting for 90% of the information you’d like before acting on a reversible decision is usually too slow, and the letter frames that as costly.
If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.
That single idea, from the Amazon feature, reframes the goal for reversible decisions: optimize for speed of correction, not certainty before the first move. Two operational habits follow directly:
- Push Type 2 decisions down to the people closest to the facts, since they can move fastest and correct fastest.
- Pair delegation with “disagree and commit”: once a reversible call is made, the team commits and watches for the rollback trigger rather than relitigating the choice.
Escalation still matters. When a decision starts to look Type 1, when the rollback cost turns out to be higher than expected, that’s the signal to slow down and bring in more people.
A checklist to test whether a decision is reversible
Before you can apply the right process, you need a repeatable way to test reversibility rather than guessing. Five questions do most of the work:
- Can you actually revert it? Some decisions look reversible on paper but leave artifacts, contracts signed, data migrated, customers onboarded, that make reversal impractical.
- What does rollback cost in money, time, and trust? A rollback that takes an engineer twenty minutes is different from one that requires a week of cleanup and an apology email to every customer.
- Does it create irreversible artifacts? Deleted data, published content, signed agreements, and shipped hardware all convert an apparently reversible decision into a one-way door.
- Who else is affected, and does it touch regulation? Customer-facing changes and anything with compliance exposure need a wider process regardless of technical reversibility.
- How much migration effort is baked in? If undoing the decision means another migration on top of the original one, the true cost is double what it looks like.
Map the answers to a process choice rather than treating the checklist as a pass or fail. A decision that’s cheap to revert, contained, and low in regulatory exposure gets delegated with a rollback owner named in advance. One with moderate cost or partial reversibility gets a small pilot with a defined exit. Anything with high rollback cost, irreversible artifacts, or regulatory exposure gets escalated to a broader review before it ships.
Pro Tip: Write the rollback plan before you ship, not after something breaks. If you can’t describe the rollback in two sentences, the decision probably isn’t as reversible as you think.
When it pays to wait before deciding
Speed is the default for two-way doors, but waiting has real value under specific conditions, and the mistake is treating “let’s gather more data” as automatically wise. Real-options thinking gives a sharper test: additional time is only valuable if it will produce information that actually changes the decision, and if the opportunity to act is still available when that information arrives. According to research on the flexibility to postpone investment decisions, waiting without a plan to resolve uncertainty is not caution, it’s just delay dressed up as diligence.
Before choosing to wait, write down three things:
- What you expect to learn from the additional time, stated specifically enough that you’d recognize the answer when it arrives.
- The deadline by which that information needs to show up, tied to when the opportunity closes or the cost of waiting rises.
- The threshold that would flip your decision, so “more data” has a defined stopping point instead of becoming a permanent excuse.
Laboratory work on sequential investment decisions backs this up from the other direction: in experiments on real options in staged decisions, people routinely deviate from the normative policy of investing only once specific thresholds are met, often committing too early or sitting on the sidelines too long without ever pricing the option value of waiting.
The combination matters more than either piece alone. Reversibility plus staged learning, moving in small steps and updating as each step reveals new information, tends to beat locking in a decision up front and hoping the initial analysis holds.
How to build reversibility into a two-way door decision
Reversibility isn’t just a mindset, it’s infrastructure you build ahead of time so that undoing a decision is fast and cheap when the moment comes. A handful of tactics cover most situations:
- Feature flags let you ship a change to a subset of users and turn it off instantly if something goes wrong.
- Staged rollouts expose a new pricing tier, onboarding flow, or feature to 5% of traffic before committing to 100%.
- Data partitioning keeps new-cohort data separate from legacy data so a rollback doesn’t require untangling mixed records.
- Opt-ins let cautious customers avoid a change entirely while you validate it with the willing.
- Migration and rollback scripts written and tested before launch, not improvised during an incident.
Behind the tactics sit organizational choices that determine whether they actually get used. Name a rollback owner for every meaningful launch, someone whose job it is to watch the metrics and pull the trigger, not just someone who could technically do it if asked. Invest in the automation and observability that make rollback fast rather than a multi-hour scramble, and write the rollback trigger down in advance: the specific metric movement or customer signal that means “revert now,” decided before anyone is emotionally invested in the launch succeeding.
Pro Tip: Set your rollback trigger as a number before launch, like “error rate above 2% for 15 minutes” or “churn spikes 10% in a cohort.” A trigger you invent after the fact always gets argued with.
None of this is free, and reversibility infrastructure isn’t always worth building. A one-time internal tool used by three people doesn’t need staged rollout tooling. The investment pays off when the decision touches customers directly, when it’s one of many similar decisions you’ll make repeatedly, or when the cost of a bad outcome sitting live for even a day is high.

Who decides, how confidence gets recorded, and how reviews work
Speed on two-way doors only stays safe when the rules around it are explicit. Three pieces make that possible: a delegation matrix, a way of stating confidence, and a review ritual that closes the loop.
- Set delegation by confidence and reversibility together. A decision with high reversibility and any reasonable confidence level can usually be delegated to the person closest to the work. Low reversibility or low confidence, meanwhile, is the trigger to escalate regardless of how good the case sounds.
- State confidence as a probability, not a feeling. “I’m fairly confident” tells you nothing you can act on later. “I’d put this at 70%” gives you something to check against the outcome and, over many decisions, to calibrate.
- Tie every decision to a small number of leading metrics that will tell you within days or weeks, not quarters, whether the bet is working.
- Run the post-mortem against what you wrote down before the outcome was known. Compare the pre-registered metrics and stated confidence to what actually happened, and separate whether the decision was sound from whether it simply got lucky or unlucky.
A team that consistently states 70% confidence and wins those bets about 70% of the time is well calibrated, a pattern the Amazon shareholder letter’s framing of decision velocity implicitly assumes when it recommends acting on partial information rather than waiting for certainty. Calibration is the payoff of doing steps one through four consistently rather than skipping the paperwork when a decision feels obvious.
Following one bet from hypothesis to post-mortem
A pricing experiment makes the process concrete.
- Write the pre-decision record: the hypothesis (higher price increases revenue per customer), a stated confidence of 65% that signups hold within the 10% band, the trade-off accepted (some price-sensitive signups will be lost), and the two metrics that will decide it: signup rate and 30-day revenue per new customer.
- Roll out in stages: launch the new price for new signups only, behind a flag, leaving existing customers untouched, which keeps the decision reversible with a single config change.
- Set the rollback trigger in advance: if signups drop more than 15% week over week for two consecutive weeks, revert to $29 automatically rather than debating it live.
- Watch the metrics for the pre-agreed window, in this case four weeks, long enough to smooth out noise but short enough to act before the cost of a wrong call compounds.
- Run the post-mortem against the original write-up: if signups dropped 8% and revenue per customer rose, the bet was correct and the team notes it as a win. If signups collapsed 20%, the team fields the outcome honestly: was the hypothesis wrong, or was the confidence level too high given the evidence available at the time?
That last step, outcome fielding, is what turns a single price test into a lesson the team can actually reuse instead of a war story about the one time it worked or the one time it didn’t.
Where teams go wrong even when they know the framework
The most common trap is resulting, judging a decision by how it turned out rather than by the quality of reasoning at the time it was made. Hindsight bias makes it worse: once you know the outcome, it feels like it was obvious all along, which quietly erases the honest uncertainty that existed at decision time.
The opposite failure is overprocessing. Teams that don’t trust themselves to move fast on reversible decisions end up running one-way-door process on everything, which slows learning without reducing real risk, since the risk on a two-way door was already low.
A few safeguards catch both problems:
- Premortems force the team to imagine the decision has already failed and explain why, surfacing risks before launch rather than after.
- Decision journals capture the hypothesis and confidence level before the outcome is known, which is the only way to judge decision quality honestly later.
- Explicit rollback limits, agreed in advance, stop “let’s give it more time” from becoming an unbounded excuse to avoid admitting a bet didn’t work.
Three habits worth changing this week
Start classifying every decision out loud before debating it: two-way door or one-way door, in one sentence, before anyone argues the merits. It sounds trivial, but naming the type first changes the whole conversation that follows.
Next, delegate anything reversible to whoever is closest to the facts, and mean it. That means resisting the urge to weigh in on a decision you delegated just because you have an opinion.
Finally, write the hypothesis and confidence level down before you know the outcome. This is the single habit that pays back the most over a year, because it’s the only way to tell later whether you’re actually good at this or just good at remembering the wins.
— Cesar
How a decision journal turns this playbook into a habit
Betlog is a decision journal built for founders and small teams who want to run the practices above without relying on memory or Slack threads that get lost. It gives structure to the parts of this playbook that are easy to skip under pressure.

Specifically, it supports:
- Pre-decision capture, so the hypothesis, confidence level, and trade-offs get written down before the outcome is known, not reconstructed afterward.
- Confidence as an explicit probability, tracked over time so a team can see whether its 70% bets actually win about 70% of the time.
- Structured post-mortems that separate decision quality from luck instead of defaulting to resulting.
- A permanent, timestamped record of every bet, from Idea through Decided, that the team can’t quietly rewrite in hindsight.
Teams that already run staged rollouts and rollback triggers often have the technical discipline down. What tends to be missing is the paper trail on the reasoning side, and that’s the gap Betlog is built to close. The one plan runs $390 a year or $39 a month, and you can see the full workflow at Betlog.
Sources
- Jeff Bezos shareholder letter / Amazon feature
- To Wait or Not to Wait? Use of the Flexibility to Postpone Investment Decisions in Theory and in Practice
FAQ
What is a two-way door decision?
A two-way door decision is one you can reverse if it turns out to be wrong, unlike a one-way door decision, which is difficult or impossible to undo. Amazon’s shareholder letter popularized the term, arguing most business decisions are actually two-way doors and should be made quickly rather than with heavy process.
What is Jeff Bezos’s 70% rule?
The reasoning, laid out in Amazon’s shareholder letter, is that being slow costs more than being wrong when you can course correct quickly.
What are the key differences between one-way and two-way door decisions?
One-way door decisions are hard or impossible to reverse and warrant careful, deliberate process with broader input. Two-way door decisions can be undone at reasonable cost, so they should move fast, get delegated to people close to the facts, and rely on rollback safeguards instead of upfront certainty.
What are two types of decisions?
The most common framework splits decisions into reversible (two-way door) and irreversible (one-way door) categories, based on how costly and difficult it would be to undo the choice. This distinction, introduced in Amazon’s shareholder letter, determines how much process, deliberation, and delegation a decision should get.


