Deciding Under Uncertainty
The evidence is not in and the decision cannot wait. The move is not to guess harder: take the current evidence, make the best choice that is cheap to reverse, build the feedback that would tell you it was wrong, and adjust — a loop, not a bet.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
You have to decide now and you do not know enough — how do you decide in a way that gets better instead of just hoping?
Guest checkout or accounts-only? The founder is not sure; there are no customers yet to ask; the cart design depends on the answer; and the checkout slice is due. You could research consumer behaviour for a week and still be guessing, or pick one and hope.
Either pick one and commit — build it properly, so at least the work is not wasted — or refuse to decide until someone gives you certainty. Both feel responsible: one respects the deadline, the other respects the unknown.
Committing properly to a guess means the guess is now load-bearing: an accounts-only cart with account-scoped everything, and when guests turn out to matter the cart design has to change under a running store.
- Committing properly to a guess means the guess is now load-bearing: an accounts-only cart with account-scoped everything, and when guests turn out to matter the cart design has to change under a running store.
- Waiting for certainty produces none, because the evidence — what real customers do at checkout — cannot exist until there is a checkout. The decision blocks the thing that would decide it.
- A week of research into what other stores do returns both answers, and the guess is now dressed as a finding.
- The decision is made and no one watches it. Six weeks on, nobody can say whether the guess was right, because nothing was built to tell them.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Separate the decision from the certainty. Write down what the evidence currently says — including "nothing" — and what evidence would settle it. If the settling evidence can only come from the thing you are deciding about, the decision cannot wait for it, and the goal changes: not to be right, but to be cheap to be wrong.
- Choose the option that is best on current evidence *and* cheapest to reverse, and let the second criterion override the first when they disagree. A slightly worse option that can be undone in a day beats a slightly better one that cannot (Reversible vs Irreversible Decisions).
- Build the feedback as part of the decision, not after it. Name the observation that would show the choice was wrong — a count, a conversion, a support ticket — and make the first slice produce it. A decision without a feedback channel is a bet; with one, it is an experiment with a stake (A Prototype Answers a Question).
- Schedule the revisit. Pick the moment — a date, a number of orders, a customer count — at which you will look at the feedback and re-decide, and write it down where you will see it. Then adjust: keep, reverse, or replace, on evidence you now have.
The loop
The move as a pipeline. Each step has a way of failing that looks like success; the last step is the one that separates an experiment from a bet, and it is the one most often left out.
- 1Current evidence
Written in three lines: known, assumed, what would settle it — including "nothing is known"
fails by Research that returns both answers and is filed as evidence
- 2Best reversible choice
The option that is good on current evidence and cheapest to undo; the second criterion wins close calls
fails by Committing to the best option regardless of what it costs to reverse
- 3Feedback built in
The first slice produces the observation that would show the choice was wrong
fails by Instrumentation deferred to "after launch", which is after the evidence would have mattered
- 4Revisit trigger
A date or a number, with an owner, in the journal
fails by A vague "we will revisit" that no one is responsible for
- 5Adjust
Keep, reverse or replace, on the evidence the loop produced
fails by The trigger fires and nobody looks; the provisional decision is permanent by silence
The unknowns the decision was made on
The guest-checkout board at the moment of decision. The point of writing it is the first unknown: its experiment is the store itself, which is why the decision cannot wait for it — and why the feedback channel is the experiment, built into the slice.
- ✓The founder leans guest; no customers exist to ask.
- ✓Adding accounts to a session cart is an addition; adding guests to an account cart is a re-scope.
- ✓Checkout is due, and the cart design depends on this.
- ~A sign-up form before payment loses some customers — plausible, unmeasured, and the whole reason for leaning guest.
- ~Customers who want order history will accept creating an account after paying.
? What do customers want?
becomes What fraction of sessions that reach checkout stop at a sign-up form, on this store, with these customers?
experiment Cannot be run before checkout exists — so the checkout slice records guest/account per order and where sessions stop, and the question is answered by the store after a set number of orders.
? Will guests come back?
becomes Do guest customers ever create an account afterwards, and do they need one to see their order?
experiment The order confirmation carries a link to view the order without an account and an optional account offer; count who takes it.
? Is the session cart a problem?
becomes How often does a guest cart get lost — cleared storage, device change — before checkout?
experiment Store the session cart server-side keyed by session; count carts abandoned with items versus carts that reach checkout.
Every unknown here has an experiment, and two of the three can only be run by the decision itself. That is what "deciding under uncertainty" means: the decision is the apparatus.
The slice that carries the feedback
The checkout slice, built to produce the observation the decision needs. It is a normal vertical slice with one addition — the guest/account flag and the funnel event — and the device is honest about what a passing slice does not prove: that the decision was right. It proves that the feedback exists.
- FrontendCheckout without a sign-up form; an optional "create an account" after the confirmation.
- APIAccepts an order for a session cart with an email and no account; returns an order id and a view link.
- LogicCreates the order, marks it guest or account, emits a funnel event for the step reached.
- DatabaseOrder row with a guest flag and a nullable account id; a funnel table keyed by session.
How to do it
Most important first.
- Write the current evidence in three lines: what is known, what is assumed, what would settle it (Making Assumptions Explicit).
- List the options and, for each, one line on how it would be reversed. Prefer the one that is best-and-cheap-to-reverse over the one that is best.
- Name the feedback observation before building. If the slice cannot produce it, change the slice until it can (A Slice Is Testable).
- Record the decision, the evidence at the time, the feedback you will watch, and the revisit trigger in the journal (The Decision Journal).
- When the trigger fires, decide again with the new evidence. Do not let a provisional decision become permanent by silence.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Guest checkout. Evidence: none from customers; the founder leans guest; the cart design depends on it. What would settle it: real customers abandoning at a sign-up form, or not. That evidence needs a checkout to exist. Options: accounts-only (simpler cart, one identity) or guest (session cart, an optional account afterwards). Reversal: adding guest checkout to an accounts-only store means re-scoping the cart — a migration; adding accounts to a guest store means attaching an optional account to an existing session cart — an addition. Guest is cheaper to reverse, and the founder leans that way: decided, provisionally.
- Feedback built in: the checkout slice records, per order, whether it was a guest or an account, and the funnel records where sessions stop. Revisit trigger: a set number of orders, written in the journal with the date it was decided. When the trigger fires the question is no longer "what do customers want?" but "what did they do?", which has an answer.
- The other case: the payment provider. Evidence: two candidates, both plausible, no experience with either. Reversal: expensive (payments code, webhooks, reconciliation all bind to one). Under uncertainty the move is to make the decision smaller before making it: a seam (one module that talks to the provider), a spike with each in test mode against the same slice, and a decision made on what the spikes showed — sequence of calls, webhook behaviour, sandbox quality — rather than on marketing pages (The Smallest Experiment With a New Technology).
How you know it worked
What now exists that did not before, and what question you can now ask.
- The decision is written with the evidence it was made on, including "none", and nobody is pretending otherwise.
- The option chosen is the one that is cheapest to reverse among the plausible ones, and you can say what reversing it would take.
- The first slice produces the observation that would show the decision was wrong.
- A revisit trigger exists, with a date or a number, and someone owns looking at it.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What does the evidence say now — and what evidence would settle it, and can it exist before I decide?
- ?Which plausible option is cheapest to reverse, and would I still choose it if it were slightly worse?
- ?What observation would show this decision was wrong, and does my first slice produce it?
- ?When will I look, and who owns looking?
What can go wrong
- The loop without the adjust. Feedback is built, the trigger fires, nobody looks, and the provisional decision is permanent by neglect. The journal entry has to have an owner and a date.
- Reversibility over everything. The cheapest-to-reverse option is chosen even when it is clearly worse on current evidence and the reversal would never actually happen; the second criterion overrides the first only when they are close.
- Feedback that cannot distinguish. The observation chosen — "conversion" — would move for a dozen reasons, and when it moves nobody knows whether the guest decision was the cause. The feedback has to be specific to the decision (Experiment Design).
- Uncertainty as an excuse for not deciding at all. "We do not know" is the starting condition of every decision worth the name; the move exists precisely for that case.
- A decision made cheap-to-reverse is often not the best decision on current evidence; the loop trades some expected quality for the ability to correct.
- Feedback channels are code and instrumentation that have to be built and read; a store with a revisit trigger on every decision has a lot of triggers and someone reading them.
- A provisional decision signals provisionality to the team, and some people build less carefully on something that "might change" — the reverse of the intended effect.
- "Just pick one and iterate." Only if the pick is reversible and the iteration has a feedback channel; "pick one" on an irreversible decision with no feedback is a guess with a slogan attached.
- "Deciding under uncertainty means deciding faster." It means deciding *smaller* — a seam, a spike, a provisional choice with a trigger — which is sometimes slower to the first line of code and faster to the right one.
- "Once the feedback says we were right, the decision is closed." It is closed until the next requirement change; the journal entry stays, with its assumptions, so that the next person can see what it rested on (When Assumptions Change).
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALEvidence, reversible choice, feedback, revisit applies to any decision made before the facts are in — architecture, product, process; the feedback observation is what changes.
- CONTESTEDThe strongest opposing view: some decisions are better made with conviction than provisionally, because a team that knows a choice is "for now" under-invests in it, and a half-built accounts system is worse than either a full one or none. Advocates of committing argue that the cost of provisionality is paid in quality every day, while the cost of a wrong commitment is paid once. The synthesis most teams reach: be provisional about the decision and not about the build — build the guest checkout properly, and keep the feedback and trigger anyway.
- ILLUSTRATIVEThe guest-checkout decision, the two providers and the six-week silence are invented; the revisit trigger in a real store would be set from the expected order volume, which is why it is left as "a set number of orders" here.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "Debug without AI" route at /manifesto/without-ai uses the same shape — hypothesis, experiment, evidence, adjust — for a bug rather than a decision.