Pre-launch demand validation: Pick the test that answers the right question

Open any pre-launch demand validation guide and the first thing it does is list every method — landing pages, interviews, smoke tests, fake-door tests, concierge tests, competitor research — as if you need all of them. You don't. Pre-launch demand validation works better as a decision tree than a checklist: pick the test that answers the question you actually have, because the wrong test wastes time and gives you a signal you can't use.

The tree has two inputs: what decision do you need to make, and how fast do you need the answer?

Pick the pre-launch demand question before you pick the test

Most validation efforts stall because the founder is trying to answer three different questions with one method.

The three questions people keep mixing up

Problem validation: does this pain exist, and does it matter enough to act on? Solution validation: will my specific approach to the problem work? Willingness-to-pay validation: will someone give me money for it?

These are different questions. A customer interview that confirms the pain is real tells you nothing about whether your solution is the right one. A landing page that converts at 8% tells you the message is attractive, not that anyone will pay. A smoke test that generates 200 signups tells you the promise is interesting, not that the product satisfies it. Mixing them creates fake certainty: you feel validated because something worked, but you don't know which question you actually answered.

The decision tree by persona, budget, and speed

Before I built the first paid feature on a previous project, I ran customer interviews for two weeks and came away convinced the pain was real. It was. But I'd answered the wrong question. I needed willingness-to-pay data, not more problem confirmation. That cost me a month.

Here's the mapping that would have saved it:

• Indie founder, low budget, need signal this week → smoke test or fake-door test first. Fastest path to intent data. Interviews if the pain is still unclear.
• PM with an existing user base → fake-door test inside the product, then interviews with the users who clicked.
• Vibe coder with a working prototype → concierge test. Do the thing manually for five people before automating it.
• Anyone trying to prove willingness to pay → preorder, deposit, or paid pilot. Nothing else substitutes.

PostHog's founders described their own early validation as building and validating with 10–15 customers in a week — fast, high-contact, not a survey.

Use the cheapest demand validation methods that answer your question

The right demand validation method is the cheapest one that produces an actionable signal for the specific decision you're making.

Landing pages when you need click-level interest

A landing page tells you whether your message is compelling enough to earn a click and an email address. That's it. It's good for testing positioning, headline framing, and whether the described problem resonates with the audience you're sending traffic to.

It falls apart the moment you treat signup rate as willingness-to-pay evidence. Someone who enters their email to "get early access" has expressed curiosity, not commitment. If your decision is "should I build this," a landing page is a weak signal. If your decision is "which of these two framings lands better," it's the right tool.

Interviews when you still need the pain to be real

Customer interviews validate the problem, not the product. The trap is mistaking a polite, engaged conversation for demand. People are generous in interviews. They'll describe pain vividly, nod at your solution, and say "I'd definitely use that." Then they don't buy.

Run interviews when you genuinely don't know if the problem is real, frequent, and painful enough to motivate action. Once you know the problem exists, stop interviewing and start testing willingness to act.

Competitor research when you need a market map, not proof

Competitor research tells you the market exists and helps you sharpen your segmentation and positioning. It cannot tell you whether buyers will choose your version. A crowded market with strong competitors means there's demand for the category. It says nothing about your differentiation or price point. Use it to calibrate positioning before you run a test, not as a substitute for one.

Run smoke tests, fake-door tests, and concierge tests without building the product

These three methods are the core of no-code, no-product validation. Each one answers a different question.

The smoke test that only proves attention

A smoke test is a landing page or ad campaign that presents the product as if it exists and measures whether people click, sign up, or engage. The HBR piece on entering markets with little demand frames this well: take small steps to validate a new market before committing resources. A smoke test is that small step.

What it proves: the promise is interesting enough to generate attention. What it doesn't prove: the product satisfies anything, or that attention converts to payment.

Fake-door tests when the promise needs a product-shaped click

A fake-door test puts a real-looking button, feature, or workflow in front of users, and when they click, they hit a "coming soon" message or a waitlist. It's stronger than a landing page because the click happens in a product context, not a marketing one. A user who clicks "Export to CSV" inside a real-feeling interface is expressing workflow intent, not just curiosity about a headline.

The failure mode is simple: the click is still curiosity, not commitment. Someone who clicks a feature button and sees a waitlist page has told you they were interested enough to try. They haven't told you they'll pay, stay, or change their workflow for it.

Concierge validation when the thing is too early to automate

A concierge test means you do the thing manually for real users before building the automation. If your product is supposed to generate weekly competitive reports, send five people a manually compiled report and watch what happens. Do they read it? Do they forward it? Do they ask for more?

The risk: the manual service can hide the real product problem. If you're doing it by hand, you're also compensating for friction the product would have, like onboarding confusion, data gaps, or output quality issues. Watch for that gap.

Decide what counts as real demand before you collect the data

The threshold has to exist before the test runs. If you set it afterward, you'll move the goalposts.

Signups, replies, interviews, and preorders are not equal

Write the signal hierarchy down before you start:

• Preorder or deposit: strongest signal. Someone gave you money for something that doesn't exist.
• Paid pilot: strong. Someone is paying for the manual version of the thing.
• Signed LOI or committed pilot: strong, but non-binding. Treat it as one step below paid.
• Interview with specific, recurring pain + named budget: medium. Real pain plus evidence they have budget to solve it.
• Signup with email: weak. Curiosity, not commitment.
• Positive reply to a cold email: weak. Politeness, not demand.

Build a simple scoring rubric for weak and strong signals

Assign weight to money, repeated pain across multiple conversations, and a named use case with a clear workflow fit. Discount compliments, vague interest, "I'd definitely use that," and one-off curiosity clicks.

A practical rule: if you can't point to at least three signals in the strong tier — paid, committed, or interview-with-budget — you don't have demand. You have interest. HBR's framing on testing for learning vs. testing for compliance applies here: the point is to learn something falsifiable, not to confirm what you already believe.

Set the threshold in one sentence before you run the test: "If fewer than three people pre-pay or commit to a paid pilot in the next two weeks, we kill or pivot."

When the signals disagree, read the conflict instead of forcing a verdict

Mixed signals are data. Don't average them into a mush verdict.

Landing page yes, interviews no

High signup rate plus skeptical interviews usually means the message is attractive but the pain is weaker than the headline implies, or the segment clicking the ad isn't the segment you interviewed. Check whether the people signing up match the people you talked to. If they don't, you have a positioning problem, not a demand problem.

Interviews yes, money no

People can be entirely honest about their pain and still not buy. When interviews confirm real pain but no one will pay, diagnose the specific blocker: Is the pain urgent enough to act on now? Does the buyer have budget authority, or are they an influencer without a card? Is there a free workaround they're not ready to abandon? Each diagnosis points to a different fix — urgency, pricing model, or go-to-market motion.

Competitors everywhere, but no one is buying this version

A crowded market with a struggling product usually means the positioning is wrong, not the market. If competitors are selling and you're not, the question is differentiation and price point, not whether demand exists. Ask what the buyers who chose a competitor valued most, and whether your version actually delivers that.

Turn pre-launch demand validation into a launch, revise, or kill decision

The decision rule should be written before the test starts

Name three things before you run any test: the threshold, the expected signal, and the decision that follows each outcome. If you hit the threshold, you launch. If you miss it, you revise or kill. Write this down. Share it with at least one other person so you can't quietly reinterpret it later.

How to package the result for a stakeholder or teammate

A one-page readout has four parts: what you tested, what threshold you set, what happened, and what decision follows. No editorializing. No "but we think with a few tweaks..." The result either hit the threshold or it didn't.

Example: "We ran a fake-door test on the CSV export feature with 200 active users over 10 days. Threshold: 15% click rate. Result: 11% clicked. Decision: deprioritize — not enough pull to justify the build sprint."

That's a stakeholder-ready summary. It's also a document you can look back at in six months without cringing.

---

FAQ

Q: What is the fastest low-cost way to validate demand before writing the full product?

A smoke test or fake-door test — a landing page or product-shaped button that measures intent without building anything. Fast to run, low cost, and it gives you a click-level signal in days. The caveat: it proves attention, not willingness to pay. If you need payment evidence, a preorder or paid pilot is the only substitute, and it takes longer to set up.

Q: Which validation method should an indie founder, PM, or vibe coder use first?

Indie founder with no user base: smoke test to check message resonance, then a preorder or paid pilot to check willingness to pay. PM with existing users: fake-door test inside the product — you have the audience, use it. Vibe coder with a working prototype: concierge test. Do the thing manually for five real people before automating it. The tradeoff in each case is speed vs. signal strength. The concierge test is slower but produces the most actionable data.

Q: How many signups, interviews, or positive responses are enough to count as real demand?

There is no universal number. The threshold depends on the decision you're making and the market size you're targeting. A practical rule of thumb: three to five people who have paid, pre-paid, or committed to a paid pilot is a stronger signal than fifty email signups or twenty enthusiastic interviews. Set the number before you run the test, not after. If you're moving the threshold because you almost hit it, that's a sign you're rationalizing, not validating.

Q: How do I test willingness to pay before launch without building the product?

Four options, in order of signal strength: a paid preorder (money now for a product later), a paid pilot (money for the manual version of the thing), a refundable deposit on a waitlist slot, or a direct pricing conversation where you name a number and watch the reaction. Each one proves something different. A preorder proves someone will pay your price. A pricing conversation proves the number isn't a dealbreaker, but not that they'll follow through. Pick the option that matches how much certainty you need before committing.

Q: How do I separate genuine demand from polite interest or founder bias?

Three filters: money, repeated pain, and a named use case. If someone has paid or committed to pay, that's demand. If the same pain comes up unprompted across multiple conversations with people who don't know each other, that's a real signal. If someone can describe a specific workflow where they'd use the product, not just "yeah, I'd use that," that's worth weighting. Polite interest fails all three filters. Founder bias shows up when you remember the encouraging quotes and forget the skeptical ones. Share the full interview notes with someone who wasn't in the room.

Conclusion

Pick the test that answers the question you actually have. Not the one that feels most thorough. Not the one everyone recommends. The one that produces the signal your specific decision requires. Set the threshold before you run it — one sentence, written down, shared with someone. When the results come in, read them against the threshold you set, not the one you wish you'd set. Then make the call: launch, revise, or kill.

This week: choose one method, write the threshold in one sentence, and run it. The test that never starts validates nothing.