{"id":3915,"date":"2014-01-13T01:37:03","date_gmt":"2014-01-13T01:37:03","guid":{"rendered":"http:\/\/insideintercom.io\/?p=3915"},"modified":"2020-07-30T13:03:58","modified_gmt":"2020-07-30T12:03:58","slug":"new-features-usually-flop","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/new-features-usually-flop\/","title":{"rendered":"Why New Features Usually Flop"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

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<\/em> 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!<\/p>\n

And it still flops. This is a tough racket.<\/p>\n

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…<\/p>\n

1. Will everyone see and understand it?<\/h3>\n
\"\"<\/div>\n

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<\/a> which highlights all features, and therefore highlights nothing. Like I said, this is tricky.<\/p>\n

When you design the first version of a product, you want it to look complete. So you don’t necessarily\u00a0plan 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<\/a> and all new features will flop, or at least require lots of training to find and adopt.<\/p>\n

2. Are you showing users what you did, or what they can do?<\/h3>\n
\"\"<\/div>\n

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.<\/p>\n

\"\"<\/div>\n

Focus your message on what your users can now achieve with this feature and you’ll get their attention.<\/p>\n

3. Are you announcing it in context?<\/h3>\n
\"\"<\/div>\n

New features, especially small additions, land in products without much context. Your goal should never be to “just get it launched<\/em>“. 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.<\/p>\n

4. How will tomorrow’s sign ups hear about it?<\/h3>\n
\"\"<\/div>\n

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.<\/p>\n

There’s a right time to introduce features to customers<\/a>, 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.<\/p>\n

5. Do you plan to follow up with users & non-users?<\/h3>\n
\"\"<\/div>\n

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:<\/p>\n