We were sitting down to have a good re-planning session to make sure that we didn’t miss anything or do something out of order or otherwise screw up when some mass psychosis took over and we all got freaked out about getting beat to market by a competitor.
And it wouldn’t matter:
We couldn’t really “hurry” onto the market any faster Our game plan doesn’t require us to be first or get 100% of the market The technology stack is not something anyone is gonna stumble on
The first two are obvious, but the third is a bit counter-intuitive. What I mean is, there are often multiple technical methods to solve any problem. Look at databases: first there were flat files, then hierarchies, then b/c-trees, then relational databases, then object databases, then back to relational databases, and then the final solution: Excel spreadsheets. (Kidding about that last.)
When the problem gets more complex than a database (save information, get it back) you start to see different solutions. Even email has made a complex journey from mainframe to client-server to web to Ajax clients that are richer than client-server.
Pick something even more complex, like, say, a Content Management System (CMS) and you might have: php, MySql, Ajax, XML, CSS, and god knows what all the widgets are written in. Ponder the Facebook/MySpace software infrastructure that is required to allow a 13 year old girl to put dancing glitter hearts over her streaming Xtina audio/video mashup.
When we set out to solve our particular problem we decided that building a service that could adequately scale and flexibly change with the market was going to be our major challenge. Without going into details (because, as the Pointy Haired Boss of Dilbertian fame, I would get them wrong) I will say that we spent more than 6 months testing and discarding our options before settling on our core technology.
Then we had to build it and find all the stuff that didn’t work “right” and trim all the places where the real world failed to mold itself to our expectations. And we had to get two major widget vendors to fix broken stuff and had to craft a good workaround to another not-quite-fixed flaw. (Oh, and the workaround had to be quickly and easily removable when the flaw is corrected!)
So any one competing with us is, in our estimation, very likely to have chosen one of the technical dead ends that will really harm them in a moderate-to-high volume marketplace. By “very” I really mean “almost 100% certain.”
Which means that even if a competitor scoops us and pulls in the “easy” first tranch of customers, their service will certainly not work reliably or be effective in the real world, even if they throw servers, patches, and outright hacks at the problem.
And ours will work. We have tested it extensively under load and it just performs. And it works because to work in this case requires a particular set of technical solutions be stacked just so.
Why am I sure that we got it right and that other people won’t have figured it out? Because our guys are just better than our competition - I’ve got 25 years experience of high performance teams and I’m very confident of that. (I can just see the “can I have a raise now emails” coming in….)
If you would like an example of needing to get the technology stack right, please cast you mind back to when Google suddenly (it seemed) got the whole internet spidered in a few months, then the spidering got faster and faster and faster. And Yahoo, Jeeves, and all the other search engines just sat around and watched their options lose value faster than yeserday’s lotto ticket.
So when we got all freaked out about a competitor it didn’t take us long to calm down. But as we all started telling stories about the EXACT SAME BEHAVIOR from other startups doing quiet launches, I realized that this is just another stage in the startup process.
It’s kind of cool - I would have bet you that I was done being surprised by new “standard” behavior in the startup process.