Reversible vs Irreversible Decisions
Decide fast on what can be undone, and slowly, in writing, with the right people, on what cannot. Most of the skill is noticing which is which — and turning the second kind into the first.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
Before you spend a week deciding, or five minutes, do you know whether this decision can be undone?
In one week, the checkout team is asked to: change the "Place order" button copy, move the promo-code field below the total, change the order-number format from 6 digits to a prefixed alphanumeric code, and email every customer about the new returns policy.
Treat them all the same way: a ticket each, a quick refinement, ship them in the sprint. They are all small changes; none needs more than a day of work.
The button copy and the promo field are fine — behind a flag, measured, revertable in minutes.
- The button copy and the promo field are fine — behind a flag, measured, revertable in minutes.
- The order-number change ships. Support's macros, finance's reconciliation spreadsheet and the warehouse's label printer all parsed six digits. Customers already have emails with the new numbers; rolling back means two formats in the wild forever.
- The returns email goes to every customer on Tuesday. On Wednesday legal notices the policy text contradicts the terms of service. There is no "unsend".
- Meanwhile the team had spent two meetings debating the button copy, which could have been tested and reverted in a day. The effort went to the reversible decision and the irreversible ones went through on autopilot.
What is really going on
- Decisions differ less in size than in the cost of being wrong and undoing it. A one-line change to an order-number format and a one-line change to button copy are the same size in the diff and nothing alike in reversibility.
- Reversible decisions should be made fast, by the people closest to the work, because the cheapest way to find out is to try. Deliberating over them costs more than a wrong answer would.
- Irreversible decisions — or ones that are very expensive to reverse — deserve the slow path: written down, with the options, the rejected ones, and the people who pay the cost in the room (The One-Pager, Decision Records).
- Irreversibility often lives outside the code. The code for an order-number format can be reverted; the emails customers received, the numbers support wrote in tickets and the labels printed cannot. Sent messages, published prices, public URLs, deleted data and promises to customers are the usual one-way doors.
- The best move is often to make an irreversible decision reversible: ship behind a flag, keep the old column, send the email to a small segment first, accept both formats for a while (Feature Flags as Product Tools).
The diff size lies
Four changes, each about a day of work. The team spent its deliberation on the button copy, because copy is visible and everyone has an opinion, and waved the order-number format through because it was "just a formatting change". The effort went exactly where it was least needed.
The question that sorts them is not "how big is this?" but "if this is wrong, what does undoing it cost and who pays?" For the button: a flag flip. For the order number: every customer email, support macro and warehouse label with the new format stays out there forever.
| Change | If it is wrong | Classification | Path |
|---|---|---|---|
| "Place order" button copy | Flip a flag back | Reversible | Decide in chat, ship behind a flag, watch completion |
| Promo field below the total | Flip a flag back; watch promo usage | Reversible | Ship to a share of traffic, compare |
| New order-number format | Two formats in customer emails, support and warehouse forever | Irreversible once sent | One-pager with support, finance, warehouse; accept both formats first |
| Returns-policy email to all customers | Cannot unsend; policy text may bind us | Irreversible | Legal review; send to a small segment first |
Two paths
The point of classifying is to give each decision the process it deserves: very little for the reversible ones, deliberately more for the irreversible ones, and an honest attempt to move decisions from the second path to the first.
Explaining the speed, in both directions
The hardest part is not classifying; it is explaining to people why you are moving at a different speed than they expect. Someone always wants to debate the reversible decision longer, and someone always wants to rush the irreversible one.
The PM wants the new order-number format shipped this sprint because a partner integration expects it. The ticket is estimated at half a day.
"I think we should be careful with this one, it might have side effects. Can we push it to next sprint?"
"The code is half a day, but the numbers go into customer emails, support's macros, finance's reconciliation and the warehouse labels, and once customers have them we cannot take them back. I would like to do it in two steps: this sprint, accept both formats everywhere and switch the partner integration over; next sprint, switch new orders once support, finance and the warehouse confirm they are ready. The partner gets what they need on time, and if something breaks we are still on the old format for customers."
Turning one-way doors into two-way ones
Most irreversible decisions can be made less irreversible with a little engineering: the cost is extra work now, the payoff is that you get to learn before committing. This is often the best contribution an engineer makes to a product decision.
- Accept both before switching. Parse old and new order numbers for a period; switch generation only when every consumer is ready (Sequencing Work So Value Lands Early).
- Send to a segment first. The returns email goes to a small share of customers; support watches replies for a day before the rest.
- Expand, then contract. Add the new column, write both, read the new one, and only then drop the old one — so the destructive step comes last and can be delayed.
- Flag it. Anything behind a flag can be switched off in minutes; the flag's removal date is part of the decision (Feature Flags as Product Tools).
How to do it
Most important first.
- Before deciding, ask one question: "If this is wrong, what does undoing it cost, and who pays?" Answer it in the payer's terms, not the code's.
- For reversible decisions: decide in the meeting or without one, ship behind a flag, set the signal you will watch, and move on. Write one line of why in the PR.
- For irreversible ones: slow down on purpose. Write the options, name who pays if it is wrong, get them to agree, and record it after.
- Before accepting that something is irreversible, ask how to make it reversible: a staged rollout, a segment-first send, an expand-then-contract data change, a period of accepting both old and new formats.
- Keep the slow path for the few decisions that need it. If everything goes through it, the team learns to treat it as bureaucracy and routes around it.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- For a reversible call, to someone who wants more debate: "This one is cheap to undo — it is behind a flag and we will see the effect on checkout completion within a week. I would rather try it than discuss it for another meeting."
- For an irreversible one, to someone who wants speed: "This one I want to slow down. Once customers have emails with the new order numbers, we cannot take them back, and support, finance and the warehouse all parse the current format. Two days to check with them is cheap compared to living with two formats."
- When proposing to make it reversible: "We can accept both formats for a month, switch new orders over, and only drop the old one when nobody is using it. That turns a one-way door into a two-way one."
- When recording it: "We classified this as irreversible because customers keep the numbers. Decided with support and finance; record linked."
- "We are overthinking a format change." The code is small. The numbers end up in customer inboxes, support tickets and warehouse labels, and none of those roll back. Two days of checking is cheaper than two formats forever.
- "Why are we not discussing the button copy properly?" Because it is behind a flag and we will see the result within a week. If it is wrong, we turn it off; the discussion would cost more than the mistake.
What can go wrong
- Treating everything as irreversible: every button colour gets a document and a meeting, and the team ships slowly while feeling careful.
- Treating everything as reversible because "we can always roll back the deploy" — forgetting that emails, prices and data do not roll back with the code.
- Misclassifying because the change is small in code. The diff size says nothing about the cost of undoing it.
- Making a decision reversible in principle and then never actually using the reversal — the flag that is never turned off, the old format that is never retired — so the complexity stays forever (Tech Debt Is a Product Decision).
- "Reversible means low-stakes." A checkout experiment can cost real revenue while it runs; it is reversible, so the right move is to run it short and watch it, not to deliberate.
- "We can always roll back." The deploy rolls back; the emails, charges, printed labels and customer memory do not.
- "Irreversible decisions need consensus." They need the people who pay the cost to know and agree, and a named owner who decides. Consensus is a different, slower thing (Disagree and Commit).
Knowing whether it worked
- Meetings are spent on the decisions that cannot be undone; the reversible ones are decided in chat and tested.
- You can name, for the last month, which decisions went through the slow path and why — and the list is short.
- No post-launch surprises of the form "we cannot undo this" from support, finance or legal.
- Flags and compatibility shims get removed on a schedule, which shows the reversibility was used and then closed.
- At small scale, many "irreversible" things are cheap to fix by hand: email the twenty affected customers, fix the rows. At 10x users the same decision touches too many people to fix manually, and more decisions move into the irreversible column.
- At 10x team size, more people depend on each format, contract and field, so fewer changes are reversible without coordination. Making things reversible by design — versioning, flags, expand-contract — becomes the default instead of a special effort.
- At 10x revenue, the cost of a slow reversible decision also grows: a week of debating a checkout experiment is a week of not learning. The pressure goes both ways.
- Classifying takes a moment of thought per decision, and you will sometimes misclassify in both directions.
- Making decisions reversible costs engineering time: flags, dual formats, staged sends. That cost is worth it for the decisions that need it and waste for the ones that do not.
- Deciding reversible things fast means being visibly wrong more often. Some organisations punish that, which pushes everything onto the slow path.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALEvery team makes both kinds of decision. What differs is where the line sits: things you can fix by hand for twenty customers stop being fixable at twenty thousand.
- PRODUCT-SPECIFICIn regulated products, more is irreversible — a disclosure sent, a record deleted, a price shown can have legal weight. In an internal tool with ten users, almost everything is reversible with a message to them.
- SIMPLIFIEDTwo categories is a teaching model; reversibility is a spectrum of cost and time to undo. The two-bucket version is enough to decide how much process a decision gets, not to price the reversal precisely.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.