Model Guide Basics

What happens when two smart people look at the same spreadsheet and still argue about what the model “means”? You usually don’t have a math problem - you have a scope problem. A model guide fixes that. It tells you exactly what the model covers, what it does not cover, and how to use it without accidentally turning it into something it was never built to do.

Leila, a 22-year-old junior analyst, keeps getting requests that sound harmless: “Can you add one more variable?” “Can we use this for a different team?” “Can you forecast next year too?” Each request changes the model’s job, even if the formula stays the same. A solid model guide gives Leila a clear boundary so she can say “yes” to the right changes and “not yet” to the rest - using the same language every time.

After this chapter, you will be able to define what a model guide is, list what it should include, and set boundaries you can defend. You will also learn how to apply those boundaries in a real work scenario, so your model stays useful instead of turning into a mystery box.

Why This Matters, How It Works, and What You’ll Be Able to Do

A model guide is a short, practical document that explains how a model works and how to use it safely. It does more than describe the model. It prevents confusion by making the model’s purpose and limits obvious - so people stop guessing. When someone asks, “Can we use this for X?” the guide gives you an answer you can point to, not a long debate.

This matters because models fail in predictable ways: people trust numbers that were never meant to answer their question, they change assumptions without realizing the impact, or they treat the model like a magic generator instead of a tool with rules. A model guide solves that by turning your model into a repeatable product. Instead of relying on your memory, you capture the decisions you already made - purpose, inputs, logic, outputs, and constraints.

Here’s the core idea: a model only helps if it matches the question. The model guide works like a map. A map does not tell you every fact about every mountain. It tells you where the paths are, what route you can take, and what you should not expect the map to cover. Your model guide does the same thing for your model’s job.

Ask yourself a simple check: when someone new opens your model, can they answer these three questions within 5 minutes - what problem it solves, what data it needs, and what it refuses to do? If you can’t, your guide needs boundaries, not extra words.

Practical takeaway / reflection prompt: Write one sentence for your current model: “This model answers __ for __.” Then write one sentence for what it does not answer. If you can’t fill both, you don’t yet have scope.

What a Model Guide Must Cover (and How to Define Boundaries)

A model guide should cover purpose, inputs, logic, outputs, and limits in plain language. The goal is not to impress anyone. The goal is to help a real person use the model correctly on the first try. For Leila, that means future requests stop turning into chaos.

Use the North Star Scope Map as your boundary tool. It forces you to pin down the model’s “north star” (the primary job) and then draw the edge of the map (what falls outside). You will write those edges in a way that you can reuse whenever someone asks for a change.

Follow these components and boundary rules:

1. State the North Star Scope (the primary job in one line).

Write: “The model estimates _ to support _ decisions.”

Why: This line stops scope creep because every feature must trace back to the same job.

Example for Leila: “The model estimates monthly staffing need to schedule shifts for the next 4 weeks.”

2. List the target user and the decision it supports.

Name the person or team who uses the result and what they do with it.

Why: The “decision” tells you what output level you need (a trend, a number, a recommendation).

Example: “Leila’s manager uses the staffing estimate to approve shift plans.”

3. Define the input set and input rules (with exact formats).

Specify what data the model accepts and how it must look: units, time range, and allowed values.

Why: Most model errors come from wrong inputs, not wrong formulas.

Example: “Use hours worked per day, measured in hours (not minutes), for the last 60 business days. If a day has no data, mark it as missing, not zero.”

4. Explain the logic at the “human level,” then point to the model sections.

Describe what the model does in steps (not every formula) and tell where each step lives in the file.

Why: People need a mental model to debug issues and to request the right changes.

Example: “Step A calculates baseline demand from last 60 days. Step B adjusts for known events (training days). Step C converts demand into headcount using a 30-day staffing conversion.”

5....