Fake-Door and Concept Testing Without Eroding Customer Trust

The case for testing before building is straightforward: it is cheaper to discover that users do not want a feature from a fake-door test than from six months of engineering investment. The logic is sound. The execution is where most teams go wrong — not because the methods are technically flawed, but because they are deployed without honest follow-up, and the customers who participated notice.

Customer trust is a finite resource. Every product interaction draws on it or deposits into it. A fake-door test that leaves users confused, deceived, or never followed up with makes a withdrawal. Enough of those withdrawals and the research relationship is damaged: users stop clicking, stop responding to surveys, stop engaging with discovery requests. The team that burned trust with poorly designed validation tests is the same team that struggles to recruit customer interview participants six months later.

Teresa Torres, in Continuous Discovery Habits, emphasizes that the relationship with customers is the research infrastructure. It must be actively maintained. The methods in this post are designed to generate valid demand signal while preserving — and ideally strengthening — the customer relationship that makes future research possible.

Understanding What Fake-Door Tests Actually Measure

A fake-door test measures one specific thing: the proportion of users who are motivated enough, when confronted with a feature entry point in their normal workflow, to take an action that implies interest. This is a behavioral signal, not a preference signal. It answers "how many users will click?" not "how many users will value this if we build it?"

This distinction matters for interpretation. A low click-through rate on a fake-door test can mean:

1. The feature is not in demand (demand problem)
2. The feature entry point was positioned in a low-traffic area (placement problem)
3. The copy describing the feature was unclear (communication problem)
4. The users who were exposed to the test are not the target segment (targeting problem)

A high click-through rate can mean:

1. The feature is in genuine demand (the conclusion the team wants to reach)
2. The entry point copy was unusually compelling regardless of actual interest (copy quality problem)
3. The users who clicked are curious explorers who click everything (segment problem)

These confounds are why fake-door tests work best when combined with at least one other validation method. A high click-through rate followed by a concept test that reveals genuine enthusiasm is strong signal. A high click-through rate followed by concept test participants who struggle to articulate why the feature would be valuable is a warning.

The Pendo 2023 Digital Adoption benchmarks found that feature demand signals from behavioral tests (fake-door, clickable prototypes) overestimated actual post-launch adoption by an average of 22% compared to teams that combined behavioral and qualitative methods. The combination is more accurate than either method alone.

Designing a Fake-Door Test That Does Not Break Trust

The ethical design of a fake-door test depends on four decisions:

Decision 1: Where to place the entry point. The entry point should be placed where the feature would naturally live if it existed — not in a location chosen to maximize clicks. A fake button in the primary navigation of a product with high daily engagement will generate more clicks than the same button in a settings sub-menu, but the traffic from the navigation button is less informative: it includes users exploring the interface, not users specifically looking for the capability.

The most valid placement is inside a workflow where the feature would naturally appear. If testing demand for an in-product collaboration feature, place the fake-door at the point in a workflow where collaboration would be useful — not on a marketing page.

Decision 2: What the landing experience says. The landing experience is where trust is made or broken. The minimum ethical requirement is immediate transparency: the user who clicked must know, on the page that loads, that (a) the feature is not yet available, (b) this was an intentional test of interest, and (c) their click has been noted and they will hear more.

A template that works:

"This feature isn't available yet — but you're helping us decide whether to build it. We're testing how many people are interested in [brief feature description]. If we get enough interest, we'll build it. Want to know when it's ready? Leave your email and we'll let you know first."

This message is honest, explains the research intent, and offers a reciprocal value exchange (early access notification). Users who understand what happened are not frustrated — they are more likely to leave their email and more likely to trust the product team.

Decision 3: What you do with the interest data. If users leave their email, you have made a commitment. You must follow up. The follow-up does not need to announce a launched feature — it can communicate a decision that the team made and why. "We tested interest in [feature] and got 143 sign-ups. We've decided to build it — here's a rough timeline." Or: "We tested interest in [feature] and got 23 sign-ups. We've decided to prioritize other features first, but this is on our radar — thank you for helping us learn."

Teams that collect interest data and never follow up are breaking an implicit promise. That is where trust erodes — not in the act of running the test, but in the silence that follows.

Decision 4: How long to run the test. Fake-door tests should have a defined duration before they launch — typically 14 to 28 days. Leaving a fake-door in place indefinitely accumulates clicks from users who should be seeing a real feature, or creates confusion when new users encounter it months after it was launched. After the test duration, either remove the entry point or replace it with a "coming soon" message if the team has decided to build.

Concept Testing Methods by Research Goal

Concept testing covers a range of methods, and choosing the right one depends on what the team needs to learn.

Exploratory concept interviews: Show a mockup or a brief written description of a feature concept to a customer in a discovery interview. The interviewer asks open-ended questions: "What do you see here? How does this relate to problems you face? What questions does this raise for you?" The goal is to understand the customer's mental model, not to get a thumbs-up or thumbs-down.

This method is most useful in early discovery, when the feature concept is loose and the team is more interested in shaping the solution than validating it. It pairs naturally with the continuous discovery interview cadence — concept testing can be added to the second half of an existing interview rather than requiring a separate recruitment.

Survey-based concept testing: Present a written or visual concept to a larger group of users via an in-app survey or email. Ask two to three structured questions: "How clearly does this describe something you need? How likely would you be to use this if it were available? What's the main thing that would or wouldn't make it useful?"

Survey-based concept testing reaches more users than interview-based, but produces shallower data. It is most useful for distinguishing between two or three competing concepts when the team needs directional feedback at scale.

Clickable prototype testing: Create a non-functional prototype (using tools like Figma or Framer) and conduct moderated sessions where users attempt to complete tasks using the prototype. This generates both behavioral data (where did users get stuck?) and qualitative data (what did they expect to happen?).

Clickable prototype testing is the most resource-intensive method but produces the richest insight. It is most appropriate for high-complexity features with multiple interaction patterns, where fake-door tests and written concepts would not capture usability issues.

Integrating Concept Testing Into the Discovery Workflow

For teams practicing continuous discovery, concept testing fits into the regular interview cadence rather than requiring dedicated research sprints. The integration works when concept testing is treated as an optional add-on to existing interviews, not as a separate research initiative.

The workflow: in each weekly interview, the PM identifies whether there is a concept that needs validation in the coming sprint. If yes, a mockup or written description is prepared before the interview. In the last 10 minutes of the interview, after the retrospective exploration is complete, the PM introduces the concept: "I want to show you something we're thinking about and get your reaction. This is a rough idea, not a finished design — I'm more interested in what questions it raises for you than in whether you like the visual."

This framing — explicitly not asking for approval, explicitly inviting questions and confusion — produces more honest feedback than presenting a polished mockup and asking "would you use this?"

For teams using an Opportunity-Solution Tree, concept testing maps to the solution candidate validation step: each solution candidate at Level 4 of the tree should be concept-tested with at least three customers before it is promoted to the development backlog.

The connection between concept testing and customer interview synthesis is direct: concept test reactions — both positive and negative — should be captured as evidence items in the pattern library, tagged with the solution candidate they relate to.

Measuring Concept Test Quality

A concept test that produces only positive reactions is not necessarily a good concept test. It may be a concept test with inadequate probing, a concept that was presented to already-enthusiastic customers, or a concept that customers feel social pressure to endorse.

The signal quality checklist for a concept test:

• Did at least one participant express genuine skepticism without prompting?
• Did participants use language that was meaningfully different from the language in the concept description? (If they merely echo the words in the mockup, they have not internalized the concept.)
• Did at least two participants raise questions that the team had not anticipated?
• Did participants describe a specific use case from their own experience, rather than a hypothetical one?

If the answer to all four questions is yes, the concept test generated genuine signal. If the answer to most is no, the test protocol should be redesigned before the next round — the most common fix is removing any language from the concept that implies how it should be used, and presenting it as an object to react to rather than a solution to approve.

Conclusion

Fake-door tests and concept testing are not shortcuts that replace real customer understanding — they are structured demand signals that reduce the cost of being wrong about what to build next. The teams that use them effectively treat the customer relationship as an asset to invest in, not a sample to extract from. Honest follow-up, clear communication about research intent, and genuine curiosity about the customer's reaction (rather than hunting for validation) are what distinguish research practices that compound over time from ones that burn out after three months.

SaasDash's concept testing module provides in-app survey templates calibrated for concept validation, a fake-door test setup wizard with pre-written follow-up messaging, and an interest list management system that ensures no participant goes uncontacted after expressing interest. If your team has been avoiding demand testing because the ethical mechanics felt unclear, the setup guide walks through every decision point.