Competing Models and Model Portfolios

By the end of this lesson, you will be able to...

• Compare two or more models by purpose, assumptions, signals, predictions, and blind spots.

• Decide when models should compete for a question and when they should be used as complementary views.

• Build a small model portfolio with explicit roles instead of collecting frameworks as decoration.

Idea in one sentence: Keep several models when each exposes a different useful relationship, but give every model a job and a way to be challenged.

Core Insight

Imagine the support team from the previous lessons. The backlog is 44 tickets. The manager uses a capacity model and predicts that moving one engineer to support will reduce the queue.

After five days, the queue is 47. The team did move the engineer. The forecast range was not absurd. Yet the explanation is incomplete.

Three people propose different models:

• The operations lead says the queue is a flow problem: too many arrivals and too little resolution capacity.
• The product lead says a recent release created a new class of tickets, so fixing the release matters more than adding staff.
• The support lead says the dashboard is misleading: easy tickets close quickly, while complex tickets remain hidden in an unmeasured queue.

They are not necessarily arguing about different facts. They are choosing different representations of the same situation.

The operations model can guide today's staffing. The product model can explain a change in arrivals. The measurement model can reveal why a green metric coexists with bad user experience.

This is the pressure behind the lesson:

When one model stops explaining an important observation, do not immediately defend it or replace it blindly. Compare it with another model that makes a different relationship visible.

Why One Model Is Rarely Enough

The previous lessons built a model with a purpose, boundary, variables, proxies, feedback, ranges, and update triggers. That discipline does not imply that one model should contain everything.

A flow model is good at counting movement through a queue. It may be poor at explaining why a new ticket category appeared. A product-cause model can explain the category while saying little about whether today's staffing is enough. A measurement model can expose proxy failure while leaving the technical cause unresolved.

The question is not:

Which model is the one true picture?

The better question is:

Which model is useful for this question, and what would it fail to show?

Plain meaning:

Competing models are different explanations or representations that can be tested against the same situation.

In this scenario:

The staffing model and the product-release model make different predictions about what should change next.

Technical term:

A model portfolio is a small, explicit set of models kept for different questions, decisions, or failure checks. A portfolio is not a pile of favorite metaphors. Each model needs a purpose, owner, evidence, and boundary.

The Temptation to Pick a Winner Too Soon

When a team is under pressure, it often wants one explanation quickly. A single explanation feels decisive:

The backlog is high because we need more people.

That explanation supports an immediate action. It may also become an identity. Evidence that contradicts it is treated as a temporary exception, a bad metric, or a reason to add another patch.

The opposite mistake is to keep every explanation equally alive:

It could be staffing, the release, user behavior, incentives, architecture, documentation, or the weather.

This sounds open-minded but does not guide action.

A portfolio creates a middle path. Keep a small number of models, state what each is for, and compare their predictions and costs. Models can coexist without receiving equal weight or equal attention.

Three Models for One Backlog

Let us make the support team's alternatives explicit.

Each model has a different center of gravity. The table does not say that only one model is valid. It tells the team which question each model can answer.

Worked Path: Let Predictions Compete

The team needs evidence, not a debate about whose vocabulary sounds best.

Starting state

Observed facts:

backlog: 44 tickets
new tickets: 15 per day
resolved tickets: 12 per day
release 2.8 shipped three days ago
most visible dashboard metric: tickets closed

The capacity model predicts that adding one trained engineer should increase resolution and reduce backlog within a few days.

The release-cause model predicts that tickets with a particular error signature will rise after release 2.8 and fall after a rollback or patch.

The measurement model predicts that closed-ticket count can improve while complex unresolved cases and abandoned requests continue rising.

Step 1: Write the predictions before acting

These predictions are not guarantees. They are ways to make each model vulnerable to evidence.

Step 2: Observe an intermediate state

After two days with the extra engineer:

resolved tickets: 15 per day
new tickets: 18 per day
error-signature tickets: 9 per day, up from 2
closed-ticket count: green
abandoned requests: rising

The capacity model correctly predicted more resolutions but did not explain why arrivals rose. The release model gained support because the error signature changed after release 2.8. The measurement model gained support because a green closure metric coexisted with rising abandonment.

Step 3: Assign model roles

The team keeps all three, but not as one blended story:

• Use the flow model to plan temporary staffing and queue limits.
• Use the release model to test a rollback or patch.
• Use the measurement model to stop treating closed tickets as the only service signal.

The decision is now a portfolio of actions: contain the queue, investigate the release, and repair the measurement rule.

Step 4: State what would change the portfolio

If the error signature does not fall after rollback, reduce confidence in the release model. If the backlog falls but abandonment remains high, keep the measurement model active. If all categories rise together after a traffic spike, the flow model may become the main explanation again.

The portfolio remains revisable. It is not a compromise where every model is always used.

So far, the worked path has shown the mechanism:

one surprising situation
-> alternative models
-> distinct predictions
-> targeted observations
-> different decisions
-> revised confidence and model roles

Compare Models by Their Blind Spots

A model comparison should include more than “which one sounds plausible.” Use five questions:

1. What question is this model built to answer?
2. Which variables and relationships does it make visible?
3. Which conditions does it treat as outside or stable?
4. What observation would support or weaken it?
5. What decision becomes safer or clearer if we use it?

This structure makes disagreement productive. Two models can agree on an observation and disagree on what it means. That disagreement tells us which additional observation might separate them.

For example, all three models agree that the backlog is high. They disagree about the next useful measurement:

• flow model: arrivals by day and resolution capacity;
• release model: error signatures by release version;
• measurement model: abandoned requests and complex-ticket wait.

The next observation should be chosen for its ability to distinguish explanations, not merely because it is easy to add to the dashboard.

When Models Should Be Combined

Sometimes two models describe different layers of one decision and can be connected carefully. The flow model can use the release model's forecast of new arrivals. The measurement model can provide an additional constraint on acceptable service.

But combining them creates a new model with new assumptions. Write those assumptions down:

release patch reduces error tickets by 40%
and
staffing can process the remaining arrivals at 15/day
therefore
backlog should fall below 25 within one week

The combined statement is not automatically stronger because it includes more ideas. It is stronger only if the relationships and evidence support it.

Keep separate models separate when:

• they operate on different time scales;
• they have different owners or evidence sources;
• combining them would hide an important assumption;
• one model is still being tested;
• the decision can be made without the extra coupling.

Trade-offs and Limits

The central trade-off is that multiple models reduce blind spots and make disagreement inspectable, but they cost attention, maintenance, and coordination.

A portfolio can become a grab bag if the team collects frameworks without assigning questions or predictions. It can also create false balance: a model with no evidence should not receive the same weight as a model that survives repeated checks.

Keeping only one model is cheaper, but it increases the risk that every new observation is forced into its vocabulary. Keeping too many models makes action slow and can produce contradictory recommendations.

You can see the boundary when the portfolio cannot answer “which model guides this decision,” when two models are combined without naming the new assumption, or when no observation could reduce confidence in any model.

Common Confusions

Confusion: Multiple models mean that anything can be true

Why it is tempting:

If every model is partial, it can sound as if evidence no longer matters.

Better model:

Models still make claims and predictions. A portfolio makes those claims easier to compare; it does not remove the need for evidence or revision.

Confusion: The most detailed model should win

Why it is tempting:

More variables look like more realism.

Better model:

Choose a model by fit to the question, evidence, inspectability, and decision value. Extra detail can create new assumptions without improving the answer.

Confusion: Complementary models must be merged

Why it is tempting:

A single diagram feels cleaner than several views.

Better model:

Models can remain separate and exchange explicit inputs. Merging them creates a new model that needs its own boundary and validation.

Confusion: A model is competing only when it disagrees with another

Why it is tempting:

The word “competing” sounds like a contest between explanations.

Better model:

Two models compete when they offer different predictions or decisions for the same question. They may also be complementary when they answer different questions about the same situation.

Check Your Understanding

Check: A team sees more tickets after a release. The capacity model says to add staff; the release model says to inspect a new error signature. What observation best separates the models?

Think first, then reveal.

Answer: Compare ticket categories and error signatures before and after the release. A sharp, release-specific cluster supports the release-cause model; a broad rise across categories supports a different explanation.

Check: A team combines “the patch will reduce arrivals by 40%” with “the extra engineer will resolve 15 tickets per day” and forecasts a safe backlog. What must be made explicit?

Think first, then reveal.

Answer: The combined forecast is a new model. It must state the evidence, timing, and assumptions behind both effects and specify what observation would reduce confidence in the forecast.

Practice: Build a Small Portfolio

Choose a messy situation: a software incident, a queue, a study problem, household spending, a team conflict, or a public service.

Create two or three model cards. For each model, write:

1. the question it answers;
2. its boundary and main variables;
3. what it reveals and hides;
4. one prediction or signal that could challenge it;
5. the decision it supports;
6. whether it competes with or complements the other models.

Then choose one immediate decision and name which model guides it. Explain why the other models remain active, or why you are retiring them.

A good answer should not merely list different vocabulary. The models should produce different observations, predictions, or decisions. It should also include a reason to change the portfolio later.

Connection to the Next Lesson

The portfolio now gives us several ways to see a situation. The next lesson asks what to do when one of those models fails in practice:

Did the prediction miss because an assumption went stale, the boundary drifted, the signal was weak, or the model should be retired?

That review turns comparison into repair rather than model collecting.

Resources

• [BOOK] The Model Thinker — Focus: Many-model thinking, model diversity, and choosing representations by purpose.
• [BOOK] Thinking in Systems — Focus: Compare system explanations by feedback, boundaries, delays, and leverage.
• [ARTICLE] Mental Models I Find Repeatedly Useful — Focus: Use models as conditional tools with explicit limits rather than universal answers.

Key Takeaways

• A competing model is useful when it makes a different prediction, blind spot, or decision visible.
• A model portfolio assigns each model a question, evidence, boundary, and role; it is not a grab bag of frameworks.
• Complementary models can exchange explicit inputs, but combining them creates a new model with new assumptions.
• Multiple models reduce blind spots but cost attention and coordination, so keep the portfolio small and revisable.
• Choose the model that guides a decision, and state what observation would make you change that choice.