Fake Door Tests: Validating Demand Before You Build a Single Feature

A fake door test (also called a painted door test) exposes users to an entry point — a button, menu item, or landing page — for a feature that doesn't exist yet, then measures who clicks it. The click-through rate becomes your demand signal. If enough people try to open a door that leads nowhere, you've earned the right to build what's behind it.

Quick Answer: A fake door test ships the entry point to a feature (a button, nav item, or ad) before the feature is built, tracks click-through rate as a demand proxy, and routes clickers to an honest "coming soon" state instead of a broken experience. Build only if clicks clear a threshold you set in advance.

What a Fake Door Test Actually Is

A fake door test is a desirability experiment disguised as a UI element. You place something that looks like a real, working feature — a button labeled "Export to Slack," a pricing tier for "Team Analytics," a nav item for "AI Summaries" — into your live product or marketing site. Nothing behind it works yet.

The mechanics are deliberately narrow:

1. Design the entry point exactly as it would look if shipped — same visual weight, same placement, same copy quality as any real feature.
2. Instrument the click with an event (not a page view) so you're measuring intent, not accidental exposure.
3. Route clickers to a graceful message, not an error page or dead link.
4. Compare click-through rate against a pre-set threshold to decide whether to build.

The term traces back to growth and product experimentation practices popularized at companies like Spotify and Airbnb in the early 2010s, and it's frequently cited alongside Eric Ries's Lean Startup concept of a minimum viable product — the fake door is arguably the most minimum version of an MVP, since it has no functioning product behind it at all. It's also a close cousin of the "smoke test" landing pages that growth teams have run since early SaaS days: a page selling a product that isn't built, gated by an email capture instead of a checkout.

How It Differs from a Landing Page Smoke Test

A fake door test embeds the fake entry point inside your existing product or site, using real users in their normal context. A landing-page smoke test, by contrast, is usually a standalone page driven by paid or organic traffic acquisition, testing a whole product concept rather than one feature inside an existing flow.

Both share the same underlying discipline: measure desirability before you spend on feasibility. Neither replaces the other — a mature experimentation program often uses smoke tests for net-new product bets and fake doors for feature-level bets inside a live product, as covered in our complete guide to experimentation.

Why Desirability Should Come Before Feasibility

Most roadmap failures aren't engineering failures — they're desirability failures wearing an engineering costume. A feature ships on time, works exactly as spec'd, and nobody uses it. The fake door test exists to catch that outcome before the build, not after the retro.

Teams default to feasibility-first thinking because feasibility is what's visible on a roadmap: story points, sprints, engineering headcount. Desirability is invisible until launch — unless you manufacture a way to see it early. A fake door test converts an invisible unknown into a measurable number before a single line of production code is written.

This isn't an argument against planning for feasibility — technical complexity, data modeling, and system dependencies still matter enormously once you decide to build. It's an argument about sequencing. Desirability signal should gate the decision to invest in feasibility work, not the other way around. Marty Cagan's product-discovery writing at the Silicon Valley Product Group makes a similar case: most product risk is value risk (will anyone want this) and usability risk, not technical risk — yet most process invests in derisking the one risk that's already lowest.

The Failure Mode Fake Doors Prevent

Consider a team that builds a "team analytics dashboard" over one quarter because three enterprise prospects asked for it in sales calls. The build ships. Usage sits near zero. In hindsight, those three prospects wanted the idea of analytics, not the specific dashboard shipped — a distinction a fake door test surfaces in a week instead of a quarter.

A well-run fake door test would have shown low click-through on the entry point months earlier, prompting a cheaper investigation: talking to the clickers (or non-clickers) about what job they were actually trying to get done, which is the territory covered in our guide to jobs-to-be-done.

Designing an Honest Fake Door Test

An honest fake door test looks and behaves like a real feature right up to the moment of the click, then immediately and gracefully tells the truth. The ethics here aren't optional — a deceptive or broken experience damages trust with the exact users you're trying to learn from and win over.

The non-negotiable design elements:

• Match production fidelity. A sloppy button reads as "not real yet" and depresses click-through independent of actual demand — you'll under-measure interest.
• Show a "coming soon" state immediately, never a 404, spinner-that-never-resolves, or silent no-op. The click should feel acknowledged, not swallowed.
• Offer something in return for the click — a waitlist signup, an email capture, or a one-line "tell us what you'd use this for" prompt. This turns a passive click into a second, richer signal.
• Time-box the exposure. Run it for a defined window (commonly 1-4 weeks depending on traffic volume) and remove it — don't leave a fake door live indefinitely.
• Disclose in aggregate, not to individuals mid-test. You don't need to tell each clicker "this was a test" in the moment (that would ruin the measurement), but be prepared to be transparent if asked directly, and follow through if you told people you'd notify them at launch.

The line between a fake door test and dark-pattern deception is intent plus follow-through: are you honestly assessing demand to serve users better, and will you act on what you learn — including telling people if you decide not to build it?

What a Graceful "Coming Soon" State Includes

A good coming-soon response does three things in order: acknowledges the click ("Thanks for your interest in Team Analytics"), sets an honest expectation ("We're evaluating this for a future release — no promised date"), and captures a lightweight signal (an email, a one-tap "notify me," or an optional open-text field asking what they'd use it for). Skipping the second step — implying a launch date you don't have — is the most common honesty failure in fake door tests.

Setting a Click-Through Threshold That Justifies Building

There's no universal magic number for a fake-door click-through rate — the right threshold depends on your baseline engagement, traffic volume, and how expensive the eventual build is. What matters is setting the threshold before you look at results, so you're not rationalizing a number after the fact.

A workable process for setting your threshold:

1. Establish a baseline. Look at click-through rates on comparable existing features in similar placements (nav items, dashboard cards, settings toggles) — this is your "normal curiosity click" rate, and your fake door needs to clear it meaningfully.
2. Size the traffic. Estimate weekly exposures to the entry point and make sure your test window will produce a sample large enough to trust — a threshold decision on 40 clicks is noise, not signal. Our guide on statistical significance in five numbers walks through the minimum sample math a PM actually needs.
3. Weigh build cost against the bar. A cheap, low-risk feature might justify building at a modest lift over baseline; a multi-quarter engineering investment should demand a much higher, more decisive signal.
4. Set two thresholds, not one: a floor below which you kill the idea outright, and a ceiling above which you greenlight without further discovery. The zone between the two means "investigate further" — talk to clickers, run a follow-up test, don't guess.
5. Pre-register the decision in writing (a one-pager, a Slack post, a doc) so the threshold can't quietly move once the data arrives.

This same rigor — a pre-registered, falsifiable expectation before you look at the data — is exactly what separates a real experiment from a vibe check, a distinction we cover in more depth in how to write a testable product hypothesis. A fake door test without a written hypothesis and threshold is just a button with analytics attached; the discipline is what makes it an experiment.

Where Fake Doors Fit in Your Broader Experiment Stack

Fake door tests are cheap and fast, but they answer a narrow question: will people click this entry point? They don't tell you whether the eventual feature will retain usage, whether it changes a broader customer journey (see our customer journey guide for mapping where a new feature sits relative to existing friction points), or whether it holds up against a proper controlled comparison. Once you've cleared the fake-door bar and built a real version, an A/B test for your first experiment is usually the right next instrument to validate the built feature actually performs, rather than just the door to it.

Where Prodinja Fits: Mocking the Entry Point Without Writing Code

The slowest part of running a fake door test is often not the analytics — it's building a convincing-enough entry point to expose to real users. Prodinja's Wireframing composer is designed to let you mock that entry point — a button, a card, a settings row, a pricing tier — quickly, so you can validate demand before anyone touches production code. The idea is to shorten the gap between "we have a feature idea" and "we have something real users can click on," so the desirability question gets answered before feasibility work ever starts.

Key Takeaways

• A fake door test measures desirability, not feasibility — it exposes an entry point to an unbuilt feature and tracks who clicks, before any engineering investment happens.
• Honesty is structural, not optional — a graceful "coming soon" state, an honest expectation, and a lightweight follow-up ask are what separate a fake door test from a dark pattern.
• Set your click-through threshold before you look at data — pre-register a kill floor and a build ceiling so results can't be rationalized after the fact.
• Baseline and sample size matter as much as the raw click rate — compare against existing feature click-through and make sure your traffic volume can produce a trustworthy result.
• Fake doors answer one narrow question — pair them with jobs-to-be-done research, journey mapping, or a follow-up A/B test once you've cleared the bar to build.
• Tools like Prodinja's Wireframing composer can shrink the time to a convincing entry point, so the demand question gets tested before code gets written.