Product Validation: Test Demand Before You Build

Product validation is collecting evidence that an idea is worth building before most of the cost is spent. This guide covers the four things to validate, methods ordered by cost, and a worked example of a fake-door test followed by a concierge test, with pass thresholds written down before either started.

What product validation is

Product validation is gathering evidence that something is worth building before building most of it. It answers four questions, in order:

1. Problem: do enough people have this problem, often enough, to care?
2. Demand: will they take an action to get a solution: click, sign up, pay, give time?
3. Solution: does your approach actually solve it in a way they can use?
4. Value: do they keep using it after the novelty wears off?

Each step is cheaper than the next. A "no" early saves the cost of everything after it.

Validation methods by cost

The table below lists common methods, what each validates, rough cost and the signal to look for.

Move to the next row only when the current one passes its threshold.

A worked example: scheduled reports

A team wants to build "scheduled reports": email a saved report every Monday. Interviews suggested people copy numbers into emails by hand. Before building, they set thresholds (sample numbers throughout):

• Fake door: at least 5% of accounts that see the button click it.
• Concierge: at least 50% of the manual group still open the emails in week 4.

Step 1, fake door (one week). A "Schedule this report" button appears on report pages for 3,000 weekly active accounts. Clicking shows: "Scheduled reports are coming. Want early access?"

• 240 accounts clicked (8%), above the 5% threshold
• 90 joined the waitlist
• 12 short interviews: 10 described a weekly manual routine

Step 2, concierge (four weeks). For 30 waitlist accounts, a team member sends the report by hand every Monday. Week 4: 22 of 30 (73%) still open it, above the 50% threshold. Five asked for a second recipient, which goes into the first version.

Decision: build a minimal version (weekly, one report, up to three recipients), then check weekly retention of the feature after launch.

Running fake doors honestly

• Say clearly that the feature is not available yet; never take payment for something that does not exist.
• Show it to a limited share of users, for a limited time.
• Follow up with everyone on the waitlist, whatever you decide.

Common mistakes

• Asking instead of observing. "Would you use this?" gets polite yeses. Clicks, sign-ups and repeat use are evidence.
• No threshold in advance. Without one, any result can be read as success.
• Validating with the wrong people. Test with the segment you are building for; see user persona.
• Skipping the value step. Early excitement fades; retention after a few weeks is the real test. See product-market fit metrics.

Measuring it in TapCub

• Fake door clicks: send an event such as "schedule_report_click" with the report type as a property; count unique accounts in All-platform analytics › Behavior › Behavior analysis and divide by accounts that viewed report pages.
• Waitlist: a goal on the waitlist form submission in Web analytics › Goals, or an event in the product.
• Value after launch: the retention model in the same Behavior analysis page, with "used scheduled report" as the start and return event, shows whether accounts keep using it week after week.
• Who: compare segments in All-platform analytics › Users › Segments & tags to see whether the target persona responds more than others.

For the earlier step of choosing what to test, see product discovery and the glossary entry on the minimum viable product.

See also: Dogfooding.

See also: Product hypothesis.

See also: What is a painted door test? How to run a fake door test.