Not Every Product Decision Is Forever: Rank Choices by Reversibility

In my first few years as a product manager, I oscillated between two opposite mistakes. Sometimes I spent days on a small change: a button position, a default copy, a notification audience. The honest answer was that the data would be clearer next week, but I acted as if shipping without a full comparison would be irresponsible. Other times I moved too fast on decisions that were actually big: swapping the core engine, rebuilding the data layer, changing the billing model. For those, I rarely asked the question that mattered most: if we are wrong, what does it cost to go back?

The lesson came slowly: the amount of thinking a request deserves depends less on how important it looks and more on how reversible it is. Yet most requirement discussions start with how many users are affected, not what reversing this would cost.

Should we build this is a prioritization question. Can we afford to undo it is a decision-style question. The first decides what to do. The second decides how much time and preparation the decision should get.

One-way doors and two-way doors

The best-known framework for reversibility comes from Amazon: one-way doors and two-way doors. If you walk through a two-way door and do not like what you see, you can walk back. If a decision is one-way, you need to be careful.

The idea is good, but the binary classification is not enough for daily product work. It works when the person making the call does not touch the details. A PM faces dozens of judgments a day, and most of them sit somewhere in the middle: partially reversible. The real question is not which door this is but what I actually sacrifice if I reverse it.

I now use three operational questions:

1. What data or state has to be rolled back?
2. Which users will notice immediately, especially as a broken promise?
3. How long will the team need to get back to the current state?

If all three answers are light, the decision does not deserve much agonizing. If any one involves established user habits or more than a week of migration, treat it with a more careful design, not a direct cutover.

Three levels of reversibility

In practice, everyday product decisions fall into three levels.

First level: direct reversal. A minor UI change, a copy tweak, a push notification timing. Users may notice, but no long-term impression is formed. The cost of reverting is one branch and one regression test. This level does not need multiple review meetings. The downside of deciding fast is very low.

Second level: planned reversal. Data structure changes, API field changes, campaign pacing. You need a migration script and a plan for old data. Users may perceive the difference, but it does not become a strong memory. Reversing takes half a day or a few days. It needs planning, but not anxiety.

Third level: costly to repair. Publicly promised experiences, pricing model changes, brand trust, and workflows that users have long depended on. The defining trait is that once the change enters the user's memory, you cannot simply roll it back. Users may not churn immediately, but they will spend a long time treating you as a product that changed once and may change again.

Many decision failures are not failures of direction. They happen when level-three decisions are handled with level-one discipline. A few engineers agree and the switch is made, and by the time the team notices, there is no easy way back. The opposite failure is also real: if every decision is treated as level three because of fear, the team stops moving.

Making irreversible decisions reversible

My biggest lesson is this: instead of trying to be more accurate in judgment, find a way to turn the irreversible into the reversible.

An architecture rewrite is a classic case. If it is handled as a one-time surgery, stopping the old path and flipping the switch, you discover problems every day during migration and reversing becomes very hard. The better version keeps the old and new paths running in parallel, with behavior differences switchable at runtime. The rewrite becomes a sequence of small, reversible steps.

AI products have the same pattern. Swapping a model looks like changing one API address, but in reality a new model shifts a whole distribution of user-visible behaviors. A safer approach is shadow mode: the new model processes real requests in the background, you compare the output differences, and only then decide. Keep the old model as a fallback. If shadow mode is too expensive, expose the new model to a small share of new users for a few days and then expand. The decision about which model to use goes from irreversible to reversible.

Pricing deserves special caution. The real cost of changing a price is not the billing system adjustments. It is the trust that is spent each time. If you only have a limited number of changes, validate acceptance and churn in a small group first. Announcing a new price publicly and then reversing is one of the most painful reversals of all.

Building escape hatches for irreversible decisions is part of the PM job, not just an engineering concern. It might mean keeping an old entry point, piloting on a small group, or keeping a snapshot of the old data structure. These preparations do not make the decision safe. They make regret affordable.

When reversibility lies

There are a few cases where reversibility thinking can mislead you.

First, reversible does not mean careless. If every release is ship first, fix later, the team can adapt to fast iteration, but users do not adapt to a permanent half-finished product. Every quick experiment needs a clear question to answer. Otherwise you are spending their patience, not your time.

Second, a technical rollback is not a user rollback. The code repository can return to yesterday's commit easily. Users do not come with a version control system. They saw the new screen, clicked the new button, experienced the new flow. That memory cannot be wiped. When you evaluate reversibility, look at the user's memory, not only your infrastructure.

Third, reversibility analysis can become a form of procrastination. For a while I nearly built a reversibility form for every request, until I realized it was a professional-looking way to avoid the few decisions that actually required deep thought. If something is clearly level one, writing down a one-line decision today is more valuable than comparing options forever.

A framework that makes decisions lighter

My current rule for new requests is simple: spend no more than thirty minutes on the judgment, then return to execution. In a short requirement note, write three lines.

Line one: do it or not. One line, no lengthy analysis. This is for you one month from now. A decision without a record cannot be reviewed; it will only resurface later as an argument without context.

Line two: reversibility level. Judge it with the three questions above. It takes about three minutes.

Line three: reverse plan. Level one does not need one. Levels two and three require a short note: if we are wrong, who is affected, what is the minimal recovery, and where can we reserve an escape hatch in advance.

The point of this rule is not to make decisions reckless. It is to make sure the truly important decisions receive enough time and attention. If a team spends most of its energy on things that can be easily reversed, the few level-three decisions will not get the preparation they need. That hidden cost is the most expensive one.

I still cannot guarantee that I will pick the right option every time. But I have learned how to tell which decisions should not weigh that much. If it is reversible, decide and move. If it is not, break it into pieces and build exits. Keeping the team moving through uncertainty is one of the most valuable product habits I know.

PaxLee