MVP Validation: How to Validate Market Demand Before You Build

TL;DR

MVP validation is the work of proving that real people want your product, and will pay for it, before you spend months and a budget building it. It is not about polishing a product; it is about collecting evidence of market demand cheaply enough that a "no" costs you a week, not a year. You validate demand with customer interviews, landing pages, fake-door tests, paid-ad tests, pre-sales, and manual "concierge" versions of the product, then you read a short list of signals, did strangers act? did anyone pay?, to decide whether to build, pivot, or drop the idea.

This guide walks through the seven proven validation methods in depth, a five-step framework you can run this week, how validation changes by business type, the tools and benchmarks that matter, a two-week validation sprint, and the famous examples that prove the discipline works. The throughline: the cheapest MVP is the one you never build because validation told you to stop. At MVP Development we help founders validate fast and then, once demand is real, ship a funding-ready MVP in 3–4 weeks. More on that at the end.

What is MVP validation?

MVP validation is the process of testing whether there is genuine market demand for your idea using the smallest possible experiment, before committing to a full build. It answers one question: do enough people want this badly enough to act, sign up, pay, or commit?

It helps to separate two ideas founders constantly blur:

• Demand validation asks whether people want the outcome your product promises. This is about the market, and it is what most early validation is for.
• Product validation asks whether your specific solution actually delivers that outcome and keeps users coming back. This comes later, usually with a working single-feature MVP.

There is a second split underneath that one, between problem validation and solution validation. Problem validation confirms that the pain you are targeting is real, frequent, and expensive enough that people already try to solve it. Solution validation confirms that your particular fix is the one they will choose. You always validate the problem first; a brilliant solution to a problem nobody has is the most common, and most expensive, startup mistake.

Most failed startups did not build a broken product. They built a working product nobody wanted. MVP validation exists to kill that exact failure mode early. It is the first real job of the MVP stage of a startup, and doing it well is what separates a scoped, fundable build from an expensive guess.

Why validating market demand matters more than ever

Building first and asking questions later is the most expensive habit in startups. Here is the trade the numbers make obvious:

Validation does not replace building, it sequences it. You spend a little to learn whether the big spend is justified. Given what an MVP actually costs to build, a week of demand testing is the highest-leverage money a founder can spend.

There is a trap worth naming here: the build trap, the belief that progress means writing code. Building feels productive. It produces something you can show, demo, and feel proud of. But until real users act, every feature is a guess dressed up as progress. Founders fall into the build trap because building is concrete and validation is uncomfortable, it can tell you that you are wrong. That discomfort is the entire value. A fast "no" is a gift; it hands you back your runway and your next year.

The bar also moved. In 2026, investors expect proof earlier, even pre-seed checks increasingly want traction over a deck, and AI tooling has collapsed build times so far that "we built it" no longer impresses anyone on its own. What impresses is evidence: a waitlist that grew on its own, pre-orders from strangers, a landing page converting cold traffic at double digits. Validation is how you manufacture that evidence before you have a product, and it is what turns a pitch from "we think" into "we know."

The two questions every validation must answer

Strip away the tactics and all validation reduces to two questions, asked in order.

Question one: is the problem real? Before anyone will buy your solution, the pain it relieves has to exist, recur, and cost something. Real problems have fingerprints: people already cobble together workarounds, pay for partial fixes, or complain about them unprompted. If you have to explain the problem before people nod, it probably is not painful enough to build a business on. Problem validation is mostly conversational, you find people who should have the pain and listen for evidence they already feel it.

Question two: will they act on your solution? A real problem is necessary but not sufficient, people tolerate painful problems all the time. Demand validation measures whether your specific fix pulls a behavior: a signup, a click, a deposit, a pre-order. The strongest validation skips opinions entirely and measures action, because what people say and what people do diverge wildly the moment money or effort is involved.

The practical tool that ties both together is the riskiest assumption. Every idea rests on a stack of beliefs, and one of them, if false, kills the whole thing. "Freelance designers will pay $29/mo to automate invoicing" hides several: that freelancers find invoicing painful (problem), that they would pay to automate it (demand), that $29 is acceptable (price), that they will trust a new tool with billing (trust). Your job is to name the single assumption most likely to be wrong and most fatal if it is, then design the cheapest test that can break it. You are not trying to prove yourself right. You are trying to find the fastest way to be proven wrong, because that is what protects you.

The 7 MVP validation methods, in depth

These are the proven MVP business validation methods, ordered from lightest to heaviest. Most of them are a type of MVP in their own right, which is why each links to a deeper guide. The governing rule across all of them: pick the lightest method that can answer your riskiest question.

1. Customer interviews (run them like The Mom Test)

Interviews are where validation starts, because they answer question one cheaply. The goal is not to pitch your idea and collect compliments; it is to learn whether the problem is real without contaminating the answer. The classic failure is asking "would you use a tool that does X?", to which everyone politely says yes. The Mom Test reframes the whole exercise: ask about the person's past behavior, not your future product. Even your mom can give you useful data if you only ask about what she actually does.

How to run them: find five to fifteen people who should have the problem, and ask about the last time they faced it. "Walk me through how you handle invoicing today." "What did you do the last time it went wrong?" "How much time or money did that cost you?" "What have you tried to fix it?" Notice that none of these mention your idea. You are mining for three things: evidence the problem is frequent, evidence it is painful, and evidence of existing workarounds, the strongest tell of all, because a workaround is someone already paying (in time or money) to solve what you want to sell.

What good looks like: the same problem surfaces unprompted across most conversations, people describe real consequences, and several already hack together a solution. What a false positive looks like: enthusiasm about your idea with no evidence of current pain. Run interviews before anything else, the Y Combinator guide to talking to users is the best free primer, and treat "that's a cool idea" as the most dangerous sentence you can hear.

2. The landing page / smoke test

A landing-page MVP is the workhorse of demand validation. You build a single page that describes the product as if it exists, the promise, the benefit, a clear call to action, and you drive real strangers to it to see whether they convert. The "smoke" is the signup: an email, a waitlist spot, a "notify me." It measures whether your promise is compelling enough to pull an action from someone who has never heard of you.

How to run it: write a headline that states the outcome, not the features; add three benefit points and one crisp call to action; and put a real email capture on it. Build it in an afternoon with a no-code page builder, you do not need anything custom yet. Then send qualified traffic: a small ad budget, a relevant subreddit or community, a cold-outreach list. The number that matters is conversion rate from cold, targeted traffic, not from friends, not from your existing audience.

What good looks like: 5–15%+ of targeted cold visitors convert to a signup or waitlist. Below ~2% and either the promise is not landing or the traffic is wrong; diagnose which by checking whether people are reaching the page and bouncing (weak promise) or not clicking your ads at all (weak hook). The landing page also doubles as an asset you keep, the waitlist it builds becomes your launch list the day the real product ships.

3. The fake-door test

A fake-door test validates demand for a specific feature before you build it. You place a button or menu item for the feature inside an existing product or page; when a user clicks, instead of the feature they see a short "coming soon, want early access?" message. The click is the data, it measures genuine intent, because the user took an action expecting the feature to be real.

How to run it: add the entry point exactly where the real feature would live, make it look completely native, and instrument the click. When clicked, capture an email and, ideally, a one-line "what did you expect this to do?" survey to learn what users assumed. Run it long enough to collect a meaningful sample relative to your traffic.

What good looks like: a click-through rate high enough to justify the build, judged against your other features, plus qualitative notes that match your intended scope. The ethical line: keep the gap short, always offer to notify them, and never take money for something that does not exist (that is the difference between a fake-door test and a pre-sale). Fake-door is the fastest way to prioritize a roadmap, it tells you which of ten possible features people actually reach for.

4. Paid ad demand tests

Paid ads turn validation into a measurable funnel. You run a small ad campaign for your offer and read two numbers: click-through rate (does the promise grab attention?) and cost per signup (how expensive is demand?). Unlike organic traffic, paid ads give you a clean, repeatable demand signal you can dial up or down, and they surface your eventual unit economics early.

How to run it: write three to five ad variations targeting the audience you believe has the problem, point them at your landing page, and cap the spend at a small, fixed budget. Let it run until you have enough clicks to trust the numbers. Test angles, not just copy, different headlines often represent different value propositions, and the winner tells you which promise resonates.

What good looks like: a click-through rate above the platform norm for your category, and a cost per signup comfortably below the value of a customer. A cheap signup means demand is strong and acquisition could work; an expensive one is an early warning that even if people want it, reaching them may not pay. This is also the method that most directly previews whether growth will compound or bleed, which is exactly what a pre-seed investor wants to understand.

5. Pre-sales and waitlist deposits

Pre-sales are the gold standard of demand validation because they require the one thing opinions never cost: money. You ask people to pay, or put down a deposit, for a product that does not exist yet. Nothing else separates polite interest from real demand so cleanly. A hundred free signups can still be curiosity; ten paid pre-orders are a market.

How to run it: make a concrete offer with a real price and a clear "shipping when" promise, then collect payment or a refundable deposit through a simple checkout. Be transparent that it is pre-launch, founders worry this scares people off, but the ones who pay anyway are precisely the customers you want, and their willingness is your proof. Keep a clean refund policy so the test is honest and low-risk for buyers.

What good looks like: any real money is a strong signal, and a pre-sale that funds even part of the build is a green light most founders never earn. Pre-sales also de-risk the build itself, you are now constructing something people have already bought, which changes the MVP build from a bet into a commitment you are fulfilling. If you cannot get a single stranger to pre-pay after real effort, that is data worth more than a year of building to find out.

6. The concierge MVP

A concierge MVP validates both demand and whether your solution actually delivers value, by having you perform the service manually, by hand, for real customers. There is no product yet; there is you, doing the work a product would eventually automate. It is heavier than the methods above, but it produces the richest learning, because you watch real value get delivered (or not) in real time.

How to run it: find a handful of customers with the problem, deliver the outcome manually behind the scenes, and charge for it if you can. If you are building a meal-planning app, you personally build the meal plans and email them. You learn exactly what customers value, what they ignore, where they get stuck, and what they will pay, all before writing code. The manual work does not scale, and that is fine; you are buying insight, not efficiency.

What good looks like: customers come back, refer others, or pay again. Repeat usage of a manual, unscaled service is one of the strongest demand signals there is, because it proves value survives contact with reality. The concierge MVP also writes your product spec for you, after delivering the service by hand ten times, you know precisely which single flow to automate first, which is the heart of the MVP development process.

7. Crowdfunding

Crowdfunding is pre-sales at scale, and it validates demand and raises build capital in the same motion. A successful campaign is irrefutable proof: hundreds or thousands of strangers paid for a product that does not exist. It works best for physical or consumer products with a story that travels, and it doubles as a marketing launch.

How to run it: craft a campaign page that sells the outcome with a demo or video, set a funding goal that maps to your real build cost, and drive an audience to it, crowdfunding rewards founders who bring their own initial traffic in the first 48 hours. The campaign itself is a validation asset: the page, the video, and the pitch all test whether the story resonates.

What good looks like: backers pre-ordering at a pace that clears your goal, with momentum that builds rather than stalls after your own network taps out. Crowdfunding is heavier and slower than the other methods, and not every product suits it, but when it fits, it is the most complete validation possible, demand, price, story, and funding, proven at once.

A note on the Wizard of Oz. A Wizard-of-Oz test sits between demand and product validation: users get a real, automated-looking experience while you run the back end by hand. It validates whether the outcome lands before you build the engine, ideal when the experience matters but the technology is expensive. Zappos famously used it to test whether people would buy shoes online before building any inventory system at all.

How to validate an MVP: a 5-step framework

If you want a repeatable way to validate your MVP idea, run this loop. It works for any of the methods above.

1. Write down your riskiest assumption. State it as one falsifiable sentence: "Freelance designers will pay $29/mo to automate invoicing." If you cannot write it, you do not yet understand your own idea well enough to test it. Naming the assumption forces you to admit what has to be true, and which belief, if wrong, ends the venture.

2. Pick the one metric that proves or disproves it. Choose before you start so you cannot move the goalposts after seeing the result. Signup rate, pre-orders, cost per signup, the pattern across interviews, exactly one. A single clear metric beats a dashboard of vanity numbers you will rationalize later.

3. Choose the lightest method that can move that metric, and set a pass/fail line in advance. If the risk is "will anyone want this?", a landing page or fake-door beats months of code. If it is "will they pay?", you need pre-sales. Write the threshold down: "≥10% of landing-page visitors join the waitlist" or "≥3 pre-orders from strangers in two weeks." A test with no predefined bar is not a test; it is a Rorschach blot.

4. Drive real demand at it. Validation fails when you test on the wrong people. Put strangers who have the problem in front of the experiment, via a small ad budget, a relevant community, or cold outreach. Warm friends and your existing audience will flatter you into a false positive.

5. Read the signal and decide: build, iterate, or drop. Be honest. A fair test that fails is a win, it saved you the build. If you passed, you have earned the right to build the smallest real product that delivers the validated outcome. If you failed, change the offer, the audience, or the price and re-test, or walk away with your runway intact.

This is the Lean Startup build-measure-learn loop applied before the build. The discipline is step two: deciding what "demand" looks like before you see the result, so the data, not your hope, makes the call.

How validation differs by business type

The methods are universal; the right mix depends on what you are building. A few patterns worth knowing before you start.

• SaaS. Landing-page smoke tests and fake-door tests dominate, because the audience is online and the signal (signups, feature clicks) is easy to instrument. Pricing validation matters early, run a pricing page as part of the smoke test. This is the most "validate digitally" of all categories; see how we approach SaaS MVP development once demand is proven.

• Marketplaces. The validation is harder because you must prove both sides. Validate the constrained side first (usually supply), often with a concierge approach where you manually match the first buyers and sellers. Demand on one side is meaningless without liquidity on the other, which is why marketplace MVPs live or die on sequencing.

• Mobile apps. Fake-door "install" buttons, app-store-style landing pages, and paid-ad tests work well, but watch acquisition cost closely, app distribution is expensive, so cost-per-signup is a make-or-break signal. Validate before you commit to a native mobile app build.

• Fintech. Trust is the riskiest assumption, not interest. People may want the outcome but balk at handing a new brand their money or data. Validate willingness to connect an account or pre-fund, not just to sign up, and expect compliance to shape what your fintech MVP can even test. Concierge and pre-sales beat fake-doors here.

• B2B. Volume is low, so quantitative tests (ads, landing pages) are weak; demand shows up as design partners and signed letters of intent. The strongest B2B validation is a handful of companies committing budget or pilot time before you build. One paying pilot outweighs a thousand B2C signups.

The principle holds across all of them: validate the riskiest assumption for your category, demand for SaaS, liquidity for marketplaces, trust for fintech, commitment for B2B, with the lightest method that can break it.

The signals that prove demand (and the ones that lie)

Validation only works if you know what a "yes" looks like. These are the signals that count, and the vanity numbers that feel good but prove nothing.

Ignore these: total page views, social likes, "great idea!" compliments, and signups from friends and family. They measure curiosity, not demand. The hierarchy of proof is simple, action beats opinion, and money beats action. A hundred strangers who pay beats ten thousand who clap. When two signals conflict, trust the one that cost the user something.

The validation toolkit

You can run every method above with cheap, off-the-shelf tools. You do not need to build anything custom to validate, that is the whole point.

The discipline is to keep the toolkit light. The moment validation requires custom engineering, you have stopped validating and started building, which is exactly the spend you were trying to defer. If your idea genuinely cannot be tested without some working product, that is the signal to scope the absolute minimum, a single-feature MVP, and treat the build itself as the experiment.

A 2-week MVP validation sprint

Validation should be fast by design. Here is a concrete two-week sprint that takes an idea from "I think" to a real go/no-go decision.

Week 1, prove the problem and the promise.

• Days 1–2: Write your riskiest assumption and the single pass/fail metric. Line up interviews with people who should have the problem.
• Days 3–4: Run five to ten customer interviews using past-behavior questions. Listen for unprompted pain and existing workarounds. Decide: is the problem real? If not, stop, you just saved months.
• Day 5: Build the smoke-test landing page, headline as outcome, three benefits, one call to action, real email capture. Stand up a simple pricing section if price is a risk.

Week 2, prove the demand.

• Days 6–7: Launch a small paid-ad test (three to five angles) plus posts in two relevant communities. Drive cold, qualified strangers to the page.
• Days 8–10: Let it run. Watch conversion rate and cost per signup daily, but do not touch the pass/fail line you set.
• Days 11–12: If signups are strong, escalate to the hardest test: ask the warmest signups to pre-order or put down a deposit. Real money is the final exam.
• Days 13–14: Read the signals against your predefined thresholds and decide, build, iterate the offer, or drop. Write down what you learned either way.

Two weeks and a small ad budget buys you an answer that would otherwise cost a full MVP build to discover. If validation drags past this, you have turned it into a build, the exact thing it exists to prevent.

How real startups validated demand first

The most valuable startups did not begin with polished products. They began with scrappy validation that proved demand before the real product existed.

Dropbox, the explainer video (smoke test). Before building the sync engine, Drew Houston posted a three-minute demo video showing how Dropbox would work. The beta waitlist jumped from around 5,000 to 75,000 overnight. He validated demand for a product that barely existed, and proved a video could be a demand test in itself. The lesson: when the product is hard to convey, sell the outcome, not the build.

Airbnb, air mattresses (concierge). In 2007 the founders rented out air mattresses in their own apartment to test one question, would strangers pay to stay in someone's home? It was a concierge MVP: manual, tiny, and just enough to prove the core hypothesis before any platform existed. The lesson: do it by hand before you automate it.

Zappos, photos from the shoe store (Wizard of Oz). Nick Swinmurn tested whether people would buy shoes online by photographing stock at local stores, posting the photos, and buying from the store when an order came in. Real transactions, no inventory, no warehouse, pure proof of demand. The lesson: fake the back end, but make the front end real enough to capture real behavior.

Buffer, the two-page pricing test (pre-sales / fake-door). Buffer's founder put up a page describing the product, then added a second page with pricing plans behind a "Plans and Pricing" button. Clicks on the paid plans, before any product existed, validated not just demand but willingness to pay at specific prices. The lesson: validate price, not just interest, because they are different questions.

The pattern across all four: each answered its riskiest question with the least possible product, and none scaled until the proof was in. That is the entire discipline of validation.

MVP validation mistakes that waste months

1. Validating with friends and family. Warm, biased, and useless. Your network wants you to succeed and will lie to protect your feelings. Test on strangers who actually have the problem, their indifference is the most valuable feedback you will get.

2. Asking instead of measuring. "Would you use this?" gets polite fiction. Make people act, click, sign up, pay, and measure the action. The gap between stated and revealed preference is where startups die.

3. No pass/fail line set in advance. Without a threshold decided before you look, you will rationalize any result into a "yes." Define success first; let the number, not your hope, make the call.

4. Validating the solution before the problem. If the pain is not real, no product fixes it. Confirm the problem exists and hurts before you test whether your specific fix wins. Founders skip this because they are in love with their solution, which is exactly why they should not.

5. Over-validating to avoid building. Endless tests become a way to dodge the scary part, committing. Once the signal is clear, repeated, and came from strangers who acted, stop. More data past that point is procrastination with a spreadsheet.

6. Confusing curiosity with commitment. Signups and likes feel like progress; deposits and repeat usage prove value. Weight the signals that cost the user something, and discount the ones that are free to give.

7. Testing on the wrong audience. A real product validated against the wrong people produces a confident, expensive mistake. Make sure the strangers you test on are the ones who actually have the problem and the budget to solve it. The full list of MVP development challenges starts here, with who you point the test at.

When you have validated enough to build

You have validated enough when the evidence is clear, repeated, and came from strangers who took a costly action. Concretely, you are ready to build when:

• Your riskiest assumption passed the threshold you set in advance.
• The signal showed up across multiple people, not one enthusiastic outlier.
• At least one stranger did something that cost them, a deposit, a pre-order, real time, not just a free click.
• You can describe, in one sentence, the single core flow the product must deliver.

Hit those and more testing just burns time. Your job flips from proving demand to building the proof, the smallest real product that delivers the validated outcome. That is the single-feature MVP at the heart of the MVP development process, and the moment to sequence it is exactly when validation, not your roadmap, says go. If you want a structured way to plan that build, an MVP roadmap turns your validated insight into a scoped sequence.

From validated idea to funding-ready MVP

Most founders searching for an MVP agency to help with business validation and market demand want the same thing: a partner who can both pressure-test the idea and build it the moment demand is real, without losing weeks in the handoff. That is how we work at MVP Development.

• We help you validate the right thing. Before a line of code, we help you name the riskiest assumption and choose the lightest test, so you spend on learning, not on a premature build.
• When demand is real, we build fast. A complete, funding-ready MVP in 3–4 weeks, built by senior engineers on a scoped quote you approve up front, exactly the single core flow your validation proved people want.
• It is funding-ready by default. A deployed product with a working core flow and a live URL, the artifact that turns a pre-seed conversation into a check.
• You own the code. Production-grade and yours to scale after product-market fit, not a throwaway prototype you will rewrite.

The honest trade-off is scope, not quality: we build the one validated flow, not ten guesses, which is what validation told you to do anyway. You can see the full range of what we build across our MVP development services, or go straight to a custom MVP build if your idea does not fit a standard category.

Validated demand and ready to build? Tell us about your idea and we will scope your funding-ready MVP.

Frequently asked questions

What is MVP validation?

MVP validation is the process of proving there is real market demand for your idea using the smallest, cheapest experiment possible, before you commit to building the product. It tests whether enough people want the outcome badly enough to act: to sign up, join a waitlist, or pay. The goal is to get an honest "yes" or "no" in days, not after a months-long build.

How do you validate an MVP idea?

Write down your riskiest assumption as a testable sentence, pick one metric that proves or disproves it, choose the lightest test that can move that metric (a landing page, fake-door test, interviews, or pre-sales), set a pass/fail threshold in advance, drive real strangers to the test, and then build, iterate, or drop based on the result.

How do you validate market demand for a business idea?

Put your offer in front of cold, relevant strangers and measure whether they act. Landing-page signups, fake-door clicks, paid-ad cost-per-signup, and especially pre-sales or deposits all measure demand because they require action. Customer interviews validate that the underlying problem is real. The strongest demand signal is money: someone paying or pre-ordering before the product exists.

What are the best MVP validation methods?

The proven methods, lightest to heaviest, are: customer interviews (is the problem real?), landing-page smoke tests (is there interest?), fake-door tests (demand for a feature), paid-ad tests (engagement at a price), pre-sales and waitlist deposits (willingness to pay), concierge MVPs (does the solution deliver value?), and crowdfunding (demand plus funding). Pick the lightest one that can answer your riskiest question.

How long does MVP validation take?

A landing-page or fake-door test runs in days for the cost of a small ad budget. Interview-based validation takes one to two weeks. Pre-sales and concierge tests take a few weeks. A complete validation sprint, problem to demand to a go/no-go decision, fits comfortably in two weeks. If validation stretches into months or starts costing real money, it has turned into a build, which is exactly what it is meant to prevent.

Can you validate an MVP without building anything?

Yes, that is the point of most early validation. Landing pages, fake-door tests, interviews, ad tests, and pre-sales all measure demand without a working product. A Wizard-of-Oz test goes one step further, giving users a real experience while you run the back end manually, so you validate the outcome before building the engine.

How much does it cost to validate an MVP?

Far less than building one. Most validation runs on a small paid-ad budget plus free or low-cost no-code tools for the landing page, forms, and checkout, often a few hundred dollars total. Compared with the cost of a full MVP build, validation is the cheapest insurance a founder can buy, and a failed test that costs a few hundred dollars can save a build worth tens of thousands.

What is the difference between problem validation and solution validation?

Problem validation confirms the pain you are targeting is real, frequent, and costly, usually through customer interviews about past behavior. Solution validation confirms that your specific fix is the one people will choose and pay for, usually through landing pages, fake-doors, or pre-sales. You always validate the problem first; solving a problem nobody has is the most expensive mistake in startups.

How many customer interviews do you need to validate an idea?

There is no magic number, but five to fifteen focused interviews with the right people usually reveal the pattern. You are looking for the same problem surfacing unprompted across most conversations, plus evidence of existing workarounds. If ten interviews produce no consistent pain, that is a clear signal, more interviews rarely change a flat result, but they will help you understand why if you plan to pivot.

When should you stop validating and start building?

Stop when the evidence is clear, repeated, and came from strangers who took a costly action (a deposit, a pre-order, real time). If your riskiest assumption passed the threshold you set in advance and you can describe the core flow in one sentence, more testing just burns runway. Build the smallest real product that delivers the validated outcome, and let real usage become your next round of validation.

Sources & references

This guide draws on established lean-startup and customer-development practice:

• Eric Ries, The Lean Startup, the build-measure-learn loop and the origin of the MVP
• Rob Fitzpatrick, The Mom Test, how to run customer interviews that surface real demand instead of polite lies
• Y Combinator, How to Talk to Users, the free primer on demand-revealing interviews
• Steve Blank, Customer Development, getting out of the building to validate before you build
• Shortform, The Original Dropbox MVP Explainer Video, a smoke-test that validated demand before the product existed

Benchmarks reflect Q2 2026 practice; the 3–4 week figure reflects MVP Development delivery data for tightly scoped builds.