Inversion Exercise

Process

1. List core assumptions — What "must" be true in your domain?
2. Invert each systematically — "What if opposite were true?"
3. Explore implications — What would we do differently?
4. Find valid inversions — Which actually work somewhere?

Instructions

When a user asks to invert assumptions:

1. Extract domain assumptions — Ask: "What are the 5 things everyone assumes must be true in [domain]?"
2. Invert each one — Create a table:

| Assumption | Inverted | Implications | Valid? |
|-----------|----------|-------------|--------|
| [standard belief] | [opposite] | [what changes] | [yes/no + why] |

3. Develop valid inversions into full idea concepts
4. Test boundaries — Where does the inversion break?
5. Extract the insight — State what the inversion taught you

Example

Problem: Users complain app is slow

Normal approach: Make everything faster (caching, optimization, CDN)

Inverted: Make things intentionally slower in some places

• Debounce search (add latency → enable better results)
• Rate limit requests (add friction → prevent abuse)
• Lazy load content (delay → reduce initial load)

Insight: Strategic slowness can improve UX

Red Flags You Need This

• "There's only one way to do this"
• Forcing solution that feels wrong
• Can't articulate why approach is necessary
• "This is just how it's done"

Remember

• Not all inversions work — test boundaries
• Valid inversions reveal context-dependence
• Sometimes the opposite IS the answer
• Question every "must be" statement
• The best hackathon ideas come from flipping what judges expect to hear