The fastest way to test if people want your product is not to build it. It is to get a real person to take a real action before a single line of code is written.
That sounds obvious. It rarely happens in practice. Most founders either skip validation entirely and build first, or they validate in ways that feel rigorous but produce unreliable signal. Conversations with supportive friends. Surveys sent to their network. Interest forms with no friction.
None of that tells you what you actually need to know. The only reliable question in early validation is not "do people like this?" It is "will people act?" And the fastest path to that answer is not a better survey. It is a better experiment.
What you are actually testing for
Before picking a method, be clear on what signal you are looking for. Different experiments answer different questions, and running the wrong one wastes the time you were trying to save.
Is the problem real and painful? You need conversations, not clicks. Surveys and landing pages cannot answer this. Real people talking about their actual experience can.
Would people pay to solve it? You need an action with real stakes, not stated intention. A waitlist with no friction is not a proxy for willingness to pay. A pre-order or a deposit is.
Is your solution the one they would choose? You need something to react to, a prototype, a mockup, or a description specific enough to be wrong. Vague concepts get polite reactions. Specific ones get honest ones.
Most early-stage validation needs to answer questions one and two before touching question three. The order matters.
The fastest methods that actually produce signal
Five problem interviews in five days
Talk to five people who match your target customer profile. Not about your idea. About their life and their current experience of the problem you think you are solving. How often does it come up? What have they tried? What did they pay? What does it cost them when it goes wrong?
The bar: three out of five describe the same problem unprompted, in specific terms, with a concrete recent example. If you are getting vague or hypothetical answers, the problem is less acute than you thought. If you are prompting people to the pain rather than them arriving there naturally, that is a signal too.
Where it fails: talking to people who already know you. They will be kind. Recruit strangers who have no reason to be polite and no interest in your success.
The landing page with a real ask
Build a one-page description of the problem you solve and what your solution does. Ask for something with real friction: a pre-order, a deposit, a commitment to a pilot, or at minimum a waitlist where people have to confirm via email. Then send it to strangers, not your network.
The bar: conversion rate matters more than volume. A 5% conversion from cold traffic is far more useful than a 30% conversion from your LinkedIn connections who are doing you a favour.
Where it fails: a frictionless email capture tells you almost nothing. Anyone will give you an email address if you ask nicely enough. The friction is the point. Remove it and you remove the signal.
The concierge test
Deliver the outcome your product would deliver, manually, for one real customer. Do not build the software. Do the work yourself. If your product is supposed to generate competitive analysis reports, write three of them by hand for a paying customer. If it is supposed to automate onboarding, run one customer through onboarding manually.
The bar: would the customer pay for this outcome again? Would they refer someone? If the answer is yes, you have validated that the outcome has value. The next question is whether you can deliver it at scale without doing it manually every time.
Where it fails: doing it for free. If a customer will not pay for the manual version of your product, they will not pay for the automated one either. Charge from the first delivery, even if the price is token.
The prototype reaction test
Build a clickable mockup or a simple working prototype, not of the whole product, but of the one workflow that represents the core value. Put it in front of five target customers and watch them use it without helping them. Where do they hesitate? Where do they get confused? What do they reach for that is not there?
The bar: watch behaviour, not feedback. What people say about a prototype is less reliable than what they do with it. If they cannot find the thing they need without prompting, the design assumption is wrong regardless of what they tell you afterwards.
Where it fails: testing the wrong part of the product. The feature that is easiest to prototype is not necessarily the one that carries the most assumption risk. Test the thing that, if wrong, makes the whole product fail.
The fake door test
Add a button or a menu item for a feature that does not exist yet. When someone clicks it, show them a message explaining that it is coming soon and ask if they want to be notified. Track the click rate. A high click rate from real users tells you there is genuine demand for that specific capability.
The bar: this only works if you already have an existing product with real users. It is a feature prioritisation tool, not a market validation tool. Do not use it to test whether a product should exist. Use it to test which parts of an existing product to build next.
Where it fails: using it with your own team or beta testers rather than real customers. Internal validation of a fake door produces the same false signal as any other internal testing.
Stated intention is not evidence. "I would definitely use that" and "that sounds really interesting" are not validation. The gap between what people say they would do and what they actually do when asked to commit time, money, or effort is consistently larger than founders expect. Design every experiment to produce behavioural evidence, not attitudinal feedback.
How to pick the right method
The right method depends on what question you are trying to answer and what stage you are at.
If you have not spoken to a single potential customer yet, start with problem interviews. No other method replaces the signal you get from five honest conversations with strangers who have the problem you think you are solving.
If you have done the interviews and the problem is clearly real, move to a landing page or a concierge test. The landing page tells you whether people will act. The concierge test tells you whether the outcome is valuable enough to pay for.
If you have validated the problem and the demand but you are not sure about your specific solution, build a prototype and watch people use it. Do not ask them what they think. Watch what they do.
What to do with what you find out
Validation is not a pass or fail test. It is information. Sometimes the information tells you the idea is worth pursuing as described. Sometimes it tells you the problem is real but your proposed solution is wrong. Sometimes it tells you the market is too small, the customer is too hard to reach, or the problem is not painful enough to sustain a product.
All of those are useful answers. The only bad outcome is not finding out until after you have built something expensive.
- Run problem interviews before anything else. Five conversations with strangers in one week. Listen for frequency, cost, and the emotional weight of the problem.
- Make every experiment ask for something real. Friction is not an obstacle to good validation. It is the mechanism that produces honest signal.
- Test with strangers, not supporters. Your network will tell you what you want to hear. The market will not.
- Watch behaviour, not opinions. What people do with a prototype or a landing page tells you more than what they say about it.
- Move fast but move in order. Problem first. Willingness to pay second. Solution fit third. The order is not arbitrary.
Product Clarity's discovery and assumption mapping workflows are built to sit alongside this process. Once you have the signal from your experiments, the platform helps you frame what you learned, surface what you still need to test, and structure the problem definition that everything downstream depends on.
Structure your validation before you build.
Assumption mapping, discovery briefs, and market sizing, built to help you find out whether your idea is worth pursuing before you spend a year finding out the hard way.
No credit card required · Start for free · Built for product teams