Code is about 8.5% of our pie. You?

If you look around at the really successful, stand-out startups, they all seem to be experts at what they do. They feel the pulse of their markets, their teams all know their product or service through and through, and they’ve been persuasive enough to take an intangible idea and convince investors, customers and employees to believe in it. This level of expertise may not be sufficient to get you the next billion dollar valuation, but it does seem pretty close to necessary (disclaimer: we’re not worth a billion dollars… yet).

So how can you become expert about your business? Cliche as it may be, I’ll fall back on Malcolm Gladwell’s 10,000 hour rule, which loosely states that around 10k hours of actually doing something can establish expertise. But surely that can’t be true for environments like startups, where speed is of the essence, right? In some lucky cases, maybe, but the major success stories have usually put in that much time at the very least. So how do those 10k break down?

Let me answer by illustration: over the past several months, my colleagues (first and foremost) and I have built a sophisticated product, Call Tracking Metrics, that tracks what marketing sources lead to phonecalls for our customers. This allows them to optimize their marketing budgets and focus on campaigns that work. The app intercepts phonecalls to virtual numbers correlated to marketing sources in order to collect data. That would have been a pretty amazing feat not too long ago, but thanks to a lineage of tools, from VOIP to Asterisk to Twilio, it wasn’t unbearably difficult. By using the right tools, we developed a fairly polished product in approximately 850 man hours. We’re nowhere near done with development – we’ve got other features in mind and we pride ourselves on responding to feature requests, but we’ve got something that people are willing to pay for, many of whom seem to think it’s pretty damned great.

But wait, we’re nowhere near Gladwell’s floor for expertise… and that’s exactly how it should be after getting a first version shipped. We’ve used our prior expertise to build the product, but now comes the task of building the business. Our 850 hours wasn’t particularly slow or fast, but it illustrates a point about timing: if expertise is necessary and you’re trying to build it as fast as possible, it’s important to build a product that allows this to happen. Don’t write really cool code at the expense of finding really cool customers. It’s impossible to reach a level of expertise about your business without focusing on the business itself: acquiring and satisfying customers. In other words, the bulk of the time you spend building expertise about your business probably shouldn’t be writing code, after a certain point, but rather doing things that grow the amount of customers paying to use the code. This equilibrium point may change significantly depending on funding and especially the size of your team when you start, but for the typical team of < 10, I can’t imagine any circumstance in which it wouldn’t prove to be true.

So by transitioning to a focus of bringing in and keeping business, will that ensure the survival of Call Tracking Metrics (or your startup)? Obviously there’s a lot more at play than that, but I can almost guarantee that we wouldn’t make it to expert/success if we didn’t. Seth Godin suggests that the importance of the 10k rule is less about the expertise itself than putting in the time doing whatever it is you’re gaining expertise about; that it’s more about perseverence and the fact that many people will give up long before 10k hours. If you accept that, then your goal becomes prioritizing that time so that you actually can survive and persevere. That’s what I’m talking about.

Oh, and by the way, if you want to know where your calls are coming from, give us a look.

More discussion over at hacker news