⚡ MVP in 2 Weeks

Why do it — and why your MVP is probably too large

The concept of MVP (Minimum Viable Product) is one of the most cited and most misunderstood ideas in startup culture. Founders invoke it constantly and then build something that takes six months, contains fifteen features, and requires a full team to maintain.

That's not an MVP. That's a product with a reduced feature set.

A real MVP is the smallest possible thing you can build that will produce a clear answer to your most dangerous hypothesis. Not "will people use our product?" but "will [this specific person] [do this specific thing] under [these specific conditions]?" The smaller and more specific the question, the more useful the MVP.

The 2-week constraint is deliberate. If your MVP takes longer than 2 weeks to build, you haven't defined it tightly enough. You're building too much, or you're testing too many things at once.

What is MVP in 2 Weeks

The MVP in 2 Weeks framework is a structured approach to identifying the single most critical hypothesis in your model, designing the smallest possible test for that hypothesis, building and launching in 14 days, and establishing a binary go/no-go criterion before you start.

The output is not a product — it's an answer. Does this hypothesis hold or not? That answer tells you whether to proceed, pivot or abandon.

How to use it: the 2-week sprint

Day 1-2: Identify the riskiest assumption
Review your Lean Canvas (Step 3) and your Customer Discovery notes (Step 4). What is the single most dangerous thing you're assuming? Not "people want convenience" — something more specific: "our target customers will give us their credit card details before seeing the product work." Write the assumption in one sentence. Your MVP tests that sentence.

Day 3: Define success before you build
Before writing a line of code, answer: what result would tell you the assumption is validated? Be specific and measurable. "People sign up" is not specific enough. "12 out of 50 people who see the landing page enter their email" is. Set your success criterion in writing before you start.

Day 4-5: Design the smallest possible test
What is the minimum you need to build to test this assumption? This is almost always much less than you think. Common MVP formats:
- Landing page with email capture (tests: is there demand?)
- Wizard-of-Oz (you do manually what the software will eventually automate)
- Concierge MVP (personal onboarding for 5 users, you do everything by hand)
- One-feature product (the absolute most important capability, nothing else)
- Video demo (test purchase intent before building anything)

Day 6-12: Build
Build only what's in the definition from Day 4-5. Nothing else. When you feel the urge to add "just one more feature," write it down on a list for later. The discipline is in the constraint.

Day 13-14: Launch and measure
Get your first data. Don't optimize yet — measure against the success criterion you defined on Day 3. Did you hit it? If yes, what's the next riskiest assumption? If no, what did you learn about why, and what does that tell you about your model?

Decision point: go, pivot or kill
Based on the data, make a clear decision: go (proceed to next step with same model), pivot (change a specific element and retest), or kill (the hypothesis failed and the model doesn't work). Don't let inconclusive data extend the experiment indefinitely.

3 common mistakes

1. Building features instead of testing assumptions
The most common MVP mistake: you list all the things users "need" and build the shortest version of that list. But that list was generated by your assumptions about what users need. The MVP should test whether those assumptions are true — not deliver on them.

2. Setting no success criterion before starting
If you don't define success before you build, you'll find a way to see success in any data. "We got 23 signups — that's promising" is not validation. 23 signups against a pre-defined target of 50 is a failed test. Define the criterion first.

3. Letting the experiment run beyond its window
An MVP that runs for 6 months is not an MVP — it's a product in slow death. Set a time window, collect the data, make the decision. The value of an MVP is in the speed of learning, not the accumulation of data.

Real Examples

Zalando (Germany): Before building any technology, Zalando's founder Oliver Samwer ran a manual test: he photographed shoes at a local store, listed them on a simple website, and fulfilled orders personally. The MVP tested one assumption: will German consumers buy shoes online without trying them on? The answer was yes. Only after validating that assumption did they build the platform.

BlaBlaCar (France): The BlaBlaCar MVP was a simple web page listing available long-distance car trips. No automated matching, no in-app payments, no driver verification — just listings and a phone number. The assumption being tested: will strangers share car rides with each other for money? The manual, low-tech version validated it before any product was built.

Wise (UK/Estonia): TransferWise (now Wise) launched with a Wizard-of-Oz MVP: they accepted money transfers manually, routed them through peer-to-peer matching by hand, and built the automation later. The MVP tested the core assumption: will people actually transfer money through an unknown startup instead of their bank? The answer, validated manually with the first 100 transfers, was yes. That answer funded the product build.

Recommended Resources

The Lean Startup — Eric Ries — the foundational text on Build-Measure-Learn cycles and validated learning. — https://theleanstartup.com/

Sprint — Jake Knapp — Google Ventures' 5-day sprint framework, useful for designing fast experiments when you have a design challenge at the core of your MVP. — https://www.thesprintbook.com/

Running Lean — Ash Maurya — the best practical guide to connecting Lean Canvas, customer interviews and MVP testing in a single workflow. — https://leanstack.com/runninglean

Next Step with IdeaLedger

Once your MVP has generated a clear answer to your most dangerous hypothesis, you have two directions. If the answer is positive, move to Step 10 (Product-Market Fit) — you're ready to look for early signs of fit. If the answer is negative but the problem is still real, go back to Step 4 (Customer Discovery) and reframe. The purpose of the MVP is to learn as fast as possible — not to ship.