Fake door testing: measuring demand before you build anything

The most expensive way to find out nobody wants a feature is to build it. The second most expensive is to run a survey, because people are consistently generous about things they will never actually pay for or click on.

A fake door test sits between those two. You build the entrance — a button, a menu item, a pricing tier — and you don’t build the room behind it. Then you count who tries the handle. It is the closest thing product work has to a cheap, honest answer, and it is the same instinct behind sending a prototype instead of a spec: make people react to something real rather than describe what they think they’d want.

What is a fake door test?

A fake door test is an experiment that measures demand for a feature by exposing its entry point to real users without building the feature itself. Users who click are shown a short message explaining that the feature isn’t available yet, usually with an option to be notified. The click-through rate is your demand signal.

The mechanics are always the same three parts:

1. The door — a real, discoverable entry point in the live product: a nav item, a button, a plan on the pricing page, an integration tile.
2. The room that isn’t there — an honest interstitial when they click.
3. The counter — an event that tells you how many people who saw the door opened it.

That third part is where most tests go wrong, and I’ll come back to it.

Fake door test vs painted door test

They are the same technique. Painted door test is the more common phrasing at Google and inside larger organisations; fake door test is more common in startups and in the Lean Startup lineage. You will also see false door test and fake feature test, and occasionally fake door experiment. If someone draws a distinction between them in a meeting, they’re describing a local convention, not an industry one.

One genuine distinction is worth keeping, though, because it changes what the result means:

	Fake / painted door	Smoke test
Where it lives	Inside the product, shown to existing users	Outside the product, usually a landing page
Who sees it	People already in your funnel	Cold traffic you have to buy or earn
What it measures	Demand within your current base	Demand plus your ability to market it

Mixing those two up is how a team concludes that a feature is wanted when what they actually measured was that an ad worked.

When a fake door test is the right instrument

It earns its place under fairly narrow conditions:

• The build is expensive and the demand is genuinely uncertain. If it’s two days of work, just build it. The test costs more than the feature.
• You have enough traffic to reach significance in a sane timeframe. Below roughly a few thousand impressions of the door, you’ll be reading noise. Run the numbers before you run the test.
• The decision is real. If the roadmap won’t change whatever the result, you’re doing theatre. This is the most common failure and nobody admits to it — and it’s a discipline problem rather than a technique problem, which is why it’s one of the things I most often end up drilling in coaching.
• The feature is a discrete thing users would look for. Fake doors measure intent to find, so they work for features people go hunting for and badly for ambient improvements like performance or reliability.

When it isn’t

Don’t run one when the answer is already knowable more cheaply — support tickets, sales-call transcripts and your own search logs will often tell you what people want without an experiment at all. Don’t run one on a feature users would only discover after an onboarding step they haven’t reached. And don’t run one in a regulated or trust-critical flow: a fake door in a billing or compliance surface is not a clever experiment, it’s a defect.

How to run one

1. Write down the decision first. One sentence, before you build anything: “If the click-through rate on this door beats X%, we build it in Q4; if it doesn’t, we drop it for at least two quarters.” If you can’t fill in X and the consequence, stop — you’re not ready to run the test.

2. Put the door where the feature would actually live. Not in a banner, not in an email. A door in an unnatural position measures your ability to draw attention to a banner.

3. Instrument the impression, not just the click. You need both halves of the ratio, and impressions are the half teams forget. A raw click count tells you nothing without a denominator.

4. Write an honest interstitial. Say the feature isn’t built yet, say you’re deciding whether to build it, and offer a way to be told when it exists. Two sentences. Do not imply it’s coming.

5. Cap the exposure. A fixed sample or a fixed window, decided up front. Fake doors that run indefinitely turn into permanent lies.

6. Follow up with the people who clicked. This is the step that turns a number into knowledge — see below.

What to measure

The headline metric is click-through rate on the door among users who saw it. Everything else is secondary, but two secondaries matter a lot:

• Second-click rate. How many people, after seeing the “not built yet” message, left their email or came back to the door later. Idle curiosity clicks once. Real need comes back.
• Who clicked. Segment by plan, tenure and use case. A 4% click-through rate spread evenly across your base and a 4% rate concentrated entirely in your enterprise accounts are two completely different findings, and the average hides that.

There is no universal benchmark for a good rate, and anyone quoting one is selling something. The number is only meaningful against a comparable door in your own product — which is why the second fake door test you run is worth far more than the first.

The ethics problem, honestly

You are showing users something that doesn’t exist. That is a small deception, and it has a real cost that compounds if you’re careless with it.

What makes it acceptable:

• The interstitial is immediately honest. No “coming soon” unless it is genuinely coming soon.
• The user gets something — usually a place in the queue and a say in what gets built.
• It’s rare. One fake door in a quarter is an experiment. Four is a pattern users will notice, and what they’ll learn is that your UI can’t be trusted.
• It’s not in a critical path. Never in billing, never in security, never in anything with a legal consequence.

The test I apply: would I be comfortable if this user emailed me and asked what happened? If the honest answer is embarrassing, don’t ship the door.

Where fake door tests mislead you

Five failure modes, roughly in order of how often I see them:

It measures curiosity, not need. A new label in a familiar interface gets clicked because it’s new. Run the door for long enough that the novelty decays, or accept that your first-week number is inflated.

It measures your copy. “AI Assistant” and “Bulk export” will pull different rates for reasons that have nothing to do with the underlying demand. You are always testing the label as well as the feature.

It can’t tell you what people would pay. Clicking is free. If the real question is willingness to pay, the door has to be a price, and that’s a different and more delicate test.

It can’t tell you whether you’d be any good at it. Demand is necessary and not sufficient. Plenty of validated features are ones a competitor will build better than you.

A negative result is weaker than it feels. A door nobody opened might mean nobody wants it — or that it was badly placed, badly labelled, or shown to the wrong segment. Positive results are much stronger evidence than negative ones, and teams routinely treat them as symmetrical.

For what these look like in practice, the worked examples go through the common shapes — the pricing-tier probe, the integrations page, the nav item — and what each one can and can’t establish.

What to do with the result

If the rate clears your threshold: talk to the people who clicked before you build. You now have a list of self-selected, motivated users, which is the single most useful discovery asset a fake door produces and the one most teams throw away in their enthusiasm to start building.

If it doesn’t clear: write down what you learned and the date, and put the idea away for the agreed period. The discipline of actually honouring the pre-registered decision is what makes the next test believable inside your organisation.

And if the honest answer is that you’d have built it either way — that’s worth knowing too. It usually means the decision was never a product decision, and the right conversation is about who owns the roadmap rather than which experiment to run next. That’s often where a stalled roadmap turns out to have a structural cause rather than an evidence problem.