lev-os Orders of Magnitude
Overview
Orders of magnitude thinking is a mental model for reasoning about scale by categorizing quantities into powers of 10 (10¹, 10², 10³, etc.). Rather than seeking precise numbers, it focuses on whether something is "around 10," "around 100," or "around 1,000"—providing enough accuracy for most strategic decisions while being dramatically faster than detailed analysis.
This framework emerged from physics and engineering, where Enrico Fermi famously used it to make remarkably accurate estimates with minimal data—now known as "Fermi estimation" or "back-of-the-envelope calculations." The key insight is that being off by 2-3× in your estimates often doesn't matter, but being off by 10× (one order of magnitude) usually does.
Orders of magnitude thinking is powerful because:
- It enables rapid feasibility checks ("Is this even possible?")
- It helps prioritize by identifying what's 10-100× more important
- It catches errors where you're off by orders of magnitude (million vs. billion)
- It simplifies communication by focusing on scale, not false precision
- It works even with limited data by breaking problems into estimable chunks
Practitioners from engineers to entrepreneurs to consultants use orders of magnitude thinking to quickly assess opportunities, debug plans, and maintain perspective on what actually matters.
Key insight: Being approximately right about scale (within an order of magnitude) is far more valuable than being precisely wrong. Most strategic decisions only require knowing if something is ~10, ~100, or ~1,000.
When to Use
Apply orders of magnitude thinking in these situations:
- Feasibility checking: Is this technically/economically possible given constraints?
- Prioritization: Which opportunity is 10× larger than others?
- Sanity checking: Does this number make sense or is it off by orders of magnitude?
- Market sizing: Rough estimate of total addressable market
- Resource planning: Ballpark estimates of time, cost, or capacity needed
- Technical design: Choosing between architectures based on scale requirements
- Debugging calculations: Finding errors where you mixed up thousands vs. millions
- Communication: Expressing scale without false precision (e.g., "~$10M opportunity")
Trigger question: "What's the order of magnitude?" or "Are we talking 10, 100, or 1,000?"
Process
1. Frame the Question
Define what quantity you're trying to estimate. Be specific enough to enable decomposition.
- State the question clearly (e.g., "How many piano tuners in Chicago?")
- Identify the unit of measurement (people, dollars, items, time)
- Set the context (timeframe, geography, conditions)
- Note that you want an order of magnitude, not precision
Action: Write down the question with units and context specified.
2. Decompose Into Estimable Parts
Break the problem into smaller components where you can make educated guesses.
- Factor the problem into 2-5 sub-components
- Choose components where you have intuition or can find quick data
- Prefer multiplication structure (A × B × C) over addition when possible
- Look for reference points or benchmarks for each component
Action: Write out the formula showing how components multiply/add to get answer.
3. Estimate Each Component
Make rough estimates for each sub-component using round numbers.
Estimation techniques:
- Use powers of 10 for each estimate (10, 100, 1K, 10K, 100K, 1M, 10M, etc.)
- Draw on commonsense benchmarks (US population ~300M, year ~10M seconds)
- Use ranges if uncertain (10-100) and take geometric mean (~30)
- Don't worry about 2× errors—they often cancel out
Action: Assign order-of-magnitude values to each component.
4. Calculate the Result
Multiply or add components to get the final estimate.
- Use mental math with round numbers (300 × 400 = 120,000 ≈ 100K)
- Scientific notation helpful for large numbers (3×10⁸ × 4×10² = 1.2×10¹¹)
- Track significant figures loosely (one or two digits)
- Round to nearest order of magnitude
Action: Calculate answer and express as power of 10 or round number.
5. Sanity Check the Answer
Verify the result makes intuitive sense by comparing to known reference points.
- Does this pass the smell test?
- Compare to related quantities you know
- Check if implications are reasonable
- Look for obvious errors (mixed up thousands/millions, wrong units)
Action: State one comparison that validates your estimate's reasonableness.
6. Establish Error Bars
Acknowledge the uncertainty by stating likely range (typically ±1 order of magnitude).
- If components are uncertain, final answer is more uncertain
- Typical range: 0.3× to 3× your estimate (factor of 10 total range)
- For critical decisions, identify which components most affect uncertainty
- Note assumptions that could shift answer significantly
Action: Express answer as range: "Order of magnitude: 10⁴, likely between 3K and 30K"
7. Use for Decision Making
Apply the order of magnitude estimate to inform the decision at hand.
Decision implications:
- Same order of magnitude: Options are comparable, need detailed analysis
- 1 OOM different (10×): Strong signal about which option is better
- 2+ OOM different (100×): Decisive difference, no need for precision
- Within error bars: Too uncertain to decide, need more data
Action: State the decision or next action based on the estimate.
Example
Scenario: You're evaluating whether to build a mobile app. How many daily active users do you need to justify the $200K development cost?
Orders of magnitude in action:
Frame question: "What order of magnitude of daily active users generates $200K in value annually?"
Decompose:
- Revenue per user per year = (sessions/day) × (ads per session) × (revenue per ad) × 365 days
- Users needed = Target revenue / Revenue per user
Estimate components:
- Sessions per day per user: ~1 (order of magnitude: 10⁰)
- Ads per session: ~2 (order of magnitude: 10⁰)
- Revenue per ad (CPM model): ~$0.01 per ad view (order of magnitude: 10⁻²)
- Days per year: ~400 (order of magnitude: 10²)
- Revenue per user per year = 1 × 2 × $0.01 × 400 = $8 ≈ $10 (order of magnitude: 10¹)
Calculate:
- Users needed = $200K / $10 per user = 20,000 users
- Order of magnitude: 10⁴ users (tens of thousands)
Sanity check:
- This aligns with typical consumer apps: Instagram had 100M users before profitability (~10⁸)
- We need 0.01% of Instagram's scale, which seems achievable but not trivial
- $10/user/year for free app with ads is reasonable (Netflix is ~$200/user/year as comparison)
Error bars:
- Could be 10K if engagement is higher or ad rates improve
- Could be 100K if engagement/monetization is weaker
- Range: 10,000 - 100,000 DAU (10⁴ to 10⁵)
Decision:
- Need ~20K DAU (order of magnitude: 10⁴)
- Current product has 2K DAU (order of magnitude: 10³)
- Need 10× growth to justify $200K investment
- Decision: Don't build mobile app until we hit 10K DAU on web—we're one order of magnitude away from justifying it
Alternative use: If web DAU was 50K (still order of magnitude 10⁴ but upper end), then mobile app is justified because we're at the threshold order of magnitude.
Anti-Patterns
False precision: Claiming an answer is "37,429" when you estimated each component to one significant figure. Express as "~40K" or "order of magnitude 10⁴."
Mixing up orders of magnitude: Confusing millions with billions, or thousands with millions. This is the error orders of magnitude thinking is designed to catch—always verify the exponent.
Over-adjusting components: Making each component estimate "conservative" or "optimistic." Adjustments compound multiplicatively, throwing off the estimate by orders of magnitude.
Ignoring error accumulation: When you multiply 5 uncertain components, the final uncertainty is large. Don't treat the result as accurate.
Using orders of magnitude for decisions requiring precision: OOM thinking tells you if something is feasible or which option is 10× better, but not whether to price at $99 vs. $149.
Anchoring on first decomposition: There are multiple ways to decompose a problem. If your answer seems off, try a different decomposition approach.
Failure to sanity check: Not comparing your estimate to known reference points. This is how you catch 1,000× errors.
Treating all digits as meaningful: If you estimated components to 1 significant figure, don't report 5 digits in the final answer.
Related Frameworks
- Fermi Estimation: The formal methodology for making order of magnitude estimates, named after Enrico Fermi.
- Back-of-the-Envelope Calculation: Quick, rough estimates using orders of magnitude thinking.
- Power Laws: Understanding that many phenomena follow power law distributions where orders of magnitude differences are common.
- Log Scale Thinking: Visualizing data on logarithmic scales to compare across orders of magnitude.
- Significant Figures: Formal system for tracking precision in calculations—related to OOM thinking.
- Dimensional Analysis: Ensuring units are correct, which helps catch order of magnitude errors.
- Reference Class Forecasting: Using comparables to establish orders of magnitude for your estimate.
- Sanity Checks: Quick validation tests, often using order of magnitude reasoning.
- Sensitivity Analysis: Testing which components most affect your estimate—focus precision there.
- Approximate Computing: Computer science field that trades precision for speed using OOM-level accuracy.