Feature bloat is a really serious problem for anyone responsible for creating a product.  In software, "Feature Bloat" happens when developers keep adding new functionality to a program.  Eventually the program becomes so complex and messy that it's not good at anything (think Microsoft Project).  A fellow programmer joked with me that the first law of product development is that every piece of software eventually turns into an email client.

The problem is that it's really hard to say "no" to good feature requests.  Maybe a large client is starting a new project and they say they'll use your software if you add one basic feature.  Then another client suggests another and so on.  If you say yes to all these simple requests, it ends up ruining the entire user experience (even for the people that originally requested the features).

The current Zane Benefits CRM is actually the third CRM we've developed.  The other two came before my time, but they showed me two very dangerous pitfalls that I made sure to avoid with the most recent version.

Problem #1 - Too Specific

One of our CRMs was designed specifically for insurance agents to use as an individual insurance sales tool.  Of course we ended up getting users that didn't fit that model (another example of assumptions gone wrong) and our tool was just completely out of its league.

Problem #2 - Supporting Too many cases

The other CRM was only for our internal use so we ended up tweaking it all the time.  When we started our first mailing marketing campaign, we added a field to each contact to record that info.  We sold group insurance for a while and we had a way to track that.

It seems like this is the opposite of #1, but it's actually a close relative.  It's easy to think that the way to avoid being specific is to support as many different use cases as you can think of.  This generally fails because no matter how much thought you put into a program, you'll never be able to guess how people will use it.  To compound on that, supporting a bunch of different things will clutter the actually useful functionality so much that no one can figure out how they should be using the software.

So how can we avoid feature bloat without losing all the functionality the users are asking for?  It's actually pretty simple in a lot of cases.  Just make the foundation of a program as flexible as possible and that will allow you to come up with a native solution to just about every problem.  Rather than building a way to record marketing campaign information and a way to track group insurance sales, just make a system that lets users track whatever they want and then set up smart defaults for them to keep things simple.

Our new system only has a few ways to record information about a contact.  There are "pipelines" which track any type of ongoing communication (generally specific sales), "notes" which are just text fields for whatever the user wants to remember, and "lists" which are basically like labels in Gmail.

Now when a client calls up and asks us to add a field to the contacts with information about which mass mailings they received, we suggest that using a combination of lists and pipelines can solve that.  If a user wants a tool to migrate data, lists alone can solve the problem without us building a dedicated feature.

By making our very basic low-level infrastructure as general as possible, we left the door open for our users to turn the software into whatever they want.  The days of a company telling users what to do with a product are over.  Our users are teaching us how to use the very thing that we built.

It's still hard to resist feature bloat, but it's a lot easier when you do things right from the beginning.