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
Converted and distributed by TomeVault — claim your Tome and manage your conversions.