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 common, and understandable, questions we’re asked at the start of a 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. Dun dun dun *dramatic sound effect*.
#1 “Make it do this, and this, and this, and this…”
There’s a phrase Keep It Simple, Stupid (the ‘KISS’ principle) coined by Kelly Johnson, American aeronautical and systems engineer. 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 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… which could weaken 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 removing 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 X (formerly Twitter) 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? 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 5,000 times? Maybe you allow just a few characters to be edited to prevent that? But what do you do about images?
If your users want something, you should listen, but it shouldn’t be a knee jerk reaction. It needs to fit into the roadmap, have a strategic purpose, and be carefully thought through. 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.”
#3 Too much, too soon
“When does this need to launch? Yesterday.”
Everyone feels FOMO before they’ve launched their new thing. They get panicked by competitor products and feel they need to match their competitor’s products from the off.
But actually going to market with a leaner product, is arguably 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.
Conclusion
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.”
Need a fresh pair of eyes to help keep things simple? Talk to our UX/UI experts!
