Leadership
Decision-making under uncertainty: expose assumptions
Make a work decision with incomplete evidence. Separate facts from assumptions, compare options and define a review trigger with a practical record.
The team needs a decision this week. The research is incomplete, two stakeholders disagree and the deadline is real. Waiting feels responsible, but waiting is also a choice with consequences.
Decision-making under uncertainty means acting with an honest account of what you know, what you assume and what could change your mind. It does not mean inventing a confidence score or replacing evidence with a forceful opinion.
For everyday product and team decisions, a short decision record can make that work visible. Decisions involving health, safety, legal rights or major financial exposure need the appropriate expertise and governance. A lightweight worksheet does not provide those safeguards by itself.
Define the decision before collecting more information
Write the decision as a choice that someone can make. “We need more clarity about onboarding” is a concern. “Should we release the revised onboarding to a limited group or keep the current version while investigating accessibility issues?” is a decision.
Name the owner, the latest useful decision date and the options. Include the current arrangement as an option where it remains feasible. Otherwise, discussion may assume that a new proposal must be adopted.
State the objective and the constraints separately. An objective could be reducing confusion during account activation. A constraint could be retaining an accessible route to complete the process. A faster experience that breaks the constraint is not a successful option.
The leadership guide explains why the owner and criteria need to be visible. More information cannot resolve a disagreement about who has authority to choose.
Sort evidence by what it actually supports
Use four categories: observed, inferred, assumed and unknown.
An observed fact might be that several people in a usability session could not locate a control. An inference might be that its label contributed to the difficulty. An assumption might be that changing the label will help the wider audience. An unknown might be how the alternative performs for people using assistive technology.
Keep the categories distinct. A credible observation can support a hypothesis without proving the proposed solution. Repeating an inference in a slide deck does not turn it into a fact.
Tversky and Kahneman’s original Judgment under Uncertainty: Heuristics and Biases examines ways people form judgements with limited information. It gives reasons to question intuitive certainty, not a method for diagnosing a colleague from one decision.
In online consumer psychology, the same discipline separates a visible action from an explanation of why it occurred. Apply that boundary to internal decisions as well.
Ask which missing fact could change the choice
Not every unknown deserves another week of research. Identify the uncertainty most likely to change the decision or expose a serious constraint.
For the onboarding example, knowing whether the proposed control works with the supported keyboard route could change the release decision. Learning which background colour a stakeholder prefers may not.
Ask three questions: if the answer were favourable, what would we do? If it were unfavourable, what would we do? Can we obtain a useful answer before the decision date?
If both answers lead to the same action, the research may still have other value, but it is not the deciding information for this choice. Explain that distinction rather than dismissing the question as irrelevant.
Agree a stopping point for the investigation. Without one, the team may keep collecting information because nobody wants to own the remaining uncertainty.
Compare options with consequences, not adjectives
“Bold”, “safe” and “innovative” conceal different interpretations. Compare what each option requires and what could happen.
Swipe or use the arrow keys to see every column.
| Option | What it requires | Useful information gained | Main exposure | Reversal route |
|---|---|---|---|---|
| Keep the current route | Continue existing support | More time to investigate | Current friction remains | Existing arrangement |
| Limited release | Defined audience and monitoring | How the change behaves in a bounded context | Some users encounter unresolved problems | Restore the current route |
| Full release | Readiness across intended use cases | Broad operational feedback | Wider exposure if assumptions fail | Tested rollback and support plan |
This is a hypothetical comparison, not an assessment of a real service. Do not label a release reversible until somebody has checked the actual rollback.
Consider who bears each consequence. A decision may look low-cost to the delivery team while creating substantial work for support or confusion for users. Invite those perspectives before declaring the exposure acceptable.
A hypothetical decision with a genuine limit
Imagine a fictional product team choosing whether to release a revised account-activation screen. The example is hypothetical; no performance results are being claimed.
The team has observed confusion in a small usability study and prepared a clearer label. It has not yet checked the new arrangement across all supported interaction methods. The product owner initially wants a full release before a campaign.
The decision record makes the missing accessibility check visible as a constraint. The team does that check first. If it finds a barrier that prevents completion, the release stops until the barrier is addressed.
If the check is satisfactory, the owner may choose a bounded release with a tested restoration route and support coverage. That release still does not prove the label improves conversion. It answers a narrower operational question: can the revised route function under the agreed conditions without identified blocking problems?
Where the objective is to estimate an effect, the CRO and A/B testing guide explains why an appropriately designed experiment is a different kind of evidence.
Test reversibility rather than naming it
A reversible decision needs a practical route back. Who can restore the previous state? How long does it take? Which commitments, data changes or external effects remain after restoration?
A feature flag may reverse a screen but not an email already sent. A trial assignment may be easy to change on a board but costly if it has displaced another project. Identify the parts that cannot be undone.
Set the scope accordingly. Reversibility is a property of the specific decision and implementation, not a comforting label for an entire initiative.
The delegation article helps allocate the authority and resources needed for that route. A rollback owner without access or support cannot provide a reliable safeguard.
Use a short failure rehearsal carefully
Before deciding, imagine that the chosen option caused a disappointing outcome. Ask each participant to write a plausible reason independently, then compare the answers.
This can reveal assumptions that were difficult to challenge in the group discussion. It can also generate vivid but unlikely stories. Treat the output as questions to investigate, not as a forecast.
Mitchell, Russo and Pennington studied imagined explanations of events in Back to the future: Temporal perspective in the explanation of events. Their research is a reference for prospective hindsight. It does not establish that your team’s failure rehearsal will predict outcomes accurately.
For each proposed failure, ask which observation would make it more plausible and which action would address it. Remove duplications and separate preventable problems from risks the owner must knowingly accept.
Give equal space to a dissenting concern and an optimistic assumption when each is relevant to the decision. Seniority should not determine which uncertainty appears in the record.
Write a decision record you can review
Use these fields. This is an original editorial worksheet, not a validated risk assessment.
- Decision: the exact choice and its owner.
- Purpose: the outcome you are trying to enable.
- Constraints: conditions that every acceptable option must meet.
- Evidence: dated observations and their limits.
- Assumptions: explanations or expectations not yet established.
- Options: consequences, dependencies and unresolved questions.
- Choice: the option selected and the reason it fits the criteria.
- Safeguards: scope, responsible owners and any restoration route.
- Review trigger: a date, event or observation that requires reconsideration.
- Communication: who needs the choice and what it changes for their work.
Keep unresolved questions in the record after the decision. Deleting them creates a false appearance of certainty and makes later learning harder.
Define a trigger that someone can notice
“Review if there are problems” is too vague. A trigger should identify the observation, the person monitoring it and the route to a decision.
For example: if support identifies an account-activation failure with no working alternative, the release owner pauses the revised route and checks the agreed response. That is a hypothetical safeguard, not a suggested universal threshold.
Separate a stop condition from a learning question. A blocking failure may require immediate action. A question about whether a label improves completion may require a planned study. Combining them can make the team either overreact to noise or ignore a serious issue while waiting for an analysis.
In leading AI change, the same distinction helps separate adoption feedback from a failure that should suspend a use case.
Avoid hindsight that rewrites the original choice
When the outcome arrives, review the decision against the information available at the time. A favourable outcome does not prove a sound process; an unfavourable outcome does not automatically prove the choice was reckless.
Ask whether the owner followed the criteria, disclosed the unknowns and implemented the safeguards. Then identify which assumption changed and what the team should now do.
The organisational psychology guide explains why incentives and blame can discourage that honest review. If every adverse outcome becomes a personal accusation, future records may become defensive rather than informative.
A useful decision record leaves enough detail for the next person to understand the choice and challenge it with new evidence. That is the practical aim: a decision you can make now and reconsider responsibly later.
If your team keeps postponing decisions because facts, assumptions and authority are mixed together, tell me about the choice you need to make. We can clarify the decision, its evidence gaps and a workable review point.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
Difficult feedback: prepare a useful conversation
Prepare difficult feedback with observable behaviour, fair questions and a clear next agreement. Use a practical worksheet without labelling the person.
Leadership: how to lead digital teams with clarity
A practical leadership guide for digital teams: clarify decisions, delegate with useful boundaries and support people through feedback and change.
Delegation and accountability: clarify who decides
Delegate with a clear outcome, decision authority and review points, so accountability helps the work instead of creating another approval queue.