How to Test Demand for a Software Product

There is no single best way to test demand for a software product — the right method depends heavily on what kind of product you’re building and what you’re actually trying to learn. A fake-door test that works well for validating a new feature inside an existing app is close to useless for a brand-new AI product nobody has context for.

The most common mistake founders make isn’t skipping validation altogether — it’s picking a method that doesn’t match their situation, running it, and either misreading a weak result as strong or discarding a genuinely useful method too early.

Matching the Method to the Situation

Below is a decision table mapping common product situations to the validation method best suited to them, followed by a closer look at each.

Situation	Best Method	Why
Testing a new feature inside an existing product	Fake-door test	Isolates interest in one specific feature without building it
Service-based product where a human could deliver the outcome	Concierge MVP	Tests willingness to pay for the outcome before any software exists
Testing price sensitivity or willingness to commit	Smoke test	Measures reaction to a real price, not just general interest
AI or automation-heavy product	Wizard-of-Oz MVP	Tests the perceived experience while a human operates it behind the scenes
Brand-new product with no existing audience	Landing page + targeted outreach	Builds an initial audience while measuring basic interest
B2B software sold to businesses	Pre-sales conversations + LOIs	Business buyers respond to concrete commitments, not casual surveys

Fake-Door Test

Add a button, menu item, or link for a feature that doesn’t exist yet — inside a product you already have users for — and track how many people click it. When they click, show a short message explaining it’s coming soon and ask if they’d like to be notified.

This method only works when you already have some baseline traffic or user base to test against, which is why it fits best for validating a new feature or product line inside something that already exists, rather than a brand-new standalone idea.

Concierge MVP

Instead of building software, deliver the outcome by hand. If your idea is a service that matches freelance designers with small businesses, manually search for and introduce a designer to a handful of business owners, and see if they use the match and pay for it.

This is the right choice when the product’s value lives in the outcome, not the interface — matching, sourcing, coordinating, or analyzing something for the user. It directly tests whether people will pay for that outcome before any automation exists.

Smoke Test

A landing page with a real price and a call-to-action button (“Start free trial,” “Buy now”) that leads to a “coming soon” message rather than an actual purchase flow. This method isolates one specific question: will people take a purchase-intent action at this price?

Use it when you already have reasonable confidence in the product idea itself and specifically want to validate pricing or a strong commitment signal, not general interest.

Wizard-of-Oz MVP

The user-facing experience looks fully automated — a chatbot, a recommendation engine, an “AI-powered” report generator — but a person is doing the work manually behind the scenes. Unlike a concierge MVP, the user believes they’re interacting with software.

This is the best fit for AI or automation products specifically, because the thing you’re testing isn’t just “will people pay for this outcome” but “does the automated experience itself feel valuable and trustworthy” — which a plain human-delivered concierge service can’t test.

Landing Page With Outreach

For a genuinely new product category with no existing audience to tap, a simple landing page paired with targeted outreach (relevant communities, cold outreach, small ad spend) is often the realistic starting point, mainly to build an initial list while gauging basic interest levels.

Pre-Sales and Letters of Intent

For B2B software specifically, none of the consumer-style tests above capture how businesses actually buy. Structured pre-sales conversations that end in a letter of intent or a paid pilot commitment are far more predictive for this audience than a survey or landing page alone — a full walkthrough of that sequence is covered in how to test a SaaS idea before coding.

Common Mistake: One Method for Every Product

It’s tempting to reuse whichever method worked for a previous product, but each of these methods tests a different question. A fake-door test tells you almost nothing about whether people will pay a real price. A smoke test tells you almost nothing about whether an AI-driven experience will feel trustworthy. Choosing deliberately, based on what you actually need to learn, matters more than running more tests.

Once you’ve chosen a method and are looking at your results, how to test demand before building an app covers how to read those results correctly — separating real signal from vanity metrics regardless of which method produced them. If you’re preparing to bring evidence to investors or co-founders rather than just deciding for yourself, how to prove demand for a startup idea covers what counts as credible evidence to a third party. For AI-specific products, the same method-matching logic applies closely in validating an AI contract analysis product.

Y Combinator’s Startup Library has extensive founder write-ups on running fake-door and concierge-style tests across a wide range of product types, if you want more worked examples before choosing.

Choose Once, Test Deliberately

There’s no universal validation method — there’s a method that fits your product’s situation. Picking the wrong one and reading a weak result as confirmation is more damaging than not testing at all, because it creates false confidence heading into development.

Frequently Asked Questions

What is a fake-door test and when should I use it?

A fake-door test adds a button or menu item for a feature that doesn't exist yet, and measures how many people click it. It's best used to test demand for a specific new feature inside an existing product, since it isolates interest in that one feature from the rest of the product.

What is a concierge MVP?

A concierge MVP delivers the product's outcome manually, by a real person, instead of through software. It's the best method for service-based products where the value is in the outcome (a completed task, a matched provider) rather than the interface, because it tests willingness to pay before any automation is built.

What is a Wizard-of-Oz MVP and how is it different from a concierge MVP?

A Wizard-of-Oz MVP looks fully automated to the user but is actually operated manually behind the scenes — for example, a chatbot interface where a human writes the replies. It differs from a concierge MVP in that the user believes they're interacting with software, which makes it the right choice for testing demand for AI or automation-heavy products where the perceived experience matters.

How do I test demand for pricing specifically, not just the product idea?

A smoke test is the most direct method — show a real price alongside a 'Buy now' or 'Start free trial' call to action, and measure how many people proceed before hitting a message that the product isn't live yet. This isolates price sensitivity from general interest in the product.

Can I combine more than one validation method for the same product?

Yes, and it's often the right approach. A common sequence is interviews to confirm the problem, a fake-door or landing page test to gauge interest, and then a concierge or Wizard-of-Oz test to confirm people will actually use and pay for the delivered outcome.