Mental models: thinking better without oversimplifying

A small company receives a request from an important customer: build a feature its product does not yet have. The customer seems willing to pay, the team knows how to build it, and a start date is already available.

The conversation has not yet covered which work must leave the schedule, the maintenance the feature will require or the precedent for the next request. It also remains unclear whether other customers have the same problem. Without those questions, the decision tends to revolve around what is closest: possible revenue and the wish to serve the customer well.

In this hypothetical example, some consequences are visible from the beginning; others depend on questions nobody has asked. Mental models help formulate those questions before deciding.

Opportunity cost directs attention to what will be set aside. Reversibility distinguishes a test from a lasting commitment. Systems thinking examines effects on other parts of the business. Each perspective reveals a different part of the decision.

Using a model requires choosing a perspective suited to the situation, noticing what it omits and checking whether your interpretation matches what actually happens.

What a mental model is

A mental model is a simplified representation used to understand a situation and anticipate some of its behavior. It can take the form of a causal relationship, an analogy, a decision rule or a small set of questions.

Someone saying a team is overloaded because it accepts more work than it can finish is using a representation of how the team operates. There is an input, execution capacity and accumulation. That representation guides what they observe and which interventions seem reasonable.

It may omit how work is distributed, differences in task complexity or the need to redo deliveries. Depending on the problem, one omission can be decisive.

A building plan helps locate doors and corridors. Assessing sunlight requires orientation and time of day. Understanding how people move requires observing use of the space. A representation's quality depends on the question you want it to answer.

In everyday use, "mental models" groups together different kinds of things. An accounting identity has a precision that an analogy about human behavior lacks. A rule of thumb may help begin an analysis without being generally valid. Treating everything as an equally established law creates confidence the material cannot support.

Before adopting a model, ask where it comes from and under which conditions it works. What evidence would show it does not apply here?

Deciding with an incomplete view

Herbert Simon studied decisions made by people and organizations with incomplete information and limited processing capacity. In discussing bounded rationality, he examined how we choose under these conditions without assuming anyone can calculate every alternative and consequence. He presents the idea in his 1978 Nobel lecture.

An investigation therefore needs scope. We will not establish every scenario before choosing a supplier or the next product stage. We can identify uncertainties most likely to change the decision.

If two options cost almost the same, refining the price estimate may add little. If one depends on a sole supplier whose delivery capability is unproven, investigating that dependency may be much more useful.

The chosen model directs attention. It can focus time on relevant differences or lead us into a detailed analysis of something secondary.

Opportunity cost: what will not happen

If the customer's feature requires three weeks of work, ask what the team would otherwise do during that period.

It might fix a problem causing new users to abandon the product or reduce errors generating support tickets. The comparison includes that other work's expected benefit and the cost of postponing it.

Opportunity cost is the value of the best feasible alternative we give up. It does not add together everything imaginable we could do with the same time. That distinction prevents an endless inventory of losses.

Give the alternative some shape. "We could be growing" is too vague. "We could use these weeks to fix the registration step where we observe the most dropouts" allows investigation. You still need to verify whether registration is actually the problem and whether the fix would have the expected effect.

Costs also appear after delivery. A feature may be quick to build and slow to explain, test and maintain. Comparing only initial effort makes the project look smaller than the one you must sustain.

The same question can clarify a full personal schedule. A weekly commitment occupies its time and can fragment time around it. The alternative might be an activity, rest or a buffer for surprises. You need not price everything to recognize a tradeoff.

The model reaches a limit when you try to reduce different values to one measure. Time with someone close, learning and income do not always compare satisfactorily in money. The model makes the sacrifice visible; their relative importance still requires judgment.

Reversibility: distinguishing a test from a commitment

A decision can be easy to announce and difficult to undo. A button that disables a feature does not make its introduction fully reversible.

If customers depend on it, removal may require migration, negotiation and a loss of trust. If the team built processes around it, reorganizing them takes work. Examine reversibility from affected people's perspectives alongside the technical behavior.

There is a difference between adding a permanent feature for every customer and testing a manual solution with a small group. A pilot can reveal whether the problem is frequent, the proposed solution makes sense and the support effort is sustainable.

That depends on how you present the test. An experiment described as a permanent service creates expectations of continuity. Limiting the period, explaining what is being assessed and agreeing on how it ends belong to the decision's design.

Ask: what would reversing this cost, for whom and after how long? A choice can begin reversible and become difficult to undo as contracts, dependencies and habits accumulate.

The model also helps set analysis effort. A small test with limited, observable consequences can provide information. A lasting commitment with effects difficult to repair deserves further investigation before execution.

A test inexpensive for its proposer can transfer a large cost to someone else. Trying a process on customers unaware they are participating differs from a pilot agreed with informed participants.

Incentives and later consequences

Imagine the company rewards sales solely for signed contract volume. If complex and simple deals count equally, promising customizations other areas must deliver may become attractive.

The reward makes some behaviors more advantageous without solely determining what people do. Professional responsibility, relationships with colleagues and concern for customers also affect decisions.

Examine incentives beyond what people say. Who benefits? Who absorbs the cost? Which result appears in each area's report? A deal can look excellent to its salesperson and poor to those maintaining it for years.

In Leverage Points, Donella Meadows includes information flows, rules and goals among intervention points in systems. She examines how structure produces behavior and warns against generalizing about complex systems. Applying these ideas to a business requires checking how it works. Meadows' original essay.

For our example, follow the path of a sales promise. Does product participate before signing? Is maintenance cost assessed? Who monitors the contract after the sale? Investigate those questions before deciding what is happening.

Second-order thinking extends observation through time. Accepting the customization may first bring extra revenue. Later, other customers may request similar treatment. The team may divide attention between versions, extend deadlines or create a profitable specialized offer.

Avoid treating increasingly distant stories as predictions. With each additional link, state the conditions it requires. Instead of "This will disorganize the company," ask what volume of similar requests would create a problem and how you would detect its approach.

Constraints: where work gets stuck

A discussion sometimes begins with a shortage of people because that explanation is readily available. Before hiring, follow a deliverable through the process.

A task may spend a few hours in execution and many days awaiting approval. Another may return repeatedly because its recipient lacked information. Speeding up one stage does not guarantee faster delivery overall.

Looking for a constraint means identifying what limits the system's result under current conditions. Test the hypothesis through observation: where does work accumulate, how long does it remain, and what prevents passage?

For the requested feature, development may not be the scarcest resource. Every change might need one person's review. Support might already struggle to explain existing features. Adding possibilities can increase the load precisely where capacity is lowest.

A team may work intensely at an advanced stage while another prevents delivery. A constraint can move too: after approval improves, testing may begin limiting flow.

The model weakens when several constraints change rapidly or information covers only part of the process. Naming "the bottleneck" too early may end an investigation just when it needs to expand.

Probabilities: leaving room for revision

"I'm certain other customers will want this" often conceals unanswered questions. How many customers were heard? How were they selected? Did they describe their own problem or merely agree with a presented solution?

Thinking in probabilities means recognizing how much confidence available observations support. Even without calculation, distinguish an interesting possibility from a prediction with evidence behind it.

Look for a reference beyond the situation that caught your attention. How did similar initiatives behave? What do previous requests show? If almost no customization requested by one customer helped the rest, that history belongs in the analysis even when the new request is convincing.

History has limits too. The product or audience may have changed, or records may mix very different request types. A frequency is useful only when cases are sufficiently comparable for the question.

Competing explanations make belief revision clearer. Consider two hypotheses: recurring market demand or one customer's particular need. Vague interest could occur under either and does little to distinguish them. Independent customers spontaneously describing the same problem would be more informative.

Even that signal does not establish that the proposed solution works. The problem's existence, the solution's suitability and willingness to pay are separate questions. Combining them makes evidence for one seem to confirm all.

Record confidence before acting so you can assess later revision. If a test contradicts expectations, ask what changed: was the hypothesis wrong, the test inadequate or a relevant condition no longer present? One result rarely resolves every possibility.

Bringing perspectives together in a decision

The company needs to decide how much work to commit, under which conditions and what it expects to learn. "Build the feature or not" leaves those choices out.

Assume these fictional facts: customization would take three weeks from the team fixing registration; only one customer described the need in detail; maintenance is not estimated; and a manual approach can simulate part of the service.

Opportunity cost calls for comparison with the registration fix. Before postponing it, clarify the observed problem and why the planned intervention should help. Examine the existing project with the same skepticism as the new one.

Reversibility suggests considering a limited manual test. Agree on duration and scope without automatic incorporation into the product. This reduces some exit costs while still requiring support time.

Constraint analysis asks who will provide that support and what they will stop doing. If the manual operation consumes the person every delivery depends on, the pilot may be less cheap than it seems. It may need a smaller scope or postponement.

Incentives call for clarity about who can promise what. Sales needs to know the test's limits, and assessment must include work after the sale. The aim is a shared decision on total cost without presuming bad faith from whoever brought the opportunity.

Uncertainty analysis defines observations that justify continuing. The team could seek independent occurrences of the problem and track actual execution effort. Before starting, it would agree on signals for expanding, changing or ending the test.

These perspectives do not force a test. Priorities and evidence may also justify refusal or the complete project. In any case, explain the conditions, costs and supporting hypotheses, and agree on how to revisit what remains unknown.

Using models to defend a preference

Selecting convenient models can build an elegant defense of almost any choice. Someone eager to launch invokes experimentation. Someone wanting to wait emphasizes irreversibility. A supporter of the new project may inflate its potential; a supporter of the old one may treat every change as distraction.

Knowing more concepts can enlarge the vocabulary used to justify an initial preference without correcting selective use of perspectives.

Apply the most uncomfortable question you ask of the competing option to your favorite. If a new project needs demand evidence, what evidence supports the current one? If testing has a cost, what does remaining without learning cost? When imagining one option's failure, do you examine how the other could fail?

Separate observed facts from interpretations too. "Three customers mentioned registration difficulties" is an observation if properly recorded. "Registration is the main cause of slow growth" needs more evidence. Polished presentations can erase that distinction.

Ask who knows the situation from another angle. Test a model of a team's work with the people performing it. Apparently small details can invalidate a causal relationship that looked clear in a meeting.

A record that fits your routine

Start with a moderately sized decision whose result you can observe in the coming weeks.

Before deciding, record what you are considering. Use fields that help in that case:

Choose one or two perspectives that can change the analysis. For too many commitments, begin with opportunity cost. For an uncertain new idea, examine learning through a test. For recurring difficulty despite effort, follow the process and rules that may contribute to it.

During review, distinguish decision quality from the observed outcome. Careful choices can end badly for uncertain reasons. Poorly examined choices can benefit from circumstances. Outcomes alone make it harder to identify what should be repeated and what should change.

Keep the initial note and compare expectations with observations, including conditions that changed along the way. That helps adjust the model and recognize use outside its scope. At the next similar decision, consult the record to understand why the earlier choice worked or failed and which conditions still apply.