TThe Foundr Podcast
← All frameworks
Entrepreneurship

Learning-First MVP

Launch the smallest experience that resolves the next uncertainty

Difficulty
Moderate
Time to result
~weeks to results
Steps
6
Confidence
98%

A Learning-First MVP is the smallest launchable experience that answers the next material product or market question. Instead of treating “minimum” as permission to ship a cheap miniature of the final product, define the behavior that would count as evidence—such as a signup, reply, usage event, procurement effort, or payment. Build only what is necessary to expose that behavior, then watch what prospective customers work to obtain. Use those signals to identify the specific value or capability they are buying. Deliver enough to serve the earliest adopters, learn from them, and only then streamline, automate, and add depth. The mechanism limits wasted development by sequencing investment after evidence. Ernsten narrows the advice to products with low technical risk and explicitly distinguishes it from scientific products where whether the underlying intervention works is itself the critical question.

Origin

Extracted from The Foundr Podcast

Core principles

  • 01An MVP exists to generate learning
  • 02Demand evidence should precede broad technical investment
  • 03Build only enough to deliver the promised value
  • 04Early customers reveal which capability they actually buy
  • 05Strong customer effort can signal an acute problem

How to run it

  1. 1

    Define the learning goal

    State the customer or market uncertainty the MVP must resolve. Do this before selecting features or technology.

    Watch out Do not define success as merely launching the artifact.

  2. 2

    Select a behavioral signal

    Choose an action that would provide evidence of interest or need, such as signing up, replying, using the offer, or paying. Decide what you will observe before launch.

    Pro tip Use stronger signals as soon as they are practical.

    Watch out Compliments alone do not establish that someone will use or buy.

  3. 3

    Build the minimum test surface

    Create only enough of the experience to let relevant people take the target action. A landing page or outreach message may precede a functioning product.

    Watch out A low-quality miniature packed with partial features may teach less than one complete interaction.

  4. 4

    Find acute early demand

    Look for users willing to overcome friction because the problem matters to them. Invite them into the learning process rather than hiding every limitation.

    Pro tip Notice extraordinary effort, such as navigating procurement or tolerating an unfinished workflow.

    Watch out Do not infer a broad market from one determined buyer without further tests.

  5. 5

    Build the purchased value

    Determine which capability customers are actually pursuing and implement enough to deliver it well. Delay unrelated features.

    Pro tip One decisive capability can matter more than five speculative ones.

  6. 6

    Iterate and industrialize

    Learn with early customers, then streamline, automate, and expand the proven workflow. Let repeated evidence justify each increase in scope.

    Watch out Do not automate a value proposition that remains unproven.

In the wild

Alpha validates value propositions by outreach

Before knowing which buyer role and message would resonate, Alpha bought role- and industry-specific email lists and tested value propositions through outreach. Ernsten says Citibank, AT&T, and Pfizer became its first three clients through somewhat different messages, after which the company could learn what those buyers needed it to deliver.

Customer response and purchasing effort guided what Alpha built rather than a full speculative feature set.

Common mistakes

Building the cheap final-product miniature

An MVP chosen for low cost rather than a learning objective may deliver poor value and produce ambiguous evidence.

Shipping every imagined feature

Customers may buy for one capability. Building five before identifying that one delays learning and consumes resources.

Ignoring the type of technical risk

The approach assumes feasibility is not the main unknown. Scientific and safety-critical work requires evidence appropriate to those risks.

Is it for you?

Best for

Software, app, and service concepts where technical feasibility is known but demand is uncertain.

Not ideal for

Biotech, drug development, or other products whose central uncertainty is scientific or safety feasibility.

From the transcript

what is the thing we can launch to learn something

Thor Ernsten · (30:00)

you have to build very very very very little

Thor Ernsten · (32:30)

you only have to build one instead of five

Thor Ernsten · (33:00)

From the episode

336: Starting a Business During a Crisis with the founder of Alpha and Strata, Thor Ernstsson