What Actually Is a Minimum Viable Product? Assumptions, Validation and the Stages from Idea to Evidence

1. Introduction

Ask ten founders what an MVP is and you will hear ten answers: a basic version of the app with the "nice to have" features removed, a landing page, whatever can be built before the money runs out. Each contains something true, but together they show that a term meant to sharpen thinking has become a label for almost any early product.

The confusion matters because it changes behaviour. If an MVP is simply "version one, smaller", teams spend months building it, launch it, and then try to work out what the results mean. If an MVP is an experiment, teams start by asking what they most need to learn, what would count as evidence, and what is the cheapest thing that could produce it. The first approach treats building as the goal and learning as a by-product; the second treats learning as the goal and building as one possible means to it.

The distinction has sharpened recently. AI assistants now let one person produce a working prototype of a web application in days. Building a prototype has become cheap. Being wrong has not: a product nobody wants still costs the time, money and morale spent on it. When construction is easy, deciding what is worth constructing becomes the scarce skill.

Section 2 traces the origins of the term. Sections 3 and 4 present products as stacks of assumptions and a framework for validating them. Section 5 sets out the stages of an MVP, the decision gate at their centre, and their mapping onto MVPAI (Map, Validate, Plan, Assemble, Ignite). Section 6 compares types of MVP, Section 7 works through an example, Section 8 covers failure modes, ethics and AI, Section 9 the limits of evidence, and Section 10 offers an exercise.

2. Origins and definitions

The phrase "minimum viable product" is generally credited to Frank Robinson, who used it around 2001 in his product development work at SyncDev. His concern was timing: release too much too late and effort is wasted; release too little too early and nobody is satisfied.

The term reached a wide audience through Eric Ries, who defines the MVP as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Ries, 2011). Two words carry most of the weight. Learning moves the purpose from selling to finding out. Validated insists that the learning rest on evidence about real behaviour, not the team's opinion of its own work. Ries placed the MVP inside a loop, Build–Measure–Learn, in which a team turns ideas into something testable, measures the response, and uses what it learns to decide what to do next. As Figure 1 shows, the loop is meant to be run repeatedly; the speed of the whole cycle, not the polish of any single build, is what matters.

Ries built on Steve Blank's customer development, which argues that a startup is not a small version of a large company: a large company executes a known business model, whereas a startup is searching for one (Blank and Dorf, 2012). Founders must test their guesses with real customers before scaling; Blank later summarised the shift as a move from elaborate business plans to rapid experimentation and customer feedback (Blank, 2013). The MVP is the instrument that makes this search practical.

Several neighbouring terms are often confused with the MVP.

• Prototype. A representation of a product used to explore or communicate a design: a sketch, a clickable mock-up, a rough model. It serves as an MVP only when used to test an assumption with real people against a pre-agreed measure.
• Minimum marketable product (MMP). The smallest product that can be sold and delivers enough value to be adopted. Its purpose is revenue, not learning, and it usually comes after several MVPs have reduced the main risks.
• Minimum lovable product (MLP). A term arguing that "viable" sets the bar too low and that early products should delight a small group. The point is fair in crowded markets, but it can become an excuse to over-build before anything has been learned.

Henrik Kniberg offers a corrective to the commonest misreading. He describes the mistake of building a car one part at a time, a wheel, then a chassis, then a body, so that the customer can use nothing until the end. The alternative is to deliver something usable at every step, a skateboard, then a scooter, then a bicycle, each solving the transport problem a little better and each generating feedback (Kniberg, 2016). Figure 2 shows the contrast. Kniberg suggests more precise terms, the earliest testable, earliest usable and earliest lovable product, which make clear which question each release answers.

In this article, then, an MVP is defined as an experimental version of a product, or a simulation of one, that people can use or respond to, designed to produce validated learning about the riskiest assumption behind an idea with the least effort. This follows Ries's definition. An MVP need not involve software: a concierge service run by hand, or a landing page describing the offer, is a version of the product that real people respond to. But not every experiment is an MVP. A customer interview, a survey or a desk-research exercise can test assumptions, often more cheaply, yet none puts a version of the product in front of anyone. These are discovery methods, and they usually come before an MVP rather than replacing it. An MVP's success is judged by the quality of what it teaches, not of what was built.

3. Theory: products as stacks of assumptions

Every product idea, however confident its founder, is a set of untested beliefs. Beneath "independent tutors will pay for a booking tool" sit many smaller claims: that tutors find booking painful; that the pain is frequent and costly enough to act on; that parents will use a new tool; that it can be built and run at a sensible cost; that tutors will choose it over a messaging app; and that they can use it without help. If any one is false, the product fails, however well the rest is executed. A product is best understood as a stack of assumptions, and early product work is about finding the false ones before too much is built on top.

Product thinkers group these assumptions into risk types. The design firm IDEO popularised three lenses through which innovation must pass: what is desirable to people, feasible technically and viable as a business (Brown, 2009). Marty Cagan describes four big risks for technology products: value (will customers buy or choose to use it?), usability (can users work out how to use it?), feasibility (can we build it with the time, skills and technology we have?) and business viability (does it work for the rest of the business, such as sales, legal and finance?) (Cagan, 2017). Combining these gives the four kinds of risk the Academy uses:

• Desirability: do people have this problem, and do they want this kind of solution?
• Viability: can this become a sustainable business? Will people pay, and does the model hold together?
• Feasibility: can it be built and operated reliably, safely and at reasonable cost?
• Usability: can the intended users actually achieve what they came to do?

The categories overlap, and no single framework is "correct". Their value is that they force a team beyond the risk it is most comfortable with: engineers worry about feasibility, designers about usability, founders about desirability, and viability is often nobody's concern until too late. With capable AI assistants, the feasibility of a prototype is now, for most simple software products, the least uncertain of the four. Feasibility in production is another matter: security, reliability, integrations with other systems, data protection, maintainability and operating cost remain significant risks, and AI-assisted building does not remove them (Section 8.3).

Assumptions become useful only when written as testable hypotheses. "Tutors will love this" cannot be shown false; a hypothesis can. MVPAI uses one template:

"We believe [solution] for [user] will [outcome], shown by [metric]."

The user names a specific group, not "everyone"; the outcome states the change in that user's life or work; the metric states what will be observed if it happens. The metric is the hardest part and the most important, because it commits the team in advance to what counts as success. A hypothesis without a metric is a hope.

4. Framework: validating assumptions

If a product is a stack of assumptions, which should be tested first? Bland and Osterwalder (2019) propose assumption mapping. Each assumption is placed on a two-by-two grid. One axis asks how important it is: if false, would the idea fail? The other asks how much evidence exists for it: observed facts, or a guess? As Figure 3 shows, testing should begin with the important assumptions that have little evidence. Important, well-supported assumptions can be monitored; unimportant ones can wait, however uncertain, because being wrong about them will not sink the idea.

The map is only as good as the honesty of those who fill it in; a team that has spoken to three friends may feel it has "evidence" of demand. It therefore helps to grade evidence. The Academy teaches a ladder with four rungs, shown in Figure 4.

1. Opinion. Someone says your idea sounds good, or that they would use it. People are polite, imagine an idealised future self, and bear no cost for being wrong.
2. Stated need. Someone describes a real problem in their own life, unprompted, with specifics. This is about their experience rather than your idea.
3. Observed behaviour. You see what people actually do: the workaround they built, the time they spend, the click, the return visit. Behaviour is harder to fake than speech.
4. Commitment. Someone gives up something of value: time, reputation, personal information or money. A pre-order, a letter of intent, a paid pilot or an introduction to their manager all count.

The ladder is a general guide, not a fixed ranking: which evidence is strongest depends on the hypothesis being tested. For willingness to pay, a paid pilot or pre-order is the stronger evidence. For retention or habit, sustained repeated use is stronger, and a one-off payment says little about whether someone will still be using the product in three months. Commitment is not automatically "higher" for every question; the best evidence is the behaviour the hypothesis predicts.

The ladder is consistent with Fitzpatrick's The Mom Test, which warns that compliments and hypothetical statements about the future are unreliable, and that founders should ask about specific past behaviour and look for real commitments instead (Fitzpatrick, 2013). It also reflects Bland and Osterwalder's (2019) distinction between weak evidence, such as what people say in an interview, and strong evidence, such as what they do in a realistic setting.

A second principle is that thresholds must be set before results are seen. A threshold is the value of the metric that counts as success, written down in advance. Without one, almost any result can be called encouraging: twelve sign-ups from five hundred visitors might be "a strong start" or "a clear failure" depending on the mood of the meeting. A good threshold is specific (a number and a base, such as "at least 8 of 20"), linked to a decision, and realistic for the sample size. Many teams set two numbers, one above which they continue and one below which they stop or change direction, with the band between calling for a closer look. If no result would change the plan, the test is not worth running.

Although the Build–Measure–Learn loop is drawn starting with Build, Ries suggested planning it in reverse: decide what you need to learn, then what to measure, and only then what to build. Torres (2021) makes a similar point about continuous discovery: test assumptions rather than whole ideas, in small, frequent experiments.

5. The stages of an MVP

The path from idea to evidence follows a recognisable sequence of eight stages, summarised in Figure 5 with the loop back that follows a decision.

1. Ideation. Start from a problem someone has, not a technology: who has which pain, in what situation, how often, at what cost. State a first idea as a hypothesis, and generate alternatives.
2. Problem validation. Check that the problem is real, frequent and painful enough to act on, mainly through conversations about past behaviour and by observing current workarounds. Include the alternatives, especially doing nothing, every product's commonest competitor.
3. Solution hypothesis. Choose a concept, write it with the template in Section 3, list the assumptions behind it and map them as in Section 4.
4. Choosing the MVP type. The riskiest assumption determines the type: a desirability question may need only a landing page or a concierge service; a usability question needs something people can try; a feasibility question may need a technical spike. Write the metrics, thresholds and scope now.
5. Build. Build the smallest thing that will produce the evidence. With AI assistance this is fast, which is exactly why scope must be fixed beforehand.
6. Measure. Put the MVP in front of real users from the target group and collect the agreed metrics, as counts with a base, with notes on what people actually did.
7. Learn and decide. Compare the results with the thresholds and decide whether to persevere, iterate, pivot or stop (Section 5.1).
8. Scale. Invest significantly in making the product dependable and growing it only when the riskiest assumptions have survived and there is evidence of retention (people keep using it), repeatable acquisition (new customers can be reached again and again at a known cost) and viable unit economics (each customer brings in more than it costs to win and serve them). Scaling brings its own assumptions, which start the loop again.

5.1 The decision gate: the most important step

The seventh stage is where the value of everything before it is realised, and it is the one most often skipped. A test that does not end in a recorded decision is activity, not learning. The gate follows three rules.

First, the decision is made against thresholds set in advance, not the mood in the room. There are four outcomes. To persevere is to continue because the evidence supports it. To iterate is to keep the strategy but change the solution. To pivot, in Ries's (2011) sense, is to change a fundamental part of the strategy, such as the customer segment or the problem, while keeping what has been learned. To stop is to end the idea. Stopping is a legitimate outcome; an MVP that ends a weak idea cheaply has done its job.

Second, the decision is recorded with its evidence: the hypothesis, who was tested and how they were found, the threshold, the result as a count and a base, and the decision. A written record stops a team rewriting history and lets someone else check the reasoning.

Third, a conditional decision must be specific. MVPAI's Proceed with conditions is not a polite form of yes: it names the assumption still open, the person who owns it, and when, at which gate and against which threshold, it will be re-checked. If nobody can name those three things, the honest outcome is Go back. The worksheet in Section 10 puts these rules into one table.

5.2 How the stages map onto MVPAI

MVPAI turns the eight stages into five phases and eleven steps, each ending at a gate with one of three outcomes: Proceed, Proceed with conditions or Go back. The mapping is not one-to-one, and two places often puzzle beginners.

Problem validation spans Map and Validate because a problem is checked twice, at two depths. In Map you check that the pain is real, by talking to people who have it. In Validate you check it against the market: what people use today, what they pay, and whether doing nothing is good enough. The first asks "does this hurt?"; the second, "does it hurt enough, compared with the alternatives, to pay for a fix?"

Measuring sits with Assemble because the first thing to measure is what you have just built: in Assemble you demo it to real users and grade it, asking whether they reach the first moment of value. Ignite then measures something different, real-world use and growth once the product is live. Put simply, Assemble measures the experiment; Ignite measures the market.

MVPAI uses "ideation" more narrowly, for step 03, where at least three concepts are scored the same way. Its Go back outcome is not failure: it is the decision step of the Build–Measure–Learn loop written into the route itself.

6. Types of MVP

Choosing an MVP means matching the method to the assumption. Bland and Osterwalder (2019) catalogue dozens of experiment types; the table compares seven common ones. Cost and speed are rough guides for a small team. "Risk of misleading you" is how easily the method yields something that looks like evidence but is not.

Figure 6 places these types by cost and by how much they let a team learn. The positions are illustrative judgements drawn from the comparison above, not empirically measured comparisons; real cost and learning depend on the team, the market and how well the test is run. The broad pattern still holds: the cheapest methods tend to test only desirability, at the lower rungs of the evidence ladder. That is no reason to avoid them: a landing page is an excellent way to discover that almost nobody is interested, and a poor way to prove that people will keep using a product.

The most cited explainer-video MVP is Dropbox. As Ries (2011) recounts it, Drew Houston found file synchronisation hard to demonstrate through a simple prototype, so he made a short video aimed at early technology enthusiasts, and the beta waiting list grew from around 5,000 to 75,000 people. It is often retold as "Dropbox validated its idea before building anything", but working technology already existed: the video tested whether people wanted it, not whether it could be built. The lesson is narrower and more useful: one assumption, tested cheaply.

7. Worked example: TutorDesk

TutorDesk is a fictional product used throughout the Academy's teaching. All people, figures and results below are illustrative. They are not real research and do not describe real traction.

7.1 Ideation

The founder first described the idea as "an AI booking app for tutors", which names a technology, not a problem. Restated as a problem: independent tutors of school-age students lose time and income arranging and rearranging lessons with parents by message, and late-cancelled lessons often go unpaid. The idea became a hypothesis:

"We believe a booking link with self-service rescheduling for independent tutors will reduce the time spent arranging lessons, shown by at least half of reschedules being completed without a message to the tutor."

Three concepts were scored on the same criteria: a shared booking link, a group calendar shared with parents, and a cancellation policy template with automatic reminders. The booking link scored highest; the reminder concept was a strong runner-up.

7.2 Problem validation

The founder held twelve conversations with tutors about the last time a lesson had to be moved. Nine of twelve described the back-and-forth as a weekly irritation; six of twelve could name a lesson they had lost income on in the past month. Their alternatives were messaging apps, a paper diary and, in two cases, a spreadsheet. These conversations were discovery, not yet an MVP: they tested the problem, not a version of the product.

7.3 Solution hypothesis and assumption map

The team mapped the assumptions behind the hypothesis:

• Desirability: parents will use a link rather than messaging the tutor directly. (Important; little evidence.)
• Viability: tutors will pay around £8 a month. (Important; little evidence.)
• Usability: parents can reschedule on a phone in under a minute. (Important; some evidence from similar tools.)
• Feasibility: the team can build a booking link with calendar sync. (Moderately important; strong evidence, since many such tools exist.)

The riskiest assumption, important and unproven, was parental behaviour. Tutors clearly had the pain, but the product only worked if parents changed their habits.

7.4 Choosing the MVP type and setting thresholds

Because the riskiest assumption concerned behaviour, not technology, the team chose a concierge MVP. Eight tutors, recruited through the founder's network, shared a simple web form with parents for rescheduling; a team member updated calendars by hand and confirmed changes by email. Parents were told the service was a trial and that a person handled requests.

Before the two-week trial, the team wrote down its thresholds:

• Persevere: at least 50% of rescheduling requests arrive through the form.
• Iterate: between 25% and 49%.
• Pivot or stop: below 25%.
• Secondary signal: at least 3 of 8 tutors agree to a paid pilot at £8 a month.

7.5 Build and measure

The build took an afternoon: one form, one shared spreadsheet and a confirmation email template. Over the two weeks, the eight tutors received 41 rescheduling requests, of which 19 of 41 (46%) came through the form. Three of eight tutors agreed to a paid pilot.

The result sat in the iterate band, and the observations explained why. Five tutors had put the link in a reminder sent before each lesson, and most of their parents used the form. The other three had sent the link once, at the start, and most of their parents kept messaging.

7.6 Learn and decide

The team did not move the threshold to fit the result. Under its own rule, the decision was to iterate: keep the strategy and the customer, change the solution, drawing on the runner-up concept of an automatic reminder before each lesson with the link inside it. In MVPAI terms this was Proceed with conditions: the open assumption (parents use the link when it arrives at the right moment) was named, the founder owned it, and it would be retested at the next gate against a new threshold with a larger sample.

The MVP involved almost no software, the threshold turned an ambiguous number into a clear decision, and the most useful learning came from observed behaviour, not the headline percentage. Section 9 asks how much 41 requests from eight tutors can really tell anyone.

8. Failure modes and ethics

8.1 Failure modes

Vanity metrics. Ries (2011) distinguishes vanity metrics, which make a team feel good, from actionable metrics, which inform decisions. Page views, total sign-ups and downloads tend to rise whatever the product's quality. A useful metric is tied to the hypothesis, has a base, and could plausibly come out badly.

False positives. Encouraging results can have causes unrelated to the product: a burst of traffic from one forum, novelty, or the personal attention of a concierge service. Small samples make this worse (Section 9). Ask what else could explain a good result, and look for the same signal in a second, independent test before investing heavily.

Testing on friends. Friends and colleagues want to help, give kind opinions, sign up out of loyalty, and are rarely the target user. Fitzpatrick (2013) observes that people will often lie to protect your feelings; the remedy is to talk to strangers who have the problem and ask about their past behaviour, not your idea.

Over-building. The commonest failure is building far more than the test requires: login, payments and settings pages, when the question was whether parents would use a link. It delays learning, deepens the emotional investment that makes bad news hard to accept, and produces features later thrown away.

Moving the goalposts. Changing the threshold after seeing the result quietly turns an experiment back into an opinion.

8.2 The ethics of fake-door tests and pre-orders

A fake-door test presents an option, such as a button, pricing page or sign-up form, for something that does not yet exist, to measure interest. Wizard of Oz and some landing-page MVPs share this feature: the user believes something is real that is not, or not yet. These methods can be ethical, but they carry real obligations.

• Honesty. Do not make false claims about what exists, what it does or when it will be available. Say "coming soon" or "join the waiting list" rather than implying a working product.
• Consent. Collect only the data the test needs, say what it will be used for, and handle personal data lawfully. If a human is reading messages behind a Wizard of Oz interface, say so, at least once the person has taken part.
• Debriefing. When someone clicks through to a door that is not there, tell them promptly and plainly what is happening, thank them, and offer a choice about being contacted later.
• Payment. Legitimate pre-orders and crowdfunding do take money before a product exists, subject to consumer-protection, transparency, fulfilment and refund obligations. Never misrepresent availability or delivery capability. Where pre-orders are accepted, disclose the product's development status, expected delivery arrangements, material risks and applicable cancellation or refund rights.

The test is simple: would the person feel misled if they understood exactly what you were doing? If so, change the design.

8.3 The AI era: building is cheap, being wrong is not

AI assistants have changed the economics of the "Build" step. A prototype that once took weeks can be assembled by one person in an evening, so richer MVPs, such as single-feature products, become as cheap as landing pages once were. This is also a trap. When building feels free, it is tempting to skip the thinking that should precede it and to treat a working product as evidence that the idea is right. A product that works but that nobody wants is still a failure, reached faster.

It helps to separate prototype speed from production readiness and operating cost. A prototype only has to work in a demo. A production product must also be secure, cope with failures, protect personal data, integrate with other systems and remain maintainable by whoever inherits the code. And it costs money to run: hosting, monitoring, maintenance and, for products that call an AI model, an inference cost for every user action. A few pence per use is invisible in a ten-person test and decisive at ten thousand users, so cost per user is a viability assumption to test, not a detail to defer.

What does the research show? Three studies are often cited, and each is narrower than its headlines.

• In a controlled experiment, Peng et al. (2023) found that developers given GitHub Copilot completed a programming task (writing a simple web server in JavaScript) roughly 56% faster than a control group. This is experimental evidence, but for one narrow, well-specified task; it says little about larger, ambiguous or long-lived software.
• In a user study, Perry et al. (2023) found that participants with an AI code assistant tended to write less secure code on security-related tasks than those without, while being more likely to believe their code was secure. The sample was modest and the tools have moved on, but the risk it identifies, confidence outrunning correctness, is the relevant one.
• In a field experiment with management consultants, Dell'Acqua et al. (2023) found that AI improved speed and quality on tasks within its capabilities but made people less likely to reach the correct answer on a task chosen to lie outside them, an uneven boundary the authors call a "jagged technological frontier".

Together these support a cautious conclusion: AI can make well-specified building much faster, but speed does not guarantee security or correctness, and users are not always good at telling which side of the frontier they are on. Claims that AI makes whole products or teams many times more productive are, at the time of writing, largely opinion and anecdote rather than controlled evidence, and are best treated as hypotheses.

The implication for MVPs is unchanged, and stronger. Writing hypotheses, mapping assumptions and setting thresholds in advance matter more when building is easy, because they now stand between a team and a well-built mistake. A working AI-built prototype is evidence about desirability or usability at most, never evidence that the product is ready for production.

9. Evidence quality and its limits

A threshold turns a result into a decision, but it cannot make weak evidence strong. Four questions decide how much an MVP result is worth.

Who did you test with? A result describes the people in the sample, not the market. Friends, colleagues and enthusiastic early adopters are easy to reach and unusually willing to try new things, so results from them tend to overstate demand. Record who took part, how many, and how they were recruited. TutorDesk's eight tutors came through the founder's network, not from tutors in general, so the result applies, at most, to tutors like them.

What is the denominator? A percentage without its base hides how much evidence there is. Always report "19 of 41", not just "46%", and define the base: here, every rescheduling request the eight tutors received during the trial, not parents and not tutors. Changing the base after the event, by dropping an "unusual" tutor or counting only the second week, is another way of moving the goalposts.

How uncertain is the number? Small samples give wide uncertainty. Treating the 41 requests as independent, an approximate 95% confidence interval for 19 of 41 runs from roughly 31% to 62%: the true rate could sit well inside the iterate band or comfortably above the persevere threshold. Because the requests came from only eight tutors with different habits, they are not truly independent, so the real uncertainty is wider still. The secondary signal is weaker again: three of eight tutors agreeing to a paid pilot is consistent with a true rate anywhere from about one in seven to more than two in three.

Was the threshold set first? The decision rule must be written before the data arrive. Uncertainty is no excuse for moving it; it is a reason to set thresholds that are realistic for the sample size, and to treat a result near a boundary as a call for another test rather than a verdict.

None of this makes small tests useless; it means they answer a modest question. Eight tutors and 41 requests cannot establish market-wide demand. They can only justify, or fail to justify, the next, larger test, which is exactly what TutorDesk's iterate decision did. Each round should enlarge the sample, recruit beyond the founder's network and climb the ladder of evidence.

9.1 Validation is not product-market fit

An MVP can validate, or invalidate, an assumption without demonstrating a sustainable market. Even had TutorDesk's trial passed every threshold, it would have shown only that some parents use a link when prompted and that some tutors will try a paid pilot. Product-market fit, a term usually traced to Marc Andreessen, who described it as "being in a good market with a product that can satisfy that market" (Andreessen, 2007), is a later and much stronger claim. It is shown by retention (people keep using and paying), by demand that is organic or repeatable rather than pushed by the founder, and by economics that work as the business grows. A validated assumption is a step towards product-market fit, not evidence of it. Confusing the two is expensive, because it triggers scaling (Section 5) before the evidence supports it.

10. Exercise

10.1 A one-page test plan

Complete the template for an idea of your own. Work through the rows in order, and do not fill in the threshold after you have run the test.

10.2 Decision worksheet

Record each test on a decision worksheet. Fill in the first four columns before the test and the last two only after it. The first row shows the TutorDesk trial from Section 7.

If you would like a guided place to practise, the Academy's free course Build with AI: First Steps (at /academy/first-steps/) takes you from a first idea to a small working product with an AI assistant, and is a good setting in which to run your first experiment safely.

11. Key takeaways

• An MVP is an experimental version of a product, or a simulation of one, built to learn about your riskiest assumption with the least effort. It is not a cut-down first release, and not every experiment is an MVP.
• Every product is a stack of assumptions about desirability, viability, feasibility and usability.
• Write hypotheses with a metric, and set thresholds before you see any results.
• What people do and commit to usually outweighs what they say, but the strongest evidence is the behaviour your hypothesis predicts.
• Make the decision gate explicit: persevere, iterate, pivot or stop, recorded with its evidence.
• Report counts with their base, and treat a small sample as a reason for the next test, not proof of a market.
• Validating an assumption is not product-market fit; scale only with evidence of retention, repeatable acquisition and viable economics.
• AI makes prototypes cheap; it does not make production, or being wrong, any cheaper.
• The purpose of an MVP is not to prove that you can build something; it is to discover whether you should build it.