Feature Addiction: Why Too Many Features Can Ruin a Digital Product Before It Begins

Digital products are living, ever-evolving things. So, why do so many companies force feature after feature into projects without any real justification? Let’s talk about feature addiction and how to avoid it.

Feature vs function: our definition

A feature is a system within a larger system that enables functions to be accomplished. A user management feature, for example, offers functions such as adding users, managing permissions, removing users and password management. In the real world, a car’s ‘function’ is to allow a driver to go from A to B, while its features such as the gear stick, engine etc. are elements the driver interacts with to achieve its functional requirement.

What is it that drives the need for new features in a digital product? Why is it that product owners and businesses often demand a laundry list of new features either at launch or during an update cycle? Sometimes these demands come from stakeholders who simply want what other apps have. Sometimes it comes from competitors. Sometimes, from your own assumptions. Wherever these new feature demands come from, it is important to stop and recognise that ‘feature addiction’ may be weighing your product down.

Sometimes, the problem is you.

You know almost everything about your market, competitors and customers. But, unfortunately, that same rich knowledge can also lead to considerable bloat through feature addiction, as you begin to ask for features to be developed solely based on your own guesses and what your competitors have in their products.

Take, for example, the hospitality sector. A product owner at a leisure group will have rich experience in gym software, user behaviours and fit-tech integrations. Much of what drives such an owner’s understanding of ‘good’ technology decisions will come from insight gathered through marketing and experience. They are more likely to specify features because their competitors have them.

Feature addiction

Feature addiction, left unchecked, causes bloat. Worse still, adding too many features can lead to a product that either slows down or fails entirely to accomplish its original requirements. Sadly, in software development, it’s an easy trap to fall into.

Basecamp’s co-founder Jason Fried illustrates how bloat occurs in this classic Inc.com article entitled ‘How to kill a bad idea’. He uses a water bottle as an example: all of a water bottle’s features, from its cap to facilitate drinking and storage to its clear plastic container, are there to clarify its function: drinking.

In software, Jason argues, ‘software doesn’t have mass. It doesn’t have shape. [...] Nothing is pushing back, saying, "That's a bad idea; that won't work; that's going to burn someone or hurt someone or make someone drop it or..." Almost none of the tools we've developed to evaluate physical objects apply to software. This is why most software goes bad over time. Software - websites included - usually start out pretty good. The first version is pretty focused. Yes, there are horror stories of overstuffed websites or unwieldy software products. But for the most part, the first version of something has the fewest features it ever will have.”

Jason continues to discuss how as time goes on, versions become more and more bloated. Where the water bottle example is limited by the laws of physics (you can’t keep adding stuff to one or it’ll become physically unsuitable), digital software can just grow and grow with more features.

Ultimately the only limit in the digital world is the ability to say no. It is up to you, the product owner, to identify unnecessary features and remove them from the product or refuse to allow them to be added. The earlier you can do this, the better - as you’ll avoid messy launches.

Feature addiction vs requirements: when to say no

Let’s return to our leisure example. Imagine that you’re not looking at a competing leisure group and its own digital membership app. Instead of concentrating on the bigger picture (why does this work well, what does it do for users), many businesses will look at individual features that an app possesses and think they need them to compete.

A feature is simply the interaction that facilitates functions. Just because your competitor has a certain feature, you don’t have to suddenly add it to your own project pipeline. If a feature cannot be traced to a clear functional requirement, you should be able to say no to it.

Considering functionality is far a deeper way to understand your product. Rather than looking at what a competitor’s features are, why not instead look at what your users really need? Map out user journeys and build feature lists based on user needs rather than competitor envy.

A final note on feature-driven thinking: “feature” lacks depth

In an ideal world, features are developed based on the outputs of a detailed user journey that has identified needs. They are designed to help fulfil a functional requirement. Unfortunately, through competitor and market feature addiction, your project can be rapidly derailed or bloated by the added weight of lots of unnecessary features.

But ‘features’ are entirely too broad a subject to base your project around. Take a house in the real world. You could take a home and boil it down to a list of features:

1. Windows

2. Doors

3. Roof

4. Garage

5. Bedrooms

6. Living room

7. Bathroom

8. Kitchen

But realistically, no homes are the same even though they share the same features at a conceptual level. Even the features themselves will be different, based on requirements and budgets. The ‘windows’ in a £100,000 North East UK home with a cold climate will be drastically different to a £100,000,0 Spanish villa situated in direct sunlight for most of the year.

Specifying a feature list for your product is too ambiguous an approach. You have to take functionality into account first. In our window example above, consider how the functionality drives the feature. A window is built to offer ventilation and light - so its actual design choices such as double-glazing, handle-choice, size etc. will depend on the house’s position, budget, climate etc. (functionality/requirements).

In a digital product, features are better when created as outputs from user requirements. So while your competitor may have a ‘shiny’ feature that your own board wants you to put in your product, you must have the confidence to explain why that feature is not suited to your user journey. By saying no to feature addiction, you’ll save time, reduce complexity and improve user experiences.