A modern browser is required for security, reliability, and performance. Contact us.

Sep 02 2013

Try This Simple Hack To Test New Features Before You Build Them


(Photo Credit: Randomdam)

He decided to test various covers by printing them on high quality paper and placing them on existing similar sized books in the new non-fiction rack at Borders, Palo Alto. He sat with a coffee and observed, learning which cover really was most appealing.

Matt Linderman, on how Tim Ferriss A/B tested book covers for The Four Hour Workweek.

When it comes to building products, winners are beholden to one thing: whatever works best.

That means a devotion to constant iteration and improvement by studying how users interact with your product, and testing enhancements to make their experience better.

But what happens when you want to test something — say, a new feature — but can’t swing the additional development hours to build it?

This is where a lot of developers turn to surveys. This is also where a lot of developers go wrong.

Surveys are great for many things, especially for finding out what users love, hate and want. But surveys are terrible for finding out how a user will act. Only a true test, within the context of your actual user experience (that is, not within the user experience of a SurveyMonkey form), can tell you that.

So what’s a developer to do?

The Button To Nowhere

The solution is so simple that it’s almost funny, but the results are very real.

Design a simple button that will take users to your new feature. Savvy developers will test a couple of different designs.


Drop this button into your app, wherever you would put it if you had actually built the feature.

You can address the functionality of the button with a simple solution:


Users who click on the button are greeted with a message letting them know that the feature they’re looking for is currently under construction.

On Ethics

“Nick,” you might say. “Isn’t this lying to my users? I can’t undermine their trust like that!”

I understand and deeply empathize with this reaction. Our users put a lot of trust in us, and we have an obligation to uphold that trust. To do right by our users.

But doing right by our users is what this tactic is all about.

We all want to make the best product possible, and maximize value for the people who trade their time and money for the chance to use that product. That’s our biggest responsibility.

What the Button To Nowhere does is give us — developers — the flexibility to make the most of our limited time and resources and identify which pursuits we should be focusing on. I’d much rather build features that are already in demand than spend weeks or months building features that will never get clicked on.

And what the Button To Nowhere gives our users, ultimately, is the product that they need, with features that they’ll actually want to use.

What do you think?

Have you tried your own Button To Nowhere? If not, would you? And if you wouldn’t why not? I’d love to have an open and honest discussion about the merits — and morality — of this approach.

Either way, one thing is certain — the Button To Nowhere has worked for us, leading to real, fully-developed features that thousands of users love.

(This post was originally published on Medium).

Nick Kishfy