Assumption Challenger

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:

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 handles 10K concurrent users. What happens during a flash sale with 50K? What's the failure mode?"

The Dependency Audit

Trace assumption to its dependencies.

Template:

"For [assumption] to be true, what else must be true?"

Example:

"For your 6-week timeline to work, you need: (1) API specs finalized by week 1, (2) no scope changes, (3) 100% team availability, (4) no production incidents. How realistic is that?"

The Inverse Test

Consider what happens if assumption is wrong.

Template:

"If [assumption] is wrong, what's the impact? What's your Plan B?"

Example:

"If users don't adopt this feature, what's the fallback? Have you defined failure criteria?"

Wishful Thinking Indicators

Red flags that suggest assumption is based on hope rather than evidence:

1. The Optimistic Timeline

• "Should only take..."
• "If everything goes well..."
• "We can do it if we're focused..."

Reality: Things rarely go perfectly. Add 30-50% buffer.

2. The Magical Hiring

• "We'll just hire..."
• "Once we have the team..."
• "We're planning to bring on..."

Reality: Hiring takes 3-6 months for senior roles. Onboarding adds another 2-3 months to productivity.

3. The Simple Integration

• "It's just an API call..."
• "Should be straightforward..."
• "They have good documentation..."

Reality: Integrations always have edge cases, rate limits, and unexpected behaviors.

4. The Obvious Market

• "Everyone needs this..."
• "Users have been asking for..."
• "It's clear that..."

Reality: "Everyone" is not a market segment. Validate with actual user research.

5. The Linear Scaling

• "If we can do X, we can do 10X..."
• "We'll scale as needed..."
• "Growth shouldn't be a problem..."

Reality: Scaling is non-linear. What works at 10K users may fail at 100K.

Output Format

When challenging assumptions, provide:

# Assumption Analysis: [Plan/Proposal Name]

## Summary
- **Total Assumptions Identified**: [Count]
- **High-Risk Assumptions**: [Count]
- **Requires Immediate Validation**: [Count]

## Critical Assumptions (Must Validate Before Proceeding)

### Assumption 1: [Statement]

**Category**: Timeline / Resource / Technical / Business / External
**Stated or Implicit**: Stated / Implicit

**The Problem**:
[Why this assumption is questionable]

**Evidence For**:
- [Supporting evidence]

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

**If Wrong, Impact**:
- Timeline: [Impact]
- Budget: [Impact]
- Success: [Impact]

**How to Validate**:
- [Validation method]
- [Time required]
- [Cost]

**Verdict**: Valid / Questionable / Invalid / Unknown

---

### Assumption 2: [Statement]
[Same format]

---

## Medium-Risk Assumptions (Should Validate)
[List with brief analysis]

## Low-Risk Assumptions (Monitor)
[List]

## Recommendations

### Before Proceeding
1. [Validation action 1]
2. [Validation action 2]

### Risk Mitigation
1. [Mitigation for assumption 1]
2. [Mitigation for assumption 2]

### Contingency Plans Needed
1. [Plan B for assumption 1]
2. [Plan B for assumption 2]

Integration with Validation

The assumption-challenger skill feeds into the broader validation workflow:

Proposal/Plan
     │
     ▼
[assumption-challenger] → List of assumptions with verdicts
     │
     ▼
[antipattern-detector] → Identified anti-patterns
     │
     ▼
[validation-report-generator] → Final 8-section report

References

• Wishful Thinking Patterns - Common patterns to watch for
• Challenge Questions - Ready-to-use challenge questions by category