What a fake door test means
The door is the visible invitation: a feature entry, a landing page, or another specific promise. The test is useful only when the intended people can reasonably encounter it, the promised action is clear, and the next screen tells them the real current status.
An entry inside an existing product
Show a proposed feature to people already using the surrounding workflow. The entry can reveal whether that task matters in this context, but it should not block their current work or imply the feature is ready.
A concept landing page before the product exists
Explain one proposed outcome for one audience and invite a single next step. A concept page is still an acquisition test: it needs a relevant traffic source before its response can say much about the audience.
Publishing a page does not create relevant exposure. If the intended audience did not see the offer through a plausible channel, record an acquisition gap rather than calling the idea unwanted.
Write the experiment brief before publishing
Copy these prompts into a document and answer them before you look at results. They make it possible to distinguish a weak promise, the wrong audience, too little relevant traffic, and a result that actually changes a decision.
| Brief field | Write this before the test |
|---|---|
| Intended audience | Which role, situation, and existing workflow is this for? Name who should not be counted as part of this test. |
| Problem | What recent task, cost, delay, or risk are you testing? Avoid a broad market category or a feature list. |
| One promise | What specific outcome will the visitor understand? State one narrow promise, not several possible features. |
| Real current status | What exists today, what does not, and what will happen after the action? Write the disclosure in plain language. |
| One call to action | What one observable action asks for the smallest useful commitment: request access, describe the situation, or ask for a manual conversation? |
| Relevant exposure | What counts as an exposure from a person who plausibly has this problem? Record the page, placement, and audience context. |
| Traffic source | How will relevant people find this door: an existing product surface, a permissioned audience, search, a partner, or another named source? |
| Observation window | When will you review the evidence? Choose a date or a bounded number of relevant exposures, not an endless wait for a preferred answer. |
| Continue if | What combination of relevant exposure and meaningful response would justify the next, still-limited test? |
| Modify if | Which observation would make you change the audience, problem framing, promise, or traffic source before testing again? |
| Stop or pause if | What result would make this version no longer worth pursuing? Keep 'insufficient relevant exposure' separate from a negative result. |
Use a threshold suited to your audience and channel. A number without context can hide poor targeting, repeated visits, or a costly request; it is not a universal definition of success.
Make the post-click status obvious
The person who acts on the door should learn immediately what is and is not available. Put the disclosure beside the action or at the beginning of the next screen, in language a busy visitor can understand.
- State the promise, who it is intended for, and the current availability before asking for a response.
- Do not present an unbuilt feature as released, collect a fake payment, or use an automatic signup flow to disguise a manual follow-up.
Example post-click message
“You are responding to a concept test for independent recruiters who coordinate follow-ups across several client teams. This feature is not available today. If this problem is active for you, tell us what you use now and what makes it difficult; we will use the response to decide whether to run a smaller next test.”
EviDemand lets you edit and publish a validation page from your project, collect form submissions, and review consent-based page signals. You provide traffic and run the experiment; it does not recruit participants or report an experiment as completed before it runs. Research is separately scoped, with price and timing agreed before paid work begins.
Interpret the response in layers
Keep each signal distinct. This makes it harder to turn a shallow action into a broad product claim and easier to see what should be investigated next.
| Signal | What to record | What it cannot establish by itself |
|---|---|---|
| Relevant exposure | How many plausible target people saw the promise, from which source, in which context, and whether repeated views came from the same person. | A page view or broad impression does not mean the intended audience noticed, understood, or had the problem. |
| Click or tap | Which promise and placement were clicked after a relevant exposure, plus any obvious mismatch in role or situation. | A click can reflect curiosity, wording, or a mismatched audience. It does not prove intent to use, buy, or change behavior. |
| Clear stated intent | A person’s own description of the task, situation, timing, and what they want to do next, while retaining the original wording and context. | Stated interest is stronger than a click, yet it remains a claim until behavior, constraints, and alternatives are explored. |
| Specific reply | A concrete problem, current workaround, obstacle, decision, or authorized example that gives you something to test or clarify. | One detailed reply is one source. It should not be counted as several users or generalized to a wider segment. |
| Follow-through | What happened after the invitation: a booked conversation, an authorized material share, a later return, a change in approach, or another observed action. | Follow-through can support the relevance of a next test; it is not automatically a commitment to pay for a finished product. |
When there is too little relevant exposure, the honest conclusion is 'insufficient acquisition evidence.' Do not call the problem absent, the offer rejected, or the test a failure just because the page was quiet.
There is no general pass rate for a fake door test. Interpret the response against the audience, channel, promise, friction of the action, and decision rule you wrote before the test.
Illustrative, invented examples
Two results that require different next steps
These examples are fictional. They show why totals alone can mislead and do not describe EviDemand results or a benchmark for your experiment.
Fictional example: clicks from the wrong role
A concept page promises a weekly client follow-up view for independent recruiters. It gets many clicks from a broad productivity newsletter, but most replies are from people managing their own job search.
Observation
The wording earned attention, yet the stated role and workflow in the replies do not match the intended recruiter audience.
What it supports and challenges
The clicks do not support the specific recruiter problem. They may challenge the traffic source or reveal that the promise is too broad to screen for the intended situation.
Next step
Change the audience filter and use a source where independent recruiters plausibly encounter the test before drawing a product conclusion.
Fictional example: few clicks, useful detail
A small, permissioned group of operations leads sees a door for an exception-review queue. Few people act, but two describe the same approval delay, their current spreadsheet workaround, and why an existing tool falls short.
Observation
The test has limited exposure and cannot estimate prevalence, but the replies name a concrete situation, alternative, and consequence.
What it supports and challenges
This is a reason to investigate that narrow workflow, not a reason to claim broad demand or set a product roadmap from two sources.
Next step
Ask permission to examine the decision context, look for counterexamples, and design the next test around the specific approval delay.
Use the right evidence before and after the door
A fake door is one test in a wider decision process. These resources help you define the question, collect stronger context, and examine what happens after a response.
Validate a SaaS idea
Use an evidence checklist to define the decision and the uncertainty before designing the test.
Customer discovery questions
Collect recent behavior, alternatives, and decision criteria without turning a conversation into a pitch.
Analyze customer interviews
Compare several interviews without treating repeated comments or a vivid quote as a customer vote.
EviDemand Validation cycle
See how an Evidence review separates support, counterevidence, what remains unknown, and the Next test.
Before you start validation
Bring the promise you want to test, the intended role and situation, and the traffic source you have or the acquisition obstacle you cannot resolve. Share only material you have permission to share. A Validation cycle does not imply an automatic experiment, a traffic service, or a guarantee of demand.
Human Decision Review
Get a human review of one product decision
US$49, one time. Start with a free fit check; before payment, we confirm the exact scope and delivery date. Payment happens on verified external billing instructions and work starts only after a human confirms the actual receipt.