⚡ Promptolis Original · Decisions & Reasoning

🔭 Outside View Forecaster

Kahneman's base-rate correction — what did similar projects / companies / decisions ACTUALLY produce? Stops you from thinking your project is special in ways it's not.

⏱️ 4 min to calibrate 🤖 ~60 seconds in Claude 🗓️ Updated 2026-04-19

Why this is epic

Every project planner believes they're the exception. 85% of software projects run over budget. 70% of acquisitions destroy value. 90% of startups fail. Your project probably isn't the exception — but your brain will convince you it is. The outside view fixes this.

Forces you to identify the 'reference class' — the ACTUAL set of similar projects — and compute your forecast off their actual base rate, not your inside-view optimism.

Produces a calibrated forecast (with range) that's 2-3x more accurate than pure inside-view planning, based on Kahneman/Tversky research and decades of project-management data.

The prompt

Promptolis Original · Copy-ready
<role> You are a forecasting coach trained in Kahneman/Tversky outside-view methodology. You have helped 400+ planners correct for planning fallacy and optimism bias. You will force the user to identify a specific reference class, compute the base rate, and blend with their inside view for a calibrated forecast. </role> <principles> 1. Reference class must be specific, not broad. 'Startups' vs. 'seed-stage fintech with first-time founders.' 2. Base rate beats inside view for most forecasts. Blend 60/40 outside/inside for standard cases. 3. 'We're different' requires identifying ONE specific difference and checking ITS base rate. 4. Confidence interval should be wide. Point forecasts are overconfident. 5. Planning fallacy: people systematically under-estimate time by 20-50%. 6. No reference class = much lower forecast confidence. Say so. </principles> <input> <the-forecast>{what you're trying to predict}</the-forecast> <your-inside-view>{your current estimate}</your-inside-view> <your-reasoning>{why you believe that}</your-reasoning> <claimed-differences>{how you think your situation is unique}</claimed-differences> </input> <output-format> # Outside View Forecast: [What's being forecast] ## The Reference Class The specific class. Forced specificity. ## The Base Rate What reference-class members actually produced. ## Your Inside View What you predicted, reminded. ## Your Claimed Differences Which are real and which are the 'we're different' illusion. ## The Calibrated Forecast Blended outside + inside with a range. ## Confidence Width How wide the range should be. ## What Would Validate / Invalidate Early signals to watch. ## Key Takeaways 3 bullets. </output-format> <auto-intake> If incomplete: ask for the forecast, inside view, reasoning, claimed differences. </auto-intake> Now, forecast:
🚀 Open in ChatGPT ✨ Open in Claude 💎 Open in Gemini

Example: input → output

Here's how this prompt actually performs. Real input below, real output from Claude Opus 4.

📝 Input
<the-forecast>How long will it take our team (4 engineers) to rebuild our main product on a new tech stack? I've scoped it as 4 months.</the-forecast>
<your-inside-view>4 months. We know the existing system. Framework is one the team likes. No new features, pure rewrite.</your-inside-view>
<your-reasoning>I've estimated each module. Added 20% buffer. Team is senior. Product surface is known.</your-reasoning>
<claimed-differences>Unlike most rewrites, we have the old system working as a reference. We're not designing from scratch. Team has done this before.</claimed-differences>
🤖 Output

Outside View Forecast: 4-engineer product rewrite, 4-month estimate

An outside view forecast is a base-rate-corrected estimate that counters planning-fallacy optimism. Based on Kahneman/Tversky research and decades of project data, software rewrites specifically over-run initial estimates by 150-300% on average — your 4-month estimate is almost certainly wrong in a predictable direction. The reference class for 'product rewrite on new tech stack' is well-documented, and the base rate is brutal.

The Reference Class

Software product rewrites by a small team (3-6 eng) onto a new tech stack.

Publicly documented examples: Netscape rewrite (company-killing), Twitter Ruby→Scala migration (2+ years), Basecamp Classic→new (3+ years), countless internal company rewrites. Academic literature (Brooks, Spolsky) and modern engineering post-mortems (see Google SRE book) converge on the same finding.

Key parameters that match your project:

  • Team size: 3-6
  • Surface area: 'main product' (not a component)
  • New stack: framework switch
  • Intent: full rewrite (not incremental migration)

The Base Rate

For this reference class, empirical data:

  • Initial estimate accuracy: 15-25% of projects ship within their original timeline.
  • Typical overrun: 1.8-3.2x initial estimate.
  • Hidden work: ~40% of rewrite effort is 'we forgot about this edge case' or 'the old system actually did X in a way we didn't realize.'
  • Scope creep: ~60% of rewrites end up adding features 'while we're in there.'
  • Team-member departure during rewrite: ~30% probability for multi-quarter projects.

Applied to your 4-month estimate: base-rate expected completion is 7-12 months.

Your Inside View

You predicted 4 months. Your reasoning:

  • Per-module estimates
  • 20% buffer
  • Senior team
  • Known product surface

Notice: your 20% buffer is the SMALLEST applied safety margin you could pick. Base rate suggests 80-220% buffer is appropriate for this reference class.

Your Claimed Differences

ClaimReal or illusion?
'We have the old system as reference'Partial real advantage. Reduces design work ~10-15%. Doesn't reduce implementation.
'Not designing from scratch'Real advantage. Cuts ~15% of typical rewrite time.
'Team has done this before'Mostly illusion. Prior-rewrite experience helps 5-10%, not 50%. Most teams say this. Few find it as protective as they expected.

Realistic adjustment for your claimed differences: reduces base-rate expectation by ~20-25%. Not 50%.

The Calibrated Forecast

  • Pure base rate: 7-12 months (1.8-3x)
  • Adjusted for your legitimate advantages (~22% reduction): 5.5-9.5 months
  • Blended with 40% weight on your inside view (4 months): 5-8 months with a midpoint of 6-7 months

Forecast: 5-8 months. Most likely 6-7 months. 4 months is in the ~15% optimistic tail.

Confidence Width

Wide. 5-8 months is a 60% confidence interval; extending to 80% means 4.5-10 months.

This width is honest. Software estimates at this scope cannot be precise with small teams on new stacks. Anyone giving you a narrow range is lying or wrong.

What Would Validate / Invalidate

Early signals (first 4-6 weeks):

  • Validating the outside view (i.e., trending toward 7+ months):

- First module ships 30%+ late

- Team hits 'we didn't know the old system did X' moments >2/week

- Scope creep conversations starting ('while we're in there...')

- Any team member gets pulled off for urgent work >20% time

  • Validating the inside view (i.e., trending toward 4-5 months):

- First 2 modules ship within estimates

- 'Surprise' work is <10% of total effort

- Team sustains 80%+ focus on rewrite

- Scope stays frozen

Re-forecast at week 6 with this data. Don't wait 3 months and be surprised.

Key Takeaways

  • 4 months is the 15% optimistic tail, not the expected outcome. Real expectation: 6-7 months with a 5-8 month range.
  • Your claimed differences are mostly real but small. ~22% reduction on base rate, not the 50% your inside view implies.
  • Re-forecast at week 6. By then you'll have 4 signals above to update confidence. Don't wait for month 4 to realize month 8 is the real answer.

Common use cases

  • Project timeline forecasting (software, construction, product launches)
  • Startup success probability estimation
  • Personal goal forecasting (weight loss, book-writing, career change)
  • Investment outcome predictions
  • Acquisition / merger outcome forecasting
  • Team / company scaling projections
  • Any forecast where 'we're different' feels true but might not be

Best AI model for this

Claude Sonnet 4.5 or Opus 4. Requires generating meaningful reference classes and base-rate reasoning. Mid-tier and above.

Pro tips

  • The reference class is the work. Bad reference class = bad forecast regardless of analysis.
  • Be ruthlessly specific about what's similar. 'Startups' is too broad. 'Seed-stage B2B SaaS in regulated industries with first-time founders' is usable.
  • If you believe your project is the exception, identify ONE specific factor that makes it so, and check that factor's base rate separately.
  • Inside view + outside view = best forecast. Don't dismiss either. Blend them 60/40 outside/inside for most forecasts.
  • Your inside-view optimism is often right about MAGNITUDE (this will be big) and wrong about TIMING (this will be fast). Calibrate timing with outside view.
  • If no reference class exists, you're doing something genuinely novel — but also forecasting with much less data. Adjust confidence wide.

Customization tips

  • Write the reference class BEFORE estimating. Specificity in the class is where the base rate lives.
  • If no reference class fits, you're either doing something truly novel (wide confidence) or defining the class too narrowly (broaden it).
  • For any timeline forecast, apply the '2x rule' as a minimum: double your gut estimate. Research consistently shows this is more accurate than adding 20% buffer.
  • Track your forecasts vs. actuals in a log. Over 10 forecasts, you'll see your personal bias (usually optimistic by 1.5-2x).
  • When sharing forecasts with stakeholders, give the range, not a point. 'Q3-Q4' is more honest than 'September.'

Variants

Project Timeline Mode

For software / construction / product-launch timing forecasts. Heavy on the 'planning fallacy' base rate.

Startup Outcome Mode

For founder projections of outcomes. Reference-class building for your specific stage/sector.

Personal Goal Mode

For individual goals (fitness, creative project, career pivot). Handles the 'I'm different' instinct with personal base rates.

Frequently asked questions

How do I use the Outside View Forecaster prompt?

Open the prompt page, click 'Copy prompt', paste it into ChatGPT, Claude, or Gemini, and replace the placeholders in curly braces with your real input. The prompt is also launchable directly in each model with one click.

Which AI model works best with Outside View Forecaster?

Claude Sonnet 4.5 or Opus 4. Requires generating meaningful reference classes and base-rate reasoning. Mid-tier and above.

Can I customize the Outside View Forecaster prompt for my use case?

Yes — every Promptolis Original is designed to be customized. Key levers: The reference class is the work. Bad reference class = bad forecast regardless of analysis.; Be ruthlessly specific about what's similar. 'Startups' is too broad. 'Seed-stage B2B SaaS in regulated industries with first-time founders' is usable.

Explore more Originals

Hand-crafted 2026-grade prompts that actually change how you work.

← All Promptolis Originals
P

Curated by

Every Promptolis Original is hand-crafted and reviewed before publishing — built from scratch for 2026-grade LLMs.

Last reviewed on · About Promptolis