Here is a thread from the pricing channel at an invented company. The question was asked on a Monday:
Product lead, week 1: Should the new team plan be per seat or flat? Sales needs an answer for the March deals.
Founder, week 1: Per seat feels right, but let's look at usage-based before we commit.
Finance, week 2: Pulled usage numbers. Usage-based works for big accounts, hurts small ones. Could we do a hybrid?
Sales lead, week 2: Two prospects asked about annual flat pricing. Adding that as option four.
Founder, week 3: Good options. Let's not rush this. Can someone model all four against last quarter?
Pull request, week 3: Adds per-seat pricing to the team plan checkout. Assumed per seat based on the existing individual plan.
Nobody in the thread was being careless. Every reply added a real option, and every option was worth knowing about. But the thread had no answer to the one question that would have ended it: what would a good enough pricing model have to do? Without that, there was no point at which the search could stop. And while the people searched, a coding agent working on checkout did stop. It picked the first option that made its tests pass and shipped it.
The economist Herbert Simon had a word for what the agent did, and for what the team couldn't: satisficing.
Good enough, and how good is enough
Simon spent much of his career arguing that the decision-maker of classical economic theory, who knows every alternative and picks the best one, is not how people or organizations actually decide. He received the 1978 Nobel Memorial Prize in economics for his research on decision-making in economic organizations, and his Nobel lecture, "Rational Decision-Making in Business Organizations," sets out the alternative he proposed in two papers in 1955 and 1956.
Real decisions, he said, begin with a search. "If the alternatives for choice are not given initially to the decision maker, then he must search for them." Searching all the way to the best option would require the decision-maker "to be able to estimate the marginal costs and returns of search in a decision situation that was already too complex for the exercise of global rationality." So Simon described a different rule.
As an alternative to optimizing, he wrote, "one could postulate that the decision maker had formed some aspiration as to how good an alternative he should find. As soon as he discovered an alternative for choice meeting his level of aspiration, he would terminate the search and choose that alternative. I called this mode of selection satisficing."
Two details in that account matter for product teams. The first is that the aspiration level isn't fixed: "aspiration levels are not static, but tend to rise and fall in consonance with changing experiences. In a benign environment that provides many good alternatives, aspirations rise; in a harsher environment, they fall." The second is what Simon thought the idea was for. Its importance, he said, was that "it showed how choice could actually be made with reasonable amounts of calculation, and using very incomplete information."
Satisficing, then, is a rule with two parts: a bar set in advance, and a stopping point when something clears it. In Simon's account, the decision-maker forms that bar. Writing it down is the step this post adds. Simon closed the lecture by describing people as finding "ways of action that are sufficient unto the day, that satisfice."
Teams keep searching, agents stop early
The pricing thread shows both ways the rule breaks.
The team searched without a bar. Each new option was a reason to look at one more. With no stated aspiration level, nothing could clear it, so the search could only end when someone got tired or a deadline forced it. In Simon's terms, the team was trying to optimize in a situation too complicated to optimize in, which Simon called "the impossible."
The agent stopped at a bar nobody set. Coding agents are built to satisfice. They take the first implementation that meets their aspiration level and stop. The trouble is where that level comes from. Nobody told the agent what a good enough pricing model had to do, so its bar was whatever it could infer: the tests pass, the code matches the existing individual plan. It cleared that bar quickly and moved on. We've written about that kind of guess becoming the standard.
These are the same failure seen from two sides. The aspiration level was never written down, so the people couldn't stop and the agent stopped in the wrong place.
Our essay on the modern product development lifecycle describes where this leads as agents spread: "the work now piles up at the same review gates, waiting on people." Its answer for the stage after that is "Material decisions go to a named owner, routine ones stay with the team." Both halves of that sentence need an aspiration level. A routine decision only stays with the team if the team knows what good enough looks like. A material decision only gets made by its owner if the owner has a bar to judge options against, and a reason to stop looking. We've also written about why cheaper code multiplies the decisions waiting on people. Satisficing is how those people get through them.
Where Brief fits: writing down what good enough means
Brief is the product strategy agent. The homepage says it "captures decisions where they happen, connects them into one graph, and acts on them." For satisficing, that means a place to write down the two parts of Simon's rule, a person responsible for the search, and agents that stop at the team's bar instead of their own.
The bar goes in the record. In the Brief app, recording a decision requires both What was decided? and Why? before Record Decision will save it. The Why? is where the aspiration level belongs: "Per seat, because it has to be simple enough for sales to quote on a call and has to grow with the account." That one sentence would have ended the pricing thread, because it is a test that every option either passes or fails.
So does the condition for searching again. A decision can carry a Re-evaluate when condition, such as "when more than a third of new accounts ask for usage-based pricing." That is Simon's moving aspiration level, written down in advance. The team doesn't have to reopen the decision every time someone finds a new option, because the record already says what change in the environment would justify a new search.
The open search has an owner. When the bar isn't clear yet, the question can be proposed as a pending decision. In the app, Propose takes the required What needs to be decided? topic and can name Who should decide? In Slack, /propose turns an open question into a proposal, and Edit can add an owner. With the user's approval, an agent can record one too. Agents can call brief_list_pending_decisions to see what is waiting. The homepage's Friday brief "names the decision holding each late launch and who owns it." A three-week thread becomes a pending decision with a name on it, visible to everyone who checks what is still open.
Agents stop at the team's bar. Coding agents set up with Brief search the recorded decisions before they start work, and ask Brief to check significant changes with brief_ask in check mode. Once pricing is recorded, an agent working on checkout can find the decision and its reason, and build to that bar rather than one inferred from the individual plan. When the decision is still pending, the agent can hold. The homepage shows an agent asked to add per-seat pricing to the checkout API learning that D-241, the seat-based pricing decision, is pending, and replying: "Holding the pricing change until D-241 is decided." That is an agent declining to satisfice against a bar it wasn't given.
Reopening goes through the record. When the environment does change, the team can record the new decision with its own Why?, and a recorded decision's History shows its status changes, who made them, and any reason given. With Proactive Brief turned on, Brief can also prompt people to revisit decisions that may need reconfirming. The next search starts from the last bar, not from a blank thread.
None of this sets the bar for you. Brief can't tell a team what good enough pricing looks like, and a Why? field accepts a vague reason as easily as a testable one. A team that keeps reopening a decision can still do that. What Brief changes is where the aspiration level lives once someone states it: in the record that people and agents check, instead of in the head of whoever happened to read the thread.
Simon's point was that nobody can afford to find the best answer to every question, so the skill is in knowing when an answer is good enough. For the decision your team has been discussing longest, could anyone say what an option would have to do to end the search?
Objections
What is satisficing?
Satisficing is a decision strategy described by the economist Herbert Simon in which a decision-maker sets an aspiration level for how good an option needs to be, searches until finding an option that meets it, and then stops and chooses that option. Simon contrasted it with optimizing, which requires comparing every alternative to find the best one.
Who coined the term satisficing?
Herbert Simon introduced satisficing in his work on bounded rationality in the mid-1950s. His Nobel lecture names two papers as the first steps: "A Behavioral Model of Rational Choice" (1955) and "Rational Choice and the Structure of the Environment" (1956). He described the idea in his 1978 Nobel lecture: "As soon as he discovered an alternative for choice meeting his level of aspiration, he would terminate the search and choose that alternative. I called this mode of selection satisficing."
Is satisficing the same as settling?
No. Settling usually means accepting less than you wanted. Satisficing means setting in advance what an acceptable option must do and stopping when one does. Simon also noted that aspiration levels rise and fall with experience, so a team that satisfices can raise its bar when good options turn out to be plentiful.
How does satisficing apply to coding agents?
Coding agents satisfice by design: they stop at the first implementation that meets their criteria, such as passing tests. If nobody has recorded the product decision behind a task, the agent's criteria come from whatever it can infer, so it can stop at an answer the team never chose. Recorded decisions give the agent the team's aspiration level to build against.
How does Brief help teams make good enough decisions?
Brief requires a Why? when a decision is recorded in the app, where a team can state the bar the decision had to clear, and a Re-evaluate when condition records when the decision should be reopened. Open questions can be proposed as pending decisions that name who should decide. Coding agents set up with Brief search recorded decisions before they build and can hold when a decision is pending. Brief cannot set the bar for a team; it keeps the bar with the decision once someone states it.