The MVP Test: Three Questions Before You Spend a Dollar on Development

What you actually need to know

• The three questions are sequential gates, not a checklist. Failing any one of them means development should not start, regardless of how confident the founder feels about the others.
• Question one is about pain, not agreement. Most people will agree the problem exists. The question is whether they would pay $X/month to have it solved -- and the way to test that is to find people who are already paying something (money, time, workarounds) to deal with the problem today.
• Question two is about reachability, not market size. TAM slides do not pass the test. "I can get ten potential customers on a phone call this week" passes the test.
• Question three is about specificity, not vision. The MVP vision can be large; the MVP scope must be buildable by one developer in four to six weeks. If it is not, the scope is not an MVP.
• The test takes two weeks and zero budget. Development costs five to fifty thousand dollars (or more). The test is always the right investment before development starts.

The core argument

Most failed MVPs do not fail because the code was bad. They fail because the development started before the founder knew whether anyone would pay for the solution. The problem was assumed to be painful enough. The customer was assumed to be reachable. The solution was assumed to be specific enough. None of these assumptions were tested before the engineering started.

The MVP test is the structured answer to the question: "Should I start building?" Three questions, each with a binary answer. If all three pass, development is likely a good use of money. If any one of them fails, development is a bet on an unvalidated assumption, and bets on unvalidated assumptions are the most expensive thing a founder can do.

The two weeks spent answering these three questions before development begins are the highest-return investment in the entire startup journey. They are cheap to run, they answer the most important questions, and they are impossible to answer accurately after development has started (because sunk cost bias makes founders rationalize their investments instead of evaluating them honestly).

Question one: is the problem painful enough?

Pain has a dollar amount. The question is not whether people experience the problem -- most people experience many problems every day. The question is whether the pain is severe enough that people will pay meaningfully to solve it.

The test for pain severity is revealed behavior:

Are people currently paying someone or something to deal with this problem? Manual labor, expensive software that is a poor fit, consultants, workarounds -- all indicate real pain. A restaurant owner who pays $300/month for an outdated scheduling tool that barely works has proven the problem is painful. A restaurant owner who schedules shifts in a spreadsheet for free has suggested the problem is tolerable, not painful enough to pay for.

Are people describing strong negative consequences when they talk about the problem? "This takes me three hours every week that I should be spending on customers" has a dollar value. "It is a bit inconvenient" does not. Listen for consequences: lost revenue, lost time, lost customers, regulatory risk, team conflict. The more concrete the consequence, the more likely the pain translates to payment.

Are people taking action to solve the problem themselves? Homemade solutions (custom spreadsheets, manual scripts, informal processes) indicate pain significant enough to invest time in. Passive acceptance indicates the problem is not painful enough.

The customer interviews that answer question one: "How do you currently handle [problem]? How much time does it take? What does it cost you when it goes wrong? What have you tried to fix it? What did that cost?" These questions reveal whether the pain exists and what the current workaround cost is, which sets the upper bound on willingness to pay.

Question two: is the customer reachable?

The reachability test is simple: can you send ten cold outreach messages today and get at least three responses in a week?

This test fails for most founders because the customer definition is too broad. "Small business owners" is 30 million people in the US -- you cannot write a cold outreach message that resonates with all of them. "Restaurant operators in Dallas with fewer than five locations" is maybe 2,000 people -- you can find them on Google Maps, Yelp, and LinkedIn, and you can write a message specific enough to earn a response.

The right customer definition passes the following filter:

You can find them. LinkedIn, industry associations, subreddits, Slack communities, trade publications, niche job boards -- there should be a specific channel where your customer concentrates.

You can identify them without a large budget. Paid ad campaigns are not reachability at pre-development stage. Manual outreach to identified individuals is.

The definition is specific enough that your message resonates. A message to "restaurant operators with fewer than five locations who currently use spreadsheets for shift scheduling" can reference their specific situation. A message to "small business owners" cannot.

If you cannot answer the question "where do I find ten of these people this week?", the customer definition is not specific enough for development to start.

Question three: is the solution specific enough to build?

The specificity test is a proxy for product clarity. An MVP that cannot be described in one buildable paragraph is not ready for development -- it is ready for more customer discovery.

The test: write a two-sentence description of the MVP and hand it to a developer. Ask: "Can you estimate this without asking clarifying questions?" If the developer has more than three clarifying questions, the MVP scope is not specific enough.

A description that passes: "A web app where users import a CSV of customers and invoice amounts. The app sends three automated reminder emails per invoice: seven days before the due date, on the due date, and seven days after. The user can see which reminders have been sent and which invoices are overdue."

A description that fails: "An invoice management platform that helps small businesses get paid faster."

The second description is a vision, not an MVP. It will produce a scoping conversation that lasts two weeks and results in a project that takes six months. The first description is an MVP -- it can be scoped in an hour and shipped in four weeks.

Running the test in two weeks

Week one: Conduct ten customer interviews. The interviews have a specific agenda: identify the current workaround (question one), confirm the customer can be found and is willing to talk (question two), and test whether your solution description resonates or surfaces a better solution (question three).

At the end of week one, you have ten data points. Do not extrapolate from fewer than ten -- five interviews is not enough to distinguish a signal from a coincidence.

Week two: Based on the interview findings, refine the customer definition (narrow it if question two is failing), the problem statement (sharpen it if question one is weak), and the solution description (make it more specific if question three is failing). Then run five more interviews with the refined definitions.

At the end of two weeks, you have fifteen customer conversations and clear answers to all three questions. If all three pass, development is ready. If any fails, continue refining until it passes.

Common mistakes founders make before passing the MVP test

1. Confusing enthusiasm with pain. Potential customers who say "that sounds great!" are not confirming question one. They are being polite. Question one is confirmed by "I currently spend $X/month on this problem" or "I lost a client because of this last quarter."
2. Using surveys instead of interviews. Surveys cannot answer these three questions because they produce agreement, not revealed behavior. Interviews reveal how people actually behave, which is what the test is measuring.
3. Treating the questions as a checklist to pass rather than a diagnostic to understand. A founder who rushes through the test to reach development is using it wrong. The test's value is the information it produces, not the permission slip it grants.
4. Skipping the test because "I know the problem" -- because the founder has experienced the problem themselves. Personal experience with a problem is a starting hypothesis, not proof. The three questions are how you validate that the hypothesis applies to enough paying customers to build a business.
5. Starting development while question two is failing but planning to "figure out marketing later." If the customer cannot be reached before development, they cannot be reached after development. The marketing channel must exist before the product is built, not after.

Where to start: a 3-step pre-development test

Step 1: Write explicit answers to the three questions as hypotheses. "I believe the problem is [description] and it is painful because [consequences]." "I believe the customer is [specific definition] and I can reach them at [specific channel]." "I believe the MVP is [one-paragraph description] and a developer can scope it without clarifying questions." Writing the hypotheses before interviews makes the test results meaningful.

Step 2: Conduct fifteen customer interviews using a structured agenda. Confirm the problem and current workaround, confirm you found the customer through the channel you predicted, and test the solution description for resonance. Count how many interviews confirm each hypothesis versus contradict it.

Step 3: Evaluate each question against the interview results. If 12 of 15 interviews confirm the problem is painful, question one passes. If all 15 were found through the predicted channel, question two passes. If 10 of 15 said the solution description matched their expectation and they would pay for it, question three passes. If any question fails, refine and re-run before committing to development.

The Two Weeks That Save Six Months

Yashveer Singh. Founder of Yashveer Labs. I ran the MVP test for Expert Tutorials before a single line of code was written. The customer interviews revealed that question two almost failed -- the target customer I had identified (generalist developers learning new skills) was not reachable through the channels I had assumed. What I found was a more specific customer: backend developers who wanted structured, project-based learning for frontend skills. That customer could be found in specific communities (r/learnprogramming, JavaScript Discord servers, specific LinkedIn groups). The refined customer definition passed question two. If I had skipped the test and built for the original vague definition, the acquisition strategy would have failed before the product was even launched. The two weeks of customer interviews before development shaped the go-to-market strategy for the following year.

Related reading

• The MVP Feature Checklist: What to Build, What to Cut, and Why
• The Five Hour Founder Audit: Are You Ready to Build?
• The MVP Postmortem: Questions to Ask Yourself Six Months In
• The Honest MVP Checklist: 25 Items Before You Launch