In his 2015 letter to shareholders, Jeff Bezos warned about a habit that creeps into growing organizations: using a slow, heavy decision process for almost everything. The result, he wrote, is “slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.” His fix was a framework for choosing frameworks: first ask whether the decision can be undone.
Decision making frameworks are repeatable structures for making a choice: comparing options, mapping uncertain outcomes, stress-testing a plan, or assigning who decides. The right one depends on what is still unresolved and on whether the decision can be reversed. Pick the lightest tool that answers the open question.
Reversibility sets how much process a decision deserves
Bezos split decisions into two types in the 2015 letter. Type 1 decisions are “one-way doors”: consequential and hard to undo, so they “must be made methodically, carefully, slowly.” Type 2 decisions are “two-way doors.” If one turns out badly, “you can reopen the door and go back through,” so “high judgment individuals or small groups” should make them quickly.
The 2016 letter added three working rules. Most decisions should be made with “somewhere around 70% of the information you wish you had,” because waiting for 90% is usually too slow. When a team disagrees, someone with conviction can ask colleagues to “disagree and commit.” And when teams are truly misaligned, escalate early, because otherwise “whoever has more stamina carries the decision.”
| Feature | Two-way door | One-way door |
|---|---|---|
| Example | Testing a new meeting format | Signing a five-year contract |
| Who decides | One person or a small group | Owner, with wide consultation |
| Information needed | Enough to act, roughly 70% | As much as the stakes justify |
| Typical tools | A quick note, a short trial | Matrix, decision tree, premortem, clear roles |
| Biggest risk | Moving too slowly | Moving too fast |
The rest of this guide covers the heavier tools. Use them for one-way doors, or when a two-way door keeps getting stuck.
Match the framework to the bottleneck
| Unresolved question | Useful framework | Output to look for | Main limitation |
|---|---|---|---|
| Which option best fits several criteria? | Weighted decision matrix | Scores, weights, and a sensitivity check | Judgments can look more objective than they are |
| What happens under different possible outcomes? | Decision tree | Branches, assumptions, and conditional values | Unreliable probabilities produce unreliable expectations |
| How could this plan fail? | Premortem | Failure causes and responses | Imagined failures are possibilities, not predictions |
| Who drives and makes a cross-team decision? | DACI | One Driver, one Approver, Contributors, Informed | Roles do not replace analysis |
| Who recommends, must agree, decides, and executes? | RAPID | Defined rights and responsibilities | Too many approval rights can stall the process |
If an option breaks a hard requirement, such as a legal or safety rule, remove it before scoring. High marks elsewhere should not buy it back.
A weighted matrix shows how fragile a ranking is
A decision matrix scores each option against the same criteria. The Atlassian decision matrix template describes the weighted version:
- Remove options that fail hard constraints.
- Choose criteria that measure distinct things, so nothing is counted twice.
- Give each criterion a weight, with all weights adding to 1.
- Define the scale. Here, 5 is better than 1 for every criterion, including affordability.
- Multiply each score by its weight and add.
- Change a plausible weight or score and check whether the ranking survives.
Here are two fictional software options, scored with teaching numbers rather than real product ratings:
| Criterion | Weight | Option A | Option B |
|---|---|---|---|
| Affordability | 0.40 | 2 | 5 |
| Workflow fit | 0.35 | 5 | 2 |
| Support | 0.25 | 4 | 3 |
| Weighted total | 1.00 | 3.55 | 3.45 |
For A: 0.40 × 2 + 0.35 × 5 + 0.25 × 4 = 3.55. For B: 0.40 × 5 + 0.35 × 2 + 0.25 × 3 = 3.45.
The first weighting favors A slightly. A plausible change in priorities favors B.
Raise affordability to 0.50 and drop workflow fit to 0.25. Now A = 3.25 and B = 3.75. Nothing about the products changed, yet the recommendation flipped. With support fixed at 0.25, the tie point is an affordability weight of about 0.417.
So the real finding is that the choice hinges on how much the team values price against fit. Settle that disagreement, or get better evidence on workflow fit, before treating 3.55 versus 3.45 as a verdict.
A decision tree separates choices from chance
Decision trees split what you control from what you do not. Start with the options, then branch into possible outcomes under each.
In a simplified example, a pilot project has a 60% chance of an $800 net benefit and a 40% chance of a $200 net loss:
0.60 × $800 + 0.40 × (−$200) = $400.
A safe alternative paying a certain $350 has a lower expected value. It may still be the better pick if a $200 loss would break a cash limit or the 60% is a guess. Check that branch probabilities add to 1 and that no cost is counted twice. If you have no basis for probabilities, use named scenarios and ranges instead.
Opportunity cost calculations keep the forgone option visible, and second-order thinking catches later consequences a simple tree misses.
A premortem finds weak links before you commit
A premortem asks the team to imagine the project has already failed, then explain why. Gary Klein’s original description frames it this way because treating failure as a done deal makes people more willing to name its causes.
Suppose a software rollout failed because staff could not do their daily work in the new system:
| Possible cause | Early signal to check | Response |
|---|---|---|
| Essential workflow is missing | Pilot users cannot finish a required task | Test that task before the rollout |
| Responsibility is unclear | Requests bounce between teams | Assign an owner and escalation route |
| Migration takes longer than assumed | Trial migration overruns the window | Revise scope or timing before committing |
Turn a possible failure into a signal to check and a response you can assign.
These are prompts for investigation. A long list of scary possibilities is not yet a risk assessment.
DACI and RAPID settle who decides
Analysis can be finished while a decision stays stuck because nobody knows who has the final word. That is the misalignment Bezos said to escalate rather than wear down.
Atlassian’s DACI playbook uses four roles:
- Driver: organizes the process, information, and deadline.
- Approver: the one person who makes this decision.
- Contributors: provide expertise and recommendations.
- Informed: hear the outcome because their work is affected.
For a software choice, the operations lead might drive, the budget owner approve, users and engineers contribute, and affected teams be informed. Assign roles per decision instead of assuming a job title always means the same role.
Organizing the process and making the final decision are separate responsibilities.
Bain’s RAPID model names Recommend, Agree, Perform, Input, and Decide. The key distinction is between Agree and Input: giving useful advice does not grant a veto. State which issues need formal agreement, and keep a single decider where possible. For how groups gather input without drowning in it, see group decision making.
When frameworks make decisions worse
The process becomes the goal. Bezos warned against defending a bad result with “we followed the process.” A filled-in template is evidence of effort, and only sometimes evidence of judgment.
Precision hides guesses. A matrix total to two decimals or a tree with exact probabilities can make shaky inputs look solid.
Every door gets treated as one-way. Running a premortem on a reversible test wastes time that a quick trial would have saved.
Roles replace thinking. A tidy DACI chart cannot rescue an option nobody analyzed.
A decision record you can review
| Field | Question to answer |
|---|---|
| Decision and deadline | What exactly must be chosen, and when? |
| Door type | Can this be undone cheaply? |
| Owner and roles | Who organizes, contributes, decides, and implements? |
| Constraints | What must every option satisfy? |
| Alternatives | What can we actually choose, including waiting? |
| Evidence and assumptions | What is verified, and what is still a guess? |
| Choice and reasons | What was decided, and why? |
| Reopen if | What new evidence would send us back? |
For the basics behind these steps, see decision making. For a fully structured benchmark, see the rational decision-making model. When other people’s choices shape your outcome, game theory games add another layer.
Frequently asked questions
What are examples of decision-making frameworks?
A weighted matrix compares options on several criteria, a decision tree maps uncertain outcomes, a premortem explores possible failure, and DACI or RAPID clarifies roles. They solve different problems and often work together.
What is the best framework for decision-making?
No single framework fits every choice. Start by asking whether the decision is reversible, then name what is unresolved and pick the tool built for that question.
What is a strategic decision framework?
For strategic choices, a good structure links the decision to objectives, real alternatives, evidence, trade-offs, ownership, and a point at which to revisit it. Strategic decisions are often one-way doors, so they earn the heavier tools.
Your 5-minute framework picker
Decision:
One-way or two-way door?
If two-way: who decides by when? (stop here)
If one-way, what is unresolved?
Comparing options -> weighted matrix
Uncertain outcomes -> decision tree
Hidden failure risk -> premortem
Who decides -> DACI or RAPID
Owner:
Reopen if:If you stopped at line three, that is often the right answer. For one short idea like this each day, try Daily Read.