How Founders Can Use Mental Models to Reduce Bad Bets

A founder hears the same feature request in three sales calls. The team builds it, prospects praise the demo, and nobody changes their buying decision. The feature solved something people could describe, but not something they would prioritize.

Founders can use mental models to reduce bad bets by separating a promising story from the assumptions that make it work. Before committing, identify what must be true, test the weakest link, and decide how much exposure the evidence justifies.

A bad bet is not simply a decision that ends badly. Reasonable decisions sometimes fail under uncertainty. The avoidable mistake is making a large commitment on thin evidence, overlooking an obvious alternative, or continuing after the original rationale has fallen apart.

The practical aim is to make those mistakes easier to notice before they become expensive.

How Founders Can Use Mental Models to Reduce Bad Bets

Use mental models as questions inside a decision process. Each question should change what you investigate, how you structure the commitment, or what you do next.

A useful sequence is:

1. First principles: What must actually be true for this plan to work?
2. Inversion: What would cause it to fail even if the team executes well?
3. Opportunity cost: What valuable work would this commitment displace?
4. Optionality: Can we learn before making the decision difficult to reverse?
5. Confirmation bias and sunk cost: What evidence would change our minds, and will we act on it?

You do not need to apply every model to every choice. A reversible copy change needs less scrutiny than a product direction that consumes a quarter of engineering time. Increase the depth of the review with the consequences of being wrong.

Start With the Assumption, Not the Proposal

"Build a reporting dashboard" is a proposal. It contains several assumptions: customers need better reporting, the proposed dashboard meets that need, a buyer has authority to purchase it, and the benefit outweighs the effort of adopting it.

First principles thinking helps you break the proposal into these underlying requirements. Instead of accepting "customers want dashboards," ask what they are trying to accomplish and what prevents them from accomplishing it now.

Consider a hypothetical startup that helps small agencies coordinate client projects. Three prospects request reporting dashboards. The founder interprets this as a reason to build a reporting product.

But the prospects might need something simpler: a weekly summary they can send to clients without copying information between tools. A dashboard that requires another login could add friction rather than remove it.

Write the core assumption in a form you can investigate:

Agencies will adopt our service if it reduces the work of preparing their weekly client updates.

That statement points toward observing the current workflow and testing a useful output. "Reporting is a huge opportunity" points toward almost anything.

Separate what you know from what you infer. A prospect requesting a feature is an observation. Concluding that the feature will drive adoption is an inference. Treat the inference as an open question.

Use Inversion to Find the Failure Path

Inversion means examining a problem from the opposite direction. Instead of asking only how the reporting product could succeed, ask how it could fail despite a polished implementation.

For the agency startup, plausible failure paths include:

• The report looks useful, but collecting the underlying information takes too much effort.
• The person requesting it cannot approve a purchase or change the team's workflow.
• Agencies need different formats, making every customer a separate customization project.
• The need is occasional, so the product never becomes part of a recurring routine.

These possibilities suggest different tests. A better demo will not establish purchasing authority. Another interview will not reveal whether a report survives repeated use as clearly as watching a team use it.

Choose the failure path that would most undermine the proposal and remains least understood. Investigate it before polishing parts of the plan that already look convincing.

This is not an exercise in listing every imaginable disaster. A useful objection identifies a specific mechanism and leads to a check. "The market might not like it" is too vague to guide action.

For more on this approach, see inversion: solve problems by avoiding stupidity first.

Count the Opportunity Cost of the Bet

A project can be worthwhile in isolation and still be the wrong next project.

Opportunity cost is the value of the best alternative you give up when choosing an action. For a small team, scarce engineering time may matter more than the visible expense of a trial.

Suppose the reporting feature requires the same team that could fix a difficult onboarding process. Existing customers regularly get stuck during setup. Choosing reporting delays that improvement, even if no additional hiring is necessary.

Compare the proposals against the same goal. If the goal is helping more agencies reach useful recurring use, ask which project has better evidence of addressing that constraint.

A simple decision note might say:

Question	Reporting experiment	Onboarding improvement
Evidence available	Three prospects requested reporting	Current customers repeatedly struggle with setup
Main uncertainty	Whether reports change adoption	Whether the proposed fix removes the obstacle
Smallest useful test	Deliver a manual weekly summary	Observe customers using a revised setup flow
Work displaced	Time improving the existing customer experience	Time exploring a possible new use case

The table does not automatically pick a winner. It makes the comparison explicit. Reporting may deserve a small test while onboarding receives the larger commitment.

Avoid comparing a vivid new opportunity with a vague description of existing work. Describe both with similar care, including what remains uncertain about each.

Preserve Optionality With a Smaller Test

Optionality is the value of retaining useful choices. A limited experiment can preserve the option to pursue an idea while reducing the cost of abandoning it.

For the agency startup, the first test might be manually preparing a weekly client summary using information the agency already has. No dashboard is required yet.

The test should answer a defined question: does the output fit a recurring workflow well enough that agencies actually use it?

Useful observations include whether participating agencies send the summary to clients, request it again, and can provide the necessary inputs without extensive help. Compliments alone offer weaker evidence of recurring use.

Set a limit on the trial's duration and the team's effort. Also record what the manual version cannot establish. A founder personally assembling reports might conceal difficult data integration or ongoing support needs. Success at the manual stage justifies investigating those issues; it does not prove the finished product will work.

The smallest test is not always the best test. If it removes the very friction you need to understand, it can mislead you. Preserve enough of the real workflow to learn something useful.

Write the Decision Rules Before Results Arrive

Confirmation bias makes supporting evidence easier to notice and contradictory evidence easier to explain away. A founder who wants reporting to succeed may remember enthusiastic comments and discount agencies that never use the output.

Before running the trial, write what would justify the next step. For example:

Continue investigating if participating agencies use the summary repeatedly and can supply inputs without heavy assistance. Revise the idea if they value the output but the workflow is impractical. Stop this version if it receives praise but little actual use.

These are example rules for this hypothetical case, not universal thresholds. A few participants can reveal workflow problems without establishing demand across an entire market.

Keep observations separate from explanations. "Two agencies did not send the second report" is an observation. "They were probably too busy" is a possible explanation that needs checking.

Decision rules can change when you learn something relevant. Record why they changed. Otherwise, a test can become an endless process of moving the standard until the result looks positive.

Judge the Next Commitment From Here

Once work has started, the sunk cost fallacy becomes another source of bad bets. Previous effort can feel like a reason to continue even when it cannot be recovered.

Suppose the reporting trial shows that agencies like the summary but require extensive custom work each week. The founder has already designed dashboard screens and announced the direction to the team.

Neither fact establishes that a dashboard is now the best use of the next month. Ask: knowing what we know today, would we choose this next commitment over the available alternatives?

Some consequences of stopping are real future costs. Existing customer obligations, migration work, or disruption deserve consideration. Distinguish those consequences from the discomfort of admitting that earlier effort will not produce the intended result.

The evidence might support narrowing the product, trying another workflow, or returning attention to onboarding. Stopping one version of an idea does not require deciding that the entire problem is unimportant.

Make the Next Bet Easier to Evaluate

Before your next substantial commitment, write a short note covering the goal, critical assumption, likely failure path, best alternative, smallest useful test, and evidence needed to continue.

Review it after the experiment. Compare what happened with what you expected, including assumptions that proved wrong. This makes the next decision more informed and gives the team a shared explanation for changing course.

Mental models are useful when they alter the size, timing, or design of a commitment. The result should be a clearer bet: one with a reason to take it, a limit on exposure, and evidence that can change the plan.

For a broader set of thinking tools you can apply to decisions like these, 100 Mental Models offers a practical next step.