assumption-validation

# Assumption Validation

## Overview
Test whether an assumption is true or false before making commitments based on it.

## When to Use
- When an assumption has low certainty and high risk
- Before major resource commitments
- When stakeholders challenge your reasoning
- During Empathize and Define phases

## How to Apply

### 1. State the Assumption Clearly
Make it testable. Transform vague beliefs into specific claims:
- ❌ "Users want better tools"
- ✅ "Users spend >2 hours/week on manual data entry and would use an automated solution"

### 2. Define What Would Validate or Invalidate
Be explicit about criteria:
- **Validates**: 8+ out of 10 users report >2 hrs/week on manual entry
- **Invalidates**: <5 out of 10 users report this, or they prefer manual control
- **Inconclusive**: Mixed results, need different approach

### 3. Choose Validation Method
Match method to assumption type:

**User behavior/needs**: Interviews, observation, surveys
**Technical feasibility**: Spikes, prototypes, vendor demos
**Market conditions**: Market research, competitor analysis
**Business viability**: Financial modeling, expert consultation

### 4. Execute Validation
Conduct research with focus on disproving, not confirming:
- Ask open-ended questions
- Observe actual behavior, not just stated preferences
- Look for contradictory evidence
- Talk to diverse user types

### 5. Update Status
Record findings in currentstate.json:
- **Validated**: Evidence supports the assumption
- **Invalidated**: Evidence contradicts it
- **Partially validated**: More complex than assumed
- **Needs more research**: Inconclusive

### 6. Act on Findings

**If validated**: Proceed with confidence, but stay alert for new evidence

**If invalidated**: 
- Update problem framing
- Revise approach
- Generate new assumptions
- May need to pivot

**If partially validated**:
- Refine the assumption
- Identify what's true and what's not
- Adjust plans accordingly

## Example

**Assumption**: "Field technicians need offline access"

**Validation Plan**:
- Interview 8 field technicians
- Ask about connectivity at work locations
- Observe their current workarounds
- Ask what happens when connection drops

**Findings**:
- 7/8 work in areas with spotty connectivity
- All have experienced data loss from connection drops
- All use workarounds (paper notes, photos) when offline
- Strong preference for offline-first design

**Result**: VALIDATED — Offline access is a critical requirement

**Action**: Prioritize offline functionality in ideation phase

## Tips
- Seek to disprove, not confirm
- Sample diverse users, not just friendly ones
- Observe behavior, don't just ask
- Document exact evidence, not interpretations
- Update currentstate.json immediately
- One assumption may spawn new assumptions