Workshop Notes

Rational Decision Making and Where It Breaks

Listen · 7 min My words, my voice — synthesized.
Cut-paper illustration of a pale blue paper staircase of six steps, with a single orange paper figure stepping off the fourth step onto a small ledge

Rational decision making is a six-step model: define the problem, set the criteria, list the options, estimate the consequences, score the options, and pick the best one. As of November 2026, after 15 years of building products, I think the model is correct and almost never available. It needs a complete list of options, known consequences, and enough time to compare them. Real decisions rarely offer all three at once. Herbert Simon called what people do instead bounded rationality: they search until something is good enough. This page names the conditions the model needs, shows one decision under full and bounded information, and says when to drop the model on purpose.

What is rational decision making?

Rational decision making is a model where you define the problem, set your criteria, list every option, estimate what each would do, score them, and pick the best. It is a sound ideal. It assumes you can see all the options, know the consequences, and have the time to compare them. Most real decisions miss at least one.

Textbooks name the steps a little differently. Some use five, some use seven. I use six because that's the version I can hold in my head.

The model isn't wrong. I want to be clear about that, because the usual take on this topic is to knock it down. When the conditions hold, it's the best tool there is. My complaint is about how rarely they hold.

What does the rational decision making model need to work?

It needs three things: a complete list of options, known consequences for each, and enough time to compare them. Remove any one and the model gives you a confident-looking answer built on guesses. The scoring step is where this hides, because a number in a cell looks like knowledge even when it is a hunch.

Here is how I read each condition. This is my reading of the model's assumptions, not a quote from a source.

Complete options. The model says to list every option. In practice you list the ones you thought of. The best option is often the one nobody has proposed yet.

Known consequences. You have to estimate what each option will do. For a familiar, repeated decision, you can. For a new product bet, you're guessing, and so is everyone else in the room.

Enough time. Comparing options carefully costs hours or days. Plenty of decisions have a clock shorter than that.

Notice that the failure is quiet. Nothing in the process tells you a condition is missing. The worksheet fills in the same way either way.

What replaces it when the conditions are missing?

Herbert Simon called it bounded rationality. People search a small set of options, set a level that would be good enough, and take the first option that clears it. This is called satisficing. It is not a failure of reason. It is reason working inside limits of time, attention, and information.

I credit Simon here because the idea is his, and it's one of the most useful in the field. His point was that the limits are real and permanent. They aren't a flaw to train out of people.

What I keep coming back to is the "good enough" bar. It's a decision in its own right, and it has to be made first. Teams that satisfice well write the bar down before they look at options. Teams that satisfice badly pick whatever is in front of them and call it good enough afterward.

What does the same decision look like under full and bounded information?

It looks like two different processes that can reach the same answer or different ones. The table below runs one decision both ways. The example is a composite I invented to show the shape. The numbers and details are made up for illustration and come from no real project.

The decision: a small product team needs a contractor to build one customer-facing feature.

Step Full information Bounded information
Problem Build the feature within budget and quality limits. Same, but the deadline is in three weeks.
Criteria Weighted list: quality, cost, speed, communication, maintainability. Three bars, written first: has shipped something similar, can start this month, fits the budget.
Options All qualified contractors in the market, found through open review. The four people we can reach this week. Two came from referrals.
Consequences Past work audited, references called, a paid trial for each finalist. One call per candidate and one sample of past work. Gaps marked as unknown.
Choice Highest weighted score wins. First candidate who clears all three bars.
After Review at delivery. Review at week one, with a named exit if the first milestone slips.

Look at the last row. The bounded version doesn't skip the review. It moves it earlier, because it knowingly started with less information. That is the trade: you give up search and analysis, and you pay for it with faster checking.

The full-information column is better if you have a quarter and the cost of a bad hire is high. The bounded column is better if you have three weeks. I've seen teams run the first process with the second one's calendar, and they get the worst of both. They half-evaluate everyone and finish late.

Is irrational decision making the model failing?

No. Some of what gets called irrational is bounded rationality seen from the outside. Someone picks the first workable option and looks careless to a person who had more time. Other cases are real biases, like backing a choice because of what you've already spent. The label matters less than the question of what limits the decision was made under.

I don't think a person can be trained out of all of this. What a team can do is notice which conditions are missing and say so out loud. "We don't know the consequences here" is a sentence that changes the meeting.

When should you drop the rational model on purpose?

Drop it when the decision is small and reversible, when time is shorter than the analysis, or when the options will only appear after you act. In those cases, set a good-enough bar, pick the first option that clears it, and plan the review. Keep the full model for costly, hard-to-undo calls.

Three cases come up most often in my work:

  • The decision is cheap to reverse. If you can undo it in a day, a day of analysis costs more than the mistake would. Pick, watch, and adjust.
  • The options only appear by trying. In early product work, you often can't list the alternatives until you've shipped one. Running a small version is the research.
  • The clock is shorter than the method. I wrote about this in decision-making under pressure. Orient, decide, act, and review fast.

If you need a middle path, a rapid decision-making framework matches how deeply you analyze to how costly and reversible the call is.

One last thing. Dropping the model should be a decision you can explain. "We chose a good-enough bar because we had three weeks" is a position. "We went with it" is a drift.