A few months ago I tried starting a blog for Zane Benefits which was quickly abandoned due to other pressing issues.  Now I'm getting back on that project and I'm serious this time.

We've got a new look, new platform (based loosely on my personal blog) and better topics.  So if you're interested in the healthcare reform going on, or you just like reading things I write because you're closely related to me, check it out here.

Hopefully this will be a big month for me.  We're starting some really cool projects at Zane Benefits and we're expecting to see increased returns from some of our old ones.  It's hard not to get excited about the momentum building both at Zane and the healthcare system as a whole.

I've also got two weeks left to finish the freelance project I started last month.  Then I need to start full time on cbBlitz, the fantasy football site I started with my brother last year.  There's a lot going on.

Ok, so to avoid getting too emo with this post, I just want to mention something interesting I've noticed as my work load has gone from reasonable to OMG HOW WILL I FINISH IT ALL!!!!

Every time I take on a side project I worry that it might hurt my production at Zane.  Oddly enough, I think I get more productive at Zane the more work I have waiting for me at home.  I think I've boiled this down to two things:

1. Fast Pace - It's kind of hard to go back and forth from leisure to discipline.  It's easier to wake up early every day rather than just one day a week and I think the same thing applies to the rest of your life.  The past couple of weeks I've been doing things non-stop (a trip to St. Louis, a trip to Zion, work, side-project, blogging, mountain biking...) and it's a piece of cake to keep it going once I have momentum.
2. Cross Training - In sports, athletes train outside of their discipline to help keep themselves balanced.  I'm finding similar results by working on dramatically different projects all at the same time.  When I finish programming, I'm refreshed and ready to blog.  Then I'm ready to design.  By taking on extra work, I'm making my day job less monotonous.  I've also learned some really great things from side-projects that I've started incorporating at Zane.

My point is, I'd be less productive if I only focused on my full-time job.  I work slightly fewer hours than I would without the other projects, but I get a lot more done with the hours that I do spend at Zane.  I hope to start a company one day.  If that ever happens, I'm going to encourage every employee to take on projects outside of work.

What do you think?  Have you had similar experiences?

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.

I don't want to get in the habit of using this blog to give updates on my life.  After all, I have at least 5 readers and since only 2 of them are my parents, I'd be alienating three fifths of my reader base.  Today is a little different though.

This afternoon we officially launched the new Zane Benefits corporate page.  This site uses the new logo, color scheme and design that I came up with (with tons of feedback and suggestions from friends and co-workers).  Last Friday we launched a new reseller section using the same design.

We still have several live sites that are using a hybrid of old design and new design (old colors, new logo for example), but those will change over the next couple of months to use this new look and feel.

We also officially settled on some new business card designs today.  Basically, between Friday and this afternoon the company completely re-branded itself.  This is pretty exciting for me because this is the first time I've been involved in every aspect of this process and I'm really happy with the way things turned out.

I mentioned a couple days ago how I don't like planning too far ahead which means that this site is still a work in progress.  I'd love to hear what you guys think about it (I can handle a little criticism)  Also, for those of you interested in Zane Benefits (Tom), check out the new reseller section.

Ok, sorry about not having a point to this post.  I'll try to keep posts like this few and far between.

A lot of my posts on this blog will talk about general concepts in the context of specific events.  Most of my experience comes through my job, so that will be the main source of the specific events.  I'll use this post to explain what my company does just so there isn't any confusion in the future.

I work at a start-up company in Park City, Utah called Zane Benefits.  I was hired as a programmer and I still spend the majority of my time writing code but I've also taken over all of the graphic design duties and I'm getting more involved in project management and marketing.

ZaneHRA

Zane Benefits writes software that employers use to administer health benefits for their companies.  This software is called ZaneHRA.  Basically, when a company realizes that their current group policy is a complete rip-off, they go looking for other options.  They find us and sign up for an HRA (Health Reimbursement Arrangement) which allows them to give a virtual health care allowance to their employees through our system.  The employees go out and buy their own individual health insurance policies and they are reimbursed by logging into their ZaneHRA accounts and submitting a claim online.

There are a lot of reasons why this is a great system but I won't get into them since this isn't really the venue.  All you need to know is that employers create a benefits plan with us and employees use our system to submit claims.

Insurance Agents

There is also a side of our software that we're expanding really aggressively.  After employers set up their HRA with us, the employees all need to buy insurance.  We have an account that insurance agents use to sell HRAs and then fulfill the insurance policies of all the enrolled participants (employees).  This is by far the most interesting part of the software from a technical standpoint because we provide the agents with all kinds of different tools.

Ok, so that's a brief summary of the company.  I'll reference this in the future when I make posts about work.