Fake Door Testing: How to Measure Real Demand Before Building the Feature

You've got a feature idea. It feels right. Your early users mentioned it in passing. Your co-founder is excited. So you start building.

Three months later, you ship it to crickets.

This happens because you mistook interest for demand. Someone saying "that would be useful" isn't the same as someone willing to change their behavior, pay for it, or reorganize their workflow around it.

Fake door testing sits between casual validation and full development. It's where you put the feature in front of users—make it real enough to see, but stop short of actually building it. You measure what they do, not what they say.

This post covers the mechanics of fake door testing, how to run it properly, and when it actually saves you time and money.

What is fake door testing?

A fake door test creates a convincing but non-functional version of a feature. Users see it, try to use it, and hit a dead end—usually a message like "This feature is coming soon. Want early access?" or a redirect to a sign-up page.

The key insight: the user's action before hitting the wall tells you everything.

If 2% of visitors click on your "export to CSV" button, you know that feature isn't a priority. If 30% click it, you have real signal that it matters. The click-through rate, the number of sign-ups for early access, and which user segments engage—these are data points. What users actually do beats what they tell you in interviews.

This isn't deceptive if done transparently. Users see language like "coming soon" or "early access"—they understand the feature doesn't exist yet. You're measuring genuine intent, not manipulating anyone.

Why fake door testing works better than asking

Surveys, interviews, and feature request forms suffer from the same problem: they measure interest, not behavior. Someone might tell you they'd use a feature because:

• They want to be helpful
• They're imagining an idealized version of your product
• They confuse "nice to have" with "must have"
• They're thinking about a different problem than the one you solve

Fake door testing forces users to invest effort. Clicking a button takes nothing. But if the feature requires them to stop, read, decide whether it's worth their time, and take action—that's a real signal.

The user has skin in the game, even if it's just 10 seconds of attention. That friction filters out the polite responses and casual interest.

How to set up a fake door test

1. Choose your location

The feature needs to appear where users would naturally expect it. If you're testing an export function, put a fake "Export" button in the interface where that button would live. Don't hide it in a menu no one uses.

If it's a new workflow or feature set, add it as a tab, button, or menu item in your actual product (or landing page if you don't have a product yet).

2. Make it believable

It should look functional. Use the same design language as the rest of your interface. The button or link should work—it just takes users somewhere, not to a feature that exists.

Low-fidelity mockups or poorly styled buttons will underperform because they read as "this isn't real yet," which kills the test. Users won't click something that obviously doesn't work.

3. Measure the right thing

Track:

• Click-through rate: What percentage of users interact with the feature?
• Sign-up rate: Of those who click, how many register for early access?
• User segment: Who clicks? New users, power users, a specific role or company size?
• Frequency: Are the same users clicking repeatedly, or is it one-time curiosity?

The conversion funnel matters. If 25% of users see the feature but only 3% click it, you know positioning is off. If 40% click but only 5% sign up for early access, the feature concept needs refinement.

4. Set your decision threshold before you launch

Decide what numbers mean "build this" vs. "kill it" before you turn it on. Is 10% CTR your threshold? 20%? How many sign-ups do you need? Without a predetermined bar, you'll unconsciously lower it if you like the feature.

5. Run it long enough

A week isn't enough data if your user base is small or traffic is inconsistent. Run it for at least 2–4 weeks, or until you have 100+ interactions with the fake feature. The longer you run it, the more you understand whether the spike was novelty or sustained interest.

What fake door testing answers (and doesn't)

What it tells you:

• Is there measurable demand for this feature?
• Which user segments care most?
• How much of a priority is it relative to other features?
• Does the positioning resonate?

What it doesn't tell you:

• Whether users will actually use it once it's built (though it's a strong indicator)
• The optimal implementation or user experience
• Pricing or willingness to pay (though you can test this with a fake paywall)
• Whether the feature will slow down your product or create confusion

Fake door testing is a demand check, not a product design exercise. It answers "should we build this?" not "how should we build it?"

Real examples of fake door testing

Slack famously tested whether teams wanted better file search by placing a prominent search box in their interface before building the feature. The high engagement told them it was worth the engineering effort.

Dropbox tested file request functionality the same way—fake button, real conversion data. They found enough sign-ups to justify building it.

These companies didn't invent fake door testing, but they proved it works at scale. The method scales from solo founders to established products.

How to run fake door testing with limited traffic

If you don't have thousands of monthly visitors, fake door testing still works—it just takes longer.

Option 1: Test on your landing page

If you're pre-launch, run fake door tests on your main landing page. Add a button or section for the feature. The conversion data is meaningful even with 100 visitors per day—run it for a month and you'll have signal.

Option 2: Use dedicated testing tools

Tools like Valmock let you generate landing page variations in minutes without code. You can create multiple versions of your page—one without the feature, one with it—and split test across your audience. This gives you faster feedback and cleaner data than trying to hack it into your existing site.

Option 3: Email existing users or waitlist

If you have an email list, feature the fake feature prominently in an email. Track clicks back to a landing page with the sign-up form. A 15% CTR on an email feature is strong signal. A 2% CTR tells you it's not a priority.

The metrics that actually matter

Not all clicks are equal. A power user clicking your new feature is more valuable than a casual user. A user who clicks repeatedly shows sustained interest. A user who clicks and completes the sign-up form shows real intent.

Quality signals:

• Repeat clicks from the same user
• Sign-ups from users who are already engaged
• Sign-ups from users in your target segment
• Users who mention the feature in feedback or support conversations

Weak signals:

• One-time clicks from new visitors
• High CTR but low sign-up rate (suggests poor copy or expectation misalignment)
• Clicks from users who churn quickly anyway

When to kill a feature based on fake door testing

If your fake door gets less than 3% CTR after 500+ impressions, it's likely not a priority. If 20% click but fewer than 2% sign up for early access, your positioning or description needs rework—or the feature isn't what users expected.

If you see engagement but only from a tiny segment, ask whether it's worth building for 1% of your user base. Sometimes the answer is yes (if that 1% is high-value enterprise customers). Usually it's no.

The goal of fake door testing is to avoid building features nobody wants. It's also to avoid building features everybody says they want but nobody actually needs enough to use.

Building fake doors fast

The faster you can set up and run a fake door test, the more you can test. You could run 5–10 tests in parallel if you had the infrastructure.

This is where Valmock helps. Instead of coding landing page variations or manually managing split tests, you generate multiple versions in minutes. Test the feature with different copy, positioning, or audience segments without touching your actual product or needing design/development time.

You run the test, get the data, and decide. If it performs, you've validated demand. If it doesn't, you moved on in hours instead of months.

The decision after fake door testing

High engagement means build it. But "build it" doesn't mean build it first. It means it belongs on your roadmap in the right priority.

Low engagement might mean kill it, or it might mean reposition it. Test different copy, different placement, different framing. A feature might perform badly because users didn't understand it, not because they don't want it.

The test creates a feedback loop. Each iteration teaches you something. You're reducing uncertainty before you invest engineering time.

Fake door testing isn't validation—it's data

Don't confuse a successful fake door test with full product validation. It's a strong signal, but it's not proof that users will adopt the feature, that it won't create confusion in your product, or that it won't take longer to build than you expect.

What fake door testing does is eliminate the weakest ideas quickly. It gives you data instead of guesses. It prevents you from building features that nobody clicks on.

For founders with limited time and resources, that's often enough to make a better decision than instinct alone.