Feature Creep Is a Problem. Learn How to Avoid It

Too much of a good thing will often turn out to be a bad thing, harmful even. Take salt, for instance. Food without salt is tasteless and boring to eat. On the other hand, adding too much salt will turn good food into terrible food. The same thing happens in software development. Great software features enable users to be successful and accomplish their goals. Without any useful features, a software product is dead. But if a software product becomes hard to use because it has too many features, then it suffers from feature creep.

In this article we’ll explore how to identify and avoid feature creep so it doesn’t surprise and overwhelm your development team.

What Is a Software Feature?

We create software to solve real problems. Conversely, we solve real problems by using the features of our software. When our software allows users to complete a concrete task for their business, it’s providing a feature. In other words, anything our software does is considered a feature. And the totality of features in our product makes up its feature set. But if our software doesn’t have any features, well… that means it doesn’t do anything useful and probably shouldn’t exist.

Any software product is defined by its feature set. Take Microsoft Word. One of its main features enables users to type and print a business letter. Other features allow you to choose different fonts and insert headers and footers. All of these features make up Word’s feature set. You get the point. If you have features, then you may have a product; but if you don’t have features, then you really don’t have a product.

What Is Feature Creep?

Now that we know what a software feature is, let’s take a look at how a software product evolves. Software begins small, which means it starts out with a small feature set—usually a main idea that gets implemented as the initial feature set. The first version of a software product helps a specific group of users accomplish one or maybe a few tasks. It solves a specific problem well. If this product has success and its users like using it, they’ll probably request new features that would help them even more.

At first these improvements make sense because they represent refinements of the main idea or feature set. So you keep implementing them into your software product. However, as the product matures, there comes a point when some features make sense for only a limited group of users. Not only that, but some initial features may no longer make sense at all. However, you keep adding new features quickly in order to keep up with pressure from your users and your competition. And since adding new code is generally easier to do than refactoring and rethinking existing code, these new features continue to pile up on top of the existing ones. Pretty soon your product has become hard to configure and navigate, and all of a sudden you’re hearing that dreaded feedback: “It’s hard to use.”

When you get to this point, your product has already been suffering from feature creep.

Wikipedia defines feature creep this way:

Feature creep is the excessive ongoing expansion or addition of new features in a product, especially in computer software, video games and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.

How to Avoid Feature Creep

So far we’ve examined software features and how feature creep develops. Let’s move on and talk about ways to avoid it.

One main difficulty in dealing with feature creep is that it takes you by surprise. If a product manager and development team don’t pay close attention to the development process, an overabundance of features will actually creep up (hence the name) in a software product. In the exuberance of development, product owners and system architects will cut many corners in the rush to the market. This rush, however, is the perfect environment for developing feature creep.

Let’s take a look at an effective treatment plan for this software-killing disease.

1. Know Your Users

I’m sure you expected me to say that you have to know your users. I realize it sounds so generic, but I’m not saying you must know them in general terms. Rather, you should know how they’re using your product. You must learn how your customers have integrated it into their daily workflow.

This can be difficult to achieve simply because useful feedback is hard to obtain when your software is just one of the many products your users utilize each day. However, you have no choice if you want to develop a relevant product. Here are some practical ways to help you better understand how people are using your software.

Include an Easy Feedback Loop

There must be an easy way for users to provide feedback and request new features. So a good software product should have an integrated feedback loop. This alone is a very important feature to implement in your product.

Dig for More Details

Once you’ve received some feedback, work hard to validate it. Either via email or a good old-fashioned phone call, reach out and ask a simple question to clarify what the users have told you. Something like, “If we were to add this feature, what are you trying to accomplish with it?” This will go a very long way in helping you understand what is currently missing in your product.

Engage and Observe Your Users

Visit users in person and watch them use your product. Personally, I’ve had many revelations after spending a few months working alongside a customer and their employees. Development priorities became clear to me much quicker, which resulted in improved features being implemented. And the customer gained large productivity increases as a result. This is a beautiful thing to experience.

If visiting your customers face to face won’t work, arrange a remote session where you can record them using your product. Just observe them using the software how they normally would—even if it’s the wrong way.

End user testing must be an important part of your development process. So having an efficient platform—like the one Plutora provides—for software delivery and testing will increase your development team’s confidence in delivering relevant software.

Integrate Usage Analytics

Integrate usage analytics (e.g., Google Analytics) into your product so you can see what buttons your users press and what pages they visit the most. Make it a practice to analyze this data on a regular basis and share your findings with the development team.

2. Create a Clear Development Plan

Your users’ feedback should flow naturally into your software development plan. As I mentioned earlier, obtaining useful feedback can be a difficult task. So it’s very important that you rank every piece of feedback you receive.

Keep It Simple

Simple things are generally easy to use. Therefore, if you want your software to have great usability, you have to keep things simple. However, there is no shortcut for achieving simplicity in software design. The key is being able to put yourself in the place of your users as you walk through each step and the flow of the new features. Then, as you’re doing that, you must constantly ask yourself if there’s a simpler way to organize the data or actions so users can complete their tasks.

The quest for simplicity usually leads to clarity. Unfortunately, simplicity is a difficult concept to implement in software products. So you must have a lot of persistence, work hard, and bring clarity to the feedback you receive.

Work with Development

This is when your development team comes in handy. Developers are smart and experienced and have many things to say about software features and user stories. They are an excellent resource for bringing clarity to any development plan. Over the years I’ve found that an experienced team of developers can bring a lot of practicality and realism to a marketing plan.

While it’s true that developers tend to think about complexity and implementation details, they also ask really good questions about usability and how to bring value to the users. If you’re using an agile methodology for your software development, it’s considered a best practice to engage your development team at the beginning of each new sprint. So during the planning for a sprint, you can explain the reasoning for each user story/feature you want to implement. The devil is in the details. Therefore, you should capture as many details as possible in whatever tool you’re using for user story development.

Validate your plan by adding detailed use cases. Walk through the scenarios your users will experience if you implement each feature. As you do this, keep asking questions: “Does the software really need this? Does it help my users? How many users would this feature help?”

Remove Obsolete Features

As your product matures, your users will change as well—whether you like it or not. I know we all want to implement the new features because that’s fun to do. But what about the existing features? Do users still need all of them? To put it bluntly, each feature must have a strong reason for its existence. It’s a good practice to access your user analytics data to determine which features people are using and then evaluate how usage trends have changed over time. When existing features stop being used or useful, you should remove them from your software.

Don’t Get Surprised Again

Feature creep is a real problem in software development. It can overwhelm a development team, and it often leads to bad products. However, when you understand how your customers are actually utilizing your software product and if you have a clear development plan in place, you can control and even prevent feature creep. And by investing the necessary resources to remove any obsolete existing features, you’ll keep your software product clean and support its continued growth as well.