One of my favorite topics to read about is personal finance.  I don't really benefit much from the advice directly (I already know that credit card debt is bad) but it can act as an analogy for a lot of other topics.

One trick that people use in personal finance to prevent impulse buys is to set a rule that they have to wait a certain period of time before buying expensive things.  For example, I might decide that for every $100 I want to spend, I need to wait a day before finalizing the purchase.  If I want a new $1,200 tv, I can't buy it until 12 days after I decide that I want it.  The idea is that the item doesn't generally seem like a smart purchase after you have some time to think about it.

The same thing can work with product development.  It's natural to get excited about new ideas and lose perspective.  Whatever's on your mind is always going to seem like the most important thing and so it's tempting to get going on it right away.

When I (or anyone else at Zane) have a good idea, I find that it really helps to sit on it for a while before acting on it.  If the new idea would take a month to complete, I think it makes sense to wait at least a couple weeks before getting started*.  Most of the time I've forgotten all about it a week later and it's obvious that starting right away would have been a huge mistake.

This is not a way to rationalize being lazy or conservative.  I always talk about how I'm a proponent of getting started now and planning later.  The goal here isn't to use the extra time to think about the project or plan or forecast or speculate.  The goal is to let the idea sit on the backburner to make sure that you actually need it.

By putting things on hold like this, you end up having a backlog of the good ideas that actually do stand the test of time.  This way, when you come up with your next great plan, you have old ideas to work on while you let the new ones marinate.  It's kind of like a CD ladder.  Hey, another personal finance analogy.  I'm on a role.

*Note: This only applies to ideas related to a mature product.  If you have a totally new idea that isn't going to be added to an established system, by all means, get started right away.  The best way to find out if your new idea is any good is to try it out.

A couple weeks ago I talked about a new approach we're taking at work where we prepare but we don't plan.  This week we seriously benefited from the strategy and I want to spend some time going over what we did right, what we did wrong, and what I learned from it.

So here's the situation.  We recently released an CRM (Customer Relationship Manager) that our resellers can use to manage all the contacts for their entire organization.  When coming up with the structure, there was a question about how we should handle group permissions.  

For example, maybe an insurance agency has some people selling HRAs and other people selling insurance.  How should the agency control which contacts different people can see and how people can interact with these contacts?  Or maybe an agency has branches in two different states and sales leads should be confined to only the appropriate branch. Suffice to say, there are a lot of different ways people might choose to use a CRM and we needed to support as many of them as possible.

About a week of the initial CRM development was spent planning and implementing this permission structure.  Near the end of that week it became obvious that we just didn't know enough about how the product would be used to make some of the more important decisions.  We ended up throwing together a pretty simple set of features and releasing it.

So to summarize, we released the CRM without really knowing how group permissions should work.  The product was functional but a piece of it was missing.

We've now had two weeks to observe how our clients are using this system and now we feel completely comfortable making the design decision that we previously were unable to make.  It's unfortunate that our new plan makes the week we already spent on this completely wasted, but that makes our decision to wait on this particular feature all the more valuable.  

If we had made assumptions about what we needed, we would have been backing ourselves into a corner and the resulting product would have been crippled for months or years because of it.  By waiting to make any definite plans, we allowed ourselves a couple of weeks to observe our users which in turn gave us real actionable information instead of baseless assumptions.  So sure we wasted a week, but overall the process worked.

There's one important thing that I took away from this beyond an overall sense of satisfaction.  In the future, I should try to be more aware of which early decisions are based off real, solid information and which ones are wild guesses.  I might not always have enough information, but I can at least be more aware of what information I don't have.