What needs to be finished first
The demand hypothesis to be tested is explicitly documented and linked to a measurable success threshold.
What needs to be ready before start
Visible entry point (menu item, button, card) in an existing product or marketing surface; tracking setup (analytics event); explanatory page or modal after click; definition of success.
A Product Manager who sets the hypothesis and threshold; an engineer for tracking and explanatory page; an analyst for interpretation; a customer support owner for incoming questions.
Demand hypothesis as one sentence; target signal (for example, at least 5% click-through at 10,000 impressions); legal and ethical review (GDPR, consumer protection); plan for informing people who clicked.
1-5 days runtime, plus 1-2 days setup
Place the entry point in the live product. Click leads to a transparent explanatory page ("This feature is still being developed, we are collecting interest"). Implement and test tracking events.
The one question this method answers
Does the measured demand at the fake-door entry clearly confirm the demand hypothesis above the predefined success threshold?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Hypothesis and threshold | Setup, 2-4 h | Formulate hypothesis ("At least 5% of active users in solo tax advisor dashboard click a new menu item 'Client switch service' within 5 days"). Write threshold and evaluation window up front. | Do not define the threshold only after the test. Otherwise every outcome can be rationalized. |
2Phase 2: Build fake door | Setup, 4-8 h | Place entry point with clear label. Prepare explanatory page that appears after click and manages expectations. Implement and test tracking events. | The explanatory page is not optional. If users land in uncertainty, this is deceptive behavior and trust is damaged. |
3Phase 3: Go live and observe | Run, 1-5 days | Launch test live and distribute traffic. Check tracking daily. Collect support questions. Intervene immediately if anomalies occur (technical error, unclear wording). | Very high click rates can indicate confusing wording rather than demand. Cross-check with time on explanatory page. |
4Phase 4: Synthesize and learning decision | Synthesis, 2-4 h | Compare tracking data with threshold. Include support questions and explanatory-page behavior in interpretation. Document the learning decision: build, build differently, or drop. | Clear failure to reach threshold is also learning. Treating this as failure misunderstands the method. |
What comes out at the end
Markdown experiment report with hypothesis, threshold, setup description, tracking data (impressions, clicks, click-through, time on page), support request sample, learning decision, and follow-up experiments.
One entry per experiment with date and hypothesis. Link prior experiments. Record learning decision as status in header (Build/Pivot/Kill).
Short plan for hypothesis, test design, success criteria, and decision.
We believe that ...
Who are we testing for?
What exactly will participants or users do?
We count the test as positive if ...
What can the test not prove?
If positive: ... If negative: ...
...
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Hypothesis: At least 4% of active solo tax advisors click a new menu item "Tenant Switch Service" within 5 days.
Setup: Menu item added in sidebar between "Clients" and "Reports". Explanatory page with text: "We are building this offer right now, leave your email if you want to be informed first" plus micro-survey "What would be important to you?".
Results:
Learning decision: Build. At least 142 qualified leads. Next experiment: Concierge MVP with 5 of these leads from 2026-05-25. Owner: @anna.
Recognize symptoms and steer against them
Clicking users arrive at nothing or see an error page, and trust drops.
An explanatory page is mandatory. It must clearly state that the feature is planned. Optional email capture should be transparent.
Very high click rate but short time on explanatory page. Users expected something else.
Validate wording with 2-3 users beforehand. If language is misleading, pause test and clarify text.
Result is just below threshold, team shifts threshold.
Fix threshold before test and record it in report header. Changes are allowed only in follow-up experiment, not retroactively.
Fake door promises something that would trigger regulatory constraints in production (health, finance).
Run legal and compliance review before each fake-door in regulated areas. In doubt, run a different experiment.
Data evaluated after 24 hours, weekly pattern not covered.
At least 3-5 days to smooth weekly variance. Run longer with low traffic.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.