Field Notes  /  Experimentation
Experimentation

The fake door test: find out if anyone wants it before you build it

Ever shipped a feature nobody used? Everyone has. Around 80% of features in the average product are rarely or never touched. The fake door test is the cheapest way I know to find out which side of that line your idea falls on, and it takes days rather than a sprint.

Here's the test in one sentence: put the door in the product before you build the room behind it, and count who tries the handle.

That's it. You add the entry point for a feature that doesn't exist yet, you measure how many people reach for it, and you tell them the truth when they do.

How to run one

1. Put up the door. A button, a menu item, a banner, a pricing tier. It has to sit where the real feature would live, styled like everything else. If it's obviously a survey, you're measuring politeness instead of intent.

2. Count who knocks. Track clicks, and track them against how many people saw it. Raw click counts tell you nothing without the denominator.

3. Be honest the moment they click. "This isn't built yet. Want us to tell you when it is?" No dark patterns, no fake loading states, no pretending it broke. You're borrowing trust here, and you only get to do that if you give it straight back.

4. Follow up with the people who knocked. This is the part most teams skip, and it's the most valuable. The click tells you there's interest. The conversation tells you what they actually expected to find behind the door, which is often not what you were planning to build.

Buffer is the well-known example: a landing page with pricing tiers for a product that didn't exist yet, and the clicks decided whether to build it at all.

If people won't click a button, they definitely won't use the feature behind it. A click isn't proof of value, but no clicks is proof of no demand.

What it does and doesn't prove

Be careful with what you conclude. A fake door measures interest at the moment of encounter. That's genuinely useful, and it's not the same as willingness to pay, or willingness to change how they work, or the thing being valuable once it exists.

Plenty of people click things out of curiosity. So treat a strong result as permission to investigate further, not as a mandate to build. Treat a weak result as much stronger evidence: if nobody reaches for it when it's sitting right there in the interface, the feature was never going to earn its place.

That asymmetry is the point. The test is far better at killing ideas than confirming them, and killing ideas cheaply is most of what building on evidence actually means in practice.

The trust cost, and how to keep it near zero

You're showing someone something that isn't real. Done carelessly, that's a small betrayal, and you can absolutely damage a relationship with a paying customer to learn something you could have learned by asking them.

So: run it on a slice of traffic rather than everyone. Be transparent within one click. Never fake it for a feature you have no intention of building. And if someone signs up for the waitlist, actually tell them what happened, even when the answer is "we decided not to build it."

Handled that way, most users read it as a company that's paying attention. Handled badly, it reads as a company that wastes your time.

Where it fits

The fake door isn't a strategy. It's one cheap instrument among several, and it works best when running experiments is already normal rather than an event, which is the whole argument for building a culture of experimentation in small steps.

Use it when the disagreement in the room is about demand, not about design. "Would anyone use this" is a fake door question. "Which of these three flows is clearer" is not, that's a prototype question.

And remember what's actually at stake. Every feature you ship adds cost forever, whether or not anyone uses it. Spending three days finding out before you spend three weeks building is not caution. It's just arithmetic.

Running these tests as a habit, rather than the one time a year someone remembers to, is exactly what we drill in the Product Discovery Workshop.

Aleksander Uznański
Aleksander Uznański
Founder of ProductTrio. He helps teams kill bad feature ideas in days instead of discovering the truth a sprint after launch.

About to build something nobody asked for?

There's usually a two-day test that would tell you. Book a free intro call and we'll design one for whatever's next on your roadmap.

Book a free intro call
Free · 20 minutes · No pitch deck, just your actual problem