I don’t know about you, but many times when a supposed flash of brilliance hits me, I believe I have the mental equivalent of gold. I tend to get a bit ahead of myself, and start thinking about all of the money that I am going to make, what the product is going to be, how much customers are going to love it, how I am going to sell it, and who is going to buy it. Somewhere in the middle of that process, I start designing the product; making decisions about the absolutes of what the product will and won’t be.

You will find that your first idea is seldom your best one. This is true along two separate axes. First, if you spend any incremental time on design and storyboarding, you are likely to improve upon the original idea in immeasurable ways. Second, if you start letting your mind wander, you may come up with a completely different product/solution that addresses the same need, either directly or tangentially, and does so in a far better way than your first idea.

Just as the notion of testing your idea with only one person is a guaranteed recipe for fail, using yourself as the sole testing point will likely land you in a situation where you could potentially create something that no one will want. This is especially true if you just start building the first thing is that pops into your head.

Building is something that you should only be taking on after you have thought through what it is you are hoping to accomplish. Let your thoughts percolate for a little. Then let them simmer. I’m not talking about taking weeks or months, but don’t be afraid to let an idea sit for a day or two before you act.

Further, if you have a set of people you trust to not crap on your ideas, you will find that the simple act of trying to describe what it is that you want to do will reveal cracks in your idea. If you can’t explain it, you probably shouldn’t be building it. Even if your colleagues don’t buy into the concept, it’s likely that they will ask questions which will force you to think about what it is you are actually trying to do, and whether or not you are accomplishing that goal.

How many times have you said “I know what I want to say, I just don’t know how to say it?” My eighth grade English teacher would beg to differ. If you can’t explain it to someone else, why do you have any reason to believe that your translation of what’s in your head to an actual product will make any more sense? A great example of this is a focus group. If you have ever sat in a focus group, there’s a high probability that in your head you were screaming something along the lines of “why are you doing that you stupid customer?!?! You’re not supposed to use it that way. No!!!!” The physical instantiation of your idea is simply a representation of your ability to explain what it is that you wanted to do, and if you can’t explain it, you certainly can’t build it.

When I first came up with the idea for IMSafer, the product concept was to have a local program running on a computer doing all of the language analysis, and to have the code based on an open source product called Snort. IMSafer was envisioned as a program which was supposed to trap all of the traffic on a local home network, and perhaps even talk to the house router/cable modem. In not thinking through the idea, and not sharing the idea with anyone, I started making design decisions that were terrible. Awful, actually.

The team and I spent some afternoons and nights at the local Starbucks during the very early formative days of IMSafer, and just the exercise of trying to explain to them what I was trying to do showed me that I was designing something that not only would not scale (that’s a fail), but would also fail the grandma test (“can grandma install and use this?”). There was no way to make a customer friendly and easy to install piece of software doing it the way I originally wanted to do. Here’s a useful tip: any time you have to use the words “network” and “configuration” in a product intended for home use – fail.

It was clear from just the first conversation that we needed to vastly simplify the product, and that meant changing where the code lived. It also meant removing the number of moving parts from the customer computer. Our target customer was a parent in their late 40s to early 50s, and at the time we started IMSafer, that particular demographic was not the most technically savvy. If I had just rushed headlong into development, I would have either made design decisions which would have destined the product to failure, or would have cost me a great deal of time, energy, and effort to redesign when we finally figured out that what we had built was wrong.

All of this reminds me of an old joke that I love:

There’s an old bull and a younger bull sitting on a hill. The younger bull says, “Look at all those cows. Let’s run down and shag one of them.” The older bull ponders this for a moment, considers his answer carefully, and says, “How about we walk down and shag them all?”

The moral? If you take your time and think through what you are doing, you will more than likely get an optimized result.