# Outside View Inside View

> Forecast by comparing to similar past cases (outside view) instead of analyzing unique project details (inside view) - cures planning fallacy

- Skill: `lev-os/outside-view-inside-view` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lev-os/outside-view-inside-view`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lev-os/outside-view-inside-view/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lev-os (https://skillmd.com/u/lev-os)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/lev-os/outside-view-inside-view

---


# Outside View vs. Inside View

## Overview

Outside View vs. Inside View, developed by Daniel Kahneman and Amos Tversky, distinguishes two fundamentally different forecasting approaches. The Inside View focuses on unique details of the current case - your team's skills, specific plan, apparent challenges - and builds bottom-up estimates. The Outside View ignores unique details and asks "what happened to similar projects in the past?" - anchoring on reference class statistics before considering specifics.

The Inside View is seductive: you know your project intimately, your plan seems solid, and you can enumerate exactly why you'll succeed. But research shows the Inside View systematically produces optimistic bias - the Planning Fallacy. Kahneman's own curriculum development project predicted 18-24 months completion, but reference class data showed 40% of similar projects never finished and successful ones took 7-10 years. His project? 8 years.

The framework earned Kahneman the Nobel Prize in Economics. The cure: Start with Outside View (reference class forecasting), then adjust minimally for genuine differentiators. Base rate first, unique story second.

## When to Use

- Project timeline estimation - software development, construction, research projects
- Resource/budget forecasting - what do similar projects actually cost?
- Startup success probability - ignoring founder optimism, what's the reference class outcome?
- Hiring timeline - "we'll fill this role in 4 weeks" vs. "similar roles took 12 weeks"
- M&A integration - acquirer optimism vs. historical integration success rates
- Product launch forecasting - traction predictions vs. similar product trajectories

## The Process

### Step 1: Recognize When You're Using Inside View

Inside View is the default mode - catch yourself before committing to inside-view estimates.

**Inside View signals:**
- Bottom-up task breakdown ("add up all the pieces")
- Emphasis on plan quality and team capability
- Scenario analysis of things that could go wrong
- Confidence in "this time is different" narrative
- Ignoring or dismissing comparable projects

**Example Inside View:** "This software rewrite will take 8 months because we have: senior team (2 months), modern stack (faster), clear requirements (no scope creep), and learned from last failure."

**Trap:** Every failed project also had a convincing inside-view story.

### Step 2: Identify Reference Class of Comparable Cases

Find the category of past projects/outcomes that share structural similarity with your current case.

**Good reference classes (specific enough):**
- "Complex enterprise software rewrites by 5-10 person teams"
- "Series A fundraising for B2B SaaS in vertical markets"
- "Senior engineering hires for distributed teams in expensive markets"

**Bad reference classes (too broad/narrow):**
- ❌ "Software projects" (too broad - includes trivial bug fixes)
- ❌ "Exactly this codebase migration" (too narrow - no statistical base)

**Key question:** "What past situations share the causal structure, even if surface details differ?"

### Step 3: Gather Base Rate Data on Reference Class

Collect statistical outcomes from reference class - this is your Outside View anchor.

**Data sources:**
- Internal history (past projects at your company)
- Industry benchmarks (published research, consultancy reports)
- Expert estimation (people who've seen many examples)
- Public datasets (Standish Chaos Report for software, PitchBook for startups)

**Example data:**
- **Software rewrites:** 40% abandoned, 30% over budget/late, 30% roughly on target
- **Series A fundraising:** 10-15% of Seed-funded startups successfully raise
- **Senior engineering hires:** Median time-to-fill is 9-12 weeks

**Critical insight:** Distribution matters, not just average. Median ≠ mean when outcomes are skewed.

### Step 4: Use Reference Class Statistics as Your Baseline Forecast

Anchor your prediction on the reference class outcome distribution. This is your Outside View estimate.

**Anchoring examples:**
- **Project timeline:** Reference class median is 14 months → start at 14 months, not your inside-view 6 months
- **Startup success:** Reference class success rate is 12% → baseline probability 12%, not 80%
- **Hiring timeline:** Reference class median is 10 weeks → plan for 10 weeks, not 4

**Statistical sophistication:** Use percentiles for confidence intervals.
- **50th percentile (median):** Half of reference class finished by this point
- **80th percentile:** 80% finished by this point (conservative buffer)
- **20th percentile:** Optimistic scenario (only 20% finished this fast)

### Step 5: Adjust Minimally for Genuine Differentiating Factors

Now consider inside-view details - but only adjust if you have strong evidence of true differentiation from reference class.

**Strong differentiators (justify adjustment):**
- Prior track record in reference class (team has done this 5x before successfully)
- Structural advantages (regulatory moat competitors lack)
- Hard metrics showing early traction (retention cohorts, not vanity metrics)

**Weak differentiators (don't adjust):**
- Team quality/motivation (everyone thinks their team is above average)
- Quality of plan (failed projects also had good plans)
- Lessons learned from past failures (doesn't beat reference class statistics)

**Adjustment magnitude:** Typically 10-30% from reference class baseline, not 2-3x.

**Example:**
- **Reference class:** 14-month median for software rewrites
- **Differentiator:** Team has successfully completed 3 similar rewrites before (strong signal)
- **Adjustment:** 20% reduction → 11-month forecast (not 6 months from inside view)

### Step 6: Use Outside View to Set Realistic Expectations

Communicate forecasts with explicit reference to outside view vs. inside view gap.

**Communication template:**
1. "The inside view suggests [optimistic estimate based on plan details]"
2. "However, the reference class of [comparable projects] shows [statistical distribution]"
3. "Using outside view anchoring, realistic forecast is [reference class baseline with minimal adjustment]"
4. "Key differentiators that justify any upward adjustment: [list strong evidence only]"

**Benefits:**
- Preempts planning fallacy accusations
- Sets realistic stakeholder expectations
- Builds credibility through statistical grounding
- Forces acknowledgment of historical track record

## Example Application

**Situation:** Software team estimating migration from monolith to microservices. Inside view: 9 months. Outside view?

**Application:**
- **Step 1:** Recognize inside view - team enumerated services, estimated each, summed to 9 months
- **Step 2:** Reference class - "Monolith-to-microservices migrations by teams of 8-12 engineers"
- **Step 3:** Data gathering - internal history: 2 prior migrations took 18 and 24 months; industry reports: 70% exceed initial timeline, median 20 months
- **Step 4:** Outside view baseline - 20 months median
- **Step 5:** Adjustment - team has prior microservices experience (+) but this codebase is older/larger than previous (-) → minimal net adjustment, stick near 20 months
- **Forecast:** 18-22 months (vs. inside view 9 months)

**Outcome:** Project completed in 21 months. Outside view was accurate, inside view would have caused major expectation misalignment.

## Example Application 2

**Situation:** Founder pitching "we'll reach $10M ARR in 18 months based on our growth model."

**Application:**
- **Inside View:** Founder's financial model shows viral coefficient × conversion rate × pricing = $10M
- **Outside View analysis:**
  - Reference class: "B2B SaaS startups in first 3 years"
  - Base rate: ~2% reach $10M ARR by year 3
  - Current stage: $200K ARR
  - **Question:** What percentage of companies at $200K ARR reach $10M in next 18 months?
  - **Answer:** <1% (extremely rare)
- **Adjustment:** Founder has strong retention cohorts (80% month 3), prior successful exit - raises probability to ~5-8%
- **Reality check:** 5-8% >> 2% base rate, but <<< 95% founder confidence

**Result:** VC passes or prices round for high risk. Founder recalibrates expectations, extends runway plan.

## Anti-Patterns

- ❌ Dismissing outside view because "our situation is unique" (it rarely is)
- ❌ Cherry-picking reference class to get desired answer (motivated reasoning)
- ❌ Over-adjusting from reference class based on weak differentiators (team quality, motivation)
- ❌ Using average instead of median when distribution is skewed (mean is misleading)
- ❌ Starting with inside view, then trying to find reference class (order matters - anchoring bias)
- ❌ Confusing "we have a plan" with "plan immunity to reference class statistics"
- ❌ Applying outside view to individual case, not category (base rate of YOU ≠ reference class)

## Related

- base-rate-analysis (outside view is base rate anchoring for project forecasting)
- planning-fallacy (bias that outside view is designed to cure)
- reference-class-forecasting (formal methodology implementing outside view)
- inside-view-bias (tendency to overweight case specifics vs. statistical patterns)
- premortem (inside view technique that complements outside view)