Dec 06,2025 
Most product ideas fail. Research suggests up to 90% of new features and products miss the mark with users or fail to produce the expected business results. That’s a painful statistic when you consider how much time, money, and energy teams pour into building things that nobody ends up wanting.
So what if you could test demand before you build anything at all?
Fake door testing lets you do exactly that. You create something that looks real, like a button, link, or landing page for a feature that doesn’t exist yet. You put it in front of users. Then you watch what happens. If people click, you’ve got a signal that there’s interest. If they don’t, you’ve saved yourself weeks or months of wasted development work.
The concept is simple, but the execution requires care. Done poorly, fake door tests can frustrate users and damage trust. Done well, they become one of the fastest and cheapest ways to validate product ideas with real behavioral data.
This guide walks through everything you need to know: how fake door tests work, how to set them up, what to measure, how to handle the ethics, and how to use the results to make better product decisions.
What Is Fake Door Testing?
A fake door test is an experiment where you present users with what appears to be a real feature or product option, but nothing actually exists behind it. When someone clicks the button or link, they encounter a message explaining that the feature is coming soon, often with an option to sign up for updates or provide feedback.
The technique goes by several names. You might hear it called a painted door test, a 404 test, or a landing page test. Some people group it under the umbrella of smoke testing. The core idea remains the same across all these terms.
Think of it as testing demand with a facade. You’re not asking people if they would be interested in something. You’re watching to see if they actually try to use it when given the chance. That behavioral signal is far more reliable than survey responses or hypothetical questions because people are notoriously bad at predicting what they’ll actually do in the future.
The term “fake door” comes from the metaphor of a door that looks real from the outside. Users walk through it expecting something on the other side. What they find instead is a polite explanation and an invitation to stay involved.
This approach falls under a category sometimes called pretotyping, a play on prototyping. Instead of building a prototype with limited functionality, you skip the building part entirely and test the concept using only the appearance of a feature.
Why Fake Door Tests Work
The fundamental insight behind fake door testing is economic. Product development is expensive. Engineering time costs money. Design work takes effort. And once you’ve built something, there’s psychological pressure to ship it even if the market signals are weak.
Fake door tests flip that equation. They let you test before you invest. The cost of adding a button and tracking clicks is trivial compared to the cost of building a feature that users ignore.
But there’s also a psychological principle at play. Surveys and interviews capture what people say they want. Fake door tests capture what people actually do. These two things often don’t match.
When someone clicks a button labeled “Try AI-Powered Reports,” they’re demonstrating real interest through action. They’ve stopped what they were doing and actively chosen to explore something new. That’s a stronger signal than a survey response where someone rates their interest as 4 out of 5.
The behavioral data from fake door tests cuts through the noise of stated preferences. It shows you where real demand exists based on how users behave when they encounter an opportunity.
Famous Examples of Fake Door Testing
Several well-known companies have used fake door approaches to validate products before building them.
- Buffer, the social media management platform, ran an early test before the product existed. The team created a landing page describing the product concept with a “Plans and Pricing” button. Clicking the button didn’t take users to pricing information. Instead, it showed a page explaining that the product was still in development, with an option to sign up for email updates. The team used sign-up rates to validate demand before writing any product code.
- Tesla took a similar approach when releasing its first car. Before production had begun, the company asked potential customers to put down a $5,000 deposit to secure a build date. This deposit wasn’t for a car that was ready to ship. It was a commitment based on the promise of a future product. The deposit rate validated that people would actually pay for what Tesla planned to build.
- Dropbox provides another instructive example. The team created a simple video demonstrating how file syncing would work. The video showed a product that didn’t exist yet. After publishing the video, beta sign-ups jumped from 5,000 to 75,000 overnight. The company had validated demand without building the full product.
- What’s notable about the Dropbox case is that the team had struggled with traditional marketing. Google AdWords campaigns were costing up to $399 per customer acquisition for a product priced at $99. The video approach cost a fraction of that and produced a much stronger signal.
- Zynga, the game studio, has built fake door testing into its development process. The team tests new game ideas by creating a five-word pitch for each concept, then publishing promotional links in their live games. They track how much interest each pitch generates from existing users before committing to full development.
How Fake Door Tests Work Step by Step
The mechanics of a fake door test follow a predictable sequence.
Creating the Door
First, you create something that looks like a real entry point to a new feature. This might be a button in your app’s navigation, a link in an email, a new tab in your product interface, or a standalone landing page.
The key is that this element should feel natural within the context where users encounter it. A button labeled “AI Reports Beta” in your product’s sidebar looks like any other feature. Users don’t know it’s an experiment.
Common formats include menu items, call-to-action buttons, feature cards, email links, and promotional banners. The format depends on where your users will encounter the test and what feels authentic for your product.
Tracking Interactions
When someone clicks the fake door element, your analytics system records the interaction. You want to capture several data points: who clicked, when they clicked, and what segment or account type they belong to.
Click data becomes your primary demand signal. High click rates suggest strong interest. Low rates suggest weak demand or poor positioning.
Beyond counting clicks, you might track patterns like repeated clicks from the same user, which could indicate high interest or confusion, and the time between page load and click, which could indicate how immediately compelling the offer appears.
The Post-Click Moment
After clicking, users see a message explaining the situation. This is where ethical considerations become critical.
Effective post-click messages include a clear explanation that the feature is in development, a timeline estimate if you have one, an option to sign up for updates or become a beta tester, and an easy way to return to what they were doing before.
The disclosure maintains trust by being direct about what happened. Users generally respond well to honesty. Many will willingly join waitlists when they understand the purpose behind the test.
Semrush, the marketing platform, found that about 40% of users who visited a fake door wanted to become beta testers, and 23% completed both steps of a follow-up survey sharing insights about their work.
Designing Your Fake Door Test
Running a useful fake door test requires more than adding a button and watching the numbers. The design of your test determines whether the results actually tell you anything meaningful.
Start With a Testable Hypothesis
Before launching a test, write down what you expect to happen and what would convince you to move forward.
- A weak hypothesis looks like this: “Customers will want this feature.”
- A strong hypothesis looks like this: “Enterprise customers will click the SSO integration option at a rate of 15% or higher.”
The strong version specifies who you’re testing, what action you’re measuring, and what threshold would indicate success. This forces you to think through your assumptions before you start collecting data.
Writing down your success criteria in advance protects you from moving the goalposts after you see the results. If you decide that 15% is your threshold, and you get 8%, that’s a failed test. You don’t get to retroactively decide that 8% is actually pretty good.
Target the Right Audience
Fake doors should reach users who would actually use the feature if it existed. If you’re testing an enterprise reporting feature, showing it to individual users on free plans won’t produce useful signals.
Segment your audience to match the feature you’re testing. If only a portion of your user base would benefit from the capability, show the fake door only to that portion.
Random exposure to your entire user base can dilute your results. The people who should care most get mixed in with people who have no reason to click.
Choose Your Location and Copy Carefully
Where you place the fake door and how you describe it will heavily influence results.
Location matters because a prominent button in primary navigation will get more clicks than a buried link in a settings menu. This doesn’t mean prominent placement is always better. It means you should consider whether the placement matches where the real feature would live.
Copy matters because the words you use shape how users interpret the offer. A button that says “Try AI Reports” communicates something different from one that says “Automated Reporting Beta.” Test copy variations if you can. What feels compelling to your team might not resonate with users.
Plan for Statistical Significance
Don’t draw conclusions from small samples. A hundred impressions and 3 clicks tells you almost nothing.
General guidance suggests waiting until you have at least 1,000 impressions or views before evaluating results. Some practitioners recommend even higher thresholds depending on the expected click rate.
Running a test for 2 days when you need 2 weeks will produce unreliable data. Set your test duration in advance based on your traffic volume and stick to it.
Measuring Results
The primary metric in most fake door tests is click-through rate: what percentage of users who saw the fake door clicked on it.
But clicks alone don’t tell the whole story. Consider tracking these additional signals.
Unique versus total clicks help you understand whether lots of different users are interested or whether a small number of users are clicking repeatedly. Repeated clicks might indicate strong interest, or they might indicate confusion about why the feature isn’t working.
Post-click behavior matters too. After users see your disclosure page, do they immediately leave? Do they sign up for updates? Do they continue using your product normally? High sign-up rates suggest genuine interest. High bounce rates might indicate frustration.
Segment differences reveal which types of customers show the strongest interest. You might find that small business customers clicked at 3% while enterprise customers clicked at 18%. That information shapes how you prioritize development and positioning.
Time to click can indicate how compelling the offer appeared. Immediate clicks suggest the concept grabbed attention. Delayed clicks might mean users discovered it through exploration rather than being drawn to it.
Interpreting What the Numbers Mean
A high click rate suggests interest. A low click rate suggests weak demand or poor execution. But interpreting results requires nuance.
First, compare against your predefined threshold. If you decided that 10% would indicate strong demand and you got 12%, that’s validation. If you got 6%, that’s a failed hypothesis, even if 6% feels like a lot of people.
Second, consider alternative explanations. Low clicks might mean users don’t want the feature. They might also mean users didn’t notice it, didn’t understand what it was, or weren’t the right audience. High clicks might mean genuine demand. They might also mean curiosity about an unusual new element or accidental clicks on a prominent button.
Third, remember that fake door tests measure interest, not satisfaction. Lots of people clicking doesn’t guarantee they’ll actually use and love the feature once it exists. The test validates that there’s demand worth exploring further. It doesn’t validate that your solution will meet that demand well.
A failed fake door test can actually be a success. Solitaired, a card game company, had a hunch that users would want multiplayer functionality. Building multiplayer would have been complicated and expensive. Instead, they added a button to test interest. Less than 2% of users clicked it. The team didn’t consider this a failure. They considered it a sign that they could move on to other ideas without losing substantial money on a feature few people wanted.
Ethical Considerations and Maintaining Trust
Fake door testing involves showing users something that doesn’t exist. This creates ethical responsibilities that teams must take seriously.
The core risk is damaging trust. Users who click expecting a feature and find a “coming soon” message might feel deceived. In a worst-case scenario, this could harm your brand reputation. Users might feel they’ve been lured in under false pretenses.
The mitigation comes through how you handle the disclosure moment. Best practices include:
Apologize for potential disappointment. Acknowledge that they were hoping to use something that isn’t ready yet.
Be transparent about what’s happening. Explain that you’re testing whether to build this feature and their click helps inform that decision.
Thank them for their interest. Their engagement is actually valuable to you, and acknowledging that builds goodwill.
Offer something in return. Let them sign up for updates, join a beta testing list, or provide feedback. Turn the moment of disappointment into an opportunity for deeper engagement.
Provide an easy exit. Make it simple to return to what they were doing before clicking.
One approach that reduces risk is targeting fake doors to beta testers or users who have opted into early access programs. These users expect experiments and unfinished features. They’re less likely to feel frustrated and more likely to provide useful feedback.
There’s an important distinction between fake door testing and dark patterns. Dark patterns deliberately deceive users or hide information to manipulate behavior. Fake door testing, done ethically, is transparent about what’s happening once a user engages. The disclosure page makes everything honest. Users understand the situation and can choose whether to stay involved.
The size of your test cohort matters too. Exposing 1% of users to a fake door limits potential damage while still providing enough data. Exposing 100% of users amplifies both the data and the risk.
Fake Door Testing Versus Other Validation Methods
Fake door testing is one tool in a broader toolkit for product validation. Understanding how it compares to other methods helps you choose the right approach for your situation.
Wizard of Oz Testing
In a Wizard of Oz test, users believe they’re interacting with an automated system, but a human is actually operating things behind the scenes. The name comes from the film where an old man pulls levers from behind a curtain.
Zappos used this approach early on. The founder set up a simple website to take shoe orders, then manually purchased shoes from local stores to fulfill them. Customers believed they were using a functioning e-commerce site. In reality, everything was handled manually.
The Wizard of Oz approach lets you test whether your solution actually solves the user’s problem. Fake door testing only tells you whether there’s initial interest. Wizard of Oz can validate that people will complete the full workflow and find the result valuable.
However, Wizard of Oz tests require much more effort to run. You need humans performing the work behind the scenes for as long as the test runs. Fake door tests require almost no ongoing effort after setup.
Use Wizard of Oz when you have a defined solution and want to validate that it works. Use fake doors when you want to validate whether there’s interest in a concept before designing the solution in detail.
Concierge Testing
Concierge testing is similar to Wizard of Oz, but the human involvement is visible to users. Instead of pretending the system is automated, you openly provide manual service while learning what users actually need.
This approach works well when you’re not sure what the solution should look like. By providing manual service, you can observe what users ask for and how they respond. The learnings shape what you eventually build.
The trade-off is that concierge testing introduces human bias. The person providing service might influence results in ways that wouldn’t apply to an automated system.
Landing Page Tests
Landing page tests are closely related to fake door tests, but they typically operate outside your product. You create a standalone page describing something that doesn’t exist and drive traffic to it through ads or other channels.
The Dropbox video example falls into this category. The landing page measured sign-up interest without any product existing behind it.
Landing page tests work well for entirely new products. Fake door tests work well for features within existing products. The difference is mainly about where the test lives and how users encounter it.
Traditional Prototyping
Traditional prototyping involves building something functional, even if limited, and testing how users interact with it.
This approach gives you much richer feedback about usability, workflow, and feature details. You learn not only whether there’s interest but also how well your solution works.
The cost is time and resources. Building a functional prototype takes weeks. Running a fake door test takes hours.
Fake door tests make sense at the earliest stages when you want to validate interest before investing in prototype development. Traditional prototyping makes sense later when you’ve confirmed interest and want to refine the solution.
Industry Applications
Fake door testing applies across industries, though the specific formats vary.
SaaS Products
SaaS teams commonly add fake doors to their product navigation or settings. A project management tool might add a sidebar link for “AI Task Prioritization.” An analytics platform might add a tab for “Predictive Insights Beta.”
Semrush used this approach when considering a new Client Manager tool. The team wanted to understand whether users would share client data, what tasks they most needed to automate, and who might become early adopters. A fake door test provided signals for all three questions.
Email campaigns also work for SaaS products. Send a teaser about a new capability with an early access link. Track who clicks and signs up.
E-commerce
E-commerce teams can test new product categories, subscription services, or features like size options.
One approach: add a product category page with items marked “Coming Soon” or “Notify Me.” Track how many users click the notification button.
Another approach: add a “Subscribe and Save” button to product pages. The button doesn’t actually set up a subscription. It captures interest data to determine whether building subscription infrastructure is worth the investment.
Pre-order campaigns function similarly. You’re asking users to commit before the product exists. The commitment rate indicates demand.
Gaming
Gaming companies face high development costs and uncertain demand. A new game feature or concept might require months of development. Fake door testing lets teams validate interest before committing resources.
Zynga’s five-word pitch approach demonstrates this. Create a simple description of a game concept. Promote it briefly in existing games. Measure how many users click through. The highest-interest concepts move forward.
Mobile Apps
Mobile apps can embed fake doors in menus, tabs, or feature announcements. The constraint is screen space. You need to test without cluttering the interface or annoying users with too many experimental elements.
Push notifications or in-app messages can also serve as fake doors. Announce a coming feature and invite users to sign up. The sign-up rate indicates interest.
Common Mistakes and How to Avoid Them
Several pitfalls trip up teams running fake door tests for the first time.
Testing Too Many Things at Once
If you’re running multiple fake door tests simultaneously on the same user segment, you can’t isolate which results mean what. Users become confused by multiple new elements. Your data becomes muddied.
Test one thing at a time. Run a test, gather results, and then move to the next concept.
Ignoring Copy and Placement Effects
The words you use and where you put the fake door will strongly influence results. A poorly written button might get low clicks even if the underlying concept is attractive. A button buried in a submenu might go unnoticed.
Try multiple copy variations if possible. Consider whether placement reflects where the feature would actually live.
Drawing Conclusions Too Early
Small sample sizes produce unreliable results. If you launch on Monday and draw conclusions by Wednesday, you’re probably basing decisions on random noise.
Set a sample size threshold in advance. Wait until you reach it before evaluating.
Targeting the Wrong Users
Showing an enterprise feature to free tier users won’t produce useful signals. Showing a consumer feature to business accounts won’t either.
Segment your audience appropriately. Show fake doors to users who would actually care about the capability.
Over-Testing Users
If users encounter fake door after fake door with nothing real behind any of them, they’ll lose trust. They’ll stop clicking because they’ve learned that new elements are usually experiments rather than real features.
Be selective about what you test. Don’t use fake doors for everything.
Forgetting to Document
After a test concludes, record what you learned. Note the hypothesis, the results, and the decision you made based on them.
This documentation helps your team avoid repeating tests and builds organizational knowledge about user preferences over time.
When Not to Use Fake Door Testing
Fake door testing isn’t appropriate for every situation.
Established products with expectant users. If your user base expects reliable features and updates, repeatedly teasing things that don’t exist will frustrate them. Trust is at stake.
Complex proposals that take a long time to build. If validating demand through a fake door leads to a 2-year development timeline, the initial enthusiasm might fade entirely before you ship. The interest signal becomes stale.
When you’re overusing the technique. An over-reliance on fake doors can signal strategic drift. If you’re constantly testing rather than building, that’s a different problem than validation.
When you need to validate more than interest. Fake doors tell you whether there’s demand. They don’t tell you whether your solution will actually work, whether users can figure out how to use it, or whether they’ll find ongoing value. For those questions, you need prototypes or Wizard of Oz tests.
Moving From Validation to Development
A successful fake door test generates interest that you need to act on. The transition from validation to development requires planning.
Prioritize Based on Segment Data
Your test data should reveal which customer segments showed the strongest interest. Use this to prioritize development.
If enterprise accounts clicked at 3x the rate of small business accounts, that shapes how you design and position the feature. You might start with an enterprise-focused MVP.
Follow Up With Waitlist Users
Users who clicked your fake door and joined a waitlist are prime candidates for further research. They’ve already demonstrated interest. Now you can learn what specifically they’re looking for.
Reach out for interviews. Ask about their context, their current workarounds, and what they’d expect from the feature. This qualitative data fills in details that click rates can’t provide.
Consider Phased Rollouts
When you’re ready to build the real feature, consider launching first to users who clicked the fake door. They’re most likely to adopt quickly and provide early feedback.
Feature flags let you control who sees the real feature and when. Start narrow, gather feedback, and expand as you refine.
Compare Real Usage to Test Results
After launching, track how activation and engagement compare to the interest signals from your fake door test.
If 20% of users clicked your fake door but only 2% are actively using the real feature, something changed between interest and adoption. Maybe the feature didn’t meet expectations. Maybe the positioning shifted. Maybe the workflow is too complicated.
This comparison helps you interpret future fake door tests more accurately.
Building a Sustainable Practice
Fake door testing works best as part of a consistent validation practice rather than a one-time technique.
Create Standard Protocols
Develop templates for how you design, run, and document fake door tests. Standardization makes tests easier to run and results easier to compare over time.
Your protocol should cover hypothesis format, success criteria, sample size thresholds, disclosure page content, follow-up actions, and documentation requirements.
Integrate With Other Research
Fake door tests provide behavioral demand signals. Other research methods provide depth and explanation. Combining them creates a fuller picture.
Evelance enables teams to run tests and then recruit interested participants for follow-up interviews, surveys, or usability tests. The behavioral data identifies who’s interested. The qualitative research uncovers why and what they expect.
Build Organizational Knowledge
Each test teaches you something about your users. Document these lessons. Share them across teams. Build a knowledge base of what you’ve learned about demand patterns in your product.
Over time, this cumulative learning helps you make better predictions about which ideas are worth testing and which are unlikely to resonate.
Balance Speed With Trust
The appeal of fake door testing is speed. You can test ideas in days instead of months. But speed shouldn’t come at the cost of user trust.
Limit how frequently any individual user encounters fake door tests. Ensure every disclosure page is honest and helpful. Follow through on promises to notify interested users when features launch.
A practice that erodes trust isn’t sustainable even if it produces useful short-term data.
The Value of Behavioral Validation
Fake door testing represents a particular philosophy about product decisions. Instead of relying on opinions, assumptions, or hypothetical questions, you collect evidence from real behavior.
Marty Cagan, in his book Inspired, describes the goal of product discovery as validating ideas the fastest, cheapest way possible. Fake door testing embodies that goal. Minimal investment. Rapid signal. Evidence-based decisions.
The technique won’t answer every question. It won’t tell you how to design a feature, whether users can figure it out, or whether they’ll still value it after the first month. Those questions require other methods.
But for the question of whether anyone cares enough to try something new, fake door testing provides a reliable answer at minimal cost.
Teams that master this technique gain a filter for their ideas. They can quickly separate concepts that attract real interest from concepts that only seemed promising in brainstorming sessions. The result is fewer resources spent on features nobody wanted and more capacity directed toward ideas that users actually seek out.
That’s the core promise: better decisions, faster, with less waste. For teams working to build products people actually want, few techniques offer better ROI.