Leap-of-Faith MVP Scoping
Scope the smallest build that tests your riskiest assumption, not a stripped-down product
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
An MVP is not a low-quality product; it is whatever most efficiently validates the specific hypothesis you are testing. Ries reframes MVP as a deductive chain that runs from vision down to a concrete experiment, so the size and polish of the build are dictated by what you need to learn, not by a fixed idea of 'basic'. The chain forces founders to admit what they don't yet know.
Origin
Eric Ries's Lean Startup methodology (2011), derived from his experience building IMVU and later systematized for large enterprises in The Startup Way.
Core principles
- 01Quality is defined by the customer; if you don't know your customer you don't know what quality means
- 02The MVP is the most efficient way to get validation about whether a hypothesis is true
- 03People are naturally off by one or two orders of magnitude on what is 'necessary'
- 04If the bar is genuinely high, ship one critical feature at that bar rather than many features at once
- 05Containing the liability of a mistake matters more than avoiding the mistake
How to run it
- 1
State the leap-of-faith assumption
Name the specific thing you believe must be true for the business to work, and admit you don't yet know if it is. This is upstream of everything and is where most founders get stuck because they won't admit uncertainty.
Pro tip Ask 'what do I actually want to learn?' The most common reason people can't design an MVP is they haven't answered this.
Watch out Refusing to admit you don't know the answer poisons the whole chain.
- 2
Pick the learning metric
For each assumption brainstorm candidate metrics, then select the one metric that will tell you whether the assumption holds.
- 3
Establish a baseline with 10 customers
Find 10 real customers (not 10 million), get them to use the product, and have them tell you what's awful. This confirms where you actually stand today so improvement is measurable.
Pro tip Even if you're certain you're right, double-checking costs almost nothing and confirms you're on track.
Watch out Waiting for high quality then getting zero usage leaves you unable to tell if the value prop or the execution failed.
- 4
Cut the feature list in half, twice
Write the list of features you think are necessary for the MVP, cut it in half, then cut it in half again, and build that.
Pro tip MVP sizing is a U-shaped curve: get anywhere near optimal and you'll be fine, so err uncomfortably small.
Watch out Treating MVP as a fixed tactic ('a bare-bones thing that crashes') rather than a hypothesis test misses the point entirely.
In the wild
A team had PhDs pursuing a Nobel-level materials breakthrough to make a data-center product more efficient, budgeting three years and $18M. Ries convinced them to first take a brochure to customers. Customers laughed them out of the room, saying operating cost was someone else's problem and they'd never buy on efficiency.
→ The core leap-of-faith assumption (customers pay for efficiency) was falsified in days instead of after three years and $18M.
IMVU couldn't afford inverse kinematics to let avatars walk, so as an embarrassing hack Ries made avatars simply disappear and reappear when users clicked a new spot. He shipped it feeling it was below the quality bar. Tracking surveys then showed users rating IMVU as more advanced than The Sims, because teleporting was faster than waiting for a character to walk.
→ A feature the engineers were ashamed of became a competitive advantage; they didn't build inverse kinematics for a long time.
Common mistakes
Equating 'minimum' with cheap or low quality
MVPs can be extremely high-end; the LTSE MVP took 10 years. Minimum means the least work needed to test the hypothesis, whatever the required quality bar is.
Building 100x more than needed to test an assumption
Founders routinely try to do one or two orders of magnitude more work than the experiment requires because they won't cut features.
Is it for you?
Best for
First-time founders or product leaders who keep expanding scope before validating whether customers want the thing at all
Not ideal for
A pure artist building only for themselves and a market of one, who explicitly isn't testing customer demand
From the transcript
“MVP is simply for whatever the hypothesis is that we're trying to test what is the most efficient way to get the validation we need…”
“write out the list of features that are necessary in your MVP cut it in half and cut it in half again and build that”
“go find 10 customers not 10 million but like find 10 customers get them to use the product and have them tell you what's awful”
“you should first brainstorm your leap of faith assumptions and here and categorize them this way and select them like this okay now for each…”
From the episode
Reflections on a movement
Eric Ries (creator of the Lean Startup methodology)