How I Measure Feature Engagement Before Building Anything
A Red Door Test allows you to gather quantitative validation data about a feature and its usage before you even build it out.
I wanted to put this together quickly to share my thoughts on how to use Red Door Tests, what they are, and a unique approach that can help you overcome stakeholder objections.
This was originally a video; check it out here → https://youtube.com/watch?v=EqcHh1PwOyU
Now, the important thing to keep in mind is that you must do proper discovery first. You need to validate that you have a problem worth solving and a solution worth building; this is an extra feather in the cap of figuring out that solution worth building.
You’ve already talked to your users, your six to eight customer interviews, you’ve understood the problem space, you’ve validated the solution space, and now you want to add a quantitative layer to go; “okay, on top of the six to eight customers, what about these other users that are already within our platform?”
This is a powerful tool if you’ve got a big enough user base to get some signal out of that data. If you’re in the early stages, you’ve got 10–20 users, you might as well talk to all 10 or 20 users anyway.
Rather than building out a whole room, You’re just gonna install the door.
It’s gonna be a red door, and you’re gonna keep track of how many people and who knock at that door, cuz that’s gonna signal that they want to go into the room. So in the case of a product, what that’s gonna be is you’re gonna put the call to action, the menu item, the button right there in the platform as if the feature was fully built out, and then you’re gonna see who clicks it.
There are two things you wanna keep in mind here. One is you’re exposing yourself to the bias of how good is the user experience of that call to action. If you’ve got that call to action, poorly labeled, buried away somewhere, then you’re not gonna get a very good read or a very good signal about the quality of the solution. You don’t wanna let that throw you off.
Make sure you do a good job of thinking through where you wanna put it within the platform, and keep that consideration in mind when you’re evaluating.
The second thing you want to keep in mind is to provide context to your users.
Don’t put a button in there that breaks and goes nowhere. You wanna give them that message and say: Hey, this feature is coming soon. We haven’t built it yet, and we’ll make sure that we let you know when it’s released. And maybe even here’s an email address to send us feedback and thoughts. That’s a red-door test.
Now the extra pro tip that I wanna share is there’s another cool way to use this technique in reverse. What you’re going to do is, rather than going through all the work of removing a feature, you remove the door.
So if you’ve got a part of your product that you’re thinking about decommissioning, What about you? Just take away the button. Much, much easier. It’s just a small CSS change. The button’s not there anymore, and see if people complain. This works well when there are multiple ways of doing things.
You’ve got different routes and ways to achieve a given task, and one of them gets used way less and clutters up the experience. You want to rip that out and see if anybody complains. It’s a really easy way to test things out, and it’s a really good way to settle a debate with different stakeholders about whether something is a good idea or not.
Let’s test out just taking its instant to reverse. We revert the PR, and away we go.
Reverse red door test, Red door tests. These are really helpful tools when it comes to the latest stages of validating you’ve got a solution worth building. Try them out. I hope it’s useful.
This was originally a video; check it out here → https://youtube.com/watch?v=EqcHh1PwOyU
