The MVP Checklist: 12 Decisions to Make Before You Build
A minimum viable product is not a cheap version of your dream product. It is the smallest experiment that tells you whether the dream is worth building. Work through these 12 decisions before you write a line of code or hire a developer.
Key takeaways
- An MVP exists to learn, so start with the question it must answer, not the feature list.
- Many strong MVPs involve little or no code: landing pages, videos, concierge services and manual workflows.
- Set success and failure numbers before launch, or every result will look encouraging.
- Ship to a small, specific audience first. Feedback from the right 20 users beats silence from 2,000.
Eric Ries, who popularized the term in The Lean Startup, defined a minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The key words are learning and least effort.
In practice, many founders spend six months building an "MVP" with user accounts, settings pages and an admin dashboard, then launch to silence. This checklist helps you avoid that by forcing the important decisions up front.
Part 1: Define what you need to learn
1. The one problem you are solving
Write the problem in a single sentence, in your customer's words. If you need the word "and," you are probably solving two problems. Pick one.
2. The specific customer who has it
Name a narrow group you can actually reach this month, such as "freelance bookkeepers who manage more than ten clients." A broad audience makes feedback noisy and hard to act on.
3. The riskiest assumption
List what must be true for your business to work: people have the problem, they will pay to solve it, you can reach them affordably, you can deliver the solution. Your MVP should test the assumption that is both most uncertain and most fatal if wrong.
Pro tip
Turn your riskiest assumption into a question with a number in it: "Will at least 30 of 200 targeted visitors leave their email to get early access?" A question with a number can be answered. A vague hope cannot.
4. Your success and failure thresholds
Decide in advance what result means "keep going," what means "change direction" and what means "stop." Write it down and share it with a co-founder or advisor so you cannot quietly move the goalposts later.
Part 2: Choose the right type of MVP
5. The cheapest format that answers your question
Not every MVP is software. Choose the format based on what you need to learn:
| MVP type | How it works | Best for testing |
|---|---|---|
| Landing page | A page describing the product with a signup, waitlist or pre-order button | Demand and messaging |
| Explainer video | A short demo of how the product would work | Interest in a product that is hard to prototype |
| Concierge | You deliver the service manually and openly to a few customers | Whether the outcome is valuable enough to pay for |
| Wizard of Oz | Customers see a product interface while people do the work behind it | The full experience before automating it |
| Single-feature product | A working tool that does only the core job | Usage, retention and willingness to pay |
Real-world examples
Zappos founder Nick Swinmurn tested online shoe demand by photographing shoes at local stores and posting the pictures on a simple website. When someone ordered, he bought the pair at full price and shipped it. Dropbox's founders, facing a product that was hard to demo as a prototype, published a short video showing how file syncing would work. In Eric Ries's account, the beta waiting list grew from about 5,000 to 75,000 people almost overnight.
6. The single core workflow
Map the shortest path from "customer has the problem" to "customer gets the result." Everything on that path is in scope. Everything else, including profile pages, notifications and integrations, waits.
7. What you will fake, borrow or do by hand
Decide which parts can be manual or built from existing tools: spreadsheets instead of databases, a form builder instead of custom onboarding, a payment link instead of a billing system. These shortcuts are features of an MVP, not flaws.
Common mistake
Building for scale before you have demand. Load balancing, complex permissions and polished admin tools solve problems you will only have if the MVP works. Build them after the experiment says yes.
Part 3: Plan the launch and the learning
8. Where your first users will come from
Name the exact channels: a community you belong to, a list of 50 people from your interviews, a niche newsletter. "We'll post it online" is not a plan.
9. What you will measure
Choose two or three metrics tied to your riskiest assumption, such as signup rate, completion of the core workflow or repeat use within two weeks. Set up tracking before launch, not after.
10. How you will talk to users
Numbers tell you what happened. Conversations tell you why. Plan to interview at least five early users in the first two weeks, and make it easy for anyone to reach you directly.
11. Your budget and deadline
Set a hard limit on time and money, for example four weeks and $2,000. Constraints force focus, and a fixed deadline stops the MVP from slowly turning into a full product.
12. What you will do with each result
Before launch, write down your next step for each outcome: double down, change one variable and rerun, or stop and test a different assumption. That way the result leads to a decision, not a debate.
A good MVP
- Answers one clear question
- Reaches real target customers
- Has success numbers set in advance
- Takes weeks, not months
A risky MVP
- Tries to test everything at once
- Is shown mostly to friends and family
- Has no defined way to measure results
- Keeps growing in scope before launch
Your MVP checklist
- One-sentence problem statement in the customer's words
- A narrow customer segment you can reach this month
- Your riskiest assumption, written as a question with a number
- Success, pivot and stop thresholds, written and shared
- The cheapest MVP format that answers the question
- One core workflow, with everything else out of scope
- A list of parts you will do by hand or with existing tools
- Named channels for your first users
- Two or three metrics, tracked from day one
- At least five user interviews booked for the first two weeks
- A fixed budget and deadline
- A pre-agreed next step for every possible result
Frequently asked questions
How long should it take to build an MVP?
For most ideas, a few days to a few weeks. If your plan takes several months, look for a smaller format, such as a landing page or concierge test, that answers the same question sooner.
Do I need a technical co-founder to build an MVP?
Not always. No-code tools, landing page builders and manual delivery can test many ideas without custom software. A technical co-founder becomes important once the MVP shows real demand and you need to build a reliable product.
Should I charge for my MVP?
If you are testing willingness to pay, yes. Even a small pre-order or deposit is a far stronger signal than a free signup. If you are testing usability, a free pilot with clear expectations can work.
What is the difference between a prototype and an MVP?
A prototype shows how a product could look or work, usually for internal testing or demos. An MVP is put in front of real customers to test a business assumption, such as demand or willingness to pay.
Related reading
The bottom line
The goal of an MVP is not to launch something small. It is to learn something important as cheaply as possible. Make these 12 decisions first, and whatever result you get will tell you exactly what to do next.
