The hidden costs of complexity: three things that will kill your product

“How much functionality will this include?” and “How many features will our budget buy us?” are two the most common questions we’re asked at the start of any product development project.

But while it’s important to get value for money, it’s the cost of complexity you really need to keep your eye on.

Less is definitely more when it comes to scoping a product.

The more features you add at the start, the less likely you are to succeed in the long run.

In this post we’ll uncover the three hidden complexity costs you must fight against.

The life of your product may depend upon it.

#1 “Make it do this, and this, and this, and this…”

You know the phase, Keep It Simple, Stupid. Well, it exists for a reason. It’s all too easy to get carried away with building lots of advanced features from the outset, which is a classic way to bloat your tool.

A common feature request is the ability to group user accounts into teams. However, it’s rarely a good idea to try and make your product work for multiple users right out of the gate.

It sounds counterintuitive. After all, many products will need to be collaborative. But introducing this early on can trip you up before you even get started.

In our (bitter) experience, it’s better to get your product fit for a single-purpose first before making it fit for teams.

Basecamp use the phrase ‘feature loops’ for this situation, and describe their experience with them in their brilliant book, ‘Getting Real;’

We’ve had requests to add a meetings tab to Basecamp. Seems simple enough until you examine it closely. Think of all the different items a meetings tab might require: location, time, room, people, email invites, calendar integration, support documentation, etc. That’s not to mention that we’d have to change promotional screenshots, tour pages, faq/help pages, the terms of service, and more. Before you know it, a simple idea can snowball into a major headache.

This example beautifully illustrates how even adding a single feature can mean reconfiguring everything else… ultimately weakening your core product.

The more complex things become, the more obstacles you put in people’s way. The harder a product is to understand, the less it’s likely to be used.

With our teams example we can think about this in a similar way. If we added teams in…

  • Can anyone control the team account or does that have to be one (or more) people?
  • What’s the procedure for adding and remove people?
  • Does everyone have the same level of access?
  • Can admin users edit other’s accounts and content?
  • What happens to people’s content if they’ve been removed from a team?
  • Can people be on more than one team?
  • Do team members need notifications as to what the others are up to?
  • Do we need to show what the rest of the team have been working on?

What seemed like a simple additional feature quickly brings up lots of unexpected outcomes, all adding to the complexity of the design and build.

#2 “Our users keep asking for this”

When Twitter recently expanded the character limit to 280, users were in uproar. This wasn’t the feature they wanted! Where was the edit button they’d been screaming for? How hard could it be to introduce it?

Actually, allowing 280 characters is a relatively simple feature. Editing posts isn’t.

Editing requires strict rules; do you need a time limit to stop a message being changed after it’s been retweeted 30,000 times? Maybe you allow just a few characters to be edited to prevent that? But what do you do about images?

Asking twenty users what these rules should be would give you twenty different possible solutions… and objections.

Twitter doesn’t have an edit button – and probably never will – because it wouldn’t deliver in value what it would cost in complexity.

People have used Twitter for over a decade without being able to edit posts, so why start now?

Just because your users want something, doesn’t mean you should build it. As Steve Jobs famously said;

Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.

If a feature which will increase complexity is really essential, it will keep knocking at the door, one way or another. Only then is the time to start considering it seriously.

#3 Too much, too soon

If I just had this product finished before now, I’d have a bigger business! My competitors are way ahead of us …I wish we’d been first to market

Sound familiar?

Everyone feels FOMO before they’ve launched their new thing.

But actually not having a fully worked-out, live product, can be the better position to be in.

The chances are that your competitor will already regret introducing some of features they’ve found themselves agreeing to.

Perhaps they wish they’d designed their product for a different sector? Or they’ve realised their customers are using their product in a completely different way than intended? Perhaps they wish they could just start again?

Every decision you make comes with an opportunity cost. And the faster you grow, the easier it is to make bad decisions.

Starting small allows you to change things up quickly when you see they’re not working. But the more complicated your product becomes, the harder it is to untangle.


Complexity can feel like the path of least resistance, especially if you’re under pressure from users, or even senior managers, to introduce unnecessary features.

But giving in means risking the death-by-thousand-cuts of investing in things that give nothing in return.

There’s nothing worse than realising you’ve invested precious time, energy and money into features that actually make your product more difficult to use.

Keeping things simpler for longer means staying agile, flexible and more able to deliver maximum value long-term.

The bonus? Lean products often cost less to develop, too.

As Jason Fried says in Getting Real;

All the cash, all the marketing, all the people in the world can’t buy the agility you get from being small.