Why New Features Usually Flop

Launching a successful feature demands the same skills as launching a successful product. The difference is that you also have to navigate around all of your legacy decisions, and appease current customers too. It’s tricky.

The majority of new features flop. You just don’t notice it happening. And that’s the point. ‘New improvements’ sit unappreciated, unused, and are eventually cast aside. Welcome to software. Improvement is hard.

You do months of research. You pull demographics, metrics, ethnographics, analytics, psychographics, you name it. You meet with customers for days, weeks, months. You meet their parents, you feed their dogs, you feed their parent’s dogs. You do it all to understand what customers really need. Not what they say they need. Not what they think they want, or what they’re asking for. What they really need. And you go and build that!

And it still flops. This is a tough racket.

The thing is, unless customers use a feature it may as well not exist. This is often forgotten in the rush to ship fast, it’s not just about shipping code to servers, or checking boxes on a roadmap, it’s about getting your software used. So before you ship that next feature, ask yourself these questions…

1. Will everyone see and understand it?

Fun fact: when Microsoft asked their users what they wanted added to Office, they found that 90% of the requested features were already there. Microsoft assumed this was an awareness challenge, hence the launch of ribbon toolbar which highlights all features, and therefore highlights nothing. Like I said, this is tricky.

When you design the first version of a product, you want it to look complete. So you don’t necessarily plan for expansion, or leave space for future features. As you add them you make space for them, hastily, causing discoverability problems for your users. If you find yourself constantly fielding questions about where a feature is, then you have a discoverability problem and all new features will flop, or at least require lots of training to find and adopt.

2. Are you showing users what you did, or what they can do?

Telling your customers something is a “ground up rewrite”, “HTML5 based”, “responsive” or anything like that will miss the mark unless you’re selling to developers. No one cares what you did, or often even how you did it. Your customers care about what they can do.

Focus your message on what your users can now achieve with this feature and you’ll get their attention.

3. Are you announcing it in context?

New features, especially small additions, land in products without much context. Your goal should never be to “just get it launched“. The goal should be to “just get it used”. Email is the wrong medium for these announcements: it’s often overkill, and usually arrives at the wrong time and in the wrong context. The right time to promote an improvement is when someone is in your product in a position to use it.

4. How will tomorrow’s sign ups hear about it?

As a product grows, it expands beyond what’s learnable in one sitting. That’s not a problem, not every feature makes sense up front. Features are only relevant when they solve problems. Put simply you don’t need to tag files until they are uploaded. You don’t need to merge tags until you’ve got lots of different ones. So it stands to reason that telling new users how to merge tags is a badly timed message.

There’s a right time to introduce features to customers, and this is where targeted messaging matters. We promote saved replies in Intercom once a few replies have been sent. We promote keyboard shortcuts after a user has used the product long enough to care about them. This is how you make messages matter.

5. Do you plan to follow up with users & non-users?

Once a feature is live, you should follow up with those who use it to understand how, why, and when it’s used. Look for ways to increase use of it. Here’s some questions I’ve asked customers about a new feature:

• when did you notice it? what did you think? did you use it straight away? what attracted you to it?
• did you need to read the documentation? was it sufficient?
• were there any barriers to you using it?
• are there times in your work day that you want to use this but can’t?
• have you told anyone about what you use it for? what did you say?

It’s equally, if not more, important to follow up with those who don’t use it and understand what’s stopping them. Often you’ll find barriers that are easy to break down e.g. “I keep forgetting to check back on it”, “I don’t know if anyone else in the company uses it”, “I need to be able to get a CSV of the data”, etc. These are all resolvable problems once you understand them.

Your design process must acknowledge that you’ll get things wrong. So many roadmaps and sprints ignore this. Designers get things wrong all the time and when they do, they’re faced with two choices: improve it, or ignore it and jump onto the next feature. Do the latter enough times and you too will be telling the world that 90% of your feature requests were already in your app. Hope you like ribbons!

Want to read more of our product best practices? Download our free book, Intercom on Product Management. It’s recommended by folks like Ryan Singer, Hunter Walk, and Dharmesh Shah.