Focus

One of the things that appears to happen when you sell a venture funded startup is that you receive a license to give advice to people. As I have not yet received such a certificate in the mail, you would be well with your rights to suggest that I shove off, but I do have a few observations from my recent experiences that you may find useful, especially if you are running a startup of any stage.

As the dust starts to settle and I reflect back on the past few years running StyleFeeder, our team did several things exceedingly well. One of them was our collective ability to focus on a goal and execute towards that, whether our objective was related to revenue, product development, fixing a problem or otherwise. That ability to focus as a team is one of our core strengths.

You hear this all the time, right? It’s not new. It sounds obvious enough. In real life, it’s hard.

Part of the reason is that focusing implies that something else gets de-emphasized, but in small startups, subtleties don’t work. If you’re trying to do something, stop doing everything else. It’s a primitive caveman-like approach, but devoting 50% of your resources (time, money, or attention) means that whatever you’re doing will surely take much longer than 2x as long due to the inevitable distractions. Be brutal in your willingness to get your team to drop everything and just do that one important thing.

We had some principles that enabled this, notably with our product work that helped us avoid the cost of context switching. Whenever we built something, the goal was that (a) you wouldn’t go back to it for at least a year and (b) it had to scale 10x without intervention. These principles shaped our work in a way that yielded quality, stability and operational reliability and we still follow them. These principles also weren’t so aggressive that they promoted a culture of over-engineering with our team building the Infinitely Scalable System.

If you don’t adopt principles like this, even your successes can be cause for alarm. Crap, you got ten thousand new signups today and that underscored a scalability problem that you didn’t know about? Well, whatever your team was focusing on before has now been sidelined by a crashing website and emergency late-night patches. You rushed a feature out the door without properly considering the security holes that went along with it and someone cracked your site? Now you get to clean up that mess instead of doing something useful.

Starting to sound familiar?

I’ll give you a concrete example. Years ago, you used to be able to import your Amazon wishlist intto your StyleFeeder account. You’d type in some identifying information into a search box and select the Amazon Wishlist you wanted to import. We asked around and found that my friend Luis Villa had the biggest list we could find with almost 500 products! Literally five minutes after we pushed this feature live, the site crashed hard. Upon investigation, we discovered that someone tried to import a wishlist with over 5,000 books on it (we were attracting a lot of book lovers back then). Since we were holding a bunch of this data in memory, the server simply ran out and died. Wonderful. It was a stupid design decision on our part. The lesson was that this quick and dirty approach didn’t scale past the first few minutes of service. And users will always exceed whatever reasonable limits you think they’ll never exceed. Instead of moving on to work on another feature on the site, we had to immediately redesign the feature we had just finished building. That’s really costly.

What were we working on again? Oh, right.. the thing we were supposed to be focusing on.

During StyleFeeder’s trajectory, we added a lot of features to the site, some of which were pretty interesting and some of which weren’t obvious failures. One of the other skills that we didn’t get particularly good at until the later years was killing off stuff that wasn’t helping us or that we couldn’t properly support. An example might be a partnership that isn’t performing well and your company is powering features on another company’s website. Kill the partnership. It’s a distraction. Or, get some data and decide if you can make it work well enough to keep around. But your first instinct should be to view this underperforming lump of a partnership as an alarming problem that needs to be addressed one way or another.

There are many wonderfully witty quotes about how important reliable data is and how everybody except God needs supporting figures, etc., but it’s worth emphasizing that it’s all true. We now have wonderful realtime dashboards of all key metrics that we’re tracking. For many reasons, getting your entire team to focus on these metrics - and to build them as part of every feature - is The One True Path. Once you have tools like this, you’ll realize that you’ve just been a fool stumbling around in a dark room without any notion of where you’re going.

If I had to do it all again, I’d re-adopt these same principles and be even more aggressive in limiting the company’s activities to a short list of Things That Matter. It’s all a bit of a fine art and you’ll have plenty of opportunities to experiment with the right balance.