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