How Too Many Features Can Ruin a Great Product
Have you ever been excited to try a piece of software that seemed to offer so many great tools in one place… only to discover it’s unusable in real life?
I had that experience when looking for a new live chat solution. Promising apps with many great features turned out to be nearly impossible to use and riddled with issues.
From the sidelines I could see the teams had been spending too much time on feature requests and too little on the core product.
And that got me thinking… Because up until recently we suffered from the same problem…
When I set out to build SPP I too wanted it to do many things – ideally, anything that a services-based business would need. A jack of all trades (and a master of none, as I now realize) sort of thing.
I feel like we’ve narrowed our focus a great deal since then, so in this post I’ll share one of the lessons we learned along the way.
Users Will Always Want More
In a perfect world you’d have one tool that does everything, is well designed, cheap and easy to use.
Needless to say, very few products, if any, match that criteria.
One the low end of the scale you have something that’s crammed with barely usable features that are basically selling points on a spec sheet.
And on the high end you have integrated enterprise systems that come with 100-page instructional manuals and a price tag to match.
As a rule, the more things you add to a product the harder it becomes to keep it clear and easy to understand. To the point where normal people just can’t figure it out on their own.
That’s when companies start needing sales people, on-boarding consultations and ultimately fixed contracts with hefty startup fees.
It’s not a business I want to be in.
The Problem With All-In-One
Here’s a feature request we’ve received a number of times:
Can you add the ability to create to-do list for orders?
Sounds straightforward: just add a database field for tasks, design a screen or two for items and you’re good to go, right?
Not so fast.
What about assigning tasks to team members? Or adding attachments? And wouldn’t it be nice to get alerts for upcoming tasks?
Oh, and don’t forget ongoing support and technical debt from packing in another seemingly small component.
A simple feature quickly turns into a complex piece of software that could be a whole new separate product… a product that already exists, most likely in a better version that we could build ourselves with limited resources.
Heck, there are plenty of well funded super smart teams building “simple” task management apps. I mean can we really compete with Trello or Wunderlist?
I’d much rather let you choose the tools you want and connect them to SPP via Zapier or a custom module.
Killing Features For Common Good
One example of adding something that should have been a standalone product was the email marketing module which we removed some time ago.
Essentially, it was a quick way to send bulk email to customers without having an email marketing service like MailChimp.
It worked fine initially… then as people’s lists grew bigger we started facing the same hurdles an email marketing company would. Deliverability issues, dealing with spam and the sheer quantity of email being sent.
It came down to building another MailChimp inside SPP or killing the feature. We chose the latter and added dedicated integrations with professional email marketing services instead.
Will I consider adding it back if people need it? Definitely. Just not right now.
Finding The Right Balance
That’s not to say we’re going to turn down feature requests from now on.
As a founder I spend a lot of time talking to customers via email and chat, because I want to hear that feedback first hand. And I strive to implement as much of it as possible, especially if it can benefit everyone.
Yet we have to keep the balance between missing opportunities and doing too many things at once. If that means focusing on fewer features so the stuff we do build is of higher quality, so be it.