How to Test Demand Before Building the Product

Testing demand before building is not about proving your idea is good. It is about trying to kill it cheaply, and only building the ideas that survive.

Most founders run one test, get an ambiguous result, and build anyway. The trick is to run the tests in order of cost, and to be honest about what each one can actually tell you.

What a demand test can and cannot tell you

A demand test can tell you whether people will take an action: give an email, book a call, pre-pay. It cannot tell you whether they will still be using your product in six months.

So you aim for the strongest action you can get at the current stage, and you stop treating opinions as evidence. A promise is not a signal. An action is. This is the same line between a compliment and a commitment that runs through idea validation red flags.

Three tests, cheapest first

Test 1 — conversations. Cost: a few hours. Tells you whether the problem is real and urgent.
Test 2 — a landing page. Cost: a day and a small ad budget. Tells you whether your message resonates.
Test 3 — a price. Cost: whatever the pre-order or deposit is. Tells you whether they will pay.

Run them in that order. A landing page test before five conversations will only tell you that your copy is vague.

Test 1: the conversation

Talk to five people who have the problem. Ask about the last time it happened, what they did, and what it cost. You are listening for a cost mentioned without prompting and a workaround they already built.

If nobody will even take the call, that itself is data. It is hard to get people to spend thirty minutes on a problem they do not have.

Test 2: the landing page

Put up a single page that names the problem in the buyer’s words and the outcome you provide. One clear call to action. Then send people to it from where the buyers already are.

Watch the conversion between visitors and actions, not the raw number. Ten signups from twenty targeted visitors is a very different result from ten signups from two thousand strangers. Relevance beats reach at this stage.

Two rules: do not describe features, describe the outcome; and do not hide what it is. A page that tricks people into signing up teaches you nothing.

Test 3: the price

The strongest demand signal is money. Offer a pre-order, a founding-member price, or a deposit. Even a small amount separates real intent from interest.

You are not trying to fund the build. You are trying to see whether someone will part with money before the thing exists. If they will not pay a discounted early price, a free signup proves very little about later revenue. For how to read paying behaviour in public, see willingness to pay signals.

Reading the result

• Strong: people ask when it is ready, offer to pay, or introduce you to others with the same problem.
• Promising: steady signups from targeted traffic, and a few willing to pre-pay.
• Weak: polite interest, compliments with no action, traffic that bounces off the page.
• Dead: nobody takes the call, nobody clicks, nobody pays.

Weak is not always a no. It can mean the message is wrong while the problem is real. But you should be able to point to a specific reason, not a general hope.

FAQ

How long should this take?

Weeks, not months. Conversations in week one, the page in week two, the price test alongside. If it drags, you are usually avoiding a decision you already have the answer to.

Is a waitlist enough?

No. A waitlist tests the message, not the willingness to pay. Pair it with a price test before you build anything expensive.

What if I already have an audience?

You have an advantage, and a bias. Your existing audience may buy out of loyalty, which inflates the signal. Test with people who do not know you too.

What counts as good ad performance?

There is no universal number. The useful comparison is your own: does the targeted version of the page clearly beat the generic one? If a small budget cannot move the needle, more budget will not fix the message.

Where do I start if I have no idea who to test with?

Start from problems, not people. Run a research report for 2.99 EUR to get validated pain signals with sources, then reach out to the people behind them. If the problem is real, they will usually take the call. For the full validation ladder, see validate a SaaS idea.