Fake Door Testing

---

Origins

The fake door pattern emerged from direct-response marketing decades before software product teams adopted it. Direct mailers had long tested demand by sending offers for products that didn't yet exist, then building only the ones that produced enough orders. The technique migrated into web product work as "smoke testing" or "painted door testing," appearing in the lean startup tradition through Eric Ries and others¹, and widely practiced inside teams at Booking.com, Spotify, and Airbnb long before it had a tidy name.

The premise is straightforward. The most expensive way to find out nobody wants a feature is to build it. The cheapest way is to make it look as if it exists, watch what customers do when they encounter it, and let their behavior — not their survey answers — decide whether the team should invest.

What a Fake Door Is

A fake door is any element of the product that suggests a feature exists when it does not. The simplest form: a button or menu link labeled with the feature's name. The customer clicks; nothing yet exists behind the click; the click is logged.

Common formats:

• Buttons or links in the existing product that lead to a "coming soon" page or an email-capture form.
• Pricing pages or product comparison tables that list features the team is considering building.
• Landing pages for a feature or product, driven by paid ads to a defined audience.
• Empty navigation entries — "Reports," "Integrations," "Templates" — that measure whether anyone even goes looking.

The signal you collect is binary at the simplest level (clicked / didn't click) and quantitative at the next level (click rate compared to a baseline). What you do after the click matters too — an email-capture form turns a click into a softer commitment.

What a Fake Door Tells You

A fake door measures one thing well: whether the feature, presented as a promise, generates clicks. That signal is useful in proportion to how clearly the door represents the actual feature.

It can answer:

• Is there visible demand for this feature among our users?
• Which of these three competing features attracts the most interest?
• Is the demand large enough to justify building it?

It cannot answer:

• Will customers actually use the feature once it exists?
• Will they pay for it?
• How will building it affect retention, churn, or NPS?

The signal from a fake door is "interest," not "commitment." Interest is necessary but not sufficient. A feature that nobody clicks is almost certainly not worth building; a feature that gets clicked may or may not be.

How to Run a Good Test

1. Decide what would change your mind

Before launching the door, write down: "If the click rate is above X, we will build it. If it is below Y, we will not. In between, we will do more discovery." Skipping this step is how teams talk themselves into the answer they wanted regardless of what the data showed.

2. Define the audience clearly

A fake door shown to 100,000 users gives a different signal than one shown to 100. Decide who is in the test cohort, what their baseline behavior is, and how you'll know your test cohort actually saw the door.

3. Pick a meaningful baseline

"3% click rate" is meaningless in isolation. Compare against an existing element of similar prominence — if existing menu items get 1% clicks and the fake door gets 0.5%, demand is low; if 4%, demand is high.

4. Handle the click with care

What happens when the user clicks matters. Common options, in increasing order of integrity:

• A "coming soon" message with a feedback form.
• An email-capture form: "want this feature? leave your email and we'll let you know when it's ready."
• A short survey asking about the use case the user had in mind.
• A direct contact: "thanks for clicking — want to chat with a PM about what you were hoping for?"

5. Time-box and act

Decide in advance how long the test runs and what the team does at the end. Tests that run "until we have time to look" produce no decisions.

Ethics and Trust

Fake doors put a real cost on real users — the cost of clicking on something that turns out not to exist. Run carelessly, they erode trust. A few principles keep the cost low:

• Be honest after the click. "This feature isn't available yet, but we're considering building it" is fair. Pretending it exists and then failing silently is not.
• Don't fake critical paths. A fake door on a marketing page is fine. A fake door on the checkout flow erodes trust where you can least afford to.
• Limit exposure. Show the door to a small enough cohort to learn what you need, not to the entire user base.
• Follow up with people who said they wanted it. An email capture with no follow-up is a worse user experience than no test at all.

Common Pitfalls

• Treating clicks as commitments: a 5% click rate does not mean 5% will use the feature. Validate further before committing engineering effort.
• Novelty effect: a new menu item gets clicks because it's new, not because the feature it represents is valuable. Run the test long enough for the novelty to fade.
• Small N: 12 clicks out of 800 users feels significant but isn't. Calculate the sample size you need before launching.
• Door doesn't represent the feature: ambiguous labels produce clicks from users curious what they mean, not users who want what they describe. Label the door specifically.
• Hidden context: paid-traffic landing pages can be gamed by ad audience selection. Either control for it or interpret the result cautiously.
• Repeated testing on the same users: users who saw a previous fake door learn to ignore them. Vary the audience or the format.

Coaching Tips

Write the Decision Rule First

Before the test launches, write "if X happens, we build it" and "if Y, we don't." Without it, the team will rationalize whatever the data shows.

Compare to a Baseline

A click rate without context tells you nothing. Pair every test with an equivalent existing element to get a meaningful comparison.

Always Have a Honest Landing

The click should land on something that respects the user's time. "Coming soon" is fine; silent 404 is not. Trust costs more than the test saves.

Follow Up with the Clickers

The richest signal is what users hoped to find. A short call or survey with the people who clicked turns interest data into actionable understanding.

Treat It as One Signal

Don't promote or kill a feature on a single fake door test. Use it as one of several inputs — alongside interviews, support tickets, and existing usage data.

Stop When You Know

Once the test answers the question, end it. Running a fake door indefinitely turns it into a permanent broken promise.

Summary

Fake door testing is one of the cheapest discovery techniques available and one of the easiest to misuse. Run carefully — clear hypothesis, honest follow-through, defensible baseline — it produces fast directional signal for a fraction of the cost of building the feature. Run carelessly, it erodes user trust and produces noise dressed up as data.

The technique is at its best when paired with other discovery work: an email-capture follow-up with the people who clicked converts a soft signal into a real conversation, and a real conversation produces the kind of insight that turns "people want this" into "people want this specific version of this."

Back to Discovery & Validation