What you choose not to make is part of the work.

Software projects have this habit of becoming overbuilt. Feature creep comes from various common pressures:

• We don’t know what our users want most? Give them everything.
• What if they run into this weird case? Build a feature for that.
• Oh! Dude! What about this cool feature idea!? Throw that in too.

Somehow, a lot of people working in software don’t really see the problem here. At the very least, they don’t take it seriously. Building like this creates a graveyard of unused features and wasted time, sure.

So, what’s the actual harm in that? This is one of those problems that’s hard to model and quantify.

1. Overbuilding wastes your time.

This is the obvious one and the easiest to put numbers to. When people call out feature creep wasting time is usually the argument that goes with it. You build things no one ever users just because someone might want them. Or, in my experience, quite often because someone internally wants it but customers do not.

It’s not just a one time cost either. As you add more and more features and paths to your product the cost grows exponentially. Every flow requires test coverage. There is more code to manage. Product guidance and marketing need to be kept up-to-date.

If this problem is hard to model, it’s only because the complexity of the downstream costs are so enormous. It’s easy to focus just on build time and forget it’s only a fraction of the actual work created from a code change.

2. Overbuilding creates and indicates organizational problems.

I don’t hear people bemoan this one that often. It stems from the downstream costs of wasting the time of everyone on your team. You end up having meetings and arguments about features no one will ever use.

Feature creep creates more things to measure for success. Then people need to investigate why they are failing. It takes team focus away from more important product decisions. As some features are failing it dilutes clarity on the overall product success.

Before that even happens, feature creep a huge red flag for the product. It means you either don’t know what to build or you’re scared that your product thesis is wrong. So, you’re either shooting in the dark or hedging your bets.

What’s worse is that feature creep can feel like productivity while masking these issues.

3. Overbuilding waters down your product.

Then there are your poor, unfortunate users. If you’re confused about your product, just imagine how they feel.

Your marketing probably doesn’t convey a clear message because your product doesn’t. People will go in expecting a specific solution and struggle to find it. Or, feel that it’s overcomplicated.

You may have a few very useful features in your product. It’s too bad people have to click through 30 different things to find them. Or make 10 decisions when they really just wanted a one-click solution. Instead of having a focused easy-to-use product you have a frustrating, confusing experience.

Operationalizing “no.”

Awareness of the problems with feature creep is a good start. Yet, I’ve been on teams that were aware they were doing this and kept on doing it anyway.

You need to have a culture of “nope.” But to do that, you need to understand what you’re building and why. If you don’t have clear core flows in your product, it’s all too easy to just keep adding more. You throw shit against the wall to see what sticks. Eventually the wall crumbles.

It’s okay to generate and log ideas for building on the core product. But until the core product is working and people are asking for more, there is no use in building more. Save those ideas for later. Keep them in mind and build extensibly. They are immediately useful for designing forward-thinking systems for later expansion.

Ruthlessly prioritize your core flow. Anything that doesn’t make this flow clearer does not belong here. This will require some process work. It’s easy to say yes and throw some idea on the list. Usually saying no is more work. People will defend feature ideas and generate them constantly. There needs to be a systematic approach to defending the priorities.

Only once you have feedback about the success of your product’s heart can you start adapting and adjusting it. Doing so beforehand is just letting fear and chaos reign.