MVP Validation: How to Test a Minimum Viable Product Before You Build It

Quick answer

MVP validation is the discipline of testing the smallest useful version of a product — a Minimum Viable Product, or MVP — against real customer behavior before committing to a full build. The MVP exists to produce evidence, not features. The right MVP is the cheapest experiment that can produce a believable signal about the assumption that, if false, would invalidate the rest of the plan.

Six methods produce useful signal, in increasing order of strength: a landing page test, a concierge MVP, a Wizard of Oz MVP, a prototype test, a paid pilot, and a feature-scope MVP. They roughly track how much of the product has to exist before the test can run. The five-step framework is Assumption → Smallest Test → Customer Signal → Learning → Decision. Each rung must hold before the next is meaningful, and the final rung produces a build/pivot/stop decision instead of more questions.

The seven failure modes show up before the founder notices them: building too much, measuring vanity metrics, ignoring customer feedback, confusing usage with value, testing the wrong assumption, conflating the MVP with the finished product, and shipping an MVP that nobody can find.

Key takeaways

• An MVP is a learning tool, not a finished product. Eric Ries, in The Lean Startup (2011), defined the MVP as the smallest version of a product that lets you run a complete "Build–Measure–Learn" loop. The output of an MVP is evidence, not revenue. A founder who treats the MVP as a launch is reading the wrong data.
• The MVP exists to test the critical assumption. Steve Blank's Four Steps to the Epiphany (2005) and the Customer Development methodology treat the MVP as the deliverable of the customer-discovery process, not its substitute. Build the smallest thing that can produce a believable signal about the single assumption that, if false, would invalidate the rest of the plan.
• Six methods rank from cheapest to strongest. Landing page → concierge → Wizard of Oz → prototype → paid pilot → feature-scope MVP. The right method depends on the assumption being tested, not on the founder's preferences. A B2B SaaS that needs to test an integration workflow cannot do it with a landing page.
• A concierge MVP is a manual version of the product. The founder does the work automation would do, by hand, for ten to twenty real customers. The cost is high in founder hours and zero in engineering hours. The signal is honest because the customer pays for an experience, not for code.
• A Wizard of Oz MVP looks automated but is not. The customer believes they are using software; behind the curtain, a human is producing the output. The signal is whether the customer would pay for the experience if it were automated at scale. Stripe Atlas, Zappos, and many consumer AI products started this way.
• The polite-yes problem applies to MVP feedback. Rob Fitzpatrick's The Mom Test (2013) is the canonical reminder that customer compliments are not customer behavior. A founder who measures MVP success by the enthusiasm of beta users is measuring enthusiasm, not retention.
• The seven failure modes are predictable. Each has a recognizable signature. Knowing the signature lets you diagnose the real problem before the next build cycle. The most common is "building too much," which by some informal estimates accounts for more failed MVP launches than every other failure mode combined.

Why this matters

I have watched two founders launch MVPs in the same quarter with very different outcomes.

The first had a consumer productivity tool. The MVP took fourteen weeks to build. It had nine features, a polished onboarding, an animated empty state, and a marketing site. The launch went well: 1,400 signups in the first week, a small wave of press, two Product Hunt features. Day-30 retention was below 4%. The product solved a real problem, but the version that solved it had been bundled with seven other things the customer did not need. The team had spent fourteen weeks building the wrong MVP.

The second had a B2B SaaS for a narrow workflow. The MVP took six days to build. It had one feature, one customer, and one founder running the workflow by hand using a shared spreadsheet and an email parser. The customer paid $300/month for the experience. By week eight, the founder had five paying customers and had automated exactly the parts the customers actually used. The build took six days because the founder had spent the previous six weeks on customer discovery, not on engineering.

The two cases are not exceptions. The first is closer to the median. CB Insights' Startup Failure Post-Mortem reporting consistently lists "no market need" and "built the wrong product" as the two most-cited failure categories; together they account for roughly half of failed startups across multiple survey years. Most of those failures are MVP failures — they built the wrong thing, or the right thing in the wrong way, or built something nobody could find.

This article is the smallest set of steps that prevents that pattern. Not a lecture on minimum viable products. A concrete framework that turns "we should test this" into "we tested this and here is what we learned."

The deeper treatment — the four validation stages, the seven failure modes, the willingness-to-pay experiment that precedes the MVP — lives in the canonical How to Validate a Startup Idea Before Building. The vocabulary used in this article is defined in the Startup Validation glossary. The MVP definition and the difference between MVP and prototype is in the MVP glossary entry.

What is an MVP?

MVP (Minimum Viable Product) is the smallest version of a product that lets a team run a complete Build–Measure–Learn loop with the least amount of effort. The term was popularized by Eric Ries in The Lean Startup (2011) and refined across a decade of practitioner use. The MVP is a learning tool, not a finished product. Its output is evidence about an assumption; its input is the smallest amount of work that can produce that evidence.

Three things make this definition harder than it looks.

"Minimum" means minimum for the test, not minimum for the product. A founder who builds the cheapest possible thing is building the wrong MVP if the cheapest possible thing cannot produce a believable signal. The right MVP is the smallest version of the product that can deliver the experience the customer is being asked to value. A landing page is a minimum test for interest. It is not a minimum test for value.

"Viable" means viable for the customer, not viable for the founder. A B2B SaaS whose MVP is a founder running the workflow in a spreadsheet is viable for the customer when the spreadsheet workflow produces the experience the customer values. The customer does not care whether the product is automated. The customer cares whether the experience is good. The founder's job is to make the experience good with the tools available, then automate the parts that survive contact with real usage.

"Product" is a temporary label. The thing called an MVP at week one is rarely the thing called the product at week fifty. The MVP is the artifact at the moment of testing. Once the test produces a result, the artifact may be discarded. A founder who falls in love with the MVP is reading the wrong data.

A useful way to think about the concept: the MVP is an experiment you ship, not a product you launch. That distinction is the entire reason MVP validation exists.

MVP vs prototype

A prototype is a model used to test the design, the workflow, or the interaction. The prototype is for the team; it is rarely shown to the customer in any deep way. The MVP is for the customer; it is shipped to a small group and observed in real conditions. The prototype answers "does this work as we designed it?" The MVP answers "does this work in the customer's life?"

MVP vs final product

The MVP is the smallest version that can produce a signal. The final product is the version the team ships to a paying audience at scale. The distance between the two is the sum of every decision the MVP cannot yet support. A founder who treats the MVP as the final product — adding every feature the customer requested during testing — is no longer running an MVP. The founder has restarted a full build cycle, with a different name.

Why MVP validation matters

Five reasons, in increasing order of consequence.

First, building before validating burns runway in a predictable pattern. CB Insights' Startup Failure Post-Mortem (2024 update) lists "no market need" as the top-cited reason for startup failure, named by roughly 40% of failed founders across multiple survey years. "Built the wrong product" is consistently second. Both are MVP failures. The runway burned is not just the months spent building; it is the opportunity cost of the next idea, the morale damage of the failed launch, and the statistical fact that founders who launch once rarely launch again.

Second, the polite-yes problem contaminates MVP feedback. Rob Fitzpatrick's The Mom Test (2013) is the canonical reminder that customer compliments are not customer behavior. A beta user who says "this is great!" and never returns is contributing a false positive. A founder who measures MVP success by beta enthusiasm is measuring enthusiasm, not retention. The cure is the same as in every other validation stage: observe behavior, not opinion.

Third, an MVP that does not include the moment of truth produces no signal. The "moment of truth" is the action the customer takes that proves the product is providing value. For a SaaS tool, it is the second session. For a marketplace, it is the second completed transaction. For a consumer app, it is the second return visit. An MVP that does not let the customer reach the moment of truth is testing the wrong thing. A founder who ships a beautifully designed landing page and an empty product has shipped the wrong MVP.

Fourth, the assumption the MVP tests must be the critical assumption. Steve Blank's Four Steps to the Epiphany (2005) made this explicit: the MVP exists to test the hypothesis that came out of customer discovery. A founder who builds an MVP to test a non-critical assumption has built the wrong MVP. The test will produce a result, but the result will not be informative.

Fifth, the assumption behind the MVP must be falsifiable. A test whose result can never come back negative is not a test. An MVP whose designers believe will succeed regardless of what the customers do is a launch event, not an experiment. The honest MVP is one whose authors can describe, in advance, what a negative result would look like.

How to validate an MVP

Six methods produce useful signal. They run from cheapest to most expensive, and they roughly track the strength of the signal they produce.

1. Landing page test

The cheapest, weakest, and most often misread method.

The right setup is a single page that describes the product, drives a small amount of traffic through one or two channels, and measures how many visitors take the next step — sign up, request access, leave an email. The signal is intent, not commitment. A 30% conversion rate on a well-targeted landing page is encouraging. A 2% conversion rate is not a disproof; it is a signal that something is wrong with the page, the targeting, or the offer.

The landing page test is most useful when the assumption being tested is whether the value proposition is clear. It is not useful when the assumption is whether the product solves the problem. A customer who reads a landing page is not the same as a customer who uses a product.

2. Concierge MVP

The first method that tests behavior, not interest.

A concierge MVP is a manual version of the product experience delivered directly by the founder. The customer signs up for the experience; the founder does the work automation would do, by hand, often using a spreadsheet, an email parser, and a personal workflow. The cost is high in founder hours and zero in engineering hours. The signal is honest because the customer pays for an experience, not for code.

The concierge MVP is the most informative method at the customer-discovery stage because every interaction produces a learning. A founder running a concierge MVP hears the customer's words, sees the customer's workarounds, and feels the friction the automation will have to remove.

The concierge MVP has limits. It scales linearly with founder hours, which caps the number of customers the founder can serve. It also tests the experience the founder can deliver, not the experience a scaled team could deliver. A concierge MVP that works for ten customers may not work for ten thousand.

3. Wizard of Oz MVP

The middle method, and the one most worth running when the experience is the product.

A Wizard of Oz MVP looks automated but is not. The customer believes they are using software; behind the curtain, a human is producing the output. The signal is whether the customer would pay for the experience if it were automated at scale. The cost is founder hours (still), but the appearance of automation makes the test feel real to the customer and exposes frictions the concierge test would smooth over.

Stripe's early Atlas flow, Zappos' first customer experience, and many consumer AI products have started as Wizard of Oz MVPs. The pattern is the same: ship the interface, do the work by hand, observe what the customer does, automate the parts that survive contact with real usage.

The Wizard of Oz MVP is most useful when the customer experience depends on speed or volume the founder can produce manually. It is least useful when the customer is buying automation and would not value the experience without it.

4. Prototype test

The method that tests interaction before building.

A prototype is a clickable model of the product, built in a design tool or a no-code environment, used to test the interaction with a small number of customers. The prototype is not the product; the customer knows it. The signal is whether the customer can use the prototype to complete the workflow the product would automate.

The prototype test is most useful when the assumption is about the workflow, not about the value proposition. A prototype that customers can complete is encouraging; a prototype that customers cannot complete is a workflow problem, not a value problem.

5. Paid pilot

The strongest pre-build signal, and the one that closes the pricing loop.

A paid pilot is a small group of customers who pay the founder, in advance, for an early version of the product, with the understanding that they will give feedback and the founder reserves the right to refund. The customer has done the thing that actually matters: given money. The signal is whether the customer, having paid, continues to use the product and to renew.

The paid pilot is most useful when the founder needs to know whether the willingness to pay survives contact with the experience. It is least useful when the assumption is about discoverability or scale, neither of which a paid pilot tests.

6. Feature-scope MVP

The most expensive, most diagnostic method, and the one that closes the MVP loop.

A feature-scope MVP is a working product with the minimum feature set required to deliver the value proposition. The customer uses the product in real conditions. The signal is the cohort retention curve, the willingness to renew, and the willingness to refer. A feature-scope MVP that retains and renews is a strong signal that the value proposition works. A feature-scope MVP that does not retain is a strong signal that the value proposition is not landing.

The feature-scope MVP is most useful when the founder has already tested the lower-cost methods and the remaining assumption is whether the product retains at scale. It is least useful when the founder has not tested the customer-discovery stage, because a feature-scope MVP that fails to retain may be failing because of the customer, the workflow, or the value proposition, and the founder will not know which.

The MVP validation framework: Assumption → Smallest Test → Customer Signal → Learning → Decision

The five-step framework below is what every MVP validation method is a sub-test of. Each rung must hold for the next rung to be meaningful.

Assumption. A specific claim about the world that the MVP exists to test. The claim is testable, falsifiable, and tied to a customer behavior the MVP can observe. The cheapest way to write the assumption is the form "We believe [customer] will [behavior] when [condition]." A founder who cannot write the assumption in that form has not yet defined the MVP.

Smallest Test. The cheapest method that can produce a believable signal about the assumption. The method is chosen from the six above based on the assumption, not on the founder's preferences. A landing page is the smallest test for interest. A concierge MVP is the smallest test for value. A Wizard of Oz is the smallest test for experience. A paid pilot is the smallest test for willingness to pay. A feature-scope MVP is the smallest test for retention.

Customer Signal. The behavior the customer exhibits in response to the test. The signal is observed, not asked for. A customer who pays is a stronger signal than a customer who signs up. A customer who uses the product twice is a stronger signal than a customer who uses it once. A customer who refers a friend is a stronger signal than a customer who praises the product.

Learning. The interpretation of the signal that informs the next decision. The learning is one sentence: "The assumption is supported, partly supported, or not supported, because [signal]." A founder who cannot write the learning in that form has not yet interpreted the signal.

Decision. The build/pivot/stop decision the learning supports. The decision is one of three: build more of the same, change the assumption and re-test, or stop. A founder who does not make a decision has not finished the test.

The framework is sequential. A founder who has not written the assumption should not pick the smallest test, because the test will be picked for the wrong reason. A founder who has not observed the customer signal should not write the learning, because the learning will be inferred from opinion. A founder who has not written the learning should not make the decision, because the decision will be made on enthusiasm.

The framework is also cumulative. Each rung produces evidence the next rung depends on. A founder who skips the assumption and jumps straight to a feature-scope MVP can still learn something — they will learn whether the MVP retains — but they will not know whether the retention failure is caused by the wrong customer, the wrong value proposition, or the wrong feature set.

Common MVP mistakes

The seven failure modes that show up before the founder notices them. Each is recognizable, named, and preventable.

Build-too-much failure. The founder builds nine features when one would have produced the signal. The MVP takes fourteen weeks to ship. The customer is overwhelmed by the experience and cannot tell which feature is the value proposition. The fix is to revisit the assumption and pick the smallest test that can produce a believable signal.

Vanity-metric failure. The founder measures signups, downloads, social media followers, or press features. None of it converts to retained users. The conversion funnel has volume at the top and empty seats at the bottom. The fix is to test the customer signal rung before adding more top-of-funnel volume.

Ignoring-feedback failure. The founder hears customer complaints and treats them as edge cases. The complaints are signals about the value proposition. The fix is to listen to the customer behavior, not the customer compliments.

Usage-vs-value failure. The founder measures usage — sessions per week, time in product, features clicked — and treats usage as value. A customer who uses the product out of obligation is not a customer who values the product. The fix is to measure retention, renewal, and willingness to refer, not usage.

Wrong-assumption failure. The founder builds an MVP to test a non-critical assumption. The test produces a result, but the result is not informative about the assumption that, if false, would invalidate the rest of the plan. The fix is to revisit the customer discovery stage and identify the critical assumption.

MVP-as-finished-product failure. The founder treats the MVP as the launch. The founder adds every customer request to the MVP. The MVP is no longer minimum. The fix is to remember that the MVP is a learning tool, not a finished product, and to keep the MVP small until the test produces a result.

Unfindable-MVP failure. The founder builds an MVP nobody can find. The product is real; the audience is not reached. The fix is to test the distribution channel before testing the product, because an MVP that nobody can find has no customers to test against.

FAQ

What is MVP validation?

MVP validation is the discipline of testing the smallest useful version of a product — a Minimum Viable Product, or MVP — against real customer behavior before committing to a full build. The MVP is a learning tool, not a finished product. Its output is evidence about an assumption; its input is the smallest amount of work that can produce that evidence. The full framework lives in the Startup Validation glossary.

How do you validate an MVP?

By running the five-step framework — Assumption → Smallest Test → Customer Signal → Learning → Decision — and stopping to fix each rung before moving to the next. The most common error is skipping the assumption rung and jumping to a feature-scope MVP that cannot produce a believable signal. The method is explained in the canonical How to Validate a Startup Idea Before Building.

Should you build an MVP first?

Yes, but only after the customer-discovery stage has produced a falsifiable assumption. An MVP built before the customer knows the customer is a launch event, not an experiment. An MVP built after the customer discovery is the smallest test that can produce a believable signal about the critical assumption. The order matters: discovery first, MVP second. The canonical order is in the Startup Validation checklist.

What is the difference between MVP and prototype?

A prototype is a model used to test the design, the workflow, or the interaction. The prototype is for the team; it is rarely shown to the customer in any deep way. The MVP is for the customer; it is shipped to a small group and observed in real conditions. The prototype answers "does this work as we designed it?" The MVP answers "does this work in the customer's life?" Both have a place; they answer different questions.

How long should MVP validation take?

There is no honest answer that fits every idea. The right answer is "however long it takes to run a complete Build–Measure–Learn loop on the critical assumption, no longer." For a B2B SaaS whose critical assumption is the willingness to pay for a specific workflow, MVP validation can take two to six weeks. For a consumer app whose critical assumption is the retention of a specific habit trigger, MVP validation can take six to twelve weeks. A founder who has spent longer than twelve weeks on MVP validation without producing a result is probably building too much.

Can AI help validate an MVP?

AI is useful for summarizing patterns in customer feedback, drafting the assumption statement, and analyzing the customer signal data. It cannot replace the experiment, because the experiment is a real customer in a real situation, and AI cannot observe that. Treat AI as a tool for the analysis; treat the MVP as the experiment the founder must run. The validation report that Startup MRI produces surfaces the assumptions that most often prevent MVP validation from producing a result; it does not predict whether the MVP will succeed.

What is a concierge MVP?

A concierge MVP is a manual version of the product experience delivered directly by the founder. The customer signs up for the experience; the founder does the work automation would do, by hand, often using a spreadsheet, an email parser, and a personal workflow. The cost is high in founder hours and zero in engineering hours. The signal is honest because the customer pays for an experience, not for code. The full definition is in the Startup Validation glossary.

What is a Wizard of Oz MVP?

A Wizard of Oz MVP looks automated but is not. The customer believes they are using software; behind the curtain, a human is producing the output. The signal is whether the customer would pay for the experience if it were automated at scale. The pattern is the same as the concierge MVP, with one difference: the customer does not know the work is manual. Stripe's early Atlas flow and Zappos' first customer experience both started this way.

What is the difference between MVP and final product?

The MVP is the smallest version of the product that can produce a believable signal about the critical assumption. The final product is the version the team ships to a paying audience at scale. The distance between the two is the sum of every decision the MVP cannot yet support. A founder who treats the MVP as the final product — adding every feature the customer requested during testing — is no longer running an MVP; the founder has restarted a full build cycle.

What are the most common MVP failure modes?

The seven most common are: build-too-much failure (the MVP takes fourteen weeks and tests nothing), vanity-metric failure (signups without retention), ignoring-feedback failure (treating complaints as edge cases), usage-vs-value failure (measuring sessions instead of retention), wrong-assumption failure (testing a non-critical assumption), MVP-as-finished-product failure (treating the MVP as the launch), and unfindable-MVP failure (building a product nobody can find). Each has a recognizable signature; each has a fix that starts with the framework rung that broke.

What is the smallest MVP that produces a signal?

There is no universal answer; the smallest MVP depends on the assumption being tested. For interest, a landing page is enough. For value, a concierge MVP is the smallest test that can produce a believable signal. For experience, a Wizard of Oz MVP is the smallest test. For willingness to pay, a paid pilot is the smallest test. For retention, a feature-scope MVP is the smallest test. The founder's job is to match the smallest test to the assumption, not to pick the smallest test in absolute terms.

How does MVP validation relate to product-market fit?

MVP validation produces the evidence that product-market fit requires. PMF is the state in which a specific product satisfies a real, repeated demand from a specific audience well enough that retention, word-of-mouth, and organic acquisition improve on their own. MVP validation is the work that gets the product to a state where PMF can be observed. The full PMF method is in Product-Market Fit Validation.

How does MVP validation relate to willingness to pay?

Willingness to pay must be tested before the MVP. A founder who builds an MVP without testing willingness to pay may discover, after weeks of engineering, that the price the customer will pay is below the cost of building. The willingness-to-pay test is the cheaper signal; the MVP is the confirmation. The full willingness-to-pay method is in Willingness to Pay Validation.

How does MVP validation relate to customer discovery?

Customer discovery produces the assumption the MVP tests. Without customer discovery, the MVP has no falsifiable hypothesis to test, and the test produces no informative signal. The order matters: discovery first, MVP second. The full customer-discovery method is in How to Find Your First Customers Before You Build.

What is the experiment design behind an MVP?

Every MVP is an experiment, and every experiment has the same structure: hypothesis, treatment, measurement, and decision. The hypothesis is the assumption. The treatment is the smallest test. The measurement is the customer signal. The decision is the build/pivot/stop outcome. A founder who designs the MVP as an experiment, rather than as a launch event, is the founder who produces evidence instead of opinions.

Can you validate an MVP without code?

Yes. A landing page, a concierge MVP, a Wizard of Oz MVP, and a paid pilot can all run without writing a line of code. The signal a no-code MVP produces is the same as the signal a coded MVP produces, provided the test is honest and the customer reaches the moment of truth. A founder who can run the MVP without code has not yet identified the assumption that requires code to test.

Summary

MVP validation is the discipline of testing the smallest useful version of a product against real customer behavior before committing to a full build. The MVP is a learning tool, not a finished product. Its output is evidence about an assumption; its input is the smallest amount of work that can produce that evidence.

The six methods rank from cheapest to strongest: landing page → concierge → Wizard of Oz → prototype → paid pilot → feature-scope MVP. The five-step framework is Assumption → Smallest Test → Customer Signal → Learning → Decision. Each rung must hold before the next is meaningful. The seven failure modes are predictable: build-too-much, vanity-metric, ignoring-feedback, usage-vs-value, wrong-assumption, MVP-as-finished-product, and unfindable-MVP.

The polite-yes problem applies to MVP feedback as much as to customer interviews; the cure is to observe behavior, not opinion. The assumption the MVP tests must be the critical assumption. The MVP must include the moment of truth. The test must be honest enough to produce a negative result.

The goal is not to ship a perfect MVP. The goal is to find out, in weeks and for under a few hundred dollars, whether the smallest version of the product can produce a believable signal about the assumption that, if false, would invalidate the rest of the plan. If it can, build. If it cannot, change the assumption and re-test.

Related reading

• How to Validate a Startup Idea Before Building — the canonical four-stage framework this article sits inside.
• Problem-Solution Fit Validation — the rung that precedes the MVP; confirms the proposed solution addresses a real, recurring problem before any code is written.
• Startup Validation Checklist — the operational checklist that turns the framework into a 30-day plan.
• Willingness to Pay Validation — the payment signal that precedes the MVP; the MVP is the confirmation, not the substitute.
• Product-Market Fit Validation — what the MVP is producing evidence for; PMF is the state the MVP helps the product reach.
• How to Find Your First Customers Before You Build — the customer-discovery stage that produces the assumption the MVP tests.
• The Mom Test Explained for Solo Founders — the conversation discipline that prevents the polite-yes problem from contaminating MVP feedback.
• How to Validate a SaaS Idea Before You Build It — the SaaS-specific assumption stack, including the recurring-revenue cliff that the MVP must reach.
• Distribution Channels Ranked for Solo Founders — the eleven channels that move a stranger from first contact to paying customer; the MVP that nobody can find has no customers to test against.
• The Startup Validation hub — the full reading path and topical taxonomy.
• The Startup Validation glossary — plain-language definitions of MVP, concierge MVP, Wizard of Oz, prototype, and the rest of the validation vocabulary.

What to do next

If you have read this far, the question is what you will do in the next two weeks.

The smallest useful action is to write the assumption the MVP will test, in the form "We believe [customer] will [behavior] when [condition]." The next is to pick the smallest test that can produce a believable signal about that assumption — landing page, concierge, Wizard of Oz, prototype, paid pilot, or feature-scope MVP, chosen to match the assumption. The third is to ship the test to ten specific customers, observe the behavior, and write the learning in one sentence.

None of these requires a finished product. None requires permission. None requires a team.

If you would like a structured second opinion on which assumption your MVP should test before you pick the smallest test, Startup MRI's validation analysis helps. It takes about five minutes and surfaces the critical assumption your idea most depends on, so the MVP you build is the one with the highest signal.

For a worked example of what a real validation report looks like, see the SaaS validation report example, the AI startup validation report example, or the mobile app validation report example. Each shows every section your own report will contain, including the MVP scope callout.

The right validator landing depends on the audience: the Startup Idea Validator for general ideas, the Startup Idea Evaluator for founders who use "evaluate" as the verb, and the Startup Score Calculator for a numeric 0–100 read on the same six dimensions.

Build the smallest thing that can produce a signal. Run the framework. Read the customer behavior.