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