Minimum Viable Product Thinking

Summary

This chapter introduces the Lean Startup methodology and the discipline of testing your most important assumptions before spending money or time building anything. You will learn the Build-Measure-Learn cycle, how to design paper prototypes and wireframes, and how to run landing page tests and A/B experiments. By the end of this chapter, you will have identified your venture's riskiest assumption and designed a low-cost experiment to test it.

Concepts Covered

This chapter covers the following 10 concepts from the learning graph:

1. Lean Startup Methodology
2. Build-Measure-Learn Cycle
3. Minimum Viable Product
4. Wireframe
5. Landing Page Test
6. A/B Testing
7. Validated Learning
8. Customer Feedback Loop
9. Hypothesis Testing
10. Experiment Design

Prerequisites

This chapter builds on concepts from:

• Chapter 2: Ideation Across the Liberal Arts
• Chapter 3: Recognizing Opportunity
• Chapter 4: Value Propositions

---

Erik Brust '14 did not launch JonnyPops with a factory, a distribution deal, or a professionally designed brand. He launched it with ice pop molds, a folding table in Buntrock Commons, and a sign that said "pay what you think is fair." Before spending a dollar on production infrastructure, he wanted to know one thing: would St. Olaf students actually pay money for a better-tasting, ingredient-honest ice pop? The folding table answered that question in a single afternoon.

That afternoon of testing was not a preliminary step before the real work. That afternoon was the real work, in miniature. Everything that followed — the production scale-up, the Target and Costco deals, the national brand — was built on the knowledge that the folding-table test produced.

This is the core idea of minimum viable product thinking: the goal of your first version is not to impress anyone. The goal is to learn the one thing you most need to know, as cheaply and as quickly as possible, so that everything you build after that is informed by reality rather than assumption.

Chapter 5: The art of building less on purpose

The most common student founder mistake is building too much before talking to customers. This chapter fixes that. By the end of it, you will know exactly what your riskiest assumption is, and you will have a plan to test it this week — with no code, no budget, and no waiting. Your Ikigai is waiting — let's find it!

The Lean Startup Methodology

The Lean Startup methodology, developed by Eric Ries and popularized through his 2011 book of the same name, is built on a single deceptively simple premise: most of what founders believe about their customers is wrong, and the sooner you find out where you are wrong, the less time and money you waste building the wrong thing.

The methodology emerged from a frustration with the traditional startup approach, which went: write a long business plan, raise money based on the plan, spend 12–18 months building the product, launch, and discover whether anyone actually wants it. This approach had a predictable problem: by the time founders discovered the wrong assumptions, they had already spent everything on them.

The Lean Startup alternative is: make your assumptions explicit, design cheap tests to challenge them, update your beliefs based on real data, and repeat. The mechanism for this loop is the Build-Measure-Learn cycle.

Two terms need definition before we go further. An assumption is a belief you are treating as true that you have not yet verified. "College students will pay $5 per month for a study-group scheduling tool" is an assumption. "Students on campus currently lose hours per week to scheduling friction" might be a verified pain point — if you have talked to students and confirmed it. The distinction matters because assumptions are what you test; verified pain points are what you build on.

Validated learning is the specific kind of knowledge produced by a well-designed test. It is not a positive result — it is a true result. Finding out that students will not pay $5 per month for a scheduling tool is validated learning. Finding out they would pay $2, or that they would share it with five friends if it were free, is also validated learning. The test is valuable regardless of the direction of the answer, as long as you designed it to produce a real answer rather than a reassuring one.

The Build-Measure-Learn Cycle

The Build-Measure-Learn cycle is the engine of the Lean Startup methodology. Before explaining the cycle, here is something most explanations get wrong: the cycle runs backward in planning and forward in execution.

In planning, you start with what you want to learn (your hypothesis), then design what to measure, then decide what minimum thing to build to produce that measurement. You define the learning goal first. The build is last.

In execution, you build the minimum thing, collect the measurements, and extract the learning. The learning informs the next hypothesis, and the cycle repeats.

The cycle as a diagram:

Learn → Build → Measure → Learn → Build → Measure → ...

Where each Learn step produces an updated hypothesis, each Build step produces the minimum artifact needed to test it, and each Measure step produces the data that either confirms or challenges the hypothesis.

The speed of the cycle is the primary competitive advantage of early-stage ventures. A team that completes three full cycles in the time a competitor takes to complete one learns three times as much. Most of the work of increasing cycle speed involves reducing the size of the thing you build — which is where the Minimum Viable Product comes in.

What "Minimum Viable" Actually Means

A Minimum Viable Product (MVP) is the smallest experiment that tests your most important assumption. Every word in that definition matters:

• Minimum — as little as possible. Not the smallest thing you could ship professionally. The smallest thing that can produce the learning you need.
• Viable — enough to actually test the hypothesis. Not a broken prototype that teaches you nothing about the real question.
• Product — something that exists in the world and is interacted with by a real customer. Not a slide deck, not a survey, not a conversation about what you might build.

The most common confusion about MVPs is treating them as early versions of the final product — as if MVP means "rough draft of the thing we are building." It does not. An MVP is an experiment, not a version. Its success is measured by whether it produces validated learning, not by whether customers love it.

Here is the classic illustration: you want to know whether people in Northfield will pay for a same-day grocery delivery service. You could build an app, integrate with Stripe, negotiate with local grocery stores, and launch — spending four months and several thousand dollars to find out. Or you could post a flyer at Buntrock Commons saying "Text GROCERIES to [your number] and we will deliver your grocery list from the Econofoods on Division within 3 hours for $5." Take three orders manually. Fulfill them yourself. If you get real customers paying real money, you have validated demand. If no one texts, you have also learned something — far more cheaply.

The MVP test that takes a week beats the product that takes a year

J-Term is the ideal MVP season at St. Olaf. Four weeks of focused, relatively unstructured time, a captive campus audience willing to try new things, and professors who will supervise an independent research project around your experiment. If you have an idea, January is your lab.

Types of MVPs for Student Founders

Before choosing an MVP format, identify your most important assumption. To find it, ask: "If this belief is wrong, our entire venture does not work." The answer is your riskiest assumption. Everything else is a secondary concern until that one is tested.

The format of your MVP depends on what you are testing:

What You Are Testing	MVP Format	Example
Whether the problem is real and painful	Customer interviews (Mom Test, Ch. 4)	10 conversations about their current frustrations
Whether your solution concept resonates	Concierge MVP	Manually do the service for 5 customers before building anything
Whether a digital product would attract users	Landing page test	A one-page description of the product with a waitlist signup
Whether two different versions appeal differently	A/B test	Two landing page headlines sent to different groups
Whether the user experience makes sense	Wireframe walkthrough	Paper sketches shown to users who "click" through them
Whether customers will actually pay	Pre-order or paid pilot	Ask for money before the product exists

A wireframe is a rough visual sketch of a digital interface — boxes and labels showing where things will go, with no visual design, no color, and no code. Wireframes can be drawn on paper, whiteboards, or simple tools like Figma or Balsamiq. Their purpose is to test whether the user experience concept makes sense before investing engineering time. A five-minute paper wireframe walkthrough with three real users often surfaces more UX issues than a month of internal design work.

A landing page test is a single web page that describes your value proposition, shows what the product will do, and includes a clear call to action — usually a waitlist signup, a pre-order, or a contact form. Landing page tests measure whether the problem and solution framing is compelling enough to get potential customers to take a specific action. The tool below walks you through the components of an effective landing page and lets you draft your own.

Diagram: MVP Type Selector

Interactive MVP Type Selector — match your riskiest assumption to the right experiment format

Type: MicroSim sim-id: mvp-type-selector
Library: p5.js
Status: Specified

Learning objective: Students identify their venture's riskiest assumption and select the appropriate MVP format to test it. (Bloom's Taxonomy: Applying)

Canvas: 680×500px responsive, redraws on window resize events.

Layout (three-column flow): - Left column "Step 1: Your Riskiest Assumption" — a text input labeled "What must be true for your venture to work?" with a short placeholder example. - Middle column "Step 2: What Category?" — a vertically stacked set of 4 radio buttons representing assumption categories: 1. The problem is real and painful enough 2. Customers would want my specific solution 3. Customers would use and return to the product 4. Customers would actually pay - Right column "Step 3: Recommended MVP" — dynamically updates based on the selected category, showing: - MVP type name in bold (e.g., "Customer Interviews") - A 2-sentence description of what to do - A "Time to run" estimate (e.g., "1–2 weeks") - A "Cost estimate" note (e.g., "Free — just your time") - A "St. Olaf setting" suggestion (e.g., "Reach out to 10 people via email or at Buntrock Commons")

Recommended MVP per category: 1. Problem real → Customer Interviews: "Conduct 10 Mom Test conversations. Document the specific workarounds people describe." 2. Solution resonance → Concierge MVP: "Manually deliver the service for 3–5 customers before building anything automated." 3. Product usage → Wireframe or Paper Prototype: "Sketch the interface, walk 5 users through it, and record what confuses them." 4. Willingness to pay → Pre-order or Paid Pilot: "Ask for real money before you build. Even $5 per person validates demand."

Interaction: Selecting a category radio button instantly updates the right column. Changing the text in the assumption field does not affect the recommendation (the category radio buttons drive the logic).

A "My MVP Plan" section below all three columns: Two text entry fields — "I will test:" (auto-populated from assumption input) and "By:" — plus a "Save" button that generates a plain-text MVP plan summary.

Responsive design: At widths below 600px, stack the three columns vertically. Minimum canvas width: 320px. All text scales proportionally on resize.

Accessibility: Radio buttons are keyboard-navigable. Dynamic content in the right column is marked with aria-live for screen reader updates.

Hypothesis Testing and Experiment Design

Every MVP starts with a hypothesis — a specific, falsifiable prediction about customer behavior. Falsifiable means it can be proven wrong. "Customers will like our product" is not a hypothesis — it cannot be proven wrong because "like" is vague. "At least 30% of students who see our landing page will sign up for the waitlist" is a hypothesis — it has a specific metric, a specific threshold, and a specific context. You will either hit 30% or you will not.

Good hypothesis format: "We believe [specific group of customers] will [specific behavior] because [specific reason]. We will know this is true if [specific measurable outcome] within [specific time period]."

Applied: "We believe Division III varsity athletes at St. Olaf will sign up for a game film sharing tool because they currently lose coaching feedback time to email size limits. We will know this is true if 20 out of 60 athletes sign up on a landing page within two weeks of the campaign."

Experiment design is the process of deciding what to build, what to measure, and what result will constitute confirmation versus disconfirmation of your hypothesis. Good experiment design includes:

1. A clear hypothesis — see above.
2. A specific metric — what you will count or measure.
3. A threshold — what number constitutes "confirmed" versus "not confirmed."
4. A sample — who specifically will be in the experiment.
5. A time box — how long the experiment runs.
6. A plan for both outcomes — what you will do if confirmed, and what you will do if not.

The "plan for both outcomes" step is the one most founders skip. If you only plan for success, you will subconsciously design experiments that are hard to fail and easy to rationalize. Planning explicitly for the disconfirmation case forces you to define in advance what evidence would cause you to change direction.

A/B testing applies experiment design to comparative questions: which of two versions works better? Two different landing page headlines, two different pricing proposals, two different ways of framing your value proposition. The key requirement for a valid A/B test is that all other variables are held constant — you are changing exactly one thing and measuring the difference. Even simple A/B tests (sending two versions of an email to half your list each) produce more reliable data than gut feelings about which version is better.

The Customer Feedback Loop

The Build-Measure-Learn cycle is a loop, which means it runs continuously — not once, not twice, but as long as you are building. The customer feedback loop is the ongoing process by which real customer behavior informs your product decisions.

Before building: What do you believe? What experiment will test it?

After building: What happened? What did customers do, say, skip, or struggle with? What does that tell you about your next assumption?

The most important thing about the feedback loop is that it must be connected to actual customer behavior, not just what customers say. Customers routinely tell you they will do things they do not actually do — not because they are dishonest, but because predicting your own future behavior in a hypothetical situation is genuinely hard. Measure what they do, not just what they say they would do.

An experiment that fails is still a win

Finding out that your hypothesis was wrong is not failure — it is the system working correctly. The real failure is spending a year building something, then finding out the hypothesis was wrong. A fast, cheap disconfirmation is one of the most valuable things an early-stage founder can get.

Try It

1. Identify Your Riskiest Assumption. For your top opportunity from Chapter 3, complete this sentence: "If this belief turns out to be false, our entire venture does not work: _____." That is your riskiest assumption. Write it in specific, falsifiable language.

2. Write a Hypothesis. Using the hypothesis format above, draft a testable prediction about your riskiest assumption. Include the specific group, the specific behavior, the reason you believe it, and the measurable outcome that would confirm or disconfirm it.

3. Choose Your MVP Format. Use the MVP Type Selector above to match your riskiest assumption to the right experiment format. Explain in one paragraph why you selected this format over the alternatives.

4. Design Your Experiment. Fill in all five experiment design fields: hypothesis, metric, threshold, sample, and time box. Write a one-sentence description of what you will do if the hypothesis is confirmed and what you will do if it is not.

5. Run a Paper Prototype. If your venture involves any digital interface, sketch three to five screens on paper (or sticky notes) and walk one real potential customer through them. Do not explain anything — watch what they do and ask them to think out loud. Write down the three most surprising moments.

Ole Cup Connection

The Ole Cup application's "evidence of validation" section rewards teams that have done real experiments. "We believe people want this" scores zero. "We ran a two-week landing page test and got 47 signups from a total outreach of 80 targeted students, a 59% conversion rate, and we interviewed 12 of those 47" scores very high. The experiment design work in this chapter, done before the application deadline, is the difference between those two sentences. Judges know what validated learning looks like — and they know what it does not look like.

You just turned an idea into an experiment — that is a very different thing

Most teams skip from "I have a great idea" to "let me build it" and discover the gap twelve months later. You now know how to bridge that gap with a fast, cheap test that tells you what you actually need to know. In Chapter 6, we take everything you have built so far and ask a harder question: should your venture be a for-profit, a nonprofit, or something in between?