This was never published. Really weird to look back at your old writing.
Keeping the momentum alive in your startup
Time to drop a little Physics 101 on you:
p = mv
Does that mean anything to you? The astute student will know that this is the equation for momentum:
Momentum (p) = Mass (m) x Velocity (v)
Why the letter ‘p’ was chosen to represent momentum, I don’t know, but I bet it has something to do with Greek (rho perhaps?). Anyhow, maintaining momentum is a critical part of any early phase startup. Many a good business idea has been abandoned due to lack of momentum. Why did it stop? Where did it go? I think analyzing this equation a little further can help you keep the momentum towards making your startup dreams a reality.
First let’s dissect at the Velocity part of the equation. Velocity can be further broken down to a function of acceleration and time:
Velocity = Acceleration x Time
So, by substitution we can see that the momentum in your startup can be influenced by these three factors:
Momentum = Mass x Acceleration x Time
Still with me here? If not, go hit the Algebra book and come back when you are done.
Alright, I believe the goal here is NOT necessarily to maximize momentum, but rather keep it at a healthy level. You don’t want it to slip too low, causing you venture to come to a grinding halt. But you also don’t want it to spin out of control, causing unmanageable growth and popularity (see Friendster, and hopefully not Twitter). You want to balance the three factors, (mass, acceleration, time) in order to keep the right momentum alive. So how exactly do these influences relate to startups, and how can we keep them in check?
Mass
The mass element can be thought of as the size of your startup team. Are 8 developers really needed for an initial release of most web applications? Probably not, and having too many developers hands on an early version of an app can ruin things, similar to how too many chefs can spoil the soup.
On the other hand, being the sole developer on a project can greatly reduce your projects momentum. Obviously, one developer can do an entire app (ie. Flickr), but in most cases 2-3 developers is the ideal size for an early stage venture. Besides sharing the code load, it is very beneficial to have other people on the dev team for motivational reasons. There will be times where you will want to slack, not code, or even quit. This is when the other members of the team will step in and motivate you to keep things moving. Having a sense of accountability towards each other is key.
In addition to the motivational benefits, a small dev team is beneficial when unforeseen personal events occur. Is the project development going to come to a halt when your cat dies and you are grieving for three weeks? That is when the other guys/gals can step up to keep the momentum going.
Acceleration
We have to stretch the metaphor a little to accommodate the acceleration element. Acceleration can be thought of as the energy and enthusiasm put into your startup. Obviously, you want to truly believe in the potential for success of your project, but you have to be careful not to drink your own Kool-Aide, Heavens Gate style. Along every step of the way, you must analyze the viability of your startup. Unless you plan on doing the ‘I hope we get acquired by Yahoo!’ rain dance, your startup should have some method of sustaining itself. So, as your are furvently developing it is often good to step back and review your business plan. Is it still relevant? Does anything need to be updated? Don’t be like the underwear gnomes on South Park, whose business plan went something like:
1. Steal underwear
2. ????
3. Profit!
In addition to reviewing the viability of your startup, it is also necessary to step back and look at things from an outsider’s perspective. With all that enthusiasm and energy you are pouring into the project, it is too easy to get completely wrapped up in your idea. You feel soo comfortable with it, that you assume that everyone will easily grasp the concept and understand it as well as you. It is of utmost importance to think like an actual user of your application. I think the best practice is to assume as little as possible about your users; maybe think of it as designing for the least common denominator. Just because something seems intuitive to you, does not mean that a first time user of your application will feel the same way.
Time
This one should be pretty obvious, I don’t think too much needs to be said. The speed that you release to the public is paramount if you are going to throw your hat in the internet rodeo.
However, one area that gets overlooked when trying to quickly come to market is TESTING. For some reason in internet culture it is acceptable to replace system and unit level testing with a shiny ‘Beta’ tag. I guess that we have Google to thank for the proliferation of this phenomenon, since every product they release seems to remain in Beta for an indefinite amount of time, but I really think it is a cop out for good testing (Coding horror link). There are even podcasts that claim to be in ‘Beta’……
