Impossible-to-Solvable Decomposition
Turn an impossible goal into one concrete problem you can solve
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 98%
Start by replacing “this is impossible” with “what would have to become true?” Then break the desired outcome into its underlying requirements rather than accepting the conventional implementation. Classify each requirement as already solved, likely to mature independently, transferable from nature or another field, or genuinely unresolved. Keep drilling until the intimidating mission collapses into one or two bounded constraints that a team can test. Jain demonstrates the mechanism with living on the moon: radiation resistance may be addressed by biology and maturing gene editing, energy can be separated from food, and nutrients can be reduced to elements. The remaining uncertainty becomes nitrogen supply, a much more concrete problem than “humans cannot live on the moon.”
Origin
Jain illustrates the method by decomposing human life on the moon into radiation protection, energy, nutrients, and ultimately the bounded problem of obtaining enough nitrogen.
Core principles
- 01An impossible verdict hides unanswered design questions
- 02Requirements become tractable when separated from inherited solutions
- 03Nature and adjacent fields may have already solved a component
- 04A moonshot advances by isolating its smallest genuine unknown
How to run it
- 1
Convert the verdict into a question
Replace a declaration that the goal is impossible with a question about which technologies or conditions would make it possible.
Pro tip Phrase the question without naming the conventional solution.
Watch out Do not let today's technical limits become permanent assumptions.
- 2
Identify fundamental requirements
Ask what outcome each apparent requirement actually serves. Reduce familiar objects such as food into functions such as energy and nutrients.
Pro tip Keep asking why the requirement exists until you reach a physical or human need.
Watch out A familiar input is not necessarily a fundamental requirement.
- 3
Inventory available mechanisms
Look for mechanisms in nature, adjacent industries, and technologies already improving on their own timeline.
Pro tip Borrow mechanisms rather than copying whole products.
Watch out Treat forecasts as assumptions to monitor, not facts.
- 4
Remove solved constraints
Set aside requirements that existing or independently maturing technologies can plausibly satisfy. Keep them on a dependency list without making them the team's immediate work.
Pro tip Record what evidence would invalidate each dependency assumption.
- 5
Isolate and test the residual
State the smallest remaining unknown in concrete terms and design the cheapest experiment that reduces uncertainty about it.
Pro tip If the residual still sounds impossible, decompose it again.
Watch out Do not confuse a smaller statement with a solved problem.
In the wild
Jain separates lunar survival into radiation, energy, and nutrient requirements. He points to radiation-tolerant organisms and future gene editing, asks why humans need food, breaks nutrients into hydrogen, oxygen, and nitrogen, and notes that lunar water can provide the first two. This leaves finding or transporting enough nitrogen as the bounded residual problem.
→ A vague impossibility becomes a specific resource question that can be investigated.
A water startup could replace “cheap desalination is impossible” with requirements for separation, energy, materials durability, and distribution. It can then identify which constraints are already improving and test the one unresolved membrane mechanism first.
→ The team funds a bounded technical experiment instead of an undefined moonshot.
Common mistakes
Treating the current solution as a requirement
If food, rockets, or today's medical workflow is treated as fundamental, the team never explores another way to provide the underlying function.
Assuming dependencies will mature
A forecast can focus current work, but it remains a dependency that needs monitoring and a fallback.
Stopping before the residual is testable
Renaming a large challenge does not decompose it; the remaining unknown must support a concrete experiment.
Is it for you?
Best for
It is best for founders, researchers, and innovation teams pursuing goals that initially appear technically impossible.
Not ideal for
It is not ideal for routine execution problems whose requirements and solutions are already well understood.
From the transcript
“don't think about what is impossible think about how to take the problem that seemingly looks impossible and say what technologies need to be developed…”
“the question we need to be asking instead is why do we eat food”
“you took something that seemed impossible and broke it down to something that's easy to solve or at least easy to put your arms around”
From the episode
Naveen Jain: Becoming Astronomically Ambitious
Naveen Jain