How to Test Demand for a Startup Idea Before Building an MVP

Curiosity is cheap. When you describe an idea, a polite person will find something interesting in it, because they are responding to you rather than to the product. Demand is different. Demand shows up when someone spends a scarce resource: money, calendar time, political capital inside their company, or the effort of changing how they already work.

This is why "people loved it" is close to meaningless as evidence. Loved it while you were talking is not the same as opening a laptop the next morning to look for it. The useful question is whether anyone is already spending something to solve the problem badly.

Y Combinator's essential startup advice keeps returning to one instruction: talk to users and watch what they actually do. Observation beats self-report because people are unreliable narrators of their own future behavior.

Every idea rests on a stack of assumptions, and they are not equally dangerous. Testing the comfortable ones is how founders spend a month feeling productive and learning nothing. A demand test should attack the assumption that, if false, makes everything else irrelevant.

Write the stack out plainly. For a scheduling tool aimed at physiotherapy clinics: clinics lose revenue to no-shows, the owner feels it, they will change software to fix it, and they will pay monthly for that. The riskiest item is usually the one you have the least direct evidence for, not the one that sounds hardest.

Strategyzer's test card formalizes this into one sentence: we believe X, to verify that we will do Y, and we will know we are right if Z. The value is in Z. Fixing the threshold first removes your ability to reinterpret a weak result later.

Keep the assumption specific enough to be wrong. "Clinics want better software" cannot be disproved. "Clinic owners with two to five practitioners will book a 20 minute call about no-show revenue within a week of a cold email" can.

A demand test aimed at everyone produces a result you cannot act on. Narrow the audience until you can name where these people gather and how you would contact fifty of them this week. An unreachable audience makes even genuine demand commercially useless.

Narrow along the axes that change behavior rather than demographics: company size, the role that owns the budget, the tool they use today, and how often the problem occurs.

• Where does this person already look for solutions: search, a trade community, a peer group, a supplier, or a consultant.
• What do they use today, including spreadsheets, paper, or an internal process nobody documented.
• Who signs off on spending, and how often does that person get asked for money.
• How frequently does the pain occur: daily annoyance, monthly headache, or once-a-year panic.

Demand evidence gets stronger as the cost to the participant rises. A conversation costs almost nothing, so it proves almost nothing. A signed pilot costs real money and political risk, so it proves a great deal. The ladder below is a way of thinking about tests, not measured data from any market.

Run tests roughly in this order, because the cheap rungs tell you where to aim the expensive ones. Skipping to a paid test with the wrong audience burns the audience and teaches you nothing.

Search behavior

Search tells you whether people are already looking for a solution in words they chose themselves. Google Trends shows relative direction over time, useful for spotting a category that is fading or rising. Treat search as a weak positive and a strong negative: heavy interest does not prove anyone will pay, but a new behavior with no search footprint means you have to create demand rather than capture it.

Outreach response

Cold outreach measures whether the problem is worth twenty minutes of a stranger's time. Write to fifty specific people about the problem, not the product, and ask for a conversation. The metric is the reply and booking rate. If nobody answers a message about a problem you call urgent, the urgency is probably yours.

Landing-page action

A landing page tests whether a clear description of the outcome makes someone volunteer contact details. Describe the result in the buyer's language, keep one action, and drive a little targeted traffic. Signups are the weakest kind of commitment, so use them to compare messages rather than to prove a business exists.

Manual delivery

Deliver the outcome by hand for three to five people, with no product at all. It is slow on purpose. You learn what the job involves and which parts of your imagined product nobody needs. Strategyzer's experiment library catalogs many variations, and this consistently produces more insight per week than an early MVP.

Paid commitment

The top rung is someone paying, or committing to pay, before the product exists. A Stripe payment link is enough infrastructure to test this, and you can refund immediately. Be explicit about what the buyer gets and when. Taking money you cannot honor is a broken promise with a receipt.

The single upgrade that improves most founder interviews is asking to see the thing. Ask the person to walk you through the last time the problem happened, with the actual spreadsheet, inbox, or tool open. YC's note on user observation makes the case well: watching someone work reveals the workarounds they never think to mention.

Workarounds are the most reliable demand signal available before money changes hands. A messy manual process that someone maintains anyway is proof that the pain is worth effort today. No workaround at all usually means the problem is tolerated, and tolerated problems are extremely hard to sell against.

After two or three weeks of tests you will have a pile of mixed results. Do not average them into a feeling. Lay them out and score each piece of evidence on two things: what the participant actually risked, and whether the result matched the threshold you set in advance.

1. 01Separate said from did

   Put every piece of evidence in one of two columns. If the did column is empty, you have not tested demand yet, however many conversations you have had.

2. 02Compare against your written threshold

   You predicted a number before running each test. Was it met, missed, or missed narrowly for a reason you can name and retest.

3. 03Ask what would have to be true

   For every weak result, write the condition under which it would flip. If that condition is something you cannot influence, that is a finding.

4. 04Pick one next step, not five

   Continue with a sharper audience, change the problem you are solving, or stop. Running a sixth test to avoid making the call is a decision too, just an expensive one.

A useful outcome at this stage is rarely a clean yes. It is more often "yes for this narrower group, and only if acquisition works." That is a real result. It tells you what the next test is and what the business would have to look like.

If you want the wider frame around this, our guide on how to evaluate a startup idea covers the commercial signals beyond demand, and how to test an idea before building goes deeper on running tests on a small budget.