How to Build an MVP: 7 Steps From Riskiest Assumption to Launch

When an MVP is the wrong first step

Check these four lines before you build anything:

• Your product falls under regulation, such as medical or financial rules, and needs approval before anyone can use it.
• Safety is the main risk, as with a child car seat.
• It is hardware, and the first unit waits on tooling.
• You have no way to reach people who have the problem.

If one line is true, a working product is the wrong first test. Test demand without it: interviews, a waitlist, a preorder page with a refund promise. Plan the approval or the tooling in parallel. If the last line is true, go back a stage and find an idea first, or find the channel to your customers before you build.

MVP vs prototype vs proof of concept

Choose by the risk that would end the business first. If you doubt it can be built, run a proof of concept. If you doubt people can use it, test a prototype. If you doubt anyone wants it, build an MVP. If you need all three questions answered in one document before you spend, a business concept holds them, and we can prepare a concept with market research for your idea.

1. Find the problem and the people who have it

Outcome: a customer description that passes our three-line test.

Start from the problem, then find who has it most often and most painfully. In CB Insights’ 2021 report on why startups fail, working on problems that are interesting to solve instead of ones the market needs was the No. 2 reason, cited in 35% of cases⁴.

In interviews, ask about past behavior and skip opinions about the future. Cover these points:

• When it last happened, and what they did next.
• How often it happens in a typical month.
• What the last occurrence cost them in money or hours.
• What they use today to deal with it.
• Whether they have paid for a fix, and how much.

Frequency and intensity tell you whether the problem can carry a product. A problem that hurts once a year rarely supports a monthly subscription. For the full script, use our problem interview questions. For sorting and ranking what you hear, see how to find customer pain points.

Then write the customer in three lines:

If any line stays vague, narrow it before step 2. A test aimed at “small businesses” reaches no one you can name or message. More on defining who your first users are.

2. Write the riskiest assumption as one testable line

Outcome: one sentence with who, the problem, the action, a number and a deadline.

List the assumptions your idea rests on: that people have the problem, that they will pay, that you can reach them and that you can deliver. The riskiest one ends the business if it is wrong and has the least evidence behind it. Before launch, payment often has the least evidence, because nobody has paid you yet.

Fill in this line:

At least N people of type X with problem Y will do Z at price P by date D.

The action has to cost the customer something, such as money, a deposit, a signed letter of intent or an hour of setup. A “like” or an email address costs almost nothing, so it proves almost nothing. The number and the date are yours to set.

Our house rule applies to you as well. No number goes into the plan without a source or the word “assumption” written next to it. If you guessed it, label it, so you know which number to replace first.

A development firm budgets 2 weeks to 1 month for discovery and MVP planning on a custom build⁵. Your one line should take an afternoon. To put the line on one page next to the rest of your business model, use a lean canvas.

3. Check who already solves it

Outcome: you know the current solutions and the gaps they leave.

Customers always use something today: a competitor, a spreadsheet, a phone call, or nothing at all. Answer three questions in one sitting. Write down who solves it today, including the workarounds. Note how each option works and what the customer pays for it. Then name what each one leaves open for the group from step 1.

The third answer feeds your offer in step 4. Stop when you can name the gap in one sentence, because this step has its own pages. Our free idea check lists competitors for your idea. For depth, run a competitor analysis and a market analysis.

4. Pick the cheapest MVP type that tests it

Outcome: an MVP type that matches the risk in your one line.

In a concierge MVP, the customer knows you deliver by hand. In a Wizard of Oz MVP, the customer sees a product screen and you do the work behind it.

Three cases show the cheaper types at work. In March 2008, Dropbox posted a 3-minute video of its product as it was meant to work, and its beta waiting list grew from 5,000 to 75,000 people⁶. Zappos’ founder photographed shoes at his local mall and posted them online. When an order came in, he bought the pair at full retail price⁷. Airbnb started in October 2007 as an air mattress in the founders’ San Francisco living room, offered to visitors of a conference⁸.

Pick the cheapest type that can prove your line wrong. A video cannot tell you whether people renew. A single-feature product costs too much to learn whether anyone pays at all. A landing page needs a clear offer, so write your value proposition before you build it. If you only need to know whether people click “buy” before anything exists, run a fake door test.

5. Cut the feature list to what the test needs

Outcome: three Must-haves at most, each with an acceptance line, and a “later” list for everything else.

1. Time-box the build. Set the date the MVP goes live before you list a single feature. Y Combinator advises founders to time-box the spec and build in weeks³.
2. Write the spec. List every feature you can think of, with no filter. A long list on paper costs nothing.
3. Cut. For each feature, name the part of your one line it tests: the who, the action, the price or the number. If it tests none of them, it moves to “later”. Limit the Must list to three features. This cap is our working rule; a fourth Must-have usually means you are testing two things at once.

Give each Must feature an acceptance line: one sentence that says when it works. For a deposit link, that might read: “A customer pays the deposit from the link without contacting you.” If you cannot write the acceptance line, the feature is still an idea.

Use these questions when a feature is hard to place:

Logins, settings, dashboards, admin panels and integrations land in “later” in most tests. If you are unsure what the core action is, write the job your customer hires it for in one sentence. The Must-haves deliver that job and nothing else.

6. Build only what the test needs

Outcome: an MVP that runs the core action for your first users.

Choose the build path by what your line tests:

Manual work needs a stop rule. Before launch, set the number of hours per week you will spend delivering the service by hand. When a cycle passes and the hours go past that cap, automate the one task that takes most of your time, and only that one. When a cycle fails, the manual work stops with it, and you have spent hours where a coded build would have spent its whole budget.

Build the analytics with the MVP. Track the one metric from the method section below and every step before it: visit, sign-up, payment, first use, second use. Set this up before the first user arrives, because you cannot rebuild a funnel after the fact. Run the payment flow yourself with a real card before anyone else sees it.

7. Launch to a small group first

Outcome: a result for your one metric, read on the date you set.

Treat the launch as a run of small releases. Start with people you can talk to one by one, such as the ones from your step 1 interviews. The four-week split below is an assumption; stretch or shorten it to fit the window you set.

If a week fails its exit check, fix that before you widen the group. Users who cannot finish the core action in week 1 will burn the channel spend in week 3.

Test the price with commitments that cost the customer something: a prepayment, a deposit, a paid pilot. A “yes, I’d pay” in an interview is an opinion about the future. When the test passes and you are ready to go wider, our launch package covers the next stage.

Measure: one metric and two lines

Pick the metric that answers your line. It has to pass three checks: a change you make can move it, you can pull it from your own data, and you can audit how it was counted.

Keep activation apart from sign-ups. A sign-up means the person gave you an email address. Activation means they did the core action once: sent the first reminder, placed the first order, booked the first slot. Write the activation definition in one sentence before launch, so nobody redefines it once the numbers come in.

If you use Net Promoter Score, compute it the standard way. Scores of 0–6 are detractors, 7–8 are passives and 9–10 are promoters, and NPS is the percentage of promoters minus the percentage of detractors⁹. Passives stay in the total. Take 20 responses (assumption): 8 promoters and 5 detractors, with the other 7 passive. NPS is 40% minus 25%, which is 15. Dropping the passives from the total would turn the same assumed answers into a score of 23. With a small group, one answer moves NPS by several points, so read it as context next to your one metric.

If your test spends money on a channel, put the cost per paying customer next to your price in our unit economics calculator.

Decide: keep going, change one thing, or stop

Write this rule before launch, on the same page as the lines:

Change one variable per extra cycle. If you change the price and the channel together, you cannot tell which one moved the number. Before the first launch, also set how many extra cycles you allow between the lines. When you reach that count without a pass, treat the result as a fail.

Each cycle keeps the duration written in the test; a few weeks per cycle is our working assumption. When a cycle passes, plan the next assumption in a product roadmap and the wider launch in a go-to-market plan.

Run a demand test to fill in these fields for your idea and set the pass and fail lines before you build.