Two Question Problem Solving

---
name: two-question-problem-solving
description: Approach any significant problem by first identifying who has solved it and what can be learned from their approach.
license: MIT
metadata:
  author: sethmblack
  version: 1.0.5239
repository: https://github.com/sethmblack/paks-skills
keywords:
- storytelling
- two-question-problem-solving
- writing
---

# Two-Question Problem Solving

Approach any significant problem by first identifying who has solved it and what can be learned from their approach.

---

## When to Use

- Facing a new type of challenge you haven't encountered before
- Entering unfamiliar territory (new market, new domain, new role)
- Tempted to start from scratch when proven solutions may exist
- User asks "How do I approach this problem?" or "Who's solved this before?"

---

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| problem | Yes | The challenge you're trying to solve |
| context | Yes | Your specific situation, constraints, resources |
| attempted | No | What you've already tried |

---

## Gates's Two Questions

"Ever since I was a teenager, I've tackled every big new problem the same way: by starting off with two questions."

### Question 1: Who has dealt with this problem well?

Find precedents. Someone has almost certainly faced a similar challenge and either succeeded or failed instructively.

### Question 2: What can I learn from them?

Extract the transferable principles. Work backward from their solution to understand what made it work (or not work).

### The Core Insight

The best way to solve a problem is to find people who have actually solved it and work backward from their solution. Don't reinvent wheels—leverage the world's accumulated experience.

---

## Workflow

### Step 1: Gather and Review Inputs

Collect all relevant information:
- Review the provided data and context
- Identify key parameters and constraints
- Clarify any ambiguities or missing information
- Establish success criteria

### Step 2: Analyze the Situation

Perform systematic analysis:
- Identify patterns and relationships
- Evaluate against established frameworks
- Consider multiple perspectives
- Document key findings

### Step 3: Generate Recommendations

Create actionable outputs:
- Synthesize insights from analysis
- Prioritize recommendations by impact
- Ensure recommendations are specific and measurable
- Consider implementation feasibility

## Output Format

```markdown
## Two-Question Analysis

### Problem Statement
[Clear articulation of what you're trying to solve]

### Context
[Your specific situation, constraints, and resources]

---

## Question 1: Who Has Dealt With This Well?

### Direct Precedents
People/organizations who faced nearly identical challenges.

| Who | Situation | Outcome | Why Relevant |
|-----|-----------|---------|--------------|
| [Person/Org 1] | [Their challenge] | [Result] | [Similarity to yours] |
| [Person/Org 2] | [Their challenge] | [Result] | [Similarity to yours] |

### Analogous Precedents
People/organizations who faced structurally similar challenges in different domains.

| Who | Their Domain | The Parallel | Outcome |
|-----|--------------|--------------|---------|
| [Person/Org] | [Field] | [How it maps] | [Result] |

### Instructive Failures
People who tried and failed—often more instructive than successes.

| Who | What They Tried | Why It Failed | Lesson |
|-----|-----------------|---------------|--------|
| [Person/Org] | [Approach] | [Failure mode] | [What to avoid] |

---

## Question 2: What Can I Learn From Them?

### Success Patterns
What the successful precedents had in common.

| Pattern | Evidence | Applies to Your Situation |
|---------|----------|---------------------------|
| [Common element 1] | [Who did this] | [Yes/No/Partially + why] |
| [Common element 2] | [Who did this] | [Yes/No/Partially + why] |

### Failure Patterns
What the failures had in common.

| Anti-Pattern | Evidence | Your Risk Level |
|--------------|----------|-----------------|
| [Common failure mode] | [Who failed this way] | [High/Med/Low] |

### Key Transferable Principles
The lessons extracted from precedent analysis.

1. **[Principle 1]:** [Explanation and evidence]
   - How it applies: [Specific application to your context]

2. **[Principle 2]:** [Explanation and evidence]
   - How it applies: [Specific application to your context]

3. **[Principle 3]:** [Explanation and evidence]
   - How it applies: [Specific application to your context]

### What Doesn't Transfer
Important differences between precedents and your situation.

| Precedent Condition | Your Condition | Implication |
|---------------------|----------------|-------------|
| [What was true for them] | [What's true for you] | [How to adapt] |

---

## Synthesis: Your Approach

### Adapted Strategy
[How you'll apply the lessons, customized for your context]

### Key Actions
1. [First step, informed by precedent]
2. [Second step]
3. [Third step]

### Risk Mitigation
Based on failure pattern analysis:
| Risk | Mitigation |
|------|------------|
| [Risk from failure patterns] | [How you'll avoid it] |

### Precedent Gaps
Where you're in genuinely uncharted territory:
[What aspects of your situation have no clear precedent—proceed with extra caution here]

### The Gates Verdict
[Summary of the analysis and recommended approach]
```

---

## How to Find Precedents

### Direct Search Methods
1. **Industry case studies** - Harvard Business School, trade publications
2. **Biographies and memoirs** - Leaders who faced similar challenges
3. **Postmortems** - Failure analyses are often more honest than success stories
4. **Expert interviews** - "Have you seen this challenge before? What happened?"

### Analogous Domain Mapping
Think about your problem abstractly, then look for similar patterns:
- "Scaling a marketplace" → Uber, Airbnb, eBay, classified ads
- "Entering a market dominated by an incumbent" → Any disruption story
- "Building a brand in a commoditized category" → Starbucks (coffee), Dyson (vacuums)
- "Managing rapid growth" → Hypergrowth startup literature

### Red Flags in Precedent Analysis
- **Survivor bias:** You're only seeing who succeeded; what about the failures?
- **Context collapse:** Their situation may differ from yours in crucial ways
- **Recency bias:** Old precedents may be more robust than recent ones
- **Narrative oversimplification:** Success stories are often cleaned up

---

## Outputs

**Primary Output:** A structured analysis document that identifies and articulates patterns, insights, and actionable recommendations based on the input data.

**Format:**
```markdown
## Analysis: [Topic]

### Key Findings
- [Finding 1]
- [Finding 2]
- [Finding 3]

### Recommendations
1. [Action 1]
2. [Action 2]
3. [Action 3]
```

**Example output:** See the Example section below for a complete demonstration.

## Constraints

- Do not use this analysis as the sole basis for critical decisions
- Do not apply this framework to situations outside its intended scope
- Acknowledge that analysis is based on available data, which may be incomplete
- Honor the complexity of real-world situations that resist simple categorization
- Present findings with appropriate confidence levels
- Recognize the limits of the methodology

## Example

**Input:** "I'm a first-time founder building a B2B SaaS company. I need to figure out how to hire my first 10 employees. I have $1.5M in seed funding."

**Output:**



**Why this works:**

This example demonstrates the key principles of the skill in action. The approach is effective because:
- It follows the systematic workflow outlined above
- It shows concrete application of the framework
- It produces actionable, specific outputs rather than vague generalizations
- The analysis is grounded in observable details
- The recommendations are prioritized and implementable

**Alternative applications:**

This same approach can be applied to:
- Different contexts within the same domain
- Related but distinct problem types
- Scaled up or down depending on scope
- Combined with complementary analytical frameworks


## Two-Question Analysis

### Problem Statement
How to hire the first 10 employees for an early-stage B2B SaaS startup with $1.5M seed funding—getting the right people, at the right pace, without running out of money.

### Context
- First-time founder
- B2B SaaS product (assume functional MVP)
- $1.5M runway (roughly 18-24 months depending on burn)
- Starting from zero employees

---

## Question 1: Who Has Dealt With This Well?

### Direct Precedents

| Who | Situation | Outcome | Why Relevant |
|-----|-----------|---------|--------------|
| Basecamp (DHH/Fried) | Bootstrapped, slow hiring, first employees carefully selected | Profitable $100M+ company, never took VC | Model for capital-efficient hiring |
| Slack (Stewart Butterfield) | Tiny team built Slack internally before launch | 8 people built the initial product | Example of small team, large impact |
| Stripe (Collisons) | First 10 hires were extremely selective, prioritized generalists | $95B company | Extreme emphasis on hiring bar |
| Notion (Ivan Zhao) | Rebuilt product with just 4 people; slow, deliberate hiring | $10B company | Small team, long timeline |

### Analogous Precedents

| Who | Their Domain | The Parallel | Outcome |
|-----|--------------|--------------|---------|
| Navy SEALs selection | Military | Extreme selectivity for small teams with high stakes | Top performance despite small numbers |
| Y Combinator advice | Startup accelerator | Thousands of data points on early hiring | Crystallized patterns |

### Instructive Failures

| Who | What They Tried | Why It Failed | Lesson |
|-----|-----------------|---------------|--------|
| Numerous failed startups | Hired fast to "look like a real company" | Burn rate exceeded progress; couldn't make payroll | Hire slow, validate need |
| Early Uber | Hired for speed, ignored culture | Had to replace most early hires | Culture debt is real |
| Various Y Combinator failures | Hired specialists too early | Couldn't pivot when needed | Generalists first |

---

## Question 2: What Can I Learn From Them?

### Success Patterns

| Pattern | Evidence | Applies to Your Situation |
|---------|----------|---------------------------|
| Extreme selectivity on early hires | Stripe, Notion, Slack all waited for exceptional people | YES - first hires shape culture and capability |
| Generalists before specialists | YC advice, Basecamp practice | YES - at 10 people, everyone does multiple jobs |
| Founders do functional work longer | All successful precedents | YES - don't hire to avoid work, hire to multiply |
| Network hiring for first 5 | Nearly universal pattern | YES - trust and known quality matter most |
| Under-hire relative to funding | Capital-efficient winners | YES - $1.5M should last 24+ months |

### Failure Patterns

| Anti-Pattern | Evidence | Your Risk Level |
|--------------|----------|-----------------|
| Hiring to hit headcount milestones | Multiple YC failures | MEDIUM - resist investor pressure |
| Hiring people who need management | Early-stage failures | HIGH - first hires must be self-directed |
| Hiring specialists before product-market fit | Numerous pivots failed due to rigid team | HIGH - stay flexible |
| Hiring to impress (fancy titles, big names) | Various startup postmortems | LOW - be aware |

### Key Transferable Principles

1. **The Stripe Standard:** "Is this person in the top 1% of people you've ever worked with?"
   - How it applies: Use this bar for first 10 hires. Better to wait than compromise.

2. **The Basecamp Rule:** "Hire when it hurts"
   - How it applies: Don't hire until the work is clearly impossible for current team. Validate the need.

3. **The YC Generalist Principle:** "First 10 hires should be able to do almost anything"
   - How it applies: Engineers who can do sales calls. Marketing people who can debug code. Flexibility > specialization.

4. **The Network Priority:** "First 5 from direct relationships, next 5 from their networks"
   - How it applies: Start with people you know and trust. Use their referrals for the next tier.

### What Doesn't Transfer

| Precedent Condition | Your Condition | Implication |
|---------------------|----------------|-------------|
| Stripe founders knew many Stanford engineers | First-time founder, possibly smaller network | Invest more time in sourcing; accept slower pace |
| Basecamp was bootstrapped, different economics | VC-funded with growth expectations | May need to hire slightly faster, but resist overhiring |
| Slack was a pivot from a game company, had existing team | Starting from scratch | Will take longer to build trust and chemistry |

---

## Synthesis: Your Approach

### Adapted Strategy
Hire extremely selectively, prioritizing generalists from your network, at a pace slower than your funding might suggest. Use the "hire when it hurts" rule—only add when current capacity is clearly insufficient.

### Key Actions
1. **Week 1-4:** Map your network completely. Who do you know? Who do they know? Identify potential first hires before posting any jobs.

2. **Month 1-3:** Make first 2-3 hires from direct network. These people set the culture. Apply Stripe standard ruthlessly.

3. **Month 3-6:** Use first hires' networks for next 3-4 people. Let your A-players recruit their A-player friends.

4. **Month 6-12:** Consider expanding to broader sourcing for remaining positions. By now you have a culture worth protecting.

5. **Throughout:** Only hire when current team cannot do the work. Resist hiring ahead of need.

### Risk Mitigation

| Risk | Mitigation |
|------|------------|
| Hiring too fast, burning runway | Set firm rule: must justify each hire's ROI before opening role |
| Hiring specialists, losing flexibility | No specialists before product-market fit. Everyone must be willing to do other work |
| Compromising quality under pressure | Have a trusted person outside company hold you accountable to hiring bar |

### Precedent Gaps
- Your specific technical domain may have limited precedent
- Current labor market conditions may differ from precedent eras
- Your network composition may require different sourcing strategy

### The Gates Verdict

The founders who've done this well all say the same thing: your first 10 hires either accelerate you or anchor you. There's no fixing bad early hires—you just live with the consequences.

The pattern is clear: hire extremely selectively, hire generalists, hire from your network first, and hire slower than your funding suggests you can afford. Everyone who's failed has tried to shortcut this. Everyone who's succeeded has been patient.

Your $1.5M gives you time. Use it for selectivity, not speed. Ten exceptional people who can each do three jobs will outperform thirty average specialists every time.

---

## Integration

This skill is part of the **Bill Gates** expert persona. Use it to approach any significant new problem by first learning from those who've solved it before.