7 Common Triggers of Feature Creep and How to Resist Them

Extending software functionality sounds like something well-meaning and even natural – especially if we’re talking about minimum viable products that are expected to gain new features over time and eventually turn into not-so-minimum viable products. The catch here is in telling when product evolution morphs into feature creep – endless addition of new functionality to software.

This article helps you to recognize the feature-adding triggers that often lead to feature creep and gives hands-on tips on how to abstain from unreasonable feature breeding in your software product.

But first:

Can a feature really ruin a product?

With our 30 years of experience in outsourced software product development, we know that the risks of succumbing to feature creep in product evolution projects are high. Unlike product evolution that helps your product meet more of the users’ newly arising needs and solve more of their relevant problems, feature creep makes your product difficult or almost impossible to use. The worst-case scenario that puts your product in imminent danger is when your audience becomes so overwhelmed with all the features that they are unable to perform your software's primary function.

For example, what once was a widely loved music player, iTunes is now popularly referred to as “software update utility that can also play media”. Apple itself acknowledged that due to adding such features as cloud syncing, podcast and TV streaming, as well as app and book stores, iTunes got bloated. After pulling a joke about including a calendar and mail in iTunes’ core functionality, Apple announced that software would be discontinued and replaced with 3 different apps.

Large companies with mainstream product lines can usually get away with such setbacks: after all, most people still continued (and would’ve continued) to use iTunes because of being tied to Apple’s products. For smaller companies and less popular products, taking a wrong direction with the functionality update strategy can be deadly.

Recognizing and resisting feature creep triggers

By treating the addition of any new feature lightly, you can end up with a failed product and eventually lose your audience. To know when you should resist the urge to add a new feature, you need to understand the real motives for development that often differ from the reasons you think you have.

Below we list 7 most common and risky triggers for extending software functionality and help you analyze each of them.

1. You believe this feature will help you ‘strike it rich’

Whether your product has met or betrayed your expectations once it hit the market, you always believe that it deserves and can achieve bigger success. Such ambitions are perfectly valid and keep you in the business of evolving and growing your product. However, by giving in to a desperate longing for success, you may shift away from your original goals and start making wrong decisions.

Instead of taking any feature idea for the chance to turn your product into a sensation, try to remain realistic and always think back to your software’s functional core. This is what your product is about and what makes it worthy of success. Can this new feature that you want to add improve your core functionality? If yes – go for it. But if you want to integrate Facebook messenger into your sophisticated employee training software solution, hoping that both the brand and some social media flavor, in general, will give it a boost, you might want to reconsider.

2. A competitor product has this feature

Comparing yourself to competitors is useful for feature prioritization and can be a good source of insight. However, the sole fact that a competitor has a feature your product lacks isn’t a reason enough for implementing it, because your product and your audience may not need it at all.

For instance, if your document management software targets small businesses, implementing a feature for a complex approval workflow just because a competitor (who serves both large and small businesses) has it may not be the best choice. First of all, this feature won’t be used by your current audience, so your investments on building it won’t be returned. Secondly, its sole inclusion in the interface can break existing UX patterns of your users and create unnecessary frustrations.

And finally, such an update blurs the line of your product positioning on the market: do you still want to continue serving small businesses, plan to appeal to larger ones too or are willing to completely refocus on bigger customers in the long run? It’s okay to shift your targeting, but such a decision shouldn’t be a blind step in a race for competitors’ success.

To consider including the feature of your competitor to your backlog, make sure it’s needed by the user base of your product, stays in line with your product vision, and justifies the investment.

3. You feel obliged to improve your product by adding something new

Usually, this reason begets the ‘updates for the sake of the updates’ process, which never proves to be useful. When ‘something new’ doesn’t offer any other value besides being new, you risk creating a feature that your users will find irritating or hindering.

A good example of an unnecessary software improvement is social media’s evolution of timelines. Since Facebook, Instagram, and Twitter all introduced the default ‘popular first’ post sorting, in-between ads, and intrusive content suggestions, people have been frustrated with broken timelines and being unable to see the content they want to see.

The irony is that all 3 social media platforms have other well-known issues to resolve but for some reason chose to funnel their efforts in a completely different direction. ‘Improvement’ doesn’t have to equal ‘innovation’. You can improve your product by fixing existing bugs or enhancing performance and stability. There is always room for security growth, too. So, instead of investing effort in implementing a new feature that can impede your user experience, use the maturity of your product’s functionality to invest in the growth of its quality.

4. The feature is cheap to develop

You may see no reason not to develop a feature if it doesn’t cost you much, thinking that such effortless update can’t harm. Unfortunately, the reality is that you don’t have to invest much into ruining a product. Beware of any ‘cheap’ and ‘quick’ initiatives: a swiftly implemented feature is often either poorly implemented or entirely useless. And in both cases, the result of your development is an inconvenience for your users that can eventually disrupt their trust and loyalty. ‘Moments’ wasn’t a costly feature for Skype to implement, but it caused a lot of disappointments with UI and made many users move to Discord.

5. Users suggested this feature

A certain wished feature could’ve surfaced in your clients’ suggestions once and then appeared again and again until you paid attention to it and considered adding it to your backlog. Customer requests can indeed be a reasonable motive for implementing new functionality. However, take some time to look at the data from application performance monitoring tools, user comments and satisfaction surveys entries first – and then ask yourself two important questions:

1. How many users have requested the feature exactly? If it’s already a significantly large part of your audience (~60-70%), there’s room for considering development. If it’s “10 people throughout this month alone” – wait for it. The tendency may look definite, but you need more time to observe and understand it. In the long run, the suggestion may indeed turn out to be critical for most of your product’s users or end up just a temporary whim of the few.

2. Are the customers, who requested the feature, your current customers? If yes (and if they belong to the core of your audience) – you may seriously consider adding the feature to the backlog. If not, the reason you’ve paid attention to this feature is probably several customers who chose to abandon your product and listed it as one of the reasons for their leave.

Even though it may look like an emergency, analyze the data to understand what part of your audience these users belonged to. You may also want to reach out to your current users via targeted email surveys to learn their attitude to the suggested feature. It may turn out that this feature isn’t crucial for your existing users at all, and they are quite content with your product as it is.

Appreciating user input and respecting the needs and wishes of all customers is important, but implementing each and every requested feature is exactly what creates messy, shapeless bloatware. Remember that your product can’t be a good thing for everyone and that in the end, you are the one with the product vision and in control of its growth.

6. Your coworker or an executive suggested the feature

Your colleagues can indeed offer insightful and enlightening ideas. But if you ask yourself about the reason to implement a suggested feature and the first answer that comes to your mind is the name of this section – the idea wasn’t so insightful after all. Unless you see real value and obvious advantages of implementation in the prompted feature, sincerely thank whomever the suggestion came from and politely decline.

7. This feature can be optional

Stop right there: do you want to develop a feature that you believe your user base may find unnecessary or even hindering? Are you willing to invest in the implementation of a feature that you’re already planning to make invisible by default? If you consciously admit that a feature is not necessary both according to your audience and your own product vision, even considering its development isn’t worth it.

On a final note

As a product manager, you always need to have an honest conversation about software functionality with yourself and the product team, asking the right questions about your users, your product, and its future. Avoiding feature creep isn’t always about ‘saying no’. Rather, it’s about taking a stand and supporting each of your functionality-related decisions with sound and meaningful motivations.