Build a Minimum Model

On a sunny afternoon at a university decades ago, a professor challenged his students with a puzzle: How many piano tuners are there in Chicago? The class was baffled - who would know such a thing? One student shrugged and said, “I’d guess maybe 50?” Another ventured, “I heard of at least 2 or 3 big companies, maybe 100 tuners?” The professor smiled and said, “Let’s model it. How many people live in Chicago? How many households might have a piano? How often does a piano need tuning?” The students threw out rough numbers: perhaps 3 million people, one in 50 households has a piano, so 60,000 pianos; maybe each piano gets tuned once a year; one tuner can handle, say, 4 tunings a day for 250 working days = 1000 tunings a year. Divide 60,000 by 1,000, you get about 60 piano tuners. The class was astonished. They had just built a simple model to estimate something seemingly unknowable. The exact number wasn’t the point - the method was. By breaking the question into a few key variables and using rough averages, the professor’s model yielded a reasonable answer quickly. This approach, pioneered by physicist Enrico Fermi, shows that even the most complex questions can be tamed with a minimal model. You don’t need perfect data or fancy math - just the courage to pick a few critical factors and do back - of - envelope math. In work and life, building a tiny model helps you see the forest from the trees and guides better decisions when intuition alone might mislead.

Identify the few factors that matter most. Every outcome is influenced by numerous variables, but often a small subset drives the lion’s share of the result. The art of modeling is choosing those few and ignoring the rest (at least initially). Start by asking: What are the primary inputs to the outcome I care about? If you’re looking at sales revenue, it might be (1) number of customers, (2) average purchase size, and (3) purchase frequency. If you’re estimating a project timeline, perhaps (1) number of tasks, (2) average task duration, (3) number of people working concurrently. List out the potential variables and then circle the ones you suspect have meaningful impact. Often, you can group or merge some factors. For instance, instead of separately considering every marketing channel, you might use “website visitors” as one aggregate variable. The key is to be inclusive enough that your model captures reality in broad strokes, but exclusive enough that the model stays simple. A helpful thought: If I could only know three numbers about this situation, which would I choose? Those three are likely your core variables. Everything else - while it may have some effect - can be treated as constant or lumped into an average for now. By zeroing in on the smallest set of drivers, you set yourself up to model without over - complicating. Remember, you’re aiming for a first - pass understanding, not a detailed simulation. A minimal model is often a single equation or a tiny table that anyone can grasp. That clarity is powerful. It forces you to articulate how you believe the world works in this scenario, and it’s easier to refine a simple model than a bloated one. Plus, you avoid “paralysis by analysis” that comes from trying to factor in every nuance. Focus on the big levers; you can add detail later if needed.

Choose a model shape that fits the problem. Not every scenario needs a spreadsheet full of formulas. Sometimes the right model is a rate equation, sometimes it’s a checklist, other times a decision tree. How do you pick? Think about the nature of the problem. If the outcome is something quantitative that clearly multiplies factors, use a simple equation. Our piano tuner example was a multiplication model (pianos × tunings per piano / tunings per tuner). Many business outcomes (like revenue = volume × price) fall here. If the problem is more about sequential steps or conditions (“if X then Y”), a decision tree might serve: for example, hiring decisions might branch on “if candidate passes skill test go to interview, if not, reject.” And if the problem is about ensuring all critical elements are covered (not predicting a number but achieving an outcome), a checklist model could be best: for instance, a launch readiness checklist with items to ensure success. The word “model” might conjure images of math, but a model is really any simplified representation of reality that helps you reason. A checklist is a model of a process - each item stands for an important component that must be present for success. A decision tree is a model of how choices lead to outcomes. For quantifiable questions, a few variables multiplied or added might suffice, like a budgeting model (income minus expenses). Choose the form that makes the problem easiest to think about. A good hint: if you can explain your reasoning to someone in plain language, what form does it take? “First this, then that” suggests a tree or stepwise list. “These things combine to produce result” suggests an equation. And don’t over - engineer it: a model with two or three elements can be enough to start. The shape of the model should mirror the shape of the problem. For instance, if uncertainty is a big factor, maybe a simple scenario table (best/base/worst) is your model. If priority is the challenge, maybe it’s a weighted scoring system. There’s no one right model type - choose the one that clarifies rather than complicates.

Assign ballpark values and see where you land. Once you have your model structure (the variables and how they relate), plug in some numbers. Use ranges rather than exact figures to reflect uncertainty. For each variable, ask: What’s a low plausible value? What’s a high plausible value? For example, if one variable is “conversion rate of website visitors to buyers,” maybe you estimate a low of 1% and a high of 5%, based on your past data or industry typicals. Then compute the outcome for a low case (using all low values), a base case (using your best - guess or average values), and a high case (using high values). This gives you a range of outcomes rather than a single number. Visualize these as three scenarios: perhaps in the low case your project would take 12 months, base case 9 months, high (optimistic) case 6 months. Or in financial terms, low case profit is $0 (break - even), base case $50k, high case $100k. Seeing the spread helps you understand the uncertainty you’re dealing with. If the range is very wide, you know not to bank on the base case as guaranteed; you might plan conservatively near the low end or work to narrow the uncertainty by gathering more data. Conversely, if all scenarios cluster tightly, you can be more confident. Writing down these ranges also has a calming effect: it turns ambiguous risk into something you can grasp. “There’s a chance we only break even” is more informative (and less scary in a way) than a vague “This might not work.” You’ve quantified the uncertainty. And if the high case looks very attractive, you might decide it’s worth the gamble or see what needs to happen to achieve it. The act of assigning values often forces you to confront what you know versus assume. You might realize you have no idea what a realistic high value is for a variable - time to do a quick research or use a reference point. It’s okay to guess initially, just mark that as an area to improve later. The outcome of this modeling step is that you now have three numbers summarizing your model’s implication. That’s far more useful than innumerable possibilities swirling in your head.

Test your model’s sensitivity to each factor. Now that you have a working mini - model and some numbers, ask: which variable matters the most? You can find out by a simple sensitivity test: tweak one variable at a time (say, double it and halve it) and see how much the outcome changes. Do this one - by - one for each factor while holding the others at their base values. For example, if your model outcome is projected monthly sales = visitors × conversion rate × average order value, try doubling the visitors (while conversion and order value stay base) and see the new sales number; then reset and instead double the conversion rate; then do the same for order value. If doubling a variable causes a huge jump in outcome relative to others, that variable is a major driver. If halving another variable barely dents the outcome, that one is less critical or perhaps currently at a benign level. In our hypothetical, you might find that doubling conversion rate from, say, 2% to 4% yields a bigger sales boost than doubling visitors (because maybe your current visitor count is large but conversion is low). Or vice versa, maybe traffic is the limiting factor. This tells you where to focus efforts and what assumptions are worth refining. Sensitivity analysis is like shining a flashlight on each part of a dark room to see what moves. One factor might reveal itself to have an outsized effect - your “lever.” Another might show diminishing returns, meaning pushing it further yields little benefit. For instance, if conversion is already high, focusing on it may not improve much, whereas small increases in visitors could multiply sales significantly. Identify which single factor moves the needle most when changed. This doesn’t mean you ignore the rest, but it highlights where your priorities should lie. If time is short or resources limited, concentrate on boosting or protecting the sensitive variable. Additionally, if any factor barely changes outcome, you can safely simplify your model by treating that factor as fixed or negligible. Sensitivity testing basically validates that you chose the right “minimum” variables - maybe you included one that doesn’t matter much and can drop it, or realize another factor you left out is actually important because these results feel off without it.

Articulate your model in plain language. A check on whether your model truly makes sense is if you can explain it in one sentence, like a simple formula in words. For example, you might say: “Our weekly sales come from the number of site visitors, how many of those visitors sign up, and how much each paying user spends.” That’s a plain language model: outcome = volume × conversion × value per user. Then you can attach your numbers: “Right now, we get about 10,000 visitors (volume) a week, about 5% convert to a purchase (conversion), and each paying customer spends about $30 (value). Multiply those: 10,000 × 0.05 × $30 gives $15,000 sales a week.” That’s your base case. It’s straightforward enough that everyone from the intern to the CEO could follow. This way of communicating the model ensures that if you made a wrong assumption, it’s likely someone will catch it and say, “Wait, are we sure about that 5%? Last month it was closer to 3%.” It promotes clarity and alignment. It also invites constructive discussion: Which term can we improve most easily? Maybe marketing can drive visitors from 10k to 15k, or product can optimize conversion from 5% to 7%. Laying it out like Outcome = A × B × C demystifies performance drivers. Another example: if modeling a project timeline, you could say, “Completion time = number of tasks × average days per task / number of tasks done in parallel.” Plugging numbers: “We have ~20 tasks, each takes ~2 days, but we can only do 2 at a time, so roughly (20×2)/2 = 20 days to finish.” Expressing it simply exposes the logic and makes it easier to adjust or justify. It also grounds discussions in facts rather than gut feel. If someone questions your plan, you can respond with, “Here’s how I’m thinking about it: we assume X leads to Y. Does that match your understanding?” This can catch any miscommunication early. Ultimately, a model you can phrase in everyday language is one you truly understand. It’s a healthy antidote to overly complex plans that no one really grasps but all pretend to. And when things change, you can update the model just as straightforwardly, e.g., “If visitors drop by 20%, sales should drop similarly unless we boost conversion.” It becomes a shared mental model for the team.

Guard against false precision and complexity creep. As you use your model, keep an eye out for pitfalls. One big red flag is overfitting to a single story or datapoint. That’s when you tailor your model so specifically to one case that it doesn’t generalize. For instance, suppose in one lucky month sales spiked when you tried a social media campaign, and you hastily add “social media buzz factor” as a key variable in your model. If that was a one - time fluke or not well - understood, you risk building yourmodel around noise rather than signal. Resist the temptation to incorporate every anecdote or outlier into your framework. Instead, focus on consistent patterns and factors you can justify logically. Another caution: don’t add variables you can’t reliably measure or influence. If your model includes “team morale index” but you have no way to quantify that, it will only give a false sense of rigor. Keep such factors qualitative or find a proxy (like turnover rate or voluntary overtime) if you must include them. Finally, beware of treating your base - case number as certain. A point estimate is not reality; it’s one scenario. It’s easy to unconsciously start planning as if the base case will definitely happen (“We forecast $15,000 weekly sales, so let’s spend against that”). Always remember the ranges and the uncertainty. Treat the single - number output as a guide, not gospel. This humility saves you from nasty surprises. A good practice is to always mention the range: “We expect $12k - $18k, with $15k as the most likely.” It signals that you know the model is an approximation. When you communicate models this way, you appear more credible and thoughtful, and you prepare stakeholders for both upsides and downsides.

Put your model into practice with a small exercise. Take a real decision or project you’re working on and sketch a half - page model for it. Identify those key variables and relationships - maybe it’s as simple as Outcome = X × Y, or a bulleted checklist of things that need to go right. Plug in your best - guess numbers and compute the base case. Now ask yourself: if the most sensitive variable (the lever you identified) improved by 20%, what would you do differently? For instance, if your model says timeline = tasks/people, and adding one more person (effectively a 20% team boost) would finish the project a month earlier, would you hire a contractor? Or if increasing conversion by 20% would double your profit in the sales model, maybe you should invest heavily in conversion tactics. Writing down that one decision or change you’d make if the top lever improved forces you to consider where to focus. Even if you can’t magically improve that lever by 20% overnight, this thought experiment highlights your priority area. It might prompt you to reallocate resources: perhaps shift 10% of your team’s effort from something with low impact to the area that drives your model. Over time, as you refine the model with real data, you’ll gain confidence in where to double down or when to pivot. The beauty of a minimum model is that it’s quick to adjust. You can revisit it whenever something significant changes, update a few numbers, and see the new picture. It becomes a living tool, not a static prediction. You’ll start making model - thinking a habit: before jumping into any project or decision, you’ll outline the rough equation or checklist in your mind or on paper, ensuring you consider the fundamentals. And when someone asks, “Why do you think this will work?” you’ll have a logical explanation ready, not just “gut feeling.” That calm clarity is persuasive and grounding.

With a tiny model in hand, you’ve taken a big step toward first - principles decision - making. You’ve shown that you don’t need a mountain of data or a complex simulation to reason well; a few well - chosen numbers and relationships can illuminate the path. Remember how our professor estimated piano tuners with just a handful of assumptions? You can do the same for budgets, timelines, or any unkowns you face. A minimal model strips away the fog of uncertainty and gives you a compass heading. It’s not infallible, but it’s far better than flying blind or being swayed by the last story you heard. As you communicate these models, you’ll also find your colleagues trust your reasoning - they can see the logic rather than just take your word for it. Now that you know how to create clarity from complexity on paper, let’s turn to tools that create clarity in action and communication. In the next chapter, we’ll explore checklists, scripts, and shared language - simple aids that ensure your great thinking actually gets used consistently by you and your team.