Customer discovery

Fake door test: how to run one without losing your users' trust

How to run a fake door (painted door) test: set the hypothesis and threshold first, design the door and the reveal, size the test, read the clicks and protect user trust.

Instant Expert EditorialPublished 7 min read

A fake door test, also called a painted door test, puts an entry point to a product or feature that does not exist yet in front of real users, and counts how many try to use it. The door can be a button, a menu item, a pricing option, a landing page or an ad. Anyone who clicks learns that it is not available yet. Optimizely's glossary describes the method as advertising a feature before it exists to gauge demand (Optimizely), and a pretotyping quick reference from Alberto Savoia's Pretotype Labs lists the Fake Door as a way to measure initial interest by creating artifacts that suggest a product exists and is available (Pretotyping quick reference).

A fake door measures something interviews cannot: whether people act when the option looks real. It also costs the people who click something, because they expected a working feature and did not get one. A fair test keeps that cost small, tells people the truth straight away and never takes money for something that does not exist.

When a fake door test fits

It fits when:

  • Interviews or a concept test have already shown the problem is real and the idea makes sense to buyers; market validation covers that step.
  • Enough people pass the spot where the door would go for the numbers to mean something.
  • Your question is whether people will choose this option, at this point in their work.

It fits poorly when:

  • The door would sit in a critical task, such as running payroll or changing security settings, where a dead end causes real harm or worry.
  • Your users are a few dozen enterprise accounts. The numbers are too small to read and every disappointed admin matters. Interview them instead.
  • You are tempted to collect payment for the missing feature.

If the request came from a customer, how to test a feature request covers other ways to check it before building.

A worked example

This example is hypothetical. A company sells property management software to small landlords. Several customers have asked for help finding repair contractors. Before building a vendor marketplace, the team puts a button labeled "Find a vendor for this repair" on the maintenance request page, shown to a random half of landlords for 30 days.

Clicking the button opens a short message: "We're thinking about building this and haven't yet. Thanks for clicking. It helps us decide. What were you hoping it would do?" Below that is a one-line answer box and a checkbox to hear if it launches.

Write the hypothesis and threshold first

Savoia's pretotyping method suggests writing a market engagement hypothesis in the form "X% of Y will do Z" before you test (Pretotyping.org). In the example: "At least 5% of landlords who open a maintenance request in the next 30 days will click Find a vendor."

Pick the number by asking what level of interest would justify building the feature, and write it down before the test starts so you cannot move it afterward. Optimizely makes a similar point: know before you start what a positive, negative and neutral result would look like.

Design the door and the reveal

The door should look and sit like a real option. Put it where the need arises, give it the same visual weight as the buttons around it, and avoid a flashing "New" badge, which draws curious clicks that say little about demand.

The reveal should be immediate and plain. Say that the feature does not exist yet and that you are considering it. Offer something useful in return for the click:

  • A one-question follow-up: "What were you hoping it would do?"
  • An opt-in to hear if you build it.
  • A workaround, if one exists.

Savoia's quick reference shows the spirit of this with a restaurant example: if someone orders a dish that is not actually available, tell them, apologize and offer them something else for free. In software, the equivalent is a clear apology and, where it makes sense, a small credit or a workaround.

Ads and landing pages need extra care. Google Ads' misrepresentation policy does not allow ads that promise products or offers that are unavailable or cannot easily be found from the destination (Google Ads). For a landing-page test, describe the product as coming soon and ask people to join a waitlist; do not say "Buy now" for something you cannot sell. Do not collect card details on a pretend checkout. If you do take pre-orders, rules such as the FTC's Mail Order Rule may apply; market validation summarizes it.

Size and run the test

Decide in advance how many people should see the door, and do not stop early because the numbers look good. Evan Miller shows that checking results repeatedly and stopping at the first significant-looking difference inflates false positives (Evan Miller).

A rough way to think about size is the margin of error on the click rate. By the standard normal approximation, if 1,000 people see the door and 40 click (4%), the 95% margin of error is about plus or minus 1.2 percentage points. With 200 viewers it is about plus or minus 2.7 points, too wide to tell 4% from 2%. These figures are our calculation.

Two more rules keep the test fair. Show the door to a random share of users, for a fixed period, and then remove it. And compare the click rate with a familiar option on the same page, so you can tell interest in this feature from general clicking.

Read the results fairly

In the example, 1,800 landlords saw the button and 117 clicked: 6.5%, with a margin of error of about plus or minus 1.1 points, so the range runs from about 5.4% to 7.6%. That clears the 5% threshold.

A click is still a small commitment. It can overstate demand when the placement is unusually prominent or the label promises more than you would build, and understate it when the label is unclear or easy to miss. Read the follow-up answers before deciding anything. If most landlords who clicked wanted contractor phone numbers, a simple directory may serve them; if they wanted to book and pay a contractor inside the product, that is a much bigger build.

Then look for stronger evidence. Savoia's quick reference describes asking interested people for a deposit to join a waiting list, and a paid pilot plays the same role for business software. Interview five landlords who clicked about what they expected and what they do today.

Protect your users' trust

  • Tell people immediately. No fake loading screen and no pretend error message.
  • Keep doors out of critical workflows.
  • Limit exposure to a share of users and a fixed period, then remove the door.
  • Never charge for the missing feature or collect payment details.
  • Follow up with everyone who opted in, including if you decide not to build it.
  • Avoid repeating fake doors on the same users; each one spends some of their trust.

Some teams prefer an openly labeled version: a "Coming soon, tell us if you want this" option or a waitlist. It measures a softer signal, but nobody is surprised by a dead end. Either approach is reasonable, as long as you choose deliberately.

Your next step

Write your hypothesis in the form "X% of Y will do Z," the place the door will go and the reveal message, before anyone builds the button. Then plan five interviews with people who click.

If you want to hear from people in the market who are not yet your users, Instant Expert can find people who match a description such as "property managers who handle maintenance for 20 to 200 rental units." You review who it finds, it sends your invitations and you pay for each call that gets booked. The directory pages for property management consultants and product professionals in property management are one place to start.