name

problem-decomposition-mastery-skill

description

Master problem decomposition for complex challenges. Use for MECE analysis, tree analysis, root cause identification, dependency mapping, work breakdown structure (WBS), divide-and-conquer strategies, and systematic problem breakdown. This is a META-SKILL that amplifies problem-solving (1.4x multiplier). Also use for Thai keywords "แยกปัญหา", "แบ่งปัญหา", "วิเคราะห์ปัญหา", "แก้ปัญหา", "ปัญหาซับซ้อน", "MECE", "หาสาเหตุ", "root cause", "แยกประเด็น", "วิเคราะห์เชิงลึก", "ลดความซับซ้อน", "แบ่งงาน", "WBS", "dependency", "ความสัมพันธ์", "ข้อจำกัด". Also use for English keywords "problem decomposition", "break down problem", "MECE", "tree analysis", "root cause analysis", "5 whys", "fishbone", "dependency mapping", "work breakdown", "WBS", "divide and conquer", "complexity reduction", "systematic analysis", "analytical thinking".

Problem Decomposition Mastery: The Art of Breaking Down Complexity

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one." — Mark Twain

Why This Meta-Skill Exists

Problem: Most people fail to solve complex problems not because they lack intelligence, but because they try to solve the entire problem at once.

Result:

Paralysis by analysis
Overwhelmed by complexity
Miss critical dependencies
Solve symptoms instead of root causes
Incomplete or wrong solutions

Solution: Problem Decomposition

Break down complex problems into:

Manageable pieces (smaller, easier to solve)
Independent components (solve in parallel)
Dependency chains (solve in correct order)
Root causes (solve once, fix many)
Modular solutions (reusable, testable, maintainable)

Power Multiplier: 1.4x

This meta-skill multiplies effectiveness of ALL problem-solving skills by 40%:

Faster solutions (break down → parallelize)
Better solutions (understand structure → optimize correctly)
Fewer bugs (modular → easier to test)
Easier maintenance (clear structure → easier to modify)

Example:

Without decomposition:

# Problem: "Build an e-commerce platform"
# Approach: Start coding everything at once
# Result: 6 months, spaghetti code, 50% features work ❌

With decomposition:

# Problem: "Build an e-commerce platform"
# Step 1: Decompose into modules
modules = [
    "User authentication",
    "Product catalog",
    "Shopping cart",
    "Payment processing",
    "Order management",
    "Admin dashboard"
]

# Step 2: Identify dependencies
dependencies = {
    "Shopping cart": ["User auth", "Product catalog"],
    "Payment": ["Shopping cart"],
    "Order management": ["Payment"],
    "Admin": ["All modules"]
}

# Step 3: Solve in correct order (bottom-up)
order = ["User auth", "Product catalog", "Shopping cart", "Payment", "Order mgmt", "Admin"]

# Result: 3 months, clean modular code, 100% features work ✅
# Time saved: 50% (due to parallelization + fewer bugs)

This is decomposition power: 2x faster, 2x better quality.

Meta-Skill Structure

This skill contains 12 decomposition frameworks:

Part 1: Core Frameworks (4 frameworks)

MECE Decomposition - Mutually Exclusive, Collectively Exhaustive
Tree Analysis - Hierarchical breakdown
Process Decomposition - Sequential flow mapping
Root Cause Analysis - 5 Whys & Fishbone

Part 2: Domain-Specific Frameworks (4 frameworks)

Code Decomposition - Software architecture breakdown
Business Problem Decomposition - Strategic analysis
System Decomposition - Component & interaction mapping
Data Flow Decomposition - Information flow analysis

Part 3: Advanced Techniques (4 frameworks)

Dependency Mapping - Critical path & blocking analysis
Constraint Identification - Bottleneck & limitation discovery
Work Breakdown Structure (WBS) - Project task decomposition
Solution Space Mapping - Explore all possible solutions

Each framework follows this structure:

Definition - What it is and when to use it
Core Principle - The fundamental concept
Step-by-Step Method - How to apply it
Examples - Real-world applications (code, business, systems)
Practice Exercise - Hands-on problem with solution
Common Mistakes - What to avoid
Cross-References - How it connects to other frameworks

How to Use This Skill

Step 1: Identify Problem Type

problem_types = {
    "Unknown structure": "Use MECE or Tree Analysis",
    "Sequential process": "Use Process Decomposition",
    "Something's broken": "Use Root Cause Analysis",
    "Complex system": "Use System Decomposition",
    "Overwhelming task": "Use WBS",
    "Don't know where to start": "Use Solution Space Mapping"
}

Step 2: Apply Framework

Follow step-by-step method
Generate decomposition tree/map
Validate completeness (no gaps)
Validate independence (no overlaps)

Step 3: Solve Components

Identify dependencies → solve in order
Parallelize independent components
Use other skills to solve each piece

Step 4: Integrate Solutions

Combine component solutions
Test integration points
Validate complete solution

Step 5: Iterate if Needed

If solution incomplete → re-decompose
If new insights → refine decomposition
If complexity remains → apply different framework

Part 1: Core Frameworks

Framework #1: MECE Decomposition

Mutually Exclusive, Collectively Exhaustive

Definition

MECE (pronounced "ME-see") is a principle for breaking down information into categories that:

Mutually Exclusive: No overlaps between categories (each item belongs to exactly ONE category)
Collectively Exhaustive: No gaps (EVERY possible item is covered by some category)

Invented by: McKinsey & Company consultants Used for: Strategy consulting, business analysis, decision-making

Core Principle

"If your buckets don't overlap and they catch everything, you've understood the problem space completely."

Why MECE matters:

Ensures completeness - You don't miss anything important
Prevents redundancy - You don't double-count or duplicate work
Enables clear communication - Everyone understands the structure
Facilitates analysis - You can measure and compare categories

Mathematical Representation:

# Categories C1, C2, ..., Cn are MECE if:
# 1. Mutually Exclusive: Ci ∩ Cj = ∅ for all i ≠ j (no overlaps)
# 2. Collectively Exhaustive: C1 ∪ C2 ∪ ... ∪ Cn = Universe (covers everything)

Step-by-Step Method

Step 1: Define the problem space

problem = "What are ALL possible customer segments for our product?"
universe = "All potential customers"

Step 2: Choose a dimension

# Dimension: How you split the universe
dimensions = [
    "Demographics: Age, gender, income, location",
    "Behavior: Usage frequency, spending level",
    "Needs: What problem they're solving",
    "Channel: Where they found us"
]
# Pick ONE dimension at a time

Step 3: Create categories

# Example: Age dimension
categories = {
    "18-25": "Young adults",
    "26-40": "Prime working age",
    "41-60": "Established professionals",
    "60+": "Retirees"
}

# Check MECE:
# Mutually Exclusive? YES - no age is in 2 categories ✅
# Collectively Exhaustive? NO - missing 0-17! ❌

# Fixed:
categories_fixed = {
    "0-17": "Minors",
    "18-25": "Young adults",
    "26-40": "Prime working age",
    "41-60": "Established professionals",
    "60+": "Retirees"
}
# Now MECE! ✅

Step 4: Validate MECE

def validate_mece(categories, universe):
    # Test 1: Mutually Exclusive
    for c1 in categories:
        for c2 in categories:
            if c1 != c2:
                overlap = c1.intersection(c2)
                if overlap:
                    return f"NOT MECE: {c1} and {c2} overlap"

    # Test 2: Collectively Exhaustive
    union = set()
    for c in categories:
        union = union.union(c)

    if union != universe:
        missing = universe - union
        return f"NOT MECE: Missing {missing}"

    return "MECE ✅"

Example 1: Revenue Analysis (Business)

Problem: "Why did revenue decline last quarter?"

Bad Decomposition (NOT MECE):

reasons = [
    "Lost customers",
    "Reduced pricing",
    "Economic downturn",
    "Competitor actions"
]

# Issues:
# - "Lost customers" could be due to "Competitor actions" (overlap!)
# - Missing: New customer acquisition rate
# - Missing: Average transaction value changes
# NOT MECE! ❌

Good Decomposition (MECE):

# Revenue = # Customers × Average Revenue Per Customer (ARPC)
revenue_components = {
    "Customer count changes": {
        "New customers acquired": +50,
        "Customers lost (churn)": -100,
        "Net change": -50  # Lost 50 customers
    },
    "ARPC changes": {
        "Price changes": -5%,
        "Product mix changes": +2%,
        "Net change": -3%  # ARPC down 3%
    }
}

# MECE Analysis:
# Total revenue change = (-50 customers) × (1 - 3% ARPC)
# = Customer effect (-50) + ARPC effect (-3%)
# = -53% total decline

# Root cause identified:
# 1. Primary: Customer churn (96% of problem)
# 2. Secondary: Price reduction (4% of problem)
# → Focus on retention! ✅

Example 2: Bug Root Cause (Software)

Problem: "Application crashes randomly"

Bad Decomposition (NOT MECE):

possible_causes = [
    "Memory leak",
    "Race condition",
    "Bad data input",
    "Server overload"
]

# Issues:
# - "Memory leak" AND "Server overload" could coexist (not exclusive!)
# - Missing: Network issues, database errors
# NOT MECE! ❌

Good Decomposition (MECE):

# MECE dimension: Where does the crash originate?

crash_sources = {
    "Client-side": {
        "Frontend JS errors": check_browser_console(),
        "Client resource exhaustion": check_memory_usage()
    },
    "Network": {
        "Request timeout": check_network_logs(),
        "Connection drops": check_connection_stability()
    },
    "Server-side": {
        "Application errors": check_application_logs(),
        "Resource exhaustion": check_server_resources(),
        "Database errors": check_db_logs()
    },
    "External services": {
        "Third-party API failures": check_api_status(),
        "CDN issues": check_cdn_health()
    }
}

# MECE: Every possible crash source is in exactly one category ✅
# Now systematically check each category to find root cause

Example 3: Task Prioritization (Productivity)

Problem: "Too many tasks, don't know where to start"

Bad Decomposition (NOT MECE):

task_buckets = [
    "Urgent tasks",
    "Important tasks",
    "Quick tasks"
]

# Issues:
# - A task can be both urgent AND important (overlap!)
# - A task can be urgent AND quick (overlap!)
# NOT MECE! ❌

Good Decomposition (MECE using Eisenhower Matrix):

# Two dimensions: Urgency × Importance
tasks_mece = {
    "Urgent + Important": {
        "Do First": [
            "Critical bug fix (production down)",
            "Client presentation today"
        ]
    },
    "Not Urgent + Important": {
        "Schedule": [
            "System architecture refactor",
            "Employee development"
        ]
    },
    "Urgent + Not Important": {
        "Delegate": [
            "Respond to non-critical emails",
            "Attend optional meeting"
        ]
    },
    "Not Urgent + Not Important": {
        "Eliminate": [
            "Browse social media",
            "Organize old files"
        ]
    }
}

# MECE: Every task falls into exactly ONE quadrant ✅
# Action: Work through quadrants in order (1→2→3→4)

Practice Exercise

Problem: "Decompose sources of website traffic using MECE"

Click to see solution

Solution:

Step 1: Define universe

universe = "All visitors to website"

Step 2: Choose dimension - Source channel

Step 3: Create categories

traffic_sources_mece = {
    "Direct": {
        "definition": "Typed URL directly or bookmark",
        "examples": ["typing domain.com", "clicking bookmark"]
    },
    "Organic Search": {
        "definition": "Found via search engine (not paid)",
        "examples": ["Google search", "Bing search"]
    },
    "Paid Search": {
        "definition": "Clicked on paid ad in search results",
        "examples": ["Google Ads", "Bing Ads"]
    },
    "Social": {
        "definition": "Clicked link on social media",
        "examples": ["Facebook post", "Twitter link"]
    },
    "Referral": {
        "definition": "Clicked link from another website",
        "examples": ["Blog mention", "Partner site"]
    },
    "Email": {
        "definition": "Clicked link in email campaign",
        "examples": ["Newsletter", "Promotional email"]
    },
    "Other": {
        "definition": "Any source not in above categories",
        "examples": ["Mobile app", "QR code"]
    }
}

Step 4: Validate MECE

# Mutually Exclusive?
# - Direct ∩ Organic = ∅ ✅
# - Social ∩ Referral = ∅ (social is FROM social platform, referral is FROM other sites) ✅
# - All pairs are disjoint ✅

# Collectively Exhaustive?
# - Direct: ✅ Covers typed URLs
# - Organic: ✅ Covers unpaid search
# - Paid: ✅ Covers paid search
# - Social: ✅ Covers social media
# - Referral: ✅ Covers other websites
# - Email: ✅ Covers email clicks
# - Other: ✅ Catchall for remaining sources
# Universe fully covered ✅

# MECE validated! ✅

Usage:

# Now you can analyze traffic without double-counting:
traffic = {
    "Direct": 1000,
    "Organic": 2500,
    "Paid": 500,
    "Social": 800,
    "Referral": 300,
    "Email": 400,
    "Other": 100
}

total = sum(traffic.values())  # 5,600 visitors
# Each visitor counted exactly once ✅
# No visitors missed ✅

# Can confidently say: "Organic is 45% of traffic" without error

Common Mistakes

Mistake #1: Overlapping categories

# ❌ Wrong: Age categories that overlap
bad_categories = ["Under 30", "20-40", "Over 35"]
# Problem: 20-29 is in TWO categories! Not mutually exclusive!

# ✅ Correct: Non-overlapping categories
good_categories = ["Under 20", "20-34", "35-49", "50+"]

Mistake #2: Missing categories (gaps)

# ❌ Wrong: Missing "Other" catchall
bad_channels = ["Facebook", "Instagram", "Twitter"]
# Problem: What about LinkedIn? TikTok? YouTube? Not exhaustive!

# ✅ Correct: Include catchall
good_channels = ["Facebook", "Instagram", "Twitter", "Other Social"]

Mistake #3: Using multiple dimensions at once

# ❌ Wrong: Mixing dimensions
bad_segments = ["Age 18-25", "High income", "Urban location", "Frequent buyers"]
# Problem: These are different dimensions! Can't be MECE!

# ✅ Correct: One dimension at a time
# Dimension 1: Age
age_segments = ["18-25", "26-40", "41-60", "60+"]

# Dimension 2: Income (analyzed separately)
income_segments = ["<$50k", "$50k-$100k", "$100k+"]

# Can create matrix: Age × Income (but analyze one level at a time)

Mistake #4: Categories too granular or too broad

# ❌ Too granular
bad_age = ["18", "19", "20", "21", ...]  # 80+ categories! Useless!

# ❌ Too broad
bad_age_2 = ["Young", "Old"]  # Only 2 categories! Not useful!

# ✅ Goldilocks: Just right
good_age = ["18-25", "26-40", "41-60", "60+"]  # 4 meaningful segments

Cross-References

Synergies with other frameworks:

Tree Analysis (#2) - MECE ensures tree branches don't overlap
System Decomposition (#7) - MECE ensures all system components identified
Solution Space Mapping (#12) - MECE ensures all solutions considered

Synergies with Mental Models (from system-thinking-mastery-skill):

Circle of Competence (#3) - MECE helps define what you know vs don't know
First Principles (#4) - MECE helps categorize fundamental components
Pareto Principle (#10) - After MECE decomposition, apply 80/20 to prioritize

Framework #2: Tree Analysis (Hierarchical Decomposition)

Definition

Tree Analysis breaks down a problem into hierarchical levels, like an upside-down tree:

Root = Main problem
Branches = Sub-problems
Leaves = Atomic tasks (can't be broken down further)

Used for:

Understanding problem structure
Decision-making (decision trees)
Categorization (taxonomy trees)
Code architecture (class hierarchies)

Core Principle

"Complex problems are just simple problems stacked in layers. Peel the layers one by one."

Key insight:

Level 1: High-level problem (abstract)
Level 2: Medium-level sub-problems (less abstract)
Level 3: Low-level tasks (concrete, actionable)
Level 4+: Even more granular (if needed)

Rule: Stop decomposing when you reach actionable atomic units (tasks you can do in < 2 hours)

Step-by-Step Method

Step 1: State root problem

root = "Launch new mobile app"

Step 2: Decompose Level 1 (major components)

level_1 = [
    "Design app",
    "Develop app",
    "Test app",
    "Launch app",
    "Market app"
]

Step 3: Decompose Level 2 (sub-components)

level_2 = {
    "Design app": [
        "UX research",
        "UI wireframes",
        "Visual design",
        "Prototype"
    ],
    "Develop app": [
        "Frontend (iOS/Android)",
        "Backend API",
        "Database",
        "Integration"
    ],
    "Test app": [
        "Unit tests",
        "Integration tests",
        "User acceptance tests",
        "Performance tests"
    ],
    # ... continue for all Level 1 items
}

Step 4: Continue decomposing until atomic

level_3 = {
    "Frontend (iOS/Android)": [
        "Setup project structure",
        "Implement navigation",
        "Build screens",
        "Connect to API",
        "Handle offline mode"
    ],
    # Each of these is now small enough to estimate and execute
}

Step 5: Visualize tree

Launch Mobile App
├── Design App
│   ├── UX Research
│   ├── UI Wireframes
│   ├── Visual Design
│   └── Prototype
├── Develop App
│   ├── Frontend
│   │   ├── Setup project
│   │   ├── Navigation
│   │   ├── Screens
│   │   ├── API connection
│   │   └── Offline mode
│   ├── Backend API
│   ├── Database
│   └── Integration
├── Test App
│   ├── Unit tests
│   ├── Integration tests
│   ├── UAT
│   └── Performance tests
├── Launch App
└── Market App

Example 1: Debug Production Issue (Software)

Root Problem: "Website is slow (5+ seconds to load)"

Level 1: Major suspects

suspects = [
    "Frontend performance",
    "Backend performance",
    "Network latency",
    "Database queries"
]

Level 2: Decompose each suspect

tree = {
    "Frontend performance": {
        "Large bundle size": "Check JS bundle size",
        "Unoptimized images": "Check image sizes",
        "Too many requests": "Check network waterfall",
        "Render blocking": "Check critical rendering path"
    },
    "Backend performance": {
        "Slow API endpoints": "Profile API response times",
        "High CPU usage": "Check server CPU",
        "Memory leaks": "Check server memory",
        "Rate limiting": "Check throttling"
    },
    "Network latency": {
        "CDN issues": "Check CDN performance",
        "DNS resolution": "Check DNS lookup time",
        "SSL handshake": "Check TLS negotiation",
        "Geographic distance": "Check user location"
    },
    "Database queries": {
        "Slow queries": "Check query execution time",
        "Missing indexes": "EXPLAIN query plans",
        "Lock contention": "Check for deadlocks",
        "Connection pool": "Check connection limits"
    }
}

Level 3: Test hypotheses systematically

# Start at leaves, work up tree
def debug_tree(tree):
    for category, tests in tree.items():
        print(f"Testing: {category}")
        for test, action in tests.items():
            result = execute(action)
            if result.is_bottleneck():
                print(f"Found bottleneck: {test}")
                return fix(test)

    return "No bottleneck found, investigate further"

# Example result:
# Testing: Database queries
# → Slow queries: SELECT * FROM users WHERE email LIKE '%@%' (5.2 seconds!)
# → Root cause: Missing index on email column
# → Fix: CREATE INDEX idx_email ON users(email)
# → Result: Query now 0.02 seconds ✅

Example 2: Business Strategy (Increase Revenue)

Root Problem: "Increase revenue by 50% in 12 months"

Tree Decomposition:

revenue_tree = {
    "Increase Revenue": {
        "Increase customer count": {
            "Acquire new customers": {
                "Paid advertising": ["Google Ads", "Facebook Ads", "LinkedIn Ads"],
                "Content marketing": ["Blog posts", "Videos", "Podcasts"],
                "Partnerships": ["Affiliate program", "Co-marketing"],
                "Sales team": ["Hire SDRs", "Outbound campaigns"]
            },
            "Reduce churn": {
                "Improve product": ["Fix bugs", "Add features", "Better UX"],
                "Customer success": ["Onboarding", "Support", "Training"],
                "Retention campaigns": ["Win-back emails", "Loyalty program"]
            }
        },
        "Increase revenue per customer": {
            "Raise prices": {
                "Value-based pricing": ["Tier by features", "Usage-based"],
                "Grandfathering": ["Increase for new customers only"]
            },
            "Upsell": {
                "Higher tiers": ["Premium plan", "Enterprise plan"],
                "Add-ons": ["Extra features", "Integrations", "Support"]
            },
            "Cross-sell": {
                "Related products": ["Product bundles", "Complementary services"]
            }
        }
    }
}

Prioritization (Pareto applied to tree):

# After decomposing, evaluate each leaf:
leaf_impact = {
    "Google Ads": {"effort": 2, "impact": 8, "roi": 4.0},
    "Facebook Ads": {"effort": 3, "impact": 6, "roi": 2.0},
    "Fix bugs": {"effort": 5, "impact": 7, "roi": 1.4},
    "Raise prices": {"effort": 1, "impact": 9, "roi": 9.0},  # ← Highest ROI!
    "Premium plan": {"effort": 4, "impact": 8, "roi": 2.0},
    # ... score all leaves
}

# Result: Prioritize based on ROI
# 1. Raise prices (9.0 ROI) ← DO THIS FIRST
# 2. Google Ads (4.0 ROI)
# 3. Premium plan (2.0 ROI)
# ...

Example 3: Learning New Skill (Personal Development)

Root Problem: "Learn machine learning in 6 months"

Tree Decomposition:

learning_tree = {
    "Learn Machine Learning": {
        "Prerequisites": {
            "Math": {
                "Linear algebra": ["Vectors", "Matrices", "Eigenvectors"],
                "Calculus": ["Derivatives", "Gradients", "Chain rule"],
                "Probability": ["Distributions", "Bayes theorem", "Expectation"]
            },
            "Programming": {
                "Python": ["Basics", "NumPy", "Pandas", "Matplotlib"],
                "Data structures": ["Lists", "Dicts", "Sets"],
                "Algorithms": ["Sorting", "Searching", "Complexity"]
            }
        },
        "Core ML": {
            "Supervised learning": {
                "Regression": ["Linear", "Polynomial", "Regularization"],
                "Classification": ["Logistic", "SVM", "Decision trees"]
            },
            "Unsupervised learning": {
                "Clustering": ["K-means", "Hierarchical", "DBSCAN"],
                "Dimensionality reduction": ["PCA", "t-SNE"]
            },
            "Neural networks": {
                "Basics": ["Perceptron", "Backprop", "Activation functions"],
                "Deep learning": ["CNNs", "RNNs", "Transformers"]
            }
        },
        "Practice": {
            "Kaggle competitions": ["Titanic", "House prices", "Digit recognition"],
            "Personal projects": ["Build image classifier", "Sentiment analysis"],
            "Paper implementations": ["ResNet", "BERT", "GPT"]
        }
    }
}

Learning Path (Bottom-up):

# Start from leaves, work up to root
learning_order = [
    # Month 1-2: Prerequisites
    "Python basics", "NumPy", "Pandas",
    "Linear algebra", "Calculus basics",

    # Month 3-4: Core ML
    "Linear regression", "Logistic regression",
    "Decision trees", "K-means",

    # Month 5-6: Advanced + Practice
    "Neural networks", "Backprop",
    "Kaggle Titanic", "Personal project",
    "Deep learning basics"
]

# Tree decomposition made learning path clear! ✅

Practice Exercise

Problem: "Decompose 'Build a Trading Bot' using tree analysis"

Click to see solution

Solution:

trading_bot_tree = {
    "Build Trading Bot": {
        "Strategy Development": {
            "Market research": {
                "Study successful strategies": ["Trend following", "Mean reversion", "Arbitrage"],
                "Analyze market data": ["Historical prices", "Volume patterns", "Volatility"]
            },
            "Define rules": {
                "Entry conditions": ["Technical indicators", "Price patterns", "Volume signals"],
                "Exit conditions": ["Take profit", "Stop loss", "Time-based"],
                "Position sizing": ["Fixed amount", "Risk percentage", "Kelly criterion"]
            },
            "Backtest strategy": {
                "Prepare data": ["Download history", "Clean data", "Calculate features"],
                "Run simulation": ["Walk-forward analysis", "Monte Carlo", "Stress testing"],
                "Evaluate metrics": ["Sharpe ratio", "Max drawdown", "Win rate"]
            }
        },
        "Bot Development": {
            "Data pipeline": {
                "Real-time feeds": ["Connect to exchange API", "WebSocket streams"],
                "Data storage": ["Time-series database", "Caching layer"],
                "Data processing": ["Indicator calculation", "Signal generation"]
            },
            "Execution engine": {
                "Order management": ["Place orders", "Cancel orders", "Modify orders"],
                "Risk management": ["Position limits", "Exposure checks", "Circuit breakers"],
                "Error handling": ["Network errors", "API errors", "Data errors"]
            },
            "Monitoring": {
                "Logging": ["Trade logs", "Error logs", "Performance logs"],
                "Alerts": ["Telegram bot", "Email alerts", "SMS"],
                "Dashboard": ["Live PnL", "Positions", "Order status"]
            }
        },
        "Testing": {
            "Paper trading": {
                "Simulated execution": ["Test with fake money", "Validate logic"],
                "Performance tracking": ["Track P&L", "Analyze trades"]
            },
            "Live testing": {
                "Small position": ["Trade with minimal capital", "Monitor closely"],
                "Gradual scaling": ["Increase size slowly", "Validate stability"]
            }
        },
        "Deployment": {
            "Infrastructure": {
                "Server setup": ["Cloud server (AWS/GCP)", "VPS configuration"],
                "Security": ["API key management", "Firewall rules", "Backups"],
                "Monitoring": ["Uptime monitoring", "Performance monitoring"]
            },
            "Launch": {
                "Initial deployment": ["Deploy to production", "Start bot"],
                "Ongoing maintenance": ["Monitor performance", "Update strategy", "Fix bugs"]
            }
        }
    }
}

Execution Order (Bottom-up):

execution_phases = [
    # Phase 1: Strategy (Weeks 1-4)
    ["Market research", "Define rules", "Backtest"],

    # Phase 2: Development (Weeks 5-8)
    ["Data pipeline", "Execution engine", "Monitoring"],

    # Phase 3: Testing (Weeks 9-10)
    ["Paper trading", "Small live test"],

    # Phase 4: Deployment (Weeks 11-12)
    ["Infrastructure setup", "Production launch"]
]

# Total: 12 weeks from start to production ✅

Key Insight from Tree:

Strategy must be complete BEFORE development (don't code without a plan!)
Testing must be thorough BEFORE real money (paper trade first!)
Infrastructure must be solid BEFORE scaling (don't deploy on shaky foundation!)

Common Mistakes

Mistake #1: Decomposing too shallow

# ❌ Wrong: Only 1 level
shallow_tree = {
    "Build app": ["Design", "Code", "Test"]  # Too vague!
}

# ✅ Correct: Multiple levels until atomic
deep_tree = {
    "Build app": {
        "Design": {
            "UX": ["Research users", "Create wireframes", "Test prototypes"],
            "UI": ["Design system", "Visual mockups", "Style guide"]
        },
        "Code": {
            "Frontend": ["Setup", "Components", "Styling", "State management"],
            "Backend": ["API", "Database", "Auth", "Deployment"]
        },
        # ... continue until tasks are < 2 hours each
    }
}

Mistake #2: Branches not MECE

# ❌ Wrong: Overlapping branches
bad_tree = {
    "Improve website": [
        "Speed optimization",
        "Reduce load time",  # ← Overlaps with speed!
        "Better UX"
    ]
}

# ✅ Correct: MECE branches
good_tree = {
    "Improve website": [
        "Performance",  # Covers speed & load time
        "User experience",
        "Content quality"
    ]
}

Mistake #3: Mixing abstraction levels

# ❌ Wrong: High-level and low-level mixed
bad_tree = {
    "Project tasks": [
        "Complete backend",  # High-level
        "Write user model class",  # Low-level (should be INSIDE "Complete backend")
        "Deploy to production"  # High-level
    ]
}

# ✅ Correct: Same abstraction level per layer
good_tree = {
    "Project tasks": {
        "Complete backend": {
            "Database": ["Write user model", "Write product model"],
            "API": ["Auth endpoints", "CRUD endpoints"],
            "Deployment": ["Docker setup", "CI/CD pipeline"]
        },
        "Complete frontend": { ... },
        "Deploy to production": { ... }
    }
}

Cross-References

Synergies with other frameworks:

MECE (#1) - Ensures tree branches are mutually exclusive and exhaustive
WBS (#11) - Tree analysis is the core structure of WBS
Dependency Mapping (#9) - Tree nodes can have dependencies between them

Synergies with Mental Models:

First Principles (#4) - Tree decomposition breaks down to fundamentals
Second-Order Thinking (#2) - Each tree level represents an order of consequences
Theory of Constraints (#12) - Find bottleneck by analyzing critical path in tree

Framework #3: Process Decomposition (Sequential Flow Mapping)

Definition

Process Decomposition breaks down a workflow into sequential steps, like a flowchart or pipeline.

Key concept: Some problems are naturally sequential - Step B can't start until Step A completes.

Used for:

Understanding workflows
Optimizing processes
Finding bottlenecks
Automating tasks
Documenting procedures

Core Principle

"Everything that happens in order can be mapped. Once mapped, it can be measured. Once measured, it can be optimized."

Process elements:

Steps - Individual actions (nodes)
Inputs - What goes into each step
Outputs - What comes out of each step
Decision points - Where flow branches (if/then)
Feedback loops - Where output feeds back as input

Types of processes:

Linear: A → B → C → D (no branches)
Conditional: A → {if X then B else C} → D (branches)
Cyclical: A → B → C → back to A (loops)
Parallel: A → {B1, B2, B3} → D (parallel steps)

Step-by-Step Method

Step 1: Identify start and end

start = "Customer places order"
end = "Customer receives product"

Step 2: List all steps

steps = [
    "Customer places order",
    "Payment processed",
    "Order confirmed",
    "Warehouse picks items",
    "Items packed",
    "Shipping label created",
    "Picked up by courier",
    "In transit",
    "Delivered to customer"
]

Step 3: Define inputs/outputs

step_details = {
    "Payment processed": {
        "inputs": ["Order details", "Payment info"],
        "process": "Validate payment via Stripe API",
        "outputs": ["Payment confirmation", "Transaction ID"],
        "duration": "2 seconds"
    },
    "Warehouse picks items": {
        "inputs": ["Order details", "Warehouse inventory"],
        "process": "Scan items, verify quantities",
        "outputs": ["Picked items", "Pick confirmation"],
        "duration": "10 minutes"
    },
    # ... define for all steps
}

Step 4: Map flow

def process_flow():
    order = customer_places_order()

    payment = process_payment(order)
    if payment.failed:
        notify_customer("Payment failed")
        return False

    order = confirm_order(order, payment)

    items = warehouse_pick(order)
    package = pack_items(items)
    label = create_shipping_label(package, order.address)

    tracking = courier_pickup(package)

    while not delivered:
        tracking = update_tracking_status(tracking)
        time.sleep(3600)  # Check every hour

    notify_customer("Delivered!")
    return True

Step 5: Identify bottlenecks

step_durations = {
    "Payment": 2,           # seconds
    "Confirmation": 1,      # seconds
    "Warehouse pick": 600,  # 10 minutes ← BOTTLENECK!
    "Packing": 300,         # 5 minutes
    "Label creation": 30,   # 30 seconds
    "Courier pickup": 3600, # 1 hour
    "Transit": 86400        # 1 day
}

bottleneck = max(step_durations, key=step_durations.get)
print(f"Bottleneck: {bottleneck} takes {step_durations[bottleneck]}s")
# Output: "Bottleneck: Transit takes 86400s" (1 day)
# → Focus optimization on shipping speed!

Example 1: Code Deployment Pipeline (DevOps)

Process: Deploy code from local machine to production

Linear Process:

deployment_pipeline = [
    {
        "step": "1. Developer commits code",
        "input": "Code changes",
        "action": "git commit && git push",
        "output": "Code in repository",
        "duration": "10 seconds"
    },
    {
        "step": "2. CI server detects change",
        "input": "Git webhook",
        "action": "Trigger build pipeline",
        "output": "Build started",
        "duration": "5 seconds"
    },
    {
        "step": "3. Run tests",
        "input": "Code from repo",
        "action": "pytest, eslint, type-check",
        "output": "Test results",
        "duration": "120 seconds"  # ← SLOW!
    },
    {
        "step": "4. Build Docker image",
        "input": "Code + dependencies",
        "action": "docker build",
        "output": "Docker image",
        "duration": "90 seconds"  # ← SLOW!
    },
    {
        "step": "5. Push to registry",
        "input": "Docker image",
        "action": "docker push",
        "output": "Image in registry",
        "duration": "60 seconds"
    },
    {
        "step": "6. Deploy to staging",
        "input": "Image from registry",
        "action": "kubectl apply -f staging.yaml",
        "output": "Running on staging",
        "duration": "30 seconds"
    },
    {
        "step": "7. Smoke tests on staging",
        "input": "Staging URL",
        "action": "curl health checks",
        "output": "Health status",
        "duration": "10 seconds"
    },
    {
        "step": "8. Manual approval",
        "input": "Human decision",
        "action": "Review staging, click approve",
        "output": "Approval granted",
        "duration": "300 seconds"  # 5 minutes (human)
    },
    {
        "step": "9. Deploy to production",
        "input": "Image + approval",
        "action": "kubectl apply -f prod.yaml",
        "output": "Running on production",
        "duration": "60 seconds"
    },
    {
        "step": "10. Monitor & verify",
        "input": "Production metrics",
        "action": "Check errors, latency, traffic",
        "output": "Deployment verified",
        "duration": "60 seconds"
    }
]

total_time = sum(step["duration"] for step in deployment_pipeline)
print(f"Total deployment time: {total_time} seconds = {total_time/60} minutes")
# Output: "Total deployment time: 745 seconds = 12.4 minutes"

Optimization opportunities:

bottlenecks = [
    {"step": "Manual approval", "time": 300, "fix": "Automate approval with metrics"},
    {"step": "Run tests", "time": 120, "fix": "Parallelize test suites"},
    {"step": "Build Docker image", "time": 90, "fix": "Cache layers, use multi-stage"},
]

# After optimization:
optimized_pipeline = {
    "Manual approval": 0,      # Automated (deploy if all metrics green)
    "Run tests": 40,           # Parallelized (3x faster)
    "Build Docker": 30,        # Cached layers (3x faster)
}

new_total = 745 - (300 - 0) - (120 - 40) - (90 - 30)
print(f"Optimized time: {new_total} seconds = {new_total/60} minutes")
# Output: "Optimized time: 335 seconds = 5.6 minutes"
# 🚀 Deployment time reduced by 55%!

Example 2: Content Creation Workflow (Business)

Process: Create blog post from idea to published

Conditional Process (has decision points):

def content_workflow(topic):
    # Step 1: Research
    research = research_topic(topic)  # 2 hours

    # Step 2: Outline
    outline = create_outline(research)  # 30 minutes

    # Decision point: Is outline approved?
    if not manager_approves(outline):
        # Loop back: Revise outline
        outline = revise_outline(manager.feedback)
        # Continue only if approved (could loop multiple times)

    # Step 3: Write draft
    draft = write_first_draft(outline)  # 4 hours

    # Step 4: Self-edit
    draft = self_edit(draft)  # 1 hour

    # Step 5: Peer review
    feedback = peer_review(draft)  # 30 minutes (peer's time)

    # Decision point: Major revisions needed?
    if feedback.major_revisions:
        # Loop back: Rewrite sections
        draft = revise_draft(feedback)  # 2 hours
        feedback = peer_review(draft)  # Another 30 minutes

    # Step 6: Final edits
    final = apply_final_edits(draft, feedback)  # 1 hour

    # Step 7: Format for publishing
    formatted = format_for_blog(final)  # 30 minutes

    # Step 8: Add images
    formatted = add_images_and_graphics(formatted)  # 1 hour

    # Step 9: SEO optimization
    formatted = optimize_for_seo(formatted, target_keyword)  # 30 minutes

    # Step 10: Schedule publication
    scheduled = schedule_post(formatted, publish_date)  # 5 minutes

    # Step 11: Publish
    published = publish_post(scheduled)  # Instant

    # Step 12: Promote on social
    promote_on_social_media(published)  # 30 minutes

    return published

# Total time: ~10-14 hours (depending on revisions)

Optimization:

# Parallelization opportunities:
parallel_tasks = {
    "Write sections": [
        "Introduction (1 hour)",
        "Main body (2 hours)",
        "Conclusion (30 minutes)",
        "Call-to-action (30 minutes)"
    ],  # Can be written by DIFFERENT writers simultaneously

    "Final preparation": [
        "Format for blog (30 min)",
        "Add images (1 hour)",      # ← Can be done in parallel!
        "SEO optimization (30 min)"
    ]  # Formatting and images can overlap
}

# Automation opportunities:
automate = {
    "SEO optimization": "Use AI tool (Surfer SEO) → 5 minutes instead of 30",
    "Social promotion": "Use scheduler (Buffer) → 5 minutes instead of 30",
    "Formatting": "Use template → 10 minutes instead of 30"
}

# Result: 10-14 hours → 6-8 hours (40% faster)

Example 3: Customer Onboarding (SaaS Product)

Process: New user signs up → becomes active user

Parallel + Sequential Hybrid:

def onboarding_flow(user):
    # Step 1: Sign up (instant)
    user = register_user(user.email, user.password)

    # Step 2: Email verification (async)
    send_verification_email(user)
    # (User can continue while email is being sent)

    # Step 3: Welcome screen (immediate)
    show_welcome_screen(user)

    # Step 4: Parallel tasks (user chooses order)
    parallel_steps = {
        "Connect integrations": connect_slack_github_etc(),
        "Import data": import_existing_data(),
        "Invite team": send_team_invitations(),
        "Setup preferences": configure_settings()
    }
    # User doesn't need to complete these in order!

    # Step 5: Interactive tutorial (required before Step 6)
    tutorial_completed = guided_tutorial(user)

    # Decision point: Tutorial finished?
    if not tutorial_completed:
        # User stuck on tutorial → trigger help
        offer_live_demo_call(user)

    # Step 6: First real action (activation metric)
    first_action = user_creates_first_project(user)

    # Step 7: Celebrate & educate
    celebrate_milestone(user, "First project created!")
    suggest_next_steps(user)

    # Step 8: Feedback loop (after 7 days)
    schedule_email(user, days=7, template="How's it going?")

    return user.status = "Activated"

# Tracking conversion metrics:
funnel_metrics = {
    "Sign up → Email verified": "85%",
    "Email verified → Tutorial started": "70%",
    "Tutorial started → Tutorial finished": "60%",  # ← LEAKY!
    "Tutorial finished → First project": "90%",
    "First project → Active user": "95%"
}

# Bottleneck: Tutorial completion (only 60%)
# → Focus on making tutorial shorter, clearer, skippable!

Practice Exercise

Problem: "Decompose the process of 'Hire a new employee' from job posting to first day"

Click to see solution

Solution:

hiring_process = [
    {
        "stage": "1. Define Role",
        "steps": [
            "Identify need (team request)",
            "Define job responsibilities",
            "Set salary range",
            "Create job description",
            "Get budget approval"
        ],
        "duration": "1 week",
        "output": "Approved job posting"
    },
    {
        "stage": "2. Source Candidates",
        "steps": [
            "Post on job boards",
            "Share on LinkedIn/social",
            "Ask for referrals",
            "Engage recruiters (if needed)",
            "Review incoming applications"
        ],
        "duration": "2-4 weeks",
        "output": "Pool of applicants"
    },
    {
        "stage": "3. Screen Candidates",
        "steps": [
            "Resume review (filter top 20%)",
            "Phone screen (15-20 min calls)",
            "Shortlist for interviews"
        ],
        "duration": "1 week",
        "output": "5-10 qualified candidates",
        "decision": "If < 5 candidates, go back to stage 2"
    },
    {
        "stage": "4. Interview Process",
        "steps": [
            "Round 1: Technical/skills interview",
            "Round 2: Team fit interview",
            "Round 3: Hiring manager interview",
            "Reference checks"
        ],
        "duration": "2-3 weeks",
        "output": "1-2 finalists"
    },
    {
        "stage": "5. Offer & Negotiation",
        "steps": [
            "Prepare offer letter",
            "Extend verbal offer",
            "Negotiate terms (if needed)",
            "Send written offer",
            "Candidate accepts/rejects"
        ],
        "duration": "3-7 days",
        "output": "Signed offer letter",
        "decision": "If rejected, go back to stage 4 (offer to finalist #2)"
    },
    {
        "stage": "6. Pre-boarding",
        "steps": [
            "Background check",
            "Setup accounts (email, Slack, etc.)",
            "Order equipment (laptop, monitor)",
            "Prepare onboarding materials",
            "Notify team"
        ],
        "duration": "1-2 weeks",
        "output": "Ready for first day"
    },
    {
        "stage": "7. First Day",
        "steps": [
            "Welcome & orientation",
            "Setup workstation",
            "Meet the team",
            "Review expectations",
            "Assign first tasks"
        ],
        "duration": "1 day",
        "output": "Employee onboarded"
    }
]

# Total timeline: 8-13 weeks from posting to first day

Bottleneck Analysis:

bottlenecks = {
    "Sourcing candidates": "2-4 weeks (slow applicant flow)",
    "Interview coordination": "2-3 weeks (scheduling conflicts)"
}

# Optimizations:
optimizations = {
    "Sourcing": [
        "Build talent pipeline BEFORE role opens",
        "Use employee referral bonuses",
        "Hire recruiting agency for hard roles"
    ],
    "Interviews": [
        "Use scheduling tool (Calendly)",
        "Conduct multiple interviews same day",
        "Allow async video interviews for Round 1"
    ]
}

# Optimized timeline: 6-8 weeks (25-40% faster)

Decision Points Mapped:

decision_tree = {
    "After screening": {
        "if qualified_candidates >= 5": "Proceed to interviews",
        "else": "Continue sourcing (stage 2)"
    },
    "After interviews": {
        "if finalists == 0": "Restart sourcing (stage 2)",
        "if finalists >= 1": "Make offer (stage 5)"
    },
    "After offer": {
        "if accepted": "Proceed to pre-boarding (stage 6)",
        "if rejected and finalists > 1": "Offer to finalist #2",
        "if rejected and finalists == 1": "Restart interviews (stage 4)"
    }
}

Common Mistakes

Mistake #1: Missing decision points

# ❌ Wrong: Linear flow with no branches
bad_process = ["Test code", "Deploy to production"]

# Problem: What if tests FAIL? Process crashes!

# ✅ Correct: Include decision points
good_process = [
    "Test code",
    {
        "if tests pass": "Deploy to production",
        "if tests fail": "Send alert → Fix bugs → Re-test"
    }
]

Mistake #2: Ignoring parallel opportunities

# ❌ Wrong: Sequential when could be parallel
bad_workflow = [
    "Write code (2 hours)",
    "Write tests (1 hour)",
    "Write docs (1 hour)"
]
# Total: 4 hours

# ✅ Correct: Parallelize independent tasks
good_workflow = [
    "Write code (2 hours)",
    "Parallel: {
        'Write tests (1 hour)',
        'Write docs (1 hour)'
    }"
]
# Total: 3 hours (25% faster!)

Mistake #3: Not measuring step durations

# ❌ Wrong: No time data
bad = ["Step A", "Step B", "Step C"]

# Can't optimize what you don't measure!

# ✅ Correct: Track durations
good = [
    {"step": "Step A", "duration": 10},
    {"step": "Step B", "duration": 100},  # ← Bottleneck!
    {"step": "Step C", "duration": 5}
]

# Now you know where to focus optimization (Step B)

Cross-References

Synergies with other frameworks:

Dependency Mapping (#9) - Process steps = dependency chain
Constraint Identification (#10) - Bottleneck = constraint in process
Tree Analysis (#2) - Each process step can be decomposed into tree

Synergies with Mental Models:

Theory of Constraints (#12) - Optimize the slowest step in process
Margin of Safety (#6) - Add buffers to critical steps
Feedback Loops (#11) - Process output feeds back as input

Framework #4: Root Cause Analysis (5 Whys & Fishbone Diagram)

Definition

Root Cause Analysis (RCA) finds the fundamental reason a problem exists, not just surface symptoms.

Two powerful techniques:

5 Whys - Ask "Why?" repeatedly until you reach the root
Fishbone Diagram (Ishikawa) - Categorize potential causes

Key insight: Symptoms are visible; root causes are hidden. You must dig deeper.

Core Principle

"Fixing symptoms = temporary relief. Fixing root causes = permanent solution."

Example:

Symptom: "Website is down"
Shallow cause: "Server crashed"
Root cause: "No monitoring → didn't detect high memory usage → memory leak in code"

Fix symptom: Restart server (down again tomorrow!) Fix root cause: Add monitoring + fix memory leak (problem solved forever!)

Step-by-Step Method (5 Whys)

Step 1: State the problem

problem = "Production deployment failed"

Step 2: Ask "Why?" 5 times

why_1 = "Why did deployment fail?"
answer_1 = "Because tests failed"

why_2 = "Why did tests fail?"
answer_2 = "Because database connection timed out"

why_3 = "Why did database connection time out?"
answer_3 = "Because database server was overloaded"

why_4 = "Why was database server overloaded?"
answer_4 = "Because we're running slow queries during peak traffic"

why_5 = "Why are we running slow queries during peak traffic?"
answer_5 = "Because we don't have proper query optimization or caching"

# Root cause found: No query optimization + no caching

Step 3: Fix root cause

fixes = [
    "Add indexes to slow queries",
    "Implement Redis caching for frequent queries",
    "Schedule heavy queries during off-peak hours",
    "Set up query performance monitoring"
]

# Result: Problem solved at root level (not just symptoms)

Fishbone Diagram Method

Structure:

                     Problem
                        │
    ┌──────┬───────┬───┴────┬──────┬──────┐
    │      │       │        │      │      │
  People Methods Materials Machines Measurement Environment
    │      │       │        │      │      │
  (causes)(causes)(causes)(causes)(causes)(causes)

Step-by-Step:

# Problem: "Website response time increased from 200ms to 2000ms"

fishbone = {
    "People": [
        "New junior dev committed inefficient code",
        "No code review before merge",
        "Team lacks performance training"
    ],
    "Methods": [
        "No performance testing before deploy",
        "No staging environment validation",
        "Deployment during peak traffic"
    ],
    "Materials": [
        "Database schema not optimized",
        "No CDN for static assets",
        "Large uncompressed images"
    ],
    "Machines": [
        "Server running out of memory",
        "Old server hardware (5 years old)",
        "Database on same server as app (should be separate)"
    ],
    "Measurement": [
        "No monitoring alerts configured",
        "No performance benchmarks tracked",
        "Don't measure page load time"
    ],
    "Environment": [
        "Increased traffic (viral post)",
        "DDoS attack attempt",
        "ISP issues affecting users"
    ]
}

# Analysis: Which causes actually happened?
root_causes = [
    "New junior dev committed inefficient code" +  # (People)
    "No code review before merge" +                # (Methods)
    "Server running out of memory"                 # (Machines)
]

# Fix all three root causes:
fixes = [
    "Mandatory code review (especially from juniors)",
    "Add performance CI checks (fail if response time > 500ms)",
    "Upgrade server + separate database server"
]

Example 1: Customer Churn (Business)

Problem: "Customer churn rate increased from 5% to 15%"

5 Whys:

why_1 = "Why are customers leaving?"
answer_1 = "They're switching to competitors"

why_2 = "Why are they switching to competitors?"
answer_2 = "Competitors have better features"

why_3 = "Why do competitors have better features?"
answer_3 = "We haven't shipped new features in 6 months"

why_4 = "Why haven't we shipped new features in 6 months?"
answer_4 = "Engineering team is fixing bugs all the time"

why_5 = "Why is engineering team always fixing bugs?"
answer_5 = "We don't have automated testing, so bugs keep appearing"

# Root cause: No automated testing → bugs → no time for features → churn

Solution:

root_cause_fix = [
    "Implement comprehensive test suite (unit + integration + E2E)",
    "Enforce 80% code coverage minimum",
    "Set up CI to block merges if tests fail",
    "Allocate 50% engineering time to new features (not just bugs)"
]

# Expected result:
# - Bugs reduced by 70% (from testing)
# - Features shipped 2x faster
# - Churn returns to 5% (customers stay for new features)

Practice Exercise

Problem: "Use 5 Whys to find root cause: 'Team missed project deadline by 2 weeks'"

Click to see solution

why_1 = "Why did team miss deadline by 2 weeks?"
answer_1 = "Because key features weren't finished on time"

why_2 = "Why weren't key features finished?"
answer_2 = "Because we underestimated complexity"

why_3 = "Why did we underestimated complexity?"
answer_3 = "Because requirements changed mid-project"

why_4 = "Why did requirements change mid-project?"
answer_4 = "Because stakeholders didn't agree on requirements upfront"

why_5 = "Why didn't stakeholders agree upfront?"
answer_5 = "Because we didn't have a proper requirements gathering process"

# Root cause: No requirements gathering process

Fixes:

fixes = {
    "Process": [
        "Implement requirements sign-off before project starts",
        "Use PRD (Product Requirements Document) template"
    ],
    "Resources": [
        "Hire 2 more designers",
        "Train engineers in basic UI design"
    ],
    "Planning": [
        "Add 20% buffer to estimates",
        "Track velocity and adjust future estimates"
    ]
}

Common Mistakes

Mistake #1: Stopping too early (before root)

# ❌ Wrong: Stop at symptom
problem = "Server crashed"
why_1 = "Why crashed?"
answer = "Out of memory"
fix = "Restart server"  # ← NOT root cause fix!

# ✅ Correct: Dig to root
why_3 = "Why out of memory?"
answer_3 = "Memory leak in code"
fix = "Fix memory leak + add monitoring"  # ← ROOT fix!

Mistake #2: Asking "who" instead of "why"

# ❌ Wrong: Blame people
why = "Why did bug get deployed?"
answer = "Because John didn't test it"  # ← Blaming John!

# ✅ Correct: Ask about systems
why = "Why did bug get deployed?"
answer = "Because no automated testing catches this bug type"
# → Fix the system, not blame John!

Cross-References

Synergies with other frameworks:

MECE (#1) - Fishbone categories should be MECE
Process Decomposition (#3) - Find which process step causes problem
Tree Analysis (#2) - Root cause tree (problem → causes → sub-causes)

Synergies with Mental Models:

Inversion (#1) - Invert problem: "How could we CAUSE this problem?"
Second-Order Thinking (#2) - Root causes create cascading effects
Theory of Constraints (#12) - Root cause often = constraint

Part 2: Domain-Specific Frameworks

Framework #5: Code Decomposition 💻

Definition

Code Decomposition is the practice of breaking down complex codebases, systems, or features into smaller, modular, maintainable components based on architectural principles (classes, modules, layers, services, packages).

Goal: Create code that is easy to understand, test, modify, and scale.

Core Principle

"Good architecture makes the system easy to understand, develop, maintain, and deploy. The goal is to minimize lifetime cost and maximize programmer productivity."

— Robert C. Martin (Uncle Bob), Clean Architecture

Key Insight: Decompose by responsibility, not by technical layer. Each component should have one clear purpose (Single Responsibility Principle).

Step-by-Step Method

Step 1: Identify Responsibilities

# What are the distinct responsibilities in this system?
responsibilities = [
    "User authentication",
    "Data persistence",
    "Business logic",
    "External API calls",
    "Presentation/UI",
    "Logging & monitoring"
]

Step 2: Group by Cohesion

High cohesion: Components that change together should be together
Low coupling: Components should be independent

Step 3: Define Interfaces

# Clear contracts between components
class UserRepository:
    def save(self, user: User) -> None: pass
    def find_by_id(self, user_id: str) -> User: pass

class AuthService:
    def login(self, email: str, password: str) -> Token: pass
    def verify_token(self, token: str) -> User: pass

Step 4: Implement Components

Each component = single responsibility
Dependencies flow inward (Dependency Inversion)

Step 5: Test Independently

# Each component can be tested in isolation
def test_user_repository():
    repo = UserRepository()
    user = User(id="123", name="Alice")
    repo.save(user)
    assert repo.find_by_id("123") == user

Example #1: Monolith → Microservices 🏢

Before (Monolithic E-commerce):

# ❌ Everything in one giant file (5,000 lines!)
class EcommerceApp:
    def register_user(self, email, password):
        # User logic + DB + email sending + logging all mixed!
        ...

    def add_to_cart(self, user_id, product_id):
        # Cart logic + inventory check + pricing all mixed!
        ...

    def process_payment(self, order_id, card_info):
        # Payment + order update + email + analytics all mixed!
        ...

    def generate_invoice(self, order_id):
        # Invoice + PDF generation + storage all mixed!
        ...

# Problems:
# - Hard to test (everything coupled)
# - Hard to scale (must scale entire app)
# - Hard to deploy (one bug breaks everything)
# - Team conflicts (everyone edits same file)

After (Microservices Architecture):

# ✅ Decomposed into independent services

# Service 1: User Service
class UserService:
    def register(self, email, password) -> User:
        user = User(email=email)
        user.set_password(password)
        self.repo.save(user)
        self.event_bus.publish("UserRegistered", user)
        return user

# Service 2: Cart Service
class CartService:
    def add_item(self, cart_id, product_id, quantity) -> Cart:
        cart = self.repo.find(cart_id)

        # Check inventory via API call
        available = self.inventory_api.check_stock(product_id)
        if available < quantity:
            raise OutOfStockError()

        cart.add_item(product_id, quantity)
        self.repo.save(cart)
        return cart

# Service 3: Payment Service
class PaymentService:
    def process(self, order_id, payment_method) -> Payment:
        order = self.order_api.get_order(order_id)

        payment = self.gateway.charge(
            amount=order.total,
            method=payment_method
        )

        if payment.status == "success":
            self.event_bus.publish("PaymentCompleted", payment)

        return payment

# Service 4: Invoice Service (listens to PaymentCompleted event)
class InvoiceService:
    def on_payment_completed(self, payment):
        order = self.order_api.get_order(payment.order_id)
        invoice = self.generator.create_pdf(order)
        self.storage.save(invoice)
        self.email_api.send(invoice, to=order.customer_email)

# Benefits:
# ✅ Independent deployment (update Payment without touching Cart)
# ✅ Independent scaling (scale Payment 10x during sales)
# ✅ Team autonomy (separate teams own separate services)
# ✅ Fault isolation (if Invoice fails, Payment still works)
# ✅ Technology flexibility (Payment in Python, Invoice in Node.js)

Results:

Deployment frequency: 1x/week → 10x/day (+900%)
Incident recovery: 2 hours → 15 minutes (88% faster)
Team velocity: 2x faster (parallel development)

Example #2: Clean Architecture (Layers) 🎯

Before (Spaghetti Code):

# ❌ Business logic mixed with database and HTTP
@app.route('/users/<user_id>/upgrade', methods=['POST'])
def upgrade_user(user_id):
    # HTTP layer
    data = request.get_json()

    # Database layer (direct SQL!)
    conn = psycopg2.connect("dbname=myapp")
    cursor = conn.cursor()
    cursor.execute(f"SELECT * FROM users WHERE id={user_id}")  # SQL injection!
    user = cursor.fetchone()

    # Business logic (mixed in!)
    if user['subscription'] == 'free':
        new_plan = 'premium'
        price = 99
    else:
        return {"error": "Already premium"}, 400

    # Payment (mixed in!)
    stripe.charge(user['card_id'], price)

    # Database update (mixed in!)
    cursor.execute(f"UPDATE users SET subscription='{new_plan}' WHERE id={user_id}")
    conn.commit()

    # Email (mixed in!)
    send_email(user['email'], "Welcome to Premium!")

    return {"status": "success"}, 200

# Problems:
# ❌ Cannot test business logic without database
# ❌ Cannot test without HTTP server
# ❌ Business rules buried in framework code
# ❌ Hard to change database (tightly coupled)

After (Clean Architecture - 4 Layers):

# ✅ Layer 1: Domain (innermost - pure business logic)
class User:
    def __init__(self, id, email, subscription):
        self.id = id
        self.email = email
        self.subscription = subscription

    def can_upgrade(self) -> bool:
        return self.subscription == Subscription.FREE

    def upgrade_to_premium(self):
        if not self.can_upgrade():
            raise AlreadyPremiumError()
        self.subscription = Subscription.PREMIUM

# ✅ Layer 2: Use Cases (application business rules)
class UpgradeUserUseCase:
    def __init__(self, user_repo, payment_gateway, email_service):
        self.user_repo = user_repo
        self.payment_gateway = payment_gateway
        self.email_service = email_service

    def execute(self, user_id: str, payment_method: PaymentMethod):
        # 1. Get user
        user = self.user_repo.find_by_id(user_id)

        # 2. Business logic (from Domain)
        if not user.can_upgrade():
            raise AlreadyPremiumError()

        # 3. Process payment
        self.payment_gateway.charge(
            amount=Money(99, "USD"),
            method=payment_method
        )

        # 4. Upgrade user
        user.upgrade_to_premium()
        self.user_repo.save(user)

        # 5. Send email
        self.email_service.send_upgrade_confirmation(user.email)

        return user

# ✅ Layer 3: Interface Adapters (convert data formats)
class UserRepositoryPostgres(UserRepository):
    def find_by_id(self, user_id: str) -> User:
        row = self.db.query("SELECT * FROM users WHERE id = %s", [user_id])
        return User(
            id=row['id'],
            email=row['email'],
            subscription=Subscription(row['subscription'])
        )

    def save(self, user: User) -> None:
        self.db.execute(
            "UPDATE users SET subscription = %s WHERE id = %s",
            [user.subscription.value, user.id]
        )

# ✅ Layer 4: Frameworks & Drivers (HTTP, DB, external services)
@app.route('/users/<user_id>/upgrade', methods=['POST'])
def upgrade_user_endpoint(user_id):
    # Convert HTTP request → Use Case input
    data = request.get_json()
    payment_method = PaymentMethod.from_dict(data['payment'])

    # Execute use case
    use_case = UpgradeUserUseCase(
        user_repo=UserRepositoryPostgres(),
        payment_gateway=StripeGateway(),
        email_service=SendGridService()
    )

    try:
        user = use_case.execute(user_id, payment_method)
        return {"status": "success", "user": user.to_dict()}, 200
    except AlreadyPremiumError:
        return {"error": "Already premium"}, 400

# Benefits:
# ✅ Test business logic without database (mock repositories)
# ✅ Test use cases without HTTP (call use_case.execute() directly)
# ✅ Change database easily (swap Postgres → MongoDB)
# ✅ Business rules clearly visible (in Domain layer)

Dependency Flow:

HTTP → Use Case → Domain
  ↓       ↓
DB    Payment
      Email

(Dependencies point INWARD toward Domain)

Results:

Test coverage: 40% → 95% (business logic fully tested)
Bug rate: -70% (business rules isolated and tested)
Onboarding time: 2 weeks → 3 days (clear architecture)

Example #3: Module Decomposition (Feature-Based) 🎨

Before (Layer-Based Structure):

# ❌ Organized by technical layer
project/
  controllers/
    user_controller.py
    product_controller.py
    order_controller.py
    payment_controller.py
  models/
    user.py
    product.py
    order.py
    payment.py
  services/
    user_service.py
    product_service.py
    order_service.py
    payment_service.py
  repositories/
    user_repository.py
    product_repository.py
    order_repository.py
    payment_repository.py

# Problems:
# - To add "Orders" feature → edit 4 different folders
# - Hard to find all code related to one feature
# - Team conflicts (everyone edits same folders)

After (Feature-Based Structure):

# ✅ Organized by feature/domain
project/
  users/
    __init__.py
    domain.py          # User entity
    repository.py      # UserRepository
    service.py         # UserService
    controller.py      # UserController
    tests/
      test_user_service.py

  products/
    __init__.py
    domain.py          # Product entity
    repository.py      # ProductRepository
    service.py         # ProductService
    controller.py      # ProductController
    tests/
      test_product_service.py

  orders/
    __init__.py
    domain.py          # Order entity
    repository.py      # OrderRepository
    service.py         # OrderService (uses products, users)
    controller.py      # OrderController
    tests/
      test_order_service.py

  payments/
    __init__.py
    domain.py          # Payment entity
    gateway.py         # PaymentGateway (Stripe)
    service.py         # PaymentService
    controller.py      # PaymentController
    tests/
      test_payment_service.py

# Benefits:
# ✅ All "Orders" code in one folder
# ✅ Easy to delete entire feature (rm -rf orders/)
# ✅ Team ownership (Team A owns users/, Team B owns orders/)
# ✅ Clear dependencies (orders imports products, payments)

Module Dependency Graph:

dependencies = {
    "users": [],                    # No dependencies
    "products": [],                 # No dependencies
    "orders": ["users", "products"], # Depends on users, products
    "payments": ["orders"]          # Depends on orders
}

# Build order: users → products → orders → payments

Results:

Feature development time: -40% (all code in one place)
Merge conflicts: -80% (teams work in different folders)
Code ownership clarity: 100% (each team owns folders)

Practice Exercise #5: Trading Bot Decomposition 🤖

Scenario: You have a 2,000-line trading bot in one file. It does:

Fetches market data from API
Calculates technical indicators (RSI, MACD, Bollinger Bands)
Generates buy/sell signals
Executes trades via broker API
Manages positions and risk
Logs everything to database
Sends alerts via Telegram

Task: Decompose into modules following Clean Architecture.

💡 Solution (Click to Expand)

# ✅ Clean Architecture Decomposition

# Layer 1: Domain (Core Business Logic)
trading_bot/
  domain/
    entities/
      position.py          # Position(symbol, quantity, entry_price, ...)
      order.py             # Order(symbol, side, quantity, price, ...)
      signal.py            # Signal(symbol, direction, strength, ...)

    value_objects/
      money.py             # Money(amount, currency)
      percentage.py        # Percentage(value)

    strategies/
      base_strategy.py     # Abstract base class
      rsi_strategy.py      # RSI-based signals
      macd_strategy.py     # MACD-based signals
      bollinger_strategy.py # Bollinger Bands signals

# Layer 2: Use Cases (Application Logic)
trading_bot/
  use_cases/
    fetch_market_data.py   # Fetch latest prices
    calculate_indicators.py # Calculate RSI, MACD, etc.
    generate_signals.py    # Run strategies → signals
    execute_trade.py       # Place order via broker
    manage_risk.py         # Check position limits
    send_alert.py          # Send Telegram notification

# Layer 3: Interface Adapters
trading_bot/
  adapters/
    repositories/
      position_repository_postgres.py
      trade_history_repository.py

    gateways/
      binance_gateway.py      # Market data from Binance
      interactive_brokers_gateway.py # Execute via IB
      telegram_gateway.py     # Send Telegram alerts

    presenters/
      trade_log_presenter.py  # Format logs for humans

# Layer 4: Infrastructure
trading_bot/
  infrastructure/
    database/
      postgres_connection.py

    config/
      settings.py            # Configuration

    schedulers/
      cron_scheduler.py      # Run every 5 minutes

# Main Entry Point
trading_bot/
  main.py

# Example main.py
def main():
    # Setup dependencies
    market_gateway = BinanceGateway(api_key=config.BINANCE_KEY)
    broker_gateway = InteractiveBrokersGateway(account=config.IB_ACCOUNT)
    position_repo = PositionRepositoryPostgres(db=db_connection)
    telegram = TelegramGateway(bot_token=config.TELEGRAM_TOKEN)

    # Setup strategies
    strategies = [
        RSIStrategy(period=14, oversold=30, overbought=70),
        MACDStrategy(fast=12, slow=26, signal=9),
        BollingerStrategy(period=20, std_dev=2)
    ]

    # Run use cases
    while True:
        # 1. Fetch data
        data = FetchMarketDataUseCase(market_gateway).execute("BTCUSDT")

        # 2. Calculate indicators
        indicators = CalculateIndicatorsUseCase().execute(data)

        # 3. Generate signals
        signals = GenerateSignalsUseCase(strategies).execute(data, indicators)

        # 4. Execute trades (if signals present)
        for signal in signals:
            # Check risk
            risk_ok = ManageRiskUseCase(position_repo).execute(signal)

            if risk_ok:
                # Execute trade
                order = ExecuteTradeUseCase(broker_gateway).execute(signal)

                # Send alert
                SendAlertUseCase(telegram).execute(order)

        time.sleep(300)  # Wait 5 minutes

# Benefits:
# ✅ Each strategy can be tested independently
# ✅ Easy to swap Binance → Coinbase (change 1 file)
# ✅ Easy to add new strategy (add 1 file)
# ✅ Clear separation of concerns
# ✅ No circular dependencies

Module Dependency Graph:

main.py → use_cases → domain
            ↓
         adapters → infrastructure

Common Mistakes

Mistake #1: Decompose by Technical Layer (not by Feature)

# ❌ Wrong
project/
  models/        # All models together
  views/         # All views together
  controllers/   # All controllers together

# ✅ Correct
project/
  users/         # All user-related code
  orders/        # All order-related code
  payments/      # All payment-related code

Mistake #2: Create "God Objects" (too many responsibilities)

# ❌ Wrong: OrderService does EVERYTHING
class OrderService:
    def create_order(self): pass
    def update_inventory(self): pass
    def charge_payment(self): pass
    def send_confirmation_email(self): pass
    def generate_invoice(self): pass
    def update_analytics(self): pass
    # 500+ lines in one class!

# ✅ Correct: Single Responsibility
class OrderService:
    def create_order(self, items):
        order = Order(items)
        self.inventory_service.reserve(items)  # Delegate!
        self.payment_service.charge(order)     # Delegate!
        self.email_service.send_confirmation(order)  # Delegate!
        return order

Mistake #3: Circular Dependencies

# ❌ Wrong: A imports B, B imports A
# users/service.py
from orders.service import OrderService

class UserService:
    def get_user_orders(self, user_id):
        return OrderService().get_by_user(user_id)

# orders/service.py
from users.service import UserService

class OrderService:
    def get_by_user(self, user_id):
        user = UserService().get_user(user_id)  # Circular!
        ...

# ✅ Correct: Use Dependency Inversion
# domain/interfaces.py
class UserRepository(ABC):
    @abstractmethod
    def find_by_id(self, user_id): pass

class OrderRepository(ABC):
    @abstractmethod
    def find_by_user(self, user_id): pass

# orders/service.py
class OrderService:
    def __init__(self, user_repo: UserRepository, order_repo: OrderRepository):
        self.user_repo = user_repo
        self.order_repo = order_repo

    def get_by_user(self, user_id):
        user = self.user_repo.find_by_id(user_id)  # No circular dependency!
        return self.order_repo.find_by_user(user_id)

Cross-References

Synergies with other frameworks:

MECE (#1) - Modules should be MECE (no overlapping responsibilities)
Tree Analysis (#2) - Code hierarchy (app → modules → classes → functions)
Dependency Mapping (#9) - Map module dependencies to avoid cycles

Synergies with Mental Models:

Circle of Competence (#5) - Each module has clear scope of responsibility
Occam's Razor (#18) - Simplest decomposition that works
Compound Interest (#3) - Good architecture compounds over time (easier changes)

Design Principles:

SOLID Principles - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
DRY - Don't Repeat Yourself
KISS - Keep It Simple, Stupid
YAGNI - You Aren't Gonna Need It

Framework #6: Business Problem Decomposition 📊

Definition

Business Problem Decomposition is the practice of breaking down strategic business challenges into actionable components: market segments, customer problems, value propositions, revenue streams, cost structures, and growth drivers.

Goal: Transform vague business goals into clear, measurable initiatives.

Core Principle

"If you can't measure it, you can't improve it."

— Peter Drucker

Key Insight: Decompose business problems into leading indicators (actions you control) and lagging indicators (outcomes you measure).

Step-by-Step Method

Step 1: Define the Business Goal

# What specific outcome do we want?
goal = {
    "metric": "Monthly Recurring Revenue (MRR)",
    "current": 50000,  # $50k/month
    "target": 100000,  # $100k/month
    "timeline": "6 months"
}

Step 2: Decompose Goal into Components (MECE)

# MRR = New Customers × ARPU + Existing Customers × ARPU - Churn
mrr_components = {
    "new_customer_revenue": {
        "new_customers_per_month": 20,
        "average_revenue_per_user": 200,
        "total": 4000  # $4k/month
    },
    "existing_customer_revenue": {
        "existing_customers": 250,
        "arpu": 200,
        "total": 50000  # $50k/month
    },
    "churn_loss": {
        "churned_customers": 10,
        "lost_revenue": -2000  # -$2k/month
    }
}

# Net MRR growth = +4k + 0 - 2k = +2k/month
# Time to reach $100k: (100k - 50k) / 2k = 25 months ❌ (Too slow!)

Step 3: Identify Levers to Pull

growth_levers = [
    {"lever": "Increase new customers", "from": 20, "to": 40, "impact": "+$4k MRR"},
    {"lever": "Increase ARPU (upsell)", "from": 200, "to": 250, "impact": "+$12.5k MRR"},
    {"lever": "Reduce churn", "from": 4, "to": 2, "impact": "+$1k MRR"},
]

# New MRR growth = +8k (new) + 12.5k (upsell) + 1k (churn reduction) = +21.5k/month
# Time to reach $100k: (100k - 50k) / 21.5k = 2.3 months ✅ (Achievable!)

Step 4: Create Action Plans

action_plans = {
    "increase_new_customers": [
        "Launch Facebook Ads ($5k/month budget → 20 new customers)",
        "Start content marketing (SEO → 10 organic signups/month)",
        "Build referral program (20% existing customers refer → 10 new)"
    ],
    "increase_arpu": [
        "Create premium tier ($400/month with advanced features)",
        "Upsell 25% of customers to premium → +$12.5k MRR"
    ],
    "reduce_churn": [
        "Implement onboarding email sequence (reduce early churn)",
        "Add usage monitoring (alert when customer stops using product)"
    ]
}

Step 5: Measure & Iterate

Track weekly: New customers, ARPU, churn rate
Monthly review: Adjust tactics based on data

Example #1: E-commerce Revenue Growth 🛒

Problem: "Increase revenue by 50% in 6 months"

Decomposition:

# Revenue = Traffic × Conversion Rate × Average Order Value × Repeat Rate

current_state = {
    "traffic": 10000,         # visitors/month
    "conversion_rate": 0.02,  # 2%
    "aov": 50,                # $50 per order
    "repeat_rate": 0.3,       # 30% buy again
    "revenue": 10000 * 0.02 * 50 * (1 + 0.3) = 13000  # $13k/month
}

target_revenue = 13000 * 1.5 = 19500  # $19.5k/month

# Which lever has biggest impact?
lever_analysis = [
    {
        "lever": "Traffic: 10k → 15k (+50%)",
        "new_revenue": 15000 * 0.02 * 50 * 1.3 = 19500,
        "cost": "$3k/month (ads)",
        "roi": "650%"
    },
    {
        "lever": "Conversion: 2% → 3% (+50%)",
        "new_revenue": 10000 * 0.03 * 50 * 1.3 = 19500,
        "cost": "$5k (CRO expert)",
        "roi": "1300% (one-time cost)"
    },
    {
        "lever": "AOV: $50 → $75 (+50%)",
        "new_revenue": 10000 * 0.02 * 75 * 1.3 = 19500,
        "cost": "$2k (bundling strategy)",
        "roi": "3250%"
    },
    {
        "lever": "Repeat: 30% → 45% (+50%)",
        "new_revenue": 10000 * 0.02 * 50 * 1.45 = 14500,
        "cost": "$1k (email automation)",
        "roi": "150%"
    }
]

# Best lever: AOV (highest ROI)
# Action: Create product bundles, volume discounts, upsell at checkout

Result:

Focus on AOV → Revenue $13k → $19.5k (+50%) in 3 months
Cost: $2k (one-time)
ROI: 3,250%

Example #2: Customer Churn Reduction 📉

Problem: "Churn rate is 8% per month (too high!)"

Decomposition by Customer Segment:

churn_by_segment = {
    "new_customers_0_30_days": {
        "churn_rate": 0.15,  # 15% churn!
        "customers": 100,
        "churned": 15,
        "revenue_lost": 15 * 99 = 1485  # $1.5k/month
    },
    "customers_31_90_days": {
        "churn_rate": 0.10,  # 10% churn
        "customers": 150,
        "churned": 15,
        "revenue_lost": 1485
    },
    "customers_91_365_days": {
        "churn_rate": 0.05,  # 5% churn (normal)
        "customers": 400,
        "churned": 20,
        "revenue_lost": 1980
    },
    "customers_365_plus_days": {
        "churn_rate": 0.02,  # 2% churn (loyal!)
        "customers": 350,
        "churned": 7,
        "revenue_lost": 693
    }
}

total_churn = (15 + 15 + 20 + 7) / 1000 = 0.057 = 5.7% ❌ (Wait, math error!)

# Recalculate:
weighted_churn = (
    (15 * 100) + (15 * 150) + (20 * 400) + (7 * 350)
) / (100 + 150 + 400 + 350)
# = (1500 + 2250 + 8000 + 2450) / 1000 = 14200 / 1000 = 14.2% (Still too high!)

Root Cause Analysis by Segment:

# Why do 0-30 day customers churn at 15%?
root_causes_new_customers = [
    "Poor onboarding (don't understand product)",
    "No value realization in first week",
    "Technical issues during setup",
    "Wrong customer fit (not qualified)"
]

# Fix Strategy:
fixes = {
    "0_30_days": [
        "Build interactive onboarding wizard",
        "Send daily tips email (7-day sequence)",
        "Offer 1-on-1 setup call",
        "Tighten qualification (reject bad-fit customers)"
    ],
    "31_90_days": [
        "Usage monitoring (alert when customer goes inactive)",
        "In-app feature discovery prompts",
        "Quarterly business review calls"
    ],
    "91_365_days": [
        "Annual plan discount (lock in customers)",
        "Exclusive features for annual subscribers"
    ]
}

Results After 3 Months:

new_churn_rates = {
    "0_30_days": 0.08,    # 15% → 8% (-47%)
    "31_90_days": 0.07,   # 10% → 7% (-30%)
    "91_365_days": 0.04,  # 5% → 4% (-20%)
    "365_plus": 0.02      # 2% → 2% (unchanged)
}

# Overall churn: 14.2% → 5.8% (-59%)
# Revenue saved: $5.6k/month × 12 = $67k/year

Example #3: Market Expansion Strategy 🌍

Problem: "Enter new market (Thailand)"

Decomposition:

market_entry_components = {
    "market_sizing": {
        "total_addressable_market": "5M potential customers",
        "serviceable_available_market": "500k qualified",
        "serviceable_obtainable_market": "50k realistic (Year 1)"
    },

    "customer_segments": [
        {
            "segment": "Bangkok professionals",
            "size": 30000,
            "willingness_to_pay": "High",
            "acquisition_cost": "$20",
            "ltv": "$500",
            "priority": 1  # Target first!
        },
        {
            "segment": "University students",
            "size": 15000,
            "willingness_to_pay": "Low",
            "acquisition_cost": "$5",
            "ltv": "$50",
            "priority": 3  # Target later
        },
        {
            "segment": "SME business owners",
            "size": 5000,
            "willingness_to_pay": "Very High",
            "acquisition_cost": "$100",
            "ltv": "$5000",
            "priority": 2  # Target second
        }
    ],

    "go_to_market_tactics": {
        "bangkok_professionals": [
            "Facebook Ads (Thai language)",
            "LinkedIn outreach",
            "Co-working space partnerships",
            "Bangkok tech meetup sponsorships"
        ],
        "sme_business_owners": [
            "Direct sales team (3 reps)",
            "Chamber of Commerce partnerships",
            "Trade show booths"
        ]
    },

    "localization_requirements": [
        "Translate app to Thai (10,000 strings)",
        "Thai payment gateway (PromptPay, TrueMoney)",
        "Thai customer support (hire 2 agents)",
        "Adapt pricing for Thai market ($99 → ฿999)"
    ],

    "milestones": {
        "month_1_3": "Localization complete, first 100 customers",
        "month_4_6": "Expand to 500 customers, hire local team",
        "month_7_12": "Reach 2,000 customers, profitability"
    }
}

Execution Priority:

Month 1-3: Localize product + target Bangkok professionals (high LTV, low risk)
Month 4-6: Add SME sales channel (highest LTV segment)
Month 7-12: Scale proven channels, add student segment if capacity allows

Expected Results Year 1:

Customers: 2,000
ARPU: $30/month (฿999/month)
MRR: $60k
LTV:CAC ratio: 10:1 (healthy)

Practice Exercise #6: SaaS Product Expansion 🚀

Scenario: Your SaaS product serves freelancers ($50k MRR). You want to expand to small agencies (5-10 person teams).

Question: How do you decompose this expansion?

💡 Solution (Click to Expand)

# Step 1: Understand the New Segment
agencies_vs_freelancers = {
    "freelancers": {
        "arpu": 49,
        "features_used": ["Individual workspace", "Basic reports"],
        "decision_maker": "Individual",
        "sales_cycle": "1 day (self-serve)"
    },
    "agencies": {
        "arpu": 299,  # 6x higher!
        "features_needed": [
            "Team collaboration",
            "Client management",
            "White-label reports",
            "Role-based permissions",
            "API access"
        ],
        "decision_maker": "Agency owner + team lead",
        "sales_cycle": "14 days (demo + trial)"
    }
}

# Step 2: Decompose What Needs to Change
changes_required = {
    "product": [
        "Build team workspaces (Est: 6 weeks)",
        "Add user roles & permissions (Est: 4 weeks)",
        "Build client portal (Est: 8 weeks)",
        "White-label customization (Est: 3 weeks)"
    ],

    "pricing": [
        "Create 'Agency' plan at $299/month",
        "Add annual plan option ($2,999/year = 2 months free)"
    ],

    "marketing": [
        "Create agency-focused landing page",
        "Case studies from early agency customers",
        "Content: 'How agencies use [Product] to scale'"
    ],

    "sales": [
        "Build demo script",
        "Create 14-day trial flow",
        "Hire 1 account executive (target: 10 demos/week)"
    ],

    "support": [
        "Onboarding checklist for agencies",
        "Dedicated account manager for $299+ plans"
    ]
}

# Step 3: Build Execution Roadmap
roadmap = {
    "month_1_2": {
        "focus": "Build MVP agency features",
        "deliverables": [
            "Team workspaces",
            "User roles",
            "Agency landing page"
        ],
        "target": "3 beta agencies"
    },

    "month_3_4": {
        "focus": "Refine product based on beta feedback",
        "deliverables": [
            "Client portal",
            "White-label reports",
            "Case studies from beta"
        ],
        "target": "10 paying agencies"
    },

    "month_5_6": {
        "focus": "Scale acquisition",
        "deliverables": [
            "Hire AE",
            "Launch paid ads targeting agencies",
            "Build referral program"
        ],
        "target": "30 agencies ($9k MRR from agencies)"
    }
}

# Step 4: Success Metrics
kpis = {
    "leading_indicators": [
        "Demo requests/week",
        "Trial activation rate",
        "Feature usage (team features)"
    ],
    "lagging_indicators": [
        "Agency customers count",
        "Agency MRR",
        "Agency churn rate"
    ]
}

# Expected Outcome:
# - Month 6: 30 agencies × $299 = $9k new MRR
# - Original freelancer MRR: $50k
# - Total MRR: $59k (+18% growth)
# - Agency LTV: $299 × 18 months = $5,382
# - Development cost: ~$80k (team time)
# - ROI: Break even at 15 agencies (achievable in Month 4)

Common Mistakes

Mistake #1: Vague Goals ("Increase revenue")

# ❌ Wrong: Too vague
goal = "Increase revenue"  # How much? By when? From what?

# ✅ Correct: Specific & measurable
goal = {
    "metric": "MRR",
    "from": 50000,
    "to": 100000,
    "by": "2025-06-30",
    "via": ["New customers", "Upsell existing", "Reduce churn"]
}

Mistake #2: Not Decomposing Enough (Stop at Surface Level)

# ❌ Wrong: Surface-level decomposition
plan = ["Increase traffic", "Improve conversion"]  # HOW?

# ✅ Correct: Deep decomposition
traffic_breakdown = {
    "organic": {
        "current": 3000,
        "target": 5000,
        "tactics": ["Publish 8 SEO articles/month", "Build 20 backlinks/month"]
    },
    "paid": {
        "current": 5000,
        "target": 8000,
        "tactics": ["Increase ad budget $3k → $5k", "Test 5 new ad creatives"]
    },
    "referral": {
        "current": 2000,
        "target": 4000,
        "tactics": ["Launch referral program with $50 credit incentive"]
    }
}

Mistake #3: Ignoring Constraints

# ❌ Wrong: Plan ignores budget constraint
plan = [
    "Hire 10 salespeople",  # $1M/year salary
    "Open 5 new offices"    # $500k setup
]
# Budget available: $200k ❌

# ✅ Correct: Plan within constraints
plan = [
    "Hire 2 SDRs ($120k total)",
    "Invest in marketing automation ($20k)",
    "Remaining $60k for paid ads"
]

Cross-References

Synergies with other frameworks:

MECE (#1) - Business components must be MECE (e.g., revenue sources)
Root Cause Analysis (#4) - Find why metrics are underperforming
Tree Analysis (#2) - Business hierarchy (company → departments → teams → individuals)

Synergies with Mental Models:

Leverage (#15) - Find high-leverage business activities
Pareto Principle (#14) - 80% of revenue from 20% of customers
Compound Interest (#3) - Business improvements compound over time

Business Frameworks:

Business Model Canvas - Decompose entire business model
Pirate Metrics (AARRR) - Acquisition, Activation, Retention, Referral, Revenue
OKRs - Objectives & Key Results framework

Install Skill

SKILL.md

Problem Decomposition Mastery: The Art of Breaking Down Complexity

Why This Meta-Skill Exists

Meta-Skill Structure

Part 1: Core Frameworks (4 frameworks)

Part 2: Domain-Specific Frameworks (4 frameworks)

Part 3: Advanced Techniques (4 frameworks)

How to Use This Skill

Part 1: Core Frameworks

Framework #1: MECE Decomposition

Definition

Core Principle

Step-by-Step Method

Example 1: Revenue Analysis (Business)

Example 2: Bug Root Cause (Software)

Example 3: Task Prioritization (Productivity)

Practice Exercise

Common Mistakes

Cross-References

Framework #2: Tree Analysis (Hierarchical Decomposition)

Definition

Core Principle

Step-by-Step Method

Example 1: Debug Production Issue (Software)

Example 2: Business Strategy (Increase Revenue)

Example 3: Learning New Skill (Personal Development)

Practice Exercise

Common Mistakes

Cross-References

Framework #3: Process Decomposition (Sequential Flow Mapping)

Definition

Core Principle

Step-by-Step Method

Example 1: Code Deployment Pipeline (DevOps)

Example 2: Content Creation Workflow (Business)

Example 3: Customer Onboarding (SaaS Product)

Practice Exercise

Common Mistakes

Cross-References

Framework #4: Root Cause Analysis (5 Whys & Fishbone Diagram)

Definition

Core Principle

Step-by-Step Method (5 Whys)

Fishbone Diagram Method

Example 1: Customer Churn (Business)

Practice Exercise

Common Mistakes

Cross-References

Part 2: Domain-Specific Frameworks

Framework #5: Code Decomposition 💻

Definition

Core Principle

Step-by-Step Method

Example #1: Monolith → Microservices 🏢

Example #2: Clean Architecture (Layers) 🎯

Example #3: Module Decomposition (Feature-Based) 🎨

Practice Exercise #5: Trading Bot Decomposition 🤖

Common Mistakes

Cross-References

Framework #6: Business Problem Decomposition 📊

Definition

Core Principle

Step-by-Step Method

Example #1: E-commerce Revenue Growth 🛒

Example #2: Customer Churn Reduction 📉

Example #3: Market Expansion Strategy 🌍

Practice Exercise #6: SaaS Product Expansion 🚀

Common Mistakes

Cross-References