/assumption-challenger

name: assumption-challenger
description: Identify and challenge implicit assumptions in plans, proposals, and technical decisions. Use when strategic-cto-mentor needs to surface hidden assumptions and wishful thinking before they become costly mistakes.

Assumption Challenger

Systematically identifies and stress-tests assumptions that are treated as facts but may not be validated.

When to Use

• Validating roadmaps and project plans
• Reviewing architecture proposals
• Assessing build vs buy decisions
• Evaluating timelines and budgets
• Challenging strategic initiatives

Why Assumptions Matter

Most project failures trace back to invalid assumptions:

• **Timeline assumptions**: "We can ship in 6 weeks" (based on nothing)
• **Resource assumptions**: "We'll hire 3 engineers" (in a tight market)
• **Technical assumptions**: "The API can handle 10K requests/sec" (never tested)
• **Business assumptions**: "Users will adopt this feature" (never validated)

**The cost of invalid assumptions compounds over time.** A bad assumption in week 1 can waste months of work.

---

Assumption Categories

1. Timeline Assumptions

Assumptions about how long things will take.

**Common patterns**:

• "This should only take 2 weeks"
• "We'll have the integration done by launch"
• "The team can absorb this additional scope"

**Challenge questions**:

• What's this estimate based on? Past experience or hope?
• What similar work have we done? How long did it actually take?
• What's not included in this estimate? (Testing, documentation, deployment)
• What happens if this takes 2x longer?

2. Resource Assumptions

Assumptions about team capacity and availability.

**Common patterns**:

• "We'll hire 2 senior engineers by Q2"
• "The DevOps team can support this"
• "Sarah can lead this while maintaining her other work"

**Challenge questions**:

• What's the hiring timeline? What if we can't find the right people?
• What's the team's current utilization? Where does time come from?
• Who's the backup if the key person is unavailable?
• What happens if the team is 50% of expected capacity?

3. Technical Assumptions

Assumptions about system capabilities and constraints.

**Common patterns**:

• "The database can handle the load"
• "We can integrate with their API easily"
• "Our architecture supports this use case"

**Challenge questions**:

• Has this been tested at the required scale?
• What are the documented limits? What happens at those limits?
• What's the failure mode? How do we recover?
• Have we talked to the API provider about our usage patterns?

4. Business Assumptions

Assumptions about market, users, and business outcomes.

**Common patterns**:

• "Users want this feature"
• "This will reduce churn by 20%"
• "The market will wait for our solution"

**Challenge questions**:

• What evidence supports this? User research? Data?
• What if users don't adopt this? What's the fallback?
• What are competitors doing in this space?
• How will we know if this assumption is wrong?

5. External Assumptions

Assumptions about factors outside your control.

**Common patterns**:

• "The vendor will have the feature ready"
• "Regulations won't change"
• "The market will remain stable"

**Challenge questions**:

• What's our contingency if this doesn't happen?
• What's the vendor's track record on commitments?
• What early warning signs would indicate this is wrong?
• What's the cost of being wrong?

---

Assumption Identification Process

Step 1: Surface Assumptions

Read the proposal and identify statements that are treated as facts but aren't validated:

**Flag statements containing**:

• "We will..." (without evidence)
• "We can..." (without proof)
• "Users want..." (without data)
• "It should..." (without testing)
• "We expect..." (without basis)
• "We assume..." (at least they're honest)

Step 2: Categorize Assumptions

For each assumption, categorize:

| Category | Risk if Wrong | Validation Difficulty | |----------|---------------|----------------------| | Timeline | Project delay | Medium (compare to past) | | Resource | Execution failure | Medium (check market) | | Technical | System failure | High (requires testing) | | Business | Wasted investment | High (requires market validation) | | External | Plans disrupted | Variable |

Step 3: Assess Each Assumption

For each significant assumption:

### Assumption: [Statement]

**Category**: [Type]
**Stated or Implicit**: [Was it stated or hidden?]

**Evidence Supporting**:
- [Evidence 1]
- [Evidence 2]

**Evidence Against**:
- [Counter-evidence 1]
- [Counter-evidence 2]

**Risk if Wrong**:
- [Impact on timeline]
- [Impact on cost]
- [Impact on success]

**Validation Method**:
- [How to test this assumption]
- [Cost/time to validate]

**Verdict**:
[ ] Valid - Evidence supports
[ ] Questionable - Needs validation
[ ] Invalid - Evidence contradicts
[ ] Unknown - Cannot assess

Step 4: Prioritize Challenges

Focus on assumptions that are: 1. **High impact** - Project fails if wrong 2. **Low evidence** - Based on hope, not data 3. **Testable** - Can be validated before commitment

---

Challenge Patterns

The Reality Check

Compare assumption to external data.

**Template**: > "You assume [X]. Industry data shows [Y]. What makes you different?"

**Example**: > "You assume you can hire 3 senior engineers in 2 months. The average time-to-hire for senior engineers in your market is 4-6 months. What's your strategy to beat that?"

The History Test

Compare to organization's past performance.

**Template**: > "You assume [X]. Last time you attempted [similar thing], it took [Y]. What's changed?"

**Example**: > "You assume 8 weeks for the microservices migration. Your last infrastructure migration took 5 months. What's different this time?"

The Stress Test

Push assumption to failure point.

**Template**: > "You assume [X]. What happens when [stress scenario]?"

**Example**: > "You assume the system hand