No. 013Ways of Thinking

Satisficing

With limited time, information and attention, set a clear bar for good enough and take the first option that meets it, instead of searching for the best.

“As soon as he discovered an alternative for choice meeting his level of aspiration, he would terminate the search and choose that alternative.”
— Herbert A. Simon, “Rational Decision-Making in Business Organizations”, Nobel Memorial Lecture (1978)

Set the bar for good enough in advance, then take the first option that clears it instead of searching for the best.

To an executive

Searching for the perfect option costs time and money that rarely pay back. Agree what good enough means, then choose the first option that meets it.

To an engineer

Write the acceptance criteria for a choice before you evaluate options. Stop at the first option that meets them, and save deep comparison for hard-to-reverse decisions.

The idea

Herbert Simon argued that real decision-makers have bounded rationality: limited time, incomplete information and finite attention. Classical economics assumed people optimise, weighing every option to find the best. Simon observed that people and organisations instead search until they find an option that meets their aspiration level, and then stop.

He introduced the word satisficing, a blend of satisfy and suffice, in his 1956 paper "Rational Choice and the Structure of the Environment" in Psychological Review. His point was not that people are lazy, but that satisficing is a sensible way to adapt when searching is costly and the environment is too complex to optimise over. In 1978 he received the Nobel Memorial Prize in Economic Sciences for his research into decision-making within economic organisations.

Why it works

Search has a cost. Every extra week spent comparing vendors, frameworks or designs delays value and uses attention that other decisions need.

The optimum is often an illusion. With uncertain requirements and incomplete data, the "best" option on paper is a guess, and refining the guess rarely changes the outcome much.

An explicit bar makes the decision defensible. Writing down the criteria before looking at options stops the goalposts moving and makes it clear why the search ended.

Where it applies

Vendor and tool selection, where the criteria (security, integration, cost, support) can be set first and the shortlist evaluated against them.
Design choices with many acceptable answers, such as a library, a message format or a naming scheme.
Roadmap and platform decisions under time pressure, where waiting for perfect information means missing the window.
Architecture reviews, to stop debates comparing two options that both clearly meet the need.

How to apply

Decide how much the choice deserves. Easily reversed choices need a low bar and a short search; hard-to-reverse ones justify more.
Write the good-enough criteria first. Include the must-haves and the limits, such as cost, latency or compliance, before anyone presents options.
Evaluate options in a sensible order, most promising or cheapest to check first.
Stop at the first option that meets every criterion and record why it was chosen.
Revisit the bar if nothing passes, rather than quietly lowering it for a favourite.

Example scenario

A team needed a feature-flag service. Three months in, they were still comparing seven products on forty attributes, and two delivery teams had built their own flags in the meantime.

The architect reset the decision. The group agreed five criteria: single sign-on, an audit trail, SDKs for their two languages, data residency in the EU, and a cost ceiling. They checked the two most-used products first; the second met all five, so they chose it within a week and noted that switching later would be a contained migration behind a thin wrapper.

Questions to ask

What would good enough look like here, written down before we compare options?
What is it costing us to keep searching for a better option?
Is this decision costly to reverse, and so worth a longer search?

When not to use it

Irreversible, high-stakes decisions, such as a core data platform or a long contract, where a deeper search pays off.
When the criteria themselves are unclear, which means the problem needs framing before any choice.

How it misleads you

Satisficing becomes an excuse when the bar is set after the favourite option is known, or set so low that anything passes. It also misleads when "good enough" ignores long-term costs, such as lock-in or operational load. Write the criteria first, include the costs that show up later, and match the depth of search to how hard the choice is to undo.