What they don't tell you about "Ship early and often"

I read this post from Rick Segal, a Toronto based VC, where he describes sitting down with a big company, asking them if they ever worry about some small player coming up from behind and stealing their customers. The big company responds with "ha, that would take years." Rick then goes on to describe how he demonstrated right before their eyes (even coding some in front of them?) how this might be far easier for a grad-student to do than Big Company thinks...

What? A VC actually wrote code on the spot, that duplicated core functionality of a Big Company product? Something's not quite right here...

Rick is clearly telling this story to make a point. Big Companies: don't sit on your ass. Development costs, marketing costs, and switching costs are all lower than ever. If there's money to be made, the competition will heat up and people will be coming after you constantly.

And while I sense there may be a small bit of exaggeration in Rick's story, he makes a couple of good points:

1. Always be looking over your shoulder
2. Don't assume that no-one else can do what you're doing right now, better.

However.

All you read about now is "ship early and often." As if anyone building anything for longer than 2 months is a complete idiot and obviously "doesn't get it."

In general, I am also a believer that your bias in development should be to get "something" (anything) working end-to-end first (a complete skeleton) and then iterate like crazy to fill in the missing pieces and keep raising the value of your app - even if it means going back and re-writing some pieces later (classically trained developers hate to re-write code. They want to design and write something once that will work for everything and live forever, which is, futile. Every day you wake up, you know more about the problem than you did yesterday when you wrote the code.)

All of the Agile methodologies came from some learning that occured in some very nasty places:

• Never-got-off-the-drawing-board-land
• and Oops-we-built-something-that-nobody-wants-ville

These places really are scary. They're like "broken homes" of development. They've sunk more than one company. But today, even though web development is still only a sliver of "all software development" going on world-wide (including embedded devices, server software, desktop software, etc.), us Webbies have the biggest voice. Why? We're born and bread on a communications medium of course (the Web).

So now, what seems to be working for a pile of Web 2.0 companies is being pushed on everyone without stopping to think if it is really appropriate. (I say seems to work because sooooo many Web 2.0 plays have yet to monetize anything, particularly on the consumer side [free stuff]).

So, while I believe "ship early and often" is a great bias to begin with, here are some things that you really should take into consideration before rushing something out the door, convincing yourself you'll iterate like crazy (a.k.a. fix it later).

1. Are you making anything other than Web apps? If so, tread carefully. The Web has virtually instant and free re-deployment, unlike having to send patches to all your desktop users every 2 weeks, or recalling a bunch of embedded devices for service, or bugging the MIS staff of all of your customers to re-install, re-configure and re-test. Us Webbies have it easier that way. You may be better off taking the extra time to get it right the first time and not have to iterate to fix a bug or plug a feature gap.
2. What scale of user base are we talking about? If you remember back in the day, before the recent surge in popularity of Agile methods, a bunch of developers realized that fixing the car while driving it was much harder than fixing it before it left the shop. A little more work up-front with respect to performance and scalability can go a loooooong way for you later in the game. One of the myths in the software world is that "we'll have more time later." Wrong. You'll have less time later (for development) because you'll suddenly inherit a bunch of support and maintenance responsiblities that will eat up your dev time. The trick is to be realistic about not over-engineering. You likely won't have 1 million users in the first month, despite what your biz plan says.
3. Do you have any Intellectual Property barriers to competition? The first-mover advantage is meaningless in a world of near-zero switching costs and marketing costs. If you can pump something out in 2 months (and let's say you're the first in the category to do it), how fast do you think your competition can? After you've done the hard part (design) and they only have to copy and add their own spin? In this kind of world, you're better off making sure that when you do ship, you've put something in there that is going to make the competition scratch their head for a while before they can duplicate it.

One of my nagging pet peeves about the promise of Agile methods is that they always seem to use anecdotes like, "Look what we built in 2 weeks!!! Could your process do that?" As a friend of mine said, "anything can be built quickly - the question is, how well was it built?". In other words, don't confuse a rapid prototype with a rock-solid, scalable, configurable, high performing product. Those ones take much longer than 2 weeks (or 2 months) to build. If you are building one of those bigger apps, then I would simply tweak the mantra to "Build early and often" so that you do actually have a version that someone can use as early as possible and keep giving you feedback at every iteration - just don't automatically rush to ship it unless you've thought about the factors I listed above.