Early Startup Time Wasters

Early Startup Time Wasters
Source: http://talkfast.org/2012/05/05/early-startup-time-wasters

May 05, 2012
by Jeff Miller


A major difference between launching a brand new startup and working on one that’s a year or two old is quality of shot selection. Every day begins with 1,000 doors in front of you: which door do you go through to make the most progress? Shot selection is choosing what to focus on at the expense of other forgone opportunities. It’s one of the most critical skills in running a startup.

As a company matures, I think it’s normal (ideally) for judgment to improve and shot selection to get a lot better, resulting in less wasted time and more forward momentum. This can be driven by many things. Maybe it’s having enough live users to give you feedback on market fit. Or you found some role models to help with targeted advice. Or you figured out how to optimize against your true traction metrics.

Looking back on the first six months of my own startup, I’m embarrassed by how terrible my shot selection was. I routinely spent time on features that ended up having zero impact on the business. I was especially prone to working on short-term (1 to 2 week) projects that seemed fun and harmless, but wasted a lot of time when you add them all up. I simply wasn’t focused enough. Thinking back on it now makes me cringe.

Here are some things I wish I had never spent time on:

1. Invite-only access. Invites are traditionally a strategy for stoking interest in your product while also managing the scalability of your roll-out. In my case, all I accomplished was making some users angry when I left them on the invite list too long. It seems strange in retrospect that I would keep new users out of my app on purpose, but at the time I thought it would help with virality. Also, implementing the numerous moving parts of an invite-only access system consumed much engineering time.

2. Real-time traffic measurement. I went through a phase where I used GoSquared (and before that, Chartbeat) to observe users of my webapp in real-time. I was able to see how many visitors were on my site, where in the world they were coming from, which pages they were viewing, etc. Vanity metrics at its finest. And, of course, I had to waste time checking the traffic dashboard 10 times a day. Nowadays I ignore real-time stats and just use Google Analytics to look at historical trends.

3. User admin dashboard. Another engineering boondoggle, I built this amazingly detailed admin panel where I could view all my registered users along with matching social and biographical information pulled from the Qwerly API (since acquired by Fliptop). For example, if a new user Fred Bloggs signed in to my app with Facebook, I could also see Fred’s LinkedIn profile, his handle on Twitter and his picture. The original purpose of this dashboard was to identify influential users to further engage with, but I never found the time. And after my app gained more than a few thousand users, the dashboard became unscalable.

4. Experimenting with ads too early. I was so eager to attempt monetizing my site with ads that I placed grocery-coupon text links on the front page when I only had a few thousand uniques/day. Don’t know why I was surprised when only about ten people clicked on the ad. It was a cold-shower lesson in low CTR’s. You need real traction and attention on your site to attract quality advertisers, too.

5. Amazon affiliate links. Another monetization experiment I shouldn’t have tried in the first place, but was driven by an unfounded belief that users would want to purchase cookbooks while browsing my site. Building this system also consumed several days’ worth of engineering time—it required learning about the Amazon Affiliate API, writing code to match cookbooks to recipes, and so on. The final profit was less than $1/day. I have yet to meet anyone who is making serious money on the side with Amazon links.

6. TechCrunch. TechCrunch can be a good way to gain visibility among investors and the tech community in general, but in my experience, it didn’t have value beyond that. (Perhaps some SEO value.) I regret I expended so much mental energy figuring out how to get my startup covered on TC. When I finally did make it onto TechCrunch, both the article itself and the resulting traffic were very underwhelming. I should have concentrated on other outlets that are less tech-centric and more suited to my site’s audience—for example, LifeHacker and kottke.org, which ended up yielding 100x as many signups as TC.

7. One-off partnership projects. I once spent about two weeks building a custom prototype with my API as part of a potential partership with another company. The partnership was never fulfilled and the final result ended up basically zilch. There’s nothing particularly wrong with this situation; sometimes you have to gamble a little bit of upfront time for a larger gain down the road. But two weeks worth of time is way too valuable in the early days of a startup. I should have just said no thanks to the partnership and instead devoted that time to making my product more awesome.

8. Coffee meetings / “let’s jump on a call”. This is rookie stuff, but initially I was caught off guard by how insidious a “quick” meeting or phone call can be. They always go longer than expected, can eat up half a day of work, then destroy the productivity of the other half because of lost focus and having to play catch-up (especially if you’re writing code). It’s important to concentrate on meetings that add value or build relationships, and avoid the people who just want to pick your brain for their own purposes.

9. Excessive side projects. Side projects are like comfort food for coders. I’m a believer in doing a side project here and there to keep burnout at bay. Unfortunately, there was a period where I overdosed on them and was working on enough side projects to rival my real startup. I think it’s particularly easy to fall into this trap when your company is new but not brand new, i.e. traversing the Trough of Sorrow. Better to just suck it up and stay focused on product.

10. Working from home. I spent the first year of my startup working from a home office. After that, I moved to a spartan desk in a shared space in downtown Palo Alto. My productivity from the office space is easily 2-3x that of the home office. I can’t explain it well but there’s a mysterious psychological barrier that prevents me from truly cranking when I’m working from home. If I had started on day one working from an outside office, I’d be way further along on my company now. At the outset, I had no idea that would be true, though. Hindsight.
It’s easy to criticize with the benefit of hindsight, but I believe most of these mistakes were avoidable at the time. They all distracted me from the one strategy that always works no matter what—iterating on your product vision, listening to feedback, and working towards making your product awesome.




-----
good article...

Cheers,
June