Fake-Door Test

A fake-door test is a real-looking button or link for a feature that doesn't exist yet, dropped inside a product you already have. Someone taps it, and instead of the feature they get a short "we're building this, want to hear when it's ready?" The tap is the signal. You're counting who reaches for a door before you build the room behind it.

The question it answers

It answers one question. Does anyone actually want this feature?

There are four things you can test before you build: whether people want it (desirability), whether they can use it (usability), whether you can build it (feasibility), and whether the words land (messaging). Desirability is the one I always start with. Not "can they use it," not "can we build it," not "do the words land." Just: will a real person, in your live product, reach for this thing at all?

Anyone can get excited about a feature in a planning meeting. The team's been arguing for it, a loud customer keeps asking, somebody saw a competitor ship it. None of that is evidence. Evidence is watching what people do when the door is in front of them and they think it's real. A fake door buys you that for the cost of a button.

The catalog of experiment types underneath this, and the desirability-first framing, comes from Testing Business Ideas by David Bland and Alex Osterwalder. Credit where it's due.

How to run it cheaply

The minimum version is one button and one panel.

1. Pick the one feature you're unsure about. Not three. One. Bundling muddies the read.
2. Add a real-looking entry point inside your live product. A button, a menu link, a dashboard card. It has to look like it belongs, or the test reads your design, not your demand.
3. Behind the tap, show the truth, gently. A short panel: "We're building this. Want early access?" with an email field. No dark patterns. The honest version still gets you the number.
4. Write the success bar down before you launch. A target tap rate, and a target for how many of those leave an email. The number and the end date, written first, or the test bends to whatever result you wanted anyway. Every experiment in this catalog leans on that one discipline.
5. Run it for a fixed window, then read it. Two weeks is usually enough. Count the taps. Count the emails. Decide.

A rough benchmark to start from: more than 5% of active users tap the door (active users being the people actually using the product during your test window, not everyone who ever signed up), and more than half of those who tap leave an email. Treat that as the kind of starting number I'd give a student, not a research finding. Set your real target for your audience, before launch.

A worked example

You run a budgeting app, and the team's been arguing for months about whether to build bill-splitting for roommates. Everybody has an opinion. Nobody has evidence.

So instead of building it, you add a "Split a bill" button to the main screen. Tapping it opens a panel: "We're building this. Want early access?" with an email field. The button took an afternoon. The feature would have taken a sprint.

Target, set before launch (illustrative). The same bar from above, the 5%-tap, half-leave-email line. Two weeks later, 8% tapped and 60% of them left an email. The argument's over. The demand is real enough to build against, and you learned it without writing the feature, by watching what people did instead of asking them in a survey.

The honest version cuts both ways. If almost nobody taps, you just saved a sprint. A fake door that goes untouched is one of the cheapest "no" answers you'll ever buy. The win isn't only the green light. It's the red one too, bought before the build.

When to reach for it, and when not

Reach for the fake-door test when you already have live traffic and you want to test demand for one new feature without building it. The piece that has to be true is the live product. A fake door needs a real room to live in. No existing users, no traffic, no door to put it behind, and you're not ready for this one.

Now the line that gets blurred, because it's the one that matters. A fake-door test is not a landing-page test. The landing-page test sells a whole product that doesn't exist, on its own page, to strangers you drive there with ads. The fake door sells one feature inside a product that already exists, to users who are already yours. Whole product versus one feature. New strangers versus your live base. Pick by which one you're actually unsure about.

And don't confuse it with the more expensive test above it. The fake door tests whether someone wants the feature. It can't test whether they can use it or stick with it, because there's nothing behind the door to use. When you need that, you climb to a Wizard of Oz test, where the feature looks real and works, except a human runs it by hand behind the screen. The name comes from the man behind the curtain pulling the levers. The user sees a working feature, and you're the one doing the work by hand. The fake door reads desire. The Wizard of Oz reads usage. Start with the cheaper one, and climb only when "do they want it" has already come back yes.

Sibling recipes, when they're live: the landing-page test, the Wizard of Oz test, and the full Lean Experiments Catalog these all sit inside.