Base Rates Before Stories

A project manager is excitedly proposing a new timeline for a complex project: “I think we can do it in two months,” she announces. The room gets quiet; a couple of team members exchange glances. Finally, someone asks, “How long did projects like this take in the past?” The manager pauses. The truth is, the last three similar projects each took about four months, not two. But in her enthusiasm, she focused on one example where a team somewhere reportedly did it in half the time. This is a classic trap: letting a compelling story or optimistic scenario override the base rate - the track record of similar cases. We humans love stories; they stir our imagination and hope. But when making predictions or forecasts, stories can lead us astray if we ignore the data of history. Base rates are like the statistical baseline, the average experience drawn from a relevant reference class of cases. They are boring compared to exciting stories of exceptional success or failure, but they are powerful predictors. In decision science, one mantra stands out: Always start with the base rate, then adjust for specifics. Doing so grounds your expectations in reality before optimism or pessimism sway you.

Define your reference class and get the numbers. The first step in using base rates is deciding what category of past cases truly resemble your current case. This is called the reference class. It might be “software projects adding a major feature” if you’re forecasting a product timeline, or “candidates like this hire in our company” if predicting a new hire’s ramp - up time. Aim for a group of at least a few (ideally 5 - 10) comparable instances. If you only have one or two, they’re less reliable - maybe broaden slightly or use industry data. Once you have the reference class, find out the outcomes of those cases. What was the average result, and how much did it vary? For example, say you gather data on five recent similar product launches and find the average delay beyond initial schedule was 30%, with one finishing early and one 50% late (that’s the variance). That average (30% delay) is your base rate for schedule slip. Or imagine you’re estimating how many users will adopt a new feature: you look at three past feature launches and see 20%, 25%, 15% of users adopted within a month - average ~20%, with some variance. Now you have a concrete starting point, not just a gut feeling. Document these base rates explicitly: “In the last 5 projects of this type, 4 out of 5 took between 3 and 5 months, with an average of 4.” Or “Historically, about 1 in 4 trial users convert to paid customers in our SaaS product.” Writing this down forces clarity and gives everyone a dose of reality. Even if the number isn’t what you hoped (maybe your gut wanted to promise 2 months, but base rate says 4), it’s better to confront that now. If you truly believe your case is different, you’ll justify that next - but base rates ensure you’re not conjuring predictions from thin air.

Anchor your forecast to the outside view. The base rate is often called the “outside view” - it’s how an outsider, knowing nothing about your specific case except that it’s part of a category, would predict it. This outside perspective is surprisingly accurate in many domains, often more so than insiders’ detailed analyses. So, start with that outside view as your baseline. For example, you might say to the team (or to yourself), “Typically, projects like this take about 4 months. So let’s assume 4 months as our starting estimate.” This anchoring to data does a few things: it tempers unwarranted optimism (and also excessive pessimism if the base rate is better than you feared), and it sets a common reference that’s objective. People may still argue that “we can do better this time,” but now they know what “better” means relative to something real. One study trick often cited: when asked to predict something, first ask “what’s the average outcome in situations like this?” It’s remarkable how that simple step improves accuracy. Most of us naturally tend to the “inside view” - focusing on the specifics of our case, which can blind us to the statistical baseline. By deliberately anchoring to the base rate, you correct that bias upfront. Think of it as gravity pulling your estimate to earth. If you want to deviate (fly higher or lower), you’ll need some thrust in the form of evidence. That’s exactly the next step: adjusting intelligently. But commit to never skipping this phase. Even if your reference class data has limitations, a rough base rate is usually better than pure intuition. And if someone challenges, “Why 4 months? I think 2 is enough,” you have something solid to discuss: “Because that’s what similar cases have done. What evidence do we have that we’re significantly different?” This shifts debate from opinions to a fact - based adjustment.

Adjust for case - specific factors with discipline. Once you have the base rate, you consider your particular case’s unique factors and adjust up or down. But do this explicitly and sparingly. Write down the reason for each adjustment and estimate the size of its impact. For instance: “Our team is more experienced than the past average team, so maybe we can be 15% faster - adjusting timeline down a bit. However, we have a new dependency on an external API which others didn’t - that could slow us by 10%.” Net effect: maybe you argue for an overall ~5% faster than base rate, not 50% faster. Be wary of piling on optimistic adjustments that magically turn a tough baseline into a rosy outcome. A good rule of thumb: cap your adjustments unless there’s strong evidence. For example, decide not to adjust more than, say, 20 - 25% from the base unless you have data that justifies it (like a metric from a pilot or a truly game - changing factor). This prevents the common drift where people list five reasons this project will be the exception and end up forecasting something way outside historical bounds. It’s not that exceptions never happen, but they’re called exceptions for a reason. Also, challenge yourself to include downside adjustments, not only upsides. We’re psychologically prone to focus on why we’ll do better than average (“our star new hire will boost productivity!”). But ask, “Is there anything that could make us do worse than average?” Perhaps the technology is new to you, or parallel projects could distract the team. Include those too. Document each like: “+15% speed: team experience; - 10% speed: external API dependency; net +5%.” Now your final forecast might be “about 4 months minus 5% ≈ 3.8 months”. Keep the logic transparent. If someone says, “I think the external dependency risk is bigger, maybe - 20%,” you can debate that and adjust. The key is the adjustment is reasoned, not just “I have a feeling we could do 2 months.” And don’t let adjustments multiply without evidence - if you find you’re making a huge swing from the base rate, double - check if you’re falling back into wishful thinking. Sometimes, showing the unadjusted base rate and then each tweak helps everyone see how far from reality they’re wandering. An anchored adjustment approach often yields a more moderate and achievable prediction than the initial gut number, which is exactly the point: avoiding overconfidence.

Gather base rate data systematically. To make this process easier over time, start building your own small repository of base rates for things your team or company does often. It could be as simple as a spreadsheet or shared doc where after each project you record actual outcomes (duration, cost, ROI, whatever metric matters) along with a short description. Over months and years, you accumulate an internal benchmark database. For example, log every hiring process: how long to fill the position, and after six months how is the hire performing? Patterns emerge (“It takes on average 8 weeks to fill a role like X,” or “Our trial - to - paid conversion historically is 10 - 15% regardless of quarter”). Even a dozen data points can make future predictions far better. If internal data is scarce (especially for new kinds of decisions), look outward: industry reports, public benchmarks, or ask peers in other companies. Document the source and context of any external base rate you use. For example, according to Gartner, “60% of enterprises see at least a 3 - month delay in ERP implementations.” If you use that as a base, note it. And of course, adjust for context difference (maybe you’re smaller scale, so you adjust timeline shorter, but modestly). Another approach: conduct a quick expert survey by asking a few people who have done similar things for their outcomes. The average of expert estimates can serve as a base rate too. The key is to treat base rate collection as part of your decision hygiene. It’s like having vital signs recorded so you know what “normal” is. When you present a plan, include base rate info prominently: “Typically, X yields Y. We are planning for slightly above - average Y due to Z.” It shows you did your homework. Also, keep track after making your forecast: log what you predicted vs what happened. This helps calibrate you over time. If you consistently see optimism (actual outcomes worse than forecast), you’ll learn to adjust differently next time. Creating a culture of base rate awareness means decisions become less about persuasive storytelling and more about evidence - backed projections. It doesn’t kill creativity; it just grounds it with an anchor in reality.

Avoid the seduction of single anecdotes. People often counter base rates with “but I heard about this one time that…” Indeed, stories of spectacular success or failure get a lot of attention. “That startup that launched in 6 weeks and went viral” or “So - and - so hired someone in two days and it was a perfect fit.” These anecdotes are fine to consider, but don’t treat them as data unless they’re part of a set. Cherry - picking best cases (or worst cases) will skew your expectation. Remind yourself and others that extremes are extremes; that’s why they’re notable. If someone says, “Company X finished similar work in half the time,” respond with, “Interesting, were there other companies we know of? How long did they take?” Maybe you find Company X was an outlier and most took average time. The base rate principle isn’t to ignore unique factors or ignore that sometimes you can beat the odds - it’s to ensure you consciously acknowledge the odds to begin with. Another danger is ignoring variance. Base rate gives an average, but also note the spread. If outcomes vary a lot, acknowledge that in forecasts (maybe use ranges or incorporate risk factors). For example, if past projects ranged from 3 to 6 months, even if average 4, it means there’s considerable uncertainty. Plan with that in mind (maybe have contingency plans if things go into month 5 or 6). And if you do aim for an aggressive target, at least know it falls at, say, the 90th percentile of speed historically - meaning you’re trying to be among the top 10% fastest. That should prompt a conversation: “What will we do to be in that top 10%? Are we comfortable betting on that level of performance?” It might be fine if you have backup plans, but everyone should be clear that it’s a stretch relative to base rates. Using base rates doesn’t mean being mediocre; it means being honest about what typical looks like, so when you reach for extraordinary you do it with eyes open and a plan B.

Use base rates in all sorts of decisions. This concept isn’t just for timelines and budgets. It applies broadly: If you’re making a hiring decision, base rates might be “On average, 1 out of 3 hires in this role quit within a year - how can we tell if this candidate will stick?” If you’re deciding on entering a new market, base rate could be “Historically, 50% of companies fail to gain traction in a new geographic market - given those odds, what makes us different or how cautious should we be?” When making personal financial decisions, look at base rates like “most actively managed funds underperform index funds over a decade” or “the average return of this type of investment is X% with Y volatility.” If planning an event, ask how often such events run over budget or under - attended. It’s a mindset of consulting reality first, narrative second. Even in creative endeavors, it helps. An author might want to skip professional editing to publish quickly - base rate of success for unedited first drafts is low; knowing that, they might reconsider. Combining base rates with first principles (from earlier part) is powerful: question unique assumptions but start from common experience. For instance, if base rate of something is poor but you think you can buck the trend due to a new approach, articulate why specifically in light of base rate. Perhaps you have a superior technology or a partner that gives an edge. That’s fine - just quantify how much of an edge you think it provides and see if that moves you solidly above average or just marginally. If it’s marginal, maybe the risk isn’t worth it.

Consider an example with numbers: You’re about to launch a new consumer product. You ask, what’s the base rate success for new consumer products in our industry? Perhaps you find only 30% reach even 10,000 users in their first year (i.e., 70% flop or stay niche). That’s sobering. You believe you have a better marketing strategy, so you might adjust that your chance is higher - maybe you say 50% chance to hit 10k users (still basically a coin flip). Now when planning, you might set up two tracks: one plan assuming success, and a contingency if by 6 months it’s not trending well (perhaps pivot or cut losses). Without base rates, you might have gone in assuming near 100% chance of big success (after all, you love your product) and spent money accordingly. The base rate grounds you, instilling a more balanced optimism and a fallback plan.

Quick practice: apply a base rate to a decision now. Think of one decision or forecast you have to make, big or small. Take 5 minutes to find a base rate or reference data. If it’s a personal decision like learning a new skill, maybe the base rate is how long it typically takes people to get competent. If it’s something at work, recall or gather outcomes of similar efforts. Write down that outside - view prediction (even if it’s just from memory - e.g., “last three times we tried to implement software, two succeeded, one failed after 1 year”). Now, make your prediction, explicitly starting from that base: “Given typical success is 2 out of 3, and considering our strong team (maybe that nudges us up a bit), I’ll forecast about 80% chance we succeed.” Or if you’re estimating time: “Base rate average is 4 weeks; I think we’re slightly simpler case so maybe 3 weeks, but certainly not 1 week.” Write it as “Base: X, Adjust: Y, Therefore: Z.” Finally, log it somewhere or communicate it along with your reasoning. Over time, revisit these logs and see how you did. The act of using base rates will gradually calibrate your intuition as well - you’ll start internalizing the real odds and durations, making you a far more reliable predictor than the average person swayed by optimistic planning. People around you will notice that your plans tend to be realistic and your bets well - informed. That reputation is gold; it means when you do go out on a limb, they’ll know you have good reason. Next time someone excitedly says, “I have a feeling this will break all records,” you might gently reply, “Maybe, but base rates suggest a more moderate outcome - let’s prepare for both.” That’s the essence of thinking with base rates: hopeful but not in denial, cautious but not cynical.

With the base - rate habit, you’ve armed yourself against one of the most common decision - making pitfalls: the lure of the anecdote and the trap of the rosy scenario. You’ve seen how anchoring in data from the past can drastically improve how you foresee the future. This doesn’t make decisions trivial or always correct, but it sets a strong foundation. Now that you’re anchored in reality, it’s time to discuss how to explicitly handle uncertainty and talk about it. In the next chapter, we’ll put those base rates to use by converting them into plain - language probabilities and ranges, so you and your team have a shared, concrete sense of risk and likelihood, rather than vague terms that often lead to miscommunication.