In 2010, Joel Gascoigne wanted to know if anyone would pay for a tool to schedule social media posts. He didn’t build it. He put up a two-page website: one page describing the concept, one page showing pricing tiers. The pricing page had no checkout. Visitors who clicked a plan were asked for their email address. Within days, enough people had entered their emails that Gascoigne knew Buffer had real demand. Only then did he start coding.
That was a fake door test. In 2026, it remains one of the most underused techniques in product discovery.
What a Fake Door Test Actually Measures
Most discovery methods capture stated intent. You ask someone in an interview, “Would you use this feature?” and they say yes because saying yes is easy. Surveys produce the same optimistic bias. Even prototype tests, while more concrete, still measure reactions in a controlled setting.
A fake door test measures something different: whether someone takes action when they believe the feature is real. There’s no interviewer watching. No context that signals “this is research.” Users click because they want the thing, or they don’t.
That behavioral signal is harder to fake than any survey response.
The Mechanics
The setup is straightforward. Add a button, menu item, banner, or link in your existing product (or on a landing page) that appears to lead to a new feature. When a user clicks, they see a “coming soon” message with an option to join a waitlist, or a brief explanation that you’re exploring this idea and want to gauge interest.
Track the click-through rate. If 12% of users who see the button click it, that’s a strong demand signal. If 0.4% click, you probably have your answer.
The entire experiment can run in 48 hours. No engineering sprint required. A product manager with access to a feature flag tool or a basic A/B testing platform can set it up in an afternoon.
Companies That Used This Before Committing Resources
The examples are worth studying because these are not obscure startups:
Dropbox published a three-minute explainer video for a file-syncing product that didn’t exist yet. The video’s call to action was a beta signup form. Overnight, signups jumped from 5,000 to 75,000. That was the data Drew Houston needed to justify building the product.
Buffer (the Gascoigne example above) validated both the concept and the willingness to pay with a landing page that took one day to create. No code, no infrastructure, no investor pitch. Just a page and an email field.
LinkedIn added a “Find Freelancer” button to its interface before any freelancer marketplace existed. Click data from that single button provided the demand evidence that led to LinkedIn ProFinder.
Semrush ran a fake door test when considering a Client Manager tool. The team wanted to know whether users would share client data, what tasks they most wanted to automate, and who might become early adopters. One test answered all three questions.
When This Method Fits and When It Doesn’t
Fake door testing is strongest when the question is binary: “Do people want this?” It works well for:
- Feature demand validation before a single sprint is planned
- Choosing between two feature concepts by running parallel fake doors
- Testing whether a new product category resonates with existing users
- Prioritizing a backlog by measuring which proposed features draw the most clicks
It does not fit every situation. If you need to understand how someone would use a feature, a prototype test gives richer data. If you need to uncover problems you haven’t named yet, interviews still win. If the feature involves a complex multi-step workflow, a concierge test (manually delivering the service to see how people respond) works better.
Think of fake door tests as a filter. They go first, to confirm demand exists. Deeper discovery methods come second, to shape the solution for confirmed demand.
The Trust Problem
The objection product managers raise most: “Won’t users be annoyed that we showed them something fake?”
They will be, if you handle it poorly. A button that says “Export to PDF” leading to a 404 page breaks trust. A button that says “Interested in PDF export?” with a small “coming soon” badge, leading to a message that says “We’re exploring this and would love your input,” does not.
The framing makes the difference. Language that signals exploration (“Interested in…?” or “Help us decide…”) sets correct expectations. Language that implies availability (“Click here to use…”) breaks them. Zapier’s guide to painted door tests covers this framing distinction well.
I learned the cost of skipping demand validation firsthand: three months into a reporting dashboard build that an operations team had unanimously requested, usage data showed exactly two people logging in weekly. A 48-hour demand test at the start would have redirected that quarter of engineering time toward something people actually needed.
Where This Fits in Your Discovery Practice
If you’re already running continuous discovery, fake door tests slot into what Teresa Torres calls the assumption-testing layer. Her framework separates assumptions into desirability, viability, feasibility, usability, and ethics. A fake door test is the purest desirability check available: behavioral data, not opinions.
Pair it with pretotyping (testing the core premise before committing resources) and you have a lightweight discovery stack that catches bad ideas before they consume engineering time.
The product teams that ship the fewest wasted features are not the ones with the best interview technique. They’re the ones that test demand before they build.