How to use dummy features to build out your product

Many times during product development, we face questions — “What’s the next feature that will be most valuable to our customers?” or “What feature do our customers want and don’t have?”

These questions are hard to answer and are most often dealt with by good analytics that you extract from the product itself, from customers, or by running gut-feeling A/B tests.

We take the lean startup concept very seriously and believe that you must have a good MVP (minimal viable product) that works — that is, accomplishes your goal, whether it’s conversion from free to paid or any other goal. Only then can you start adding other features requested by customers or those you think will add more value to the product.

But how will you know if those added features are worth the development time and other resources? Dummy features is one tool you can use to determine whether it is worth it to focus on and develop more features.

What’s a dummy feature? Basically, if you can’t decide what’s next, you do front-end implementations, add them to your service, and grab figures on how many customers tried to use them — in other words, slap up a fake button and see how many people push it.

Dummy features are great when you need to release your product as soon as possible.

A great example is in payment processing; it usually takes a lot of time to integrate a billing system and take payments from customers. So the first time we needed to take payments from customers, we just emulated all the billing forms and didn’t save any information or charge the users — yes, you heard correctly! We didn’t charge the users. Because at the first release of a product, what you really care about is (1) does it work? (2) do customers like it? and (3) what are the conversions? It’s well worth it to release the product faster and add the billing system later.

Another example is a dilemma we had about whether we should add an SMS notifications feature in which every time a new security vulnerability was found on a customer’s website, she’d get an SMS notification. Before we even implemented that feature, we inserted a check box with an SMS notification label and tallied how many customers checked it and wanted that feature (of course, we showed them a nice message box saying that feature would soon be available). Surprisingly, more than 60 percent wanted SMS notifications, so we implemented that feature. Now everyone is happy.

Bottom line: If you can’t decide whether or not a new feature should be added, just create the user interface, add the feature to the service, grab the analytics on how many users tried to use it, and you’ll make a more fact-based decision on what the next feature should be. In addition, dummy features can be used to shorten development times and bring the product out faster.

Yaron Tal has been working on turning ideas into marketable products for more 12 years. Currently, Tal is CTO of security company 6scan and blogs at Startup Internals, where this post originally appeared.

Top image courtesy of igor1308, Shutterstock