Novice Foundation Challenge
Use outsider questions and adjacent mechanisms to escape expert assumptions
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 97%
Begin by making expert assumptions visible. List what the field treats as fixed, then distinguish laws of physics, regulation, and demonstrated constraints from conventions inherited from earlier solutions. Translate the system into the functions it must perform and search other industries for mechanisms that perform comparable functions differently. Recombine those mechanisms into a candidate architecture, then invite domain experts to disprove it. Jain's Moon Express example uses software-style modularity: instead of one enormous rocket doing every stage, use a cheaper vehicle to reach low-Earth orbit and a small propulsion system on the lander for the next leg. The framework treats novice status as a source of questions, not as permission to ignore expertise. Outsiders generate alternatives; evidence and specialists determine whether they survive.
Origin
Jain describes approaching spaceflight like a software designer, replacing a monolithic rocket assumption with modules that handle different stages of the journey.
Core principles
- 01Expert knowledge creates useful skill and hidden anchors
- 02Breakthroughs require testing assumptions beneath accepted practice
- 03Adjacent industries offer mechanisms insiders may overlook
- 04Outsiders still need experts to test safety and feasibility
How to run it
- 1
Expose the anchors
Ask experts to name practices that everyone in the industry assumes must remain true.
Pro tip Listen for phrases such as “the only way” and “everyone knows.”
Watch out Deep expertise is not itself the problem; invisible assumptions are.
- 2
Classify each foundation
Mark each assumption as a physical limit, legal requirement, measured trade-off, or inherited convention.
Pro tip Demand evidence for anything classified as a hard constraint.
- 3
Translate objects into functions
Describe what each component must achieve without naming its current implementation.
Pro tip A rocket becomes a sequence of propulsion and transport functions.
- 4
Import an adjacent mechanism
Find a field that solves an analogous functional problem with a different architecture.
Pro tip Use analogy to generate a hypothesis, not to prove one.
Watch out Surface similarity can hide different constraints.
- 5
Build the smallest alternative
Create a bounded prototype or model that tests whether the imported mechanism changes the key economics or performance.
Pro tip Test the assumption that creates the largest cost or complexity first.
- 6
Invite expert falsification
Ask specialists to identify safety, feasibility, and second-order failures before scaling the idea.
Pro tip Frame the review as an attempt to kill the hypothesis.
Watch out Outsider confidence without validation becomes avoidable recklessness.
In the wild
Moon Express questioned the assumption that a lunar mission required one massive rocket. The team considered using the smallest cheap rocket that could reach low-Earth orbit, then letting the lander's smaller rockets perform the remaining journey, analogous to modular software components.
→ Jain says the architectural change reduced the projected lunar mission cost from a billion dollars to under ten million dollars.
An XPRIZE finalist team of a tattoo artist, mechanic, and dentist approached oil cleanup without the industry's inherited design. Jain says their device cost under a million dollars and performed four times better than the existing approach.
→ A cross-disciplinary outsider team exceeded the prize's two-times improvement target.
Common mistakes
Confusing ignorance with insight
Knowing less creates freedom to question, but it does not make an untested answer correct.
Copying an analogy literally
Transfer the mechanism only after checking whether the target field has materially different constraints.
Excluding domain experts
Use experts as falsifiers and safety checks rather than allowing convention to define the initial design space.
Is it for you?
Best for
It is best for cross-functional teams entering a mature industry with entrenched architecture or incentives.
Not ideal for
It is not ideal when safety-critical domain knowledge is excluded rather than used to test an outsider's hypothesis.
From the transcript
“unless you're willing to challenge the foundations you can never make it make it disruptive improvement in anything”
“being in novice or non expert is what allows them to rethink that new industry”
“I was thinking more like a software person thinking why can't we build multiple modules that actually build on top of each other”
From the episode
Naveen Jain: Becoming Astronomically Ambitious
Naveen Jain