How to run a fake door test that gives real signal

A team ships a fake door test on Tuesday, wakes up to a nine percent click-through rate, and by Thursday has three engineers and a two-quarter slot to build the feature the door was pretending to be. Six weeks later the feature ships to a shrug. The click-through rate was real. The demand was not. Nobody asked the people who clicked what they thought they were about to get, and by then the roadmap had already moved.

This is a working guide on how to run a fake door test that returns something a team can actually build against: what the method is, when it is the right instrument, six steps that make the signal defensible, the failure modes that turn nine-percent CTRs into wasted quarters, and the pattern for capturing the qualitative reasoning behind every click without breaking the participant's trust. It sits inside the wider voice user research guide and pairs with the pieces on opportunity solution trees and continuous discovery interviews.

What a fake door test is

A fake door test is a lightweight product experiment that places a visible entry point (a button, menu item, banner, or nav entry) for a feature that does not yet exist, measures how many people click through, and shows the clicker an honest "not yet" message with an optional signup, waitlist, or short follow-up. The click is the quantitative signal for demand. The follow-up is where the qualitative reasoning lives. The method is also called a painted door test; Optimizely's glossary entry on the painted door test is the shortest canonical definition if you want the textbook version alongside this guide.

The instrument is exploratory, not confirmatory. A fake door test does not prove that the feature is worth building. It rules out the case where nobody wants it at all, and it produces a first-pass ranking of which of several candidate features attract the most intent-shaped clicks from the current traffic. The output is a click-through rate against a pre-committed threshold, plus a bundle of participant verbatim explaining what the clickers thought they were about to get.

The test lives inside a larger discipline. Teresa Torres frames it as one shape of assumption test in her treatment of continuous discovery: a small, fast experiment sized to invalidate a specific belief a product idea rests on, before the team commits engineering time to the idea itself. The belief a fake door test tests is the demand assumption, not the value or usability assumptions. That distinction shows up again in step one.

When to run a fake door test

Three cases where a fake door test is the right instrument.

• You have live traffic and a demand hypothesis. The team believes a segment of the current user base would pay attention to a specific new feature, but the belief is grounded in stakeholder confidence rather than participant evidence. A fake door test is the cheapest way to check.
• You have several candidate features and one engineering slot. Ranking three or four candidate doors against each other on the same surface produces a demand ordering the team could not get from an internal debate. Combined with the qualitative capture in step four, the ordering is defensible.
• You have a strong opinion about who wants the feature and want to test the segment, not the feature. Placing the door only on the pricing page filters clickers by intent; placing it in the settings menu filters by tenure. The door tells you which segment reaches for it.

Two cases where a fake door test is the wrong instrument.

• The feature is core to a workflow the user is already mid-task in. Interrupting a checkout, a compose, or a cancellation flow with a fake door burns trust and contaminates the analytics of the actual flow. Use a concept test with recruited participants instead.
• You need to validate willingness to pay, not willingness to click. A click is a low-cost signal. A fake door with a price tag on the other side of it is a stronger test, but the honest version of that test is a price validation or a product-market fit survey, not a plain door.

How to run a fake door test, step by step

Six steps. The first is the one most teams skip. The fourth is the one that separates a fake door test that lies to you from one you can act on.

01 · Pick the assumption the test owes evidence to

Before designing the door, write down the specific belief the test is going to falsify. "We think users want feature X" is not a testable assumption. "We think at least four percent of users on the pricing page will click a specific Salesforce sync entry point when it appears in the integrations section within seven days" is a testable assumption. The four properties that make it testable: it names a segment (pricing-page visitors), a signal threshold (four percent), a specific feature framing (Salesforce sync, not vague "integrations"), and a time window (seven days).

Naming the assumption up front does three things. It filters the door design (specific enough to attract intent, not curiosity), it filters the placement (where the segment lives), and it filters the interpretation of the result (a two-percent CTR is a fail against this assumption, a "moderate signal" against a vague one). The parent frame for this practice is the opportunity solution tree, where every solution below the branch has an assumption test attached to it; the full treatment is in how to build an opportunity solution tree.

02 · Design the door for specificity, not curiosity

The single biggest determinant of whether a fake door test tells you the truth is how specific the door itself is. A button labeled "New features" attracts curiosity clicks from any user with idle attention. A button labeled "Export to Salesforce, sync your pipeline daily" attracts clicks from users who have that exact problem and no other. The first door gives you a number you cannot interpret. The second gives you a number that maps to a real segment.

Three properties a specific door has:

• It names the outcome, not the mechanism. "Sync your pipeline daily" is an outcome. "Salesforce API v2 integration" is a mechanism. The user is here to solve a problem, not to consume a spec.
• It anchors to a segment word. "For finance leads", "for solo founders", "for teams over ten". The clicker who identifies with the anchor is the segment; the clicker who doesn't is filtering themselves out at the door.
• It lives at the same visual weight as the surrounding surface. A door dressed up as a promotion (highlight color, "NEW" badge, animated ping) collects clicks from novelty. A door dressed at the same weight as the shipped features collects clicks from intent. The novelty version inflates the CTR by roughly the noise floor of the surface.

03 · Place the door where the real user encounters it

Placement is the second-biggest driver of signal quality. A door in the marketing footer collects clicks from a segment that reads marketing footers. A door in the product's core surface collects clicks from users mid-workflow. Neither is right or wrong; the two produce different numbers because they filter for different segments.

The four placements a product team typically has available:

• In-product surface (inside the feature area the door proposes to extend). Highest signal from paying users; smallest sample per week; hardest to interpret if the surrounding surface is already noisy.
• Settings or integrations page. Common for integration doors; the users who reach it have already decided the product is worth configuring.
• Marketing site (pricing, comparison, docs). Highest volume; broadest segment; includes non-users, which is either a feature or a bug depending on the assumption.
• Contextual prompt inside a specific flow (activation, upgrade, cancellation). Highest specificity to a moment; smallest cohort; requires clean instrumentation so the flow's own metrics stay legible.

Place the door on exactly one surface for the first run. Multi-surface tests conflate segment mix with feature interest, and the first thing the team then argues about is whose surface deserves the credit.

04 · Capture the "why" behind every click

This is the step that separates a fake door test that returns a real signal from one that returns a plausible number. A click on its own is ambiguous: the user might have wanted the feature; they might have wanted a different thing they thought the label described; they might have clicked out of curiosity and would never have paid. The number alone cannot distinguish between the three, and the team's interpretation of the number will drift toward whichever explanation supports the roadmap they already wanted.

The instrument that closes the gap is a short, honest capture on the other side of the door. When the clicker arrives at the "not yet" screen, ask one open-ended question about what they expected to happen next, and let them answer in voice, text, choice, or rating on their own device. Voice is the mode that returns the richest reasoning; text is what people default to on a train; a choice or rating is what they can complete in five seconds when the context does not permit more. Forcing one mode discards the other three. The qualitative case sits in voice vs text surveys.

Set the follow-up probing depth to match the surface. On a churn or cancellation door, keep it shallow: a single clarifier and move on, because dropoff dominates. On a pricing-page door, run medium depth: a small probing chain if the answer is vague. On a targeted in-product door aimed at a small segment, run expert depth: the AI keeps probing until it has the same context a senior researcher would dig out, contradiction, scope, who and when and how, prior alternatives tried, capped only when the model is satisfied or the participant disengages. The participant retains the right to skip on every probe. The full pattern is in AI follow-up questions in user research.

"I thought this was going to export the pipeline as a CSV I could email to finance. If it also pushes into Salesforce that is fine, but the reason I clicked was the spreadsheet."

Two clicks that look identical in analytics carry completely different meanings, and the team only finds out which one it was if the participant is asked. That is the entire reason for the follow-up.

05 · Set the click-through threshold before you run

Committing to the threshold before the number lands is what turns a fake door test into a decision instrument instead of a Rorschach test. The temptation to move the goalposts after the CTR arrives is universal; the discipline that resists it is naming the number in the hypothesis document before the door goes live.

Two calibrations. The thresholds above assume a specific door (step two) placed at the surface's normal visual weight (step three) with at least a thousand unique impressions. On a wide vague door, an eight-percent CTR is not a strong signal; it is noise. On a buried settings-page door, a two-percent CTR is not weak; it is meaningful, because the segment reaching it is small and pre-qualified. The number only means what the setup lets it mean.

06 · Close the loop with the participant

The ethics of a fake door test collapse or hold up in the final second. If the clicker arrives at a screen that reads "sorry, this doesn't exist yet" and no further, the test has spent user trust and returned nothing to them for it. If the clicker arrives at a screen that explains what the team is trying to learn, invites them onto a waitlist for when the feature ships, and offers a way to describe what they wanted, the test has taken a small deposit of trust and returned a real interaction for it. The difference is a paragraph of copy and one honest question.

The pattern that consistently protects trust:

• Name the state honestly. "This feature isn't shipped yet. We're checking whether it's worth building."
• Invite the participant into the loop. "Tell us what you were expecting" plus a signup option for when it does ship.
• Follow up when the decision is made. If the team decides to build, email the waitlist first. If the team decides not to build, email the waitlist anyway to say so. Silence is the version that burns the trust the click asked for.

A door that closes the loop this way can be run repeatedly on the same segment. A door that ghosts the clicker cannot be run again on that segment without discounting the CTR for accumulated distrust.

The failure modes that make fake door tests lie to you

Five patterns that eat fake door test programs. Naming them makes them easier to catch before the roadmap moves.

• The curiosity door. The label is vague enough that any user with idle attention will click. The CTR reads high; the follow-ups read empty. The recovery is to rewrite the label with an outcome and a segment word.
• The moved goalpost. The threshold was not set before the run, and the interpretation drifts to fit the number. The recovery is a written hypothesis committed before the door goes live and referenced when the number lands.
• The uncontrolled surface. The door lives on a page that already has three other things competing for attention, and the CTR is a residual of the surface's mix rather than a signal about the door. The recovery is a single door per surface per week, and a control period before the test.
• The click without the reason. No qualitative capture on the other side of the door. The team gets a number and no way to interpret it, so the loudest room wins the interpretation. The recovery is step four.
• The trust-burning close. The clicker arrives at an apology page and nothing else. The next time the team runs a door on that segment, the CTR is lower by the amount of distrust the last one deposited. The recovery is step six.

How async voice studies compound a fake door test

The instrument in step four (the honest capture on the other side of the door) is where a fake door test stops being a click experiment and starts being a real evidence instrument for a product trio. The pattern that consistently returns something useful:

The door links to a Talkful study on the "not yet" screen. The study asks one open-ended question, "what were you expecting to happen when you clicked", and lets the participant answer in voice, text, choice, or rating. The AI interviewer runs a configurable probing chain (shallow, medium, or expert) on each answer, calibrated to the surface. The synthesis engine streams themes back as the responses land, tagged to the door, ready for the team to ship from or for the agents you build with to act on. The full treatment of adaptive follow-ups covers the probing depth decision in detail.

Three things follow from wiring the door this way. The first is that the study link is a standing instrument, not a one-time survey. The same door can run for weeks; responses land continuously; the synthesis stays live. If the team ships the feature and wants to keep listening, the door becomes a real feedback surface without a schema change. The second is that the same pattern works for internal review. When a designer wants to test a fake door with the engineering, support, and sales team before it goes to customers, share the link inside the company: get a synthesized cross-functional view of what people expected to happen, and skip the meeting. The third is that the deliverable is structured: each response stays linked to the participant, each quote to its click, each theme to the responses that produced it. That structure is what makes the output legible to the next researcher, the next decision, and the agents the product team is building on top of the same data. The framing of the broader pattern sits in AI-powered async user research.

For teams already running fake doors, this does not replace the click. It changes what the click means. The nine-percent CTR that would otherwise have kicked off a two-quarter build becomes a nine-percent CTR with fifty transcripts explaining what the clickers actually wanted, and the team can tell inside a week whether the demand was for the feature they were about to build or for the adjacent one they had not thought of yet. Talkful has a free plan that will run a first study; the voice user research guide covers what to do once the responses start landing.

FAQ

What is a fake door test?

A fake door test is a lean product experiment that places a visible entry point (a button, menu, banner, or nav item) for a feature that has not been built, measures the click-through rate on the entry point against a pre-committed threshold, and shows the clicker an honest "not yet" message with an optional way to describe what they were expecting. It is used to test the demand assumption behind a feature idea before the team commits engineering time to it. The method is also called a painted door test.

How is a fake door test different from a landing page test?

A landing page test lives outside the product on a standalone URL and measures acquisition-shaped signals (visits, signups, waitlist joins) from paid or organic traffic. A fake door test lives inside a product surface the user already engages with and measures whether current users click a specific entry point relative to their existing behavior on that surface. Landing pages test whether people can be attracted; fake doors test whether people who are already there care.

Is fake door testing ethical?

Yes, when the door closes honestly. The ethical version names the state on the other side of the click ("this feature isn't shipped yet, we're checking whether it's worth building"), invites the participant into a waitlist and a short follow-up, and emails the waitlist with the eventual decision. The unethical version ships an apology page and nothing else, or worse, silently redirects the clicker to a working feature they did not choose. Trust is the resource the test spends; step six of the guide above is how the test earns some of it back.

What is a good click-through rate for a fake door test?

Against a specific door placed at the surface's normal visual weight with at least a thousand unique impressions: above five percent is a strong demand signal, two to five percent is moderate, below two percent is weak. Those thresholds only hold if the door is specific enough to filter for intent rather than curiosity and honest enough to close the loop with the clicker. The interpretation always has to reference the surface, the segment, and the door's label; a five-percent CTR on a vague nav item and a five-percent CTR on a targeted integration entry point mean completely different things.

How do you capture qualitative reasoning from a fake door test?

Link the "not yet" screen to a short async study that asks one open-ended question ("what were you expecting to happen when you clicked?") and lets the participant answer in voice, text, choice, or rating. Set the AI probing depth per surface: shallow for churn or cancellation contexts where dropoff dominates, medium for pricing-page or activation contexts, expert for targeted in-product doors where the AI keeps probing until it has senior-researcher-level context on the clicker's reasoning. The transcripts, sentiment, and themes are what tell the team whether the CTR meant the thing they hoped it meant.

How many clicks do you need before a fake door test is meaningful?

The floor is roughly one thousand unique impressions of the door, not one thousand clicks. Below that, the CTR is noisy enough that a five-percent number and a two-percent number are indistinguishable. In parallel, aim for at least twenty to thirty follow-up responses on the other side of the door before drawing qualitative conclusions; thematic saturation in a homogeneous segment lands somewhere in that range, and it is what turns a number into an interpretation.

---

The version of the method that survives contact with a real roadmap is the one where the click is the beginning of the test, not the end. The number tells the team whether to keep listening. The follow-up tells them what they were actually being told. Both belong in a real fake door test. Neither is a substitute for naming the assumption the test owes evidence to before the door goes live.