This is the first part of our series on how companies can use Fake Door Tests to validate and prioritize feature ideas.

A fake door test or In-Product Concept Testing is a product research method that is used to validate whether or not a user has actual intent for using an idea.

Company

Name: Mondoo (https://mondoo.com)

What they do: Security audit of infrastructure as code scripts against a policy you specify.

Mondoo is rolling out their integrations page and would like to prioritize and validate which specific integration to build next.

This is what their default page looks like:

Find out what users want

Mondoo will start with a few guesses based on what their initial customer discovery will hint at, such as Kubernetes or AWS.

To figure out what users want, we need to pull it from them by asking questions through talking or microsurveys.

At the bottom of this integrations page, will be a prompt to ask the user what integration they want.

Feedback management practices kick in, survey responses are analyzed, and the user is contacted to learn more about their use case.

But this is just observational evidence, nothing is empirical. Building from this evidence alone is high risk as users may say one thing and do another thing.

Check if they really want it with a Fake Door Test

Only working software in the hands of users is a higher form of evidence than fake doors.

Based on the previous signal that customers are asking for Azure, a fake azure integration button can be placed in the product. When the user clicks the button, a microsurvey would pop up asking more questions on why they want that feature.

Using a tool like Samelogic, this is just a simple copy, paste, and modifying of the HTML, without the need of an engineer since the SDK runs after the website has been deployed.

Statistical significance does not matter at this stage and in the context of gathering intent. So Mondoo can leave this research running for many weeks until they feel satisfied with the funnel and survey responses.

This funnel would look like the following:

The core metric to pay attention to is the "Click" event. That is our primary endpoint of measurement.

Samelogic can pull back the identity of the user who interacted with the fake door and this information can be piped back into their CDP (Customer Data Platform), such as Amplitude for further analysis.

Making Decisions

Every company is different and every Product Manager within the company is also different. They have to use the tools or framework of choice for their specific use case.

Using Fake Door Tests for validating what integrations to build can save companies weeks if not months of engineering hours and cost of maintaining things that users are not using.

The idea is to fail fast, if nobody clicks it, don't build it. But if they do interact with it, investigate it further, but now you know you have strong evidence and not wasting your time.