Before you write code, make a product, commit to inventory, staff a service or spend on delivery, name the assumption that would sink the idea if it were wrong. Then run the cheapest credible test that could change your decision. Evidence gets stronger as it moves from opinion to observed behaviour to something the buyer puts at stake. A test has done its job when the result changes what you do next: build, narrow the idea, run another test, or stop. Some things cannot be known yet. Retention, repeat purchase, real conversion and lifetime value need customers using and paying for a working product or a repeatable service, so no pre-build test settles them.
Validate market demand before an MVP by testing whether the problem is real, whether the right buyer can be reached, whether the current workaround is painful enough to challenge, and whether someone will take a consequential next step before a working product exists. That evidence can justify building, narrowing, testing again or stopping. The MVP then tests product use, delivery, adoption and other questions that pre-build demand evidence cannot settle.
The commercial questions are the same across formats: is the problem real, who has it, what do they do today, can you reach them, will they put something at stake, and is there a plausible path from that buyer to a business? The test changes with the thing being offered. The evidence boundary does not.
Software: test the problem, current workaround, buyer access and willingness to commit before you build features. An offer response, design-partner commitment or paid pilot can inform the next decision. None establishes adoption, retention, reliability or scalable delivery before people use the product.
Physical product: test the problem, buyer and willingness to commit before tooling, a production run or inventory. A prototype, deposit or pre-order can inform whether a buyer will put something at stake. It does not establish manufacturability, safety, certification, unit yield, returns, fulfilment capacity or repeat purchase.
Service: test the problem, buyer, delivery promise and willingness to pay before hiring, building operations or spending on acquisition. A paid trial, pilot or manual delivery can inform whether the outcome is worth buying. It does not establish repeatable delivery, staffing capacity, margin, quality at scale or renewal.
Already launched and wondering why nothing converts? That is a different question: read the traction diagnosis.
SaaS validation guide: Recurring workflow, buyer, current stack, switching-friction, design-partner or pilot and paid-commitment questions before choosing a validation method.
The free check reads public market evidence, so it speaks to the problem and the current workaround. Buyer, reachability, commitment and the commercial path are not settled by it: the first three are yours to test, and the last is what the paid stages work on. That boundary is the same whether the idea is software, a physical product or a service.
Problem: Is the problem real, recurring and costly enough that someone is already trying to deal with it? Evidence: People describing the problem in their own words, unprompted, and describing what it costs them in time, money or risk. Where the evidence comes from: Public market evidence (the free True Validation check); A test you run yourself, before building. Buyer: Who feels this problem, and who decides whether anything is done about it? Evidence: A description of the person and the setting specific enough that you could find ten more like them this week, and an account of who holds the budget and who can say no. Where the evidence comes from: A test you run yourself, before building; Later paid work, Stages 2 to 6; Stage 2: Buyer Precision. Current workaround: What do they do today, and what does that alternative already cost them? Evidence: The spreadsheet, the manual process, the incumbent tool, the existing supplier, the existing service, or the decision to live with it, described in enough detail that you can see where it breaks. Where the evidence comes from: Public market evidence (the free True Validation check); A test you run yourself, before building. Reachability: Can you get in front of these buyers repeatedly, without relying on a one-off favour? Evidence: A repeatable way you actually reached them: a community, a list, an introduction path or a channel you can use again next week. Where the evidence comes from: A test you run yourself, before building; Later paid work, Stages 2 to 6; Stage 4: Revenue Funnel, Stage 5: Market + Funnel. Commitment: Has any buyer put something at stake rather than saying the idea sounds good? Evidence: Access, time, data, a dated next step, a pilot they helped set up, a deposit, a pre-order or money. What matters is what they gave up, not how positive they sounded. Where the evidence comes from: A test you run yourself, before building. Commercial path: Is there a plausible route from this buyer to a business, and what would have to be true for it to hold? Evidence: A stated path to price, delivery and repeat purchase, with the parts you cannot yet know written down as open questions rather than assumed answers. For a physical product or service, this includes delivery and operating constraints that need their own feasibility work. Where the evidence comes from: Later paid work, Stages 2 to 6; Stage 3: Buyer + Offer, Stage 4: Revenue Funnel, Stage 6: Commercial Decision.
Acquisition cost, payback and lifetime value are not pre-build gates. They need real spend and real customers, which is Stage 4: Revenue Funnel work, not something a pre-build test can settle.
Most lists of product idea validation methods, startup validation methods or demand validation methods name the techniques and stop there. The question that decides which one to use is narrower: which assumption does the method test, what can its result support, and what can it not establish? Seven method families cover the common techniques, because several of the names describe the same decision.
Methods generate evidence. The evidence rubric interprets how strong a buyer signal in that evidence is. The same method can produce a weak or a strong signal depending on what the buyer actually did, so the grade belongs to the result, not to the method. The grade shown for each family is the one its result usually reaches. The five practical dimensions below describe what each method asks of you, as editorial guidance. They are not measured costs or durations. No figure is given, because none would hold across different ideas, buyers and markets.
Problem interviews (also called: Customer interviews, Discovery interviews). Action: Ask people who should have the problem about the last time it happened, what they did, what it cost and who else was involved, before you describe any possible solution, product or service. Evidence produced: Accounts of real incidents in the buyer's own words, with the cost and the workaround attached. May support: That the problem recurs, costs something, and sits with a particular kind of person. Cannot establish: That anyone will pay, or that your solution is the one they want. Agreement in a conversation is not a decision. The interview tests a problem and its current workaround. It does not test whether you can make, deliver or operate the proposed answer. Stronger next test: Ask to see the workaround in use, then ask what would have to be true for them to replace it. Signal: Politeness. Usually Politeness, sometimes Interest. Warm words about the problem are not a signal about your offer. Founder effort Your own time finding the right people and holding the conversations. Technical effort None. Participant access People who have the problem have to agree to talk to you. Money changes hands? No. Working product needed? No. Public complaint and workaround research (also called: Complaint research, Review mining). Action: Read what people say about the problem unprompted in public: complaint threads, review platforms and relevant specialist communities, including what they say current tools get wrong. Evidence produced: Descriptions of the problem and its workarounds from people you did not ask. Complaint threads, reviews, specialist communities, trade forums and public buyer discussions can reveal problem and workaround language. They are evidence about the problem, not proof that a buyer will choose a proposed software product, physical product or service. May support: That the problem is visible beyond your own contacts, and the language buyers use for it. Cannot establish: Who would buy, what they would pay, or whether they would switch. Public complaint shows the problem, not demand for your answer to it. Stronger next test: Take the buyers' own words into problem interviews and test whether the pain is recent and costly. Signal: Not a buyer signal. Not a buyer signal about your offer. It is evidence about the problem, so the rubric does not grade it. Founder effort Desk research: finding and reading the right public sources. Technical effort None. Participant access None. The sources are already public. Money changes hands? No. Working product needed? No. Current-solution research (also called: Competitor research, Alternative mapping). Action: Map what buyers use or buy today, what they tolerate, and what changing supplier, product, workflow or provider would cost in effort, data, risk, money and internal politics. Include existing tools, suppliers, service providers, internal processes and doing nothing. Evidence produced: A picture of the alternative, its price, and the cost of moving away from it. May support: Whether there is room for a better answer, or whether the current one is good enough. Cannot establish: That anyone will actually move. Switching cost is not measured by reading about it. Stronger next test: Ask buyers what would have to be true for them to replace what they use today. Signal: Not a buyer signal. Not a buyer signal about your offer. It describes the alternative, so the rubric does not grade it. Founder effort Desk research, plus the questions you add to problem interviews. Technical effort None. Participant access Mostly public material, with some detail that only buyers can give you. Money changes hands? No. Working product needed? No. Offer response test (also called: Landing page, Smoke test, Fake-door variant, Sales page, Concept card, Prototype enquiry). Action: Put a clear description of the offer in front of the buyer you named, through a channel you could use again, and ask for a response that costs them something: a booked call, a scoped conversation or a request to be a first user. Evidence produced: What people did when shown the offer, and how much effort it took to put it in front of the right ones. May support: That the promise is understood, and that a channel can reach the buyer and produce action. Cannot establish: Willingness to pay. A click or a signup is not a purchase, and a response to a description is not a response to a working product. Stronger next test: Ask the people who responded for a dated next step, a deposit or a pre-order. Signal: Interest. Usually Interest. A request for a dated next step moves it towards Intent. In the fake-door variant, the button or signup leads to something that does not exist yet. Say plainly what happens next, because a dead end tests your wording at the cost of the visitor's trust, and the click it records says less than it appears to. For a physical product or service, make clear what is real now, what is a concept or prototype, and what happens after a buyer responds. Founder effort Writing the offer, and putting it in front of the right people rather than any people. Technical effort A page or a message. No finished product is required. A message, concept card, sales page or prototype enquiry can test whether the promise is understood. Participant access A channel that actually reaches the buyer you named. Money changes hands? Not usually. Asking for a deposit turns it into a commitment test. Working product needed? No. In the fake-door variant, nothing exists behind the interaction. Manual delivery test (also called: Concierge, Wizard-of-Oz variant). Action: Deliver the intended outcome by hand, through a prototype, or through a deliberately manual service for one buyer, and watch whether they want it again and what it actually took to produce. Evidence produced: Whether the outcome is wanted a second time, and what delivering it really involves. May support: That the outcome has value, and what the product would really have to do. Cannot establish: It cannot establish that a product can be manufactured safely, that a service can be delivered repeatedly by others, or that the outcome can be delivered economically at scale. Doing it by hand for one buyer hides the cost of doing it for many. Stronger next test: Charge for the manual delivery, then see whether the buyer pays again. Signal: Intent. Usually Intent, because the buyer gives time and attention to receive it. Paying for it makes it Commitment. In a concierge test the buyer knows the outcome is delivered by hand. In the Wizard-of-Oz variant the manual work is hidden behind something that looks like a working product, which tests the experience as well as the outcome. Hiding it carries a trust cost if the buyer later feels misled, so decide in advance what you will tell them. Founder effort You do the work the product would do, by hand, for each buyer. Technical effort Little or none for a concierge test. The Wizard-of-Oz variant needs a front end convincing enough to use. Participant access A buyer willing to receive the outcome and tell you what happened. Money changes hands? Sometimes. Charging for it makes it a commitment test as well. Working product needed? No. The point is to test the outcome before automating it. Design partner or pilot (also called: Design partner, Free pilot, Proof of concept). Action: Ask a named buyer to work with you: to define what success means, give access or data, and set a date. Write down what they are giving up by taking part. Evidence produced: What they committed, who else they involved, and whether the work survived contact with their calendar. May support: That the problem is prioritised now, and who else is involved in a decision. Cannot establish: That a free pilot converts to payment, or that other buyers share this buyer's needs. A free pilot is evidence of time and access, not willingness to pay. Stronger next test: Attach a term that costs something: a fee, a purchase order, a start date or a named payer. Signal: Intent. Usually Intent. A pilot with a fee or a named payer moves it towards Commitment. Founder effort Running the work alongside the buyer's own, often over several meetings. Technical effort A representative prototype, partial working version, sample product, or manual delivery that lets the buyer assess the relevant outcome. Participant access A named buyer who agrees to give time, access or data. Money changes hands? Not in a free pilot. In a paid pilot it does, which makes it a commitment test. Working product needed? Usually a partial version, or a manual one standing in for it. Commitment test (also called: Pre-sale, Deposit, Pre-order, Paid pilot, Signed order). Action: Ask for the commitment that carries economic consequence, with the person who controls the budget involved. Evidence produced: Whether someone with budget acted at a price, and what they expected in return. May support: That a buyer with budget acted on the problem at a price. Cannot establish: Retention, renewal or lifetime value, which need a product that exists and is used, or that one buyer's commitment will repeat. Stronger next test: Ask a buyer who owes you no favour for the same commitment. Signal: Commitment. Commitment, when the buyer genuinely puts money or an obligation at stake. Founder effort Asking for money, and agreeing terms with whoever controls it. Technical effort Depends on what is promised. A deposit, pre-order or paid pilot can happen before a finished product or service exists, provided the buyer is told what will be delivered and when. Participant access The buyer and the person who holds the budget. Money changes hands? Yes. That is the point of the test. Working product needed? Not for a pre-sale or deposit. Delivery follows the commitment.
Choose by circumstance, not by category. These questions decide which method is realistic and informative for the assumption you are testing. Can you reach buyers directly? If you can, problem interviews and design partners are within reach. If you cannot yet, public research and an offer response test tell you whether a channel exists at all. Can money change hands before the product exists? If a buyer can pay for a promise, a pre-sale or deposit is the strongest pre-build evidence available. If they cannot, for example where buying requires a working product to evaluate, a design partner or pilot is the realistic route to commitment. Can the result be delivered by hand? If it can, a manual delivery test shows whether the outcome is worth having before you automate it. If the value only exists once software runs at scale, rely more on offer response and commitment tests. Do procurement or a separate payer matter? Where the person who uses it is not the person who pays, test the payer as well. A user's enthusiasm is not a budget decision. Does the test need a functioning product? Most pre-build tests do not. If yours does, you are closer to a pilot than a pre-build test, and questions about retention start to apply. Does the idea require a physical product, regulated process or specialist delivery? Run the commercial test and the feasibility work separately. A buyer's interest, deposit or pre-order can inform demand. It does not prove safety, certification, manufacture, inventory, fulfilment, licensing or operating capacity. Does the proposed service depend on the founder's own time or specialist judgement? Use a manual delivery or paid trial to learn whether the outcome is worth buying, then record what delivery actually took. A single founder-led result does not establish that the service can be staffed, repeated or delivered profitably. A business selling to other businesses often has fewer buyers, harder access and a separate payer, which can make design partners, pilots and payer involvement more informative. A consumer product can often put an offer or pre-order in front of many people quickly. A physical product may need a prototype or sample, while a service may be delivered manually first. These are tendencies, not rules: choose by the assumption, the buyer's decision, and what the test can actually establish.
GTM Right's working interpretation of its evidence rubric for the pre-build case, not a universal standard. GTM Right's working rubric, not a universal research taxonomy.
A conversation about the idea (Politeness). Can show: Whether the problem is recognised, and the language the buyer uses for it. Cannot show: Whether anyone will change what they do, or pay. Stronger next test: Stop discussing the idea. Ask what happened the last time the problem occurred, and what it cost. An observed workaround: the spreadsheet, the manual process, the tool they pay for today (Interest). Can show: That the problem is real and is already costing someone time or money. Cannot show: That they will buy your version of the solution. This is evidence about the problem, not proof of demand. Stronger next test: Ask to see the workaround in use, then ask what would have to be true for them to replace it. Access or time given: a working session, their data, an introduction to the person who decides (Intent). Can show: That the problem is worth spending scarce time on, and who else is involved in a decision. Cannot show: What they would pay, or whether the spend survives a budget conversation. Stronger next test: Ask for a dated next step with someone who controls budget attached to it. A design-partner or pilot action: they help scope it, name success, or set a date (Intent). Can show: That the problem is prioritised now rather than in principle. Cannot show: That the pilot converts to payment, especially where the pilot costs them nothing. Stronger next test: Attach a term that costs something: a fee, a purchase order, a start date or a named payer. Economic commitment: a deposit, a pre-order, a paid pilot, a signed order (Commitment). Can show: That someone with budget acted on the problem at a price. Cannot show: Retention, renewal or lifetime value, which need the product to exist and be used. Stronger next test: Test whether the same commitment repeats with a buyer who owes you no favour.
There is no number of interviews, signups or conversion rate that makes an idea validated. The test is whether the evidence you have would change your decision, and whether the next cheapest test could change it again.
Step 1, Problem interviews. Assumption: problem. Action: Talk to people who should have the problem. Ask what happened the last time it occurred, what they did, what it cost and who else was involved. Do not describe your idea until the end. Evidence produced: Accounts of real incidents, in the buyer's words, with the cost and the workaround attached. Build: Not yet. Nothing here is purchase evidence on its own. Narrow: The problem is sharp for one kind of person and vague for the rest. Follow the sharp one. Test again: People recognise the problem but cannot recall a recent instance. Find buyers closer to the pain. Stop: Nobody can describe the problem happening, and nobody does anything about it today. Step 2, Public complaint and workaround research. Assumption: problem. Action: Look for people describing the problem unprompted in public: complaint threads, review platforms and relevant specialist communities. Read what they say the current tools get wrong. Evidence produced: Unprompted descriptions of the problem and its workarounds, from people you did not talk to. Build: Not on its own. Public evidence tells you the problem is visible, not that anyone will buy. Narrow: The complaints cluster around one setting or one job. Narrow to that cluster. Test again: You find noise but no specifics. Change the search language to the words buyers used in interviews. Stop: The problem is nowhere in public and no one you interviewed has acted on it. Step 3, Current-solution research. Assumption: workaround. Action: Map what buyers use today, including doing nothing. Find what they already pay for, what they tolerate, and what switching would cost them in effort, data, risk and politics. Evidence produced: A picture of the alternative, its price, and the cost of moving away from it. Build: Not yet. Knowing the alternative is weak is not the same as knowing anyone will move. Narrow: One segment is badly served by the incumbent while others are content. Narrow to the underserved one. Test again: The alternative looks adequate. Test whether the pain you found is worth the switching cost at all. Stop: Buyers are content, or switching costs are so high that no reachable buyer would move. Step 4, Offer response test or manual delivery test. Assumption: reachability. Action: Run an offer response test: describe the offer to the buyer you named and ask for a response that costs something, such as a booked call, a scoped conversation or a request to be a first user. Where the outcome can be delivered by hand, run a manual delivery test instead and deliver it yourself for one buyer. Evidence produced: What people did when asked, how much effort it took to reach them, and, for a manual delivery, whether they came back for more. Build: Not yet, though a manual delivery someone keeps asking for is a strong reason to continue. Narrow: One message or one audience does the work. Narrow the offer to that promise. Test again: You could not reach enough of the right people to learn anything. Change the channel, not the claim. Stop: You can reach the buyer, they understand the offer, and they still do nothing. Step 5, Design-partner or pilot test. Assumption: commitment. Action: Ask a named buyer to work with you: to define what success means, to give access or data, and to set a date. Write down what they are giving up by taking part. Evidence produced: What they committed, who else they involved, and whether the work survived contact with their calendar. Build: Buyers commit their own time and people, and the scope they ask for is one you can deliver. Narrow: They commit only to a smaller part of the problem. Build that part. Test again: They agree in principle but nothing gets scheduled. Ask for the commitment that has a date on it. Stop: Nobody will commit anything beyond encouragement. Step 6, Commitment test. Assumption: commitment. Action: Ask for the commitment that carries economic consequence: a paid pilot, a deposit, a pre-order or a signed order, with the payer involved. Evidence produced: Whether someone with budget acted at a price, and what they expected in return. Build: A buyer with budget commits at a price you can live with, and you can name who the next ones are. Narrow: They commit for a narrower scope or a lower price. Take the scope and note the price question. Test again: The commitment stalls with the payer. Find out what the payer needs to see and test that. Stop: The offer is understood, the buyer is the right one, and nobody will commit anything that costs them.
Waitlist signup. Can show: That the promise is understood and interesting enough to leave an address for. Cannot show: That anyone will pay, or that the signup will answer you later. Design partner. Can show: That a buyer will spend their own time and expose their process to shape the product. Cannot show: That the wider market shares their needs, or that they will buy what they helped design. Free pilot. Can show: That the problem is worth a slot in their calendar and permission to be inside their process. Cannot show: Willingness to pay. A pilot that costs the buyer nothing leaves the price question untested. Paid pilot, deposit, pre-order or paid trial. Can show: That someone with budget acted at a price, before the product was finished. Cannot show: That the price holds at scale, that delivery is repeatable, or that the buyer renews or repurchases. Procurement or payer involvement. Can show: That the purchase is being treated as a real one, with the people who can approve or block it in the room. Cannot show: The outcome. Procurement involvement is a sign of seriousness, not a decision. Signed commercial commitment. Can show: That terms were agreed and someone accepted an obligation. Cannot show: Delivery, repeatable operations, retention or renewal. Those questions begin only once the product or service is being used.
The evidentiary weight of an LOI depends on its actual terms and binding status; the document label alone is not the same as payment.
Illustrative software example, not a real company, customer result or benchmark. This example uses a software idea because it illustrates the sequence clearly. The evidence rule is not software-specific. For a physical product or service, the delivery test changes, while the distinction between opinion, observed behaviour and commitment remains the same. A SaaS tool that reconciles supplier invoices against delivery notes for independent wholesalers. Step 1: Interviews find that the reconciliation pain is real for wholesalers with several depots, and barely registers for single-site ones. Decision: Narrow. The problem is sharp in one setting and vague in the other, so the second group leaves the test. Step 2: Public complaint threads describe the same mismatch problem, usually as an argument with an accounting package rather than a missing product. Decision: Continue. The problem is visible unprompted, though it says nothing yet about who would buy a separate tool. Step 3: The current workaround is a shared spreadsheet plus a monthly argument with the supplier. The incumbent accounting tool is kept for other reasons. Decision: Continue. Replacing the accounting package is off the table, so the offer has to sit alongside it rather than replace it. Step 4: The offer is put to the narrowed buyer. Some book a call; reaching them at all depends on one trade community. Decision: Run another test. Reachability rests on a single channel, which is a different risk from the problem being real. Step 5: Two wholesalers agree to be design partners, give access to real invoice data and name what success would look like. Decision: Continue. Buyers are spending their own time and exposing their process, which is intent rather than encouragement. Step 6: Asked for a paid pilot, one commits with the finance lead involved. The other prefers to wait for the finished product. Decision: Continue. One buyer with budget acted at a price. The split is the next thing to test, not a reason to assume the rest will follow. Had nobody committed anything at step 5 or 6 while the problem, the buyer and the reach all held, the decision would have been to stop rather than to build and hope.
Test the assumptions before the software. Interview people who should have the problem about the last time it happened, study the workaround they use today, put a described offer in front of the buyer you named, deliver the outcome by hand where you can, and ask for a commitment that costs them something. None of these needs code, and each can change your decision before any is written.
Tests in which a buyer gives something up. A booked call, access to their data, a design-partner role with a date, a paid pilot, a deposit or a signed order are stronger than opinion, because each costs the buyer time, exposure or money. Interviews and public complaints show that the problem is real; they do not show that anyone will buy your version of the solution.
There is no correct duration. Validation has done its job for now when the evidence you hold would change your decision to build, narrow, test again or stop, and it resumes when the next cheapest test could change that decision again. Some questions, such as retention and lifetime value, cannot be settled before real customers use a working product, however long you test.
That the promise is understood and interesting enough to leave an address for. It does not show that anyone will pay, answer you later or use the product, and the size of the list is not proof of demand. Ask some of the people on it for something that costs them, such as a scoped call, access or a deposit, and read what they do.
A design partner is a buyer who spends their own time and exposes their real process to help shape the product. That shows the problem is a priority for them, not that the wider market shares their needs or that they will buy what they helped design. Look among the people who described the problem most sharply in interviews or public threads, and ask for a defined role: what success means, what access they will give, and a date to start.
When you can reach the right buyer, they understand the offer, and nobody will commit anything that costs them; or when nobody can describe the problem happening and nobody acts on it today. Stopping on that evidence is a result, not a failure. If the evidence is thin only because you could not reach the right people, change the channel and test again before you stop.
The free Stage 1 check is one way to run public complaint and workaround research. It analyses public market evidence for the problem you describe and grades what it finds. It can help with problem and current-workaround evidence for software, physical products and services. It does not test product feasibility, safety, certification, manufacture, inventory, fulfilment, service capacity, licensing, buyer commitment, retention or unit economics. Problem interviews, design partners, pilots, pre-sales and other commitment tests are founder-run activities outside the free Stage 1 check. A structured check can make assumptions explicit, apply repeatable evidence rules and record counter-evidence. It cannot manufacture primary evidence or replace format-specific feasibility work that has not been done. True Validation tests public market evidence only: whether the problem is real, visible and urgent. It does not prove buyer budget, willingness to pay, offer fit, acquisition economics or full commercial viability. Usually under 90 seconds. The paid stages continue the same questions with evidence a pre-build test cannot reach: Stage 2: Buyer Precision, Stage 3: Buyer + Offer, Stage 4: Revenue Funnel, Stage 5: Market + Funnel, Stage 6: Commercial Decision. GTM Right Canvas is a one-time £349 purchase for one idea and 90 days. It includes paid work across Stages 2 to 6: Buyer Precision, Buyer + Offer, Revenue Funnel, Market + Funnel, Commercial Decision. It delivers Paid Canvas work across Stages 2 to 6 and Commercial Readiness Pack. It is for the commercial questions your own tests leave open; it does not replace those tests, and buying it does not change what they showed. Related: commercial validation, traction diagnosis, the research. Run the free Stage 1 check.