Tony Wright dot com

There has been a lot of chatter lately about alternatives to Silicon Valley. There is no denying that Silicon Valley produces more startup success than any other town. But is it cause or effect? Does SV add some secret sauce to the startup recipe or is it simply a place where a lot of geeks tend to congregate?

For starters, it’s a good idea to read Glenn Kelman’s outstanding post on Seattle as a startup hub, inspired by the New York Times piece on the same topic. TechCrunch fairly quickly blew the post out of the water, causing Glenn to post a solid (and humble) response. And, causing Alan to point out that Arrington is “being a wanker”. Fun stuff! I I’m a big Arrington fan, but I’ll second the sentiment… It’s easy to crap on an upstart. Windows people have been doing it to Mac people for years. “You’re so far behind, why are you even trying? It’s almost pathetic,” they say. Strange that you don’t hear that too much anymore from the Windows camp. Never count out an upstart!

As a founder who is currently hip deep in the YCombinator experience in Silicon Valley, my initial inclination was to return to Seattle in March. I’m currently rethinking that sentiment (but haven’t made any sweeping decisions). The purpose of this post is to publicly run through some thoughts on this and get some feedback.

As mentioned by just about entire world, Silicon Valley births more startups than anyone. By a huge margin. It’s ridiculous how far it is ahead of upstarts like Boston, Seattle, Austin, etc. It’s obvious to me that there are many more startup PEOPLE in SV (which is a big reason for the number), but are there factors there that make startups more successful? I’m going to run through the thing I think are critical for a startup and how I think SV adds to them. Call me out if I’m wrong or if I’m missing anything:

• First and foremost, a startup needs to build something people want. I don’t think SV really helps here. In fact, the “echo chamber” effect might cause founders to thing that people around the world actually think and behave like the geeks in SV. If you buy the argument that SV people are smarter/better than other folks, then maybe SV would get an edge here.
• A startup needs a great team. People who destroy problems. People who prioritize the right problems. SV certainly has the edge here in supply, but it’s difficult to determine how the demand effects that availability of these people. I will say that, while I have been pretty damn impressed with the people in SV, I don’t think they are any better than the best people in Seattle (but there sure are a lot of ‘em). And they tend to be more motivated, more monomaniacal, and more mercenary. Again, it’s hard to gauge supply and demand here– there are plenty of startup nuts in Seattle. I’m tempted to give the edge here to Silicon Valley because that’s what people smarter than me have concluded in the past, but that seems like a lousy reason to do it. It comes down to this– if I spend 6 months trying to build a small kickass engineering team, would I get a better team in SV? Or is the competition too fierce?
• Startups need to work their asses off. This seems to be one of Arrington’s main points: That Seattle-folk frolic on hiking trails and in kayaks instead of working on their startup. I think that’s pretty ridiculous. Passion and dedication aren’t geographically bound. There are plenty of SV people who bounce from party to party and conference to conference when they should be coding or slinging pixels. This is a personal trait, though you could argue that SV attracts more monomaniacal folks. Again, however, there’s no denying SV has the edge in supply– but does the demand outstrip it? Does more = more who are available?
• Startups need money and time. And, oftentimes, money can buy you time. Here, Silicon Valley bitch-slaps any of the upstarts. Anecdotally, it seems that funding in SV happens quicker (allowing founders to get back to building products). It also seems more available for early-stage companies. For companies who can’t bootstrap their way to a 12-18 month runway, this is huge consideration. This is also a big deal for companies without an obvious revenue model (Twitter?).
• Startups need blog and press coverage. SV wins here, too– by a healthy margin. I’m tempted to break out my “marketing is a tax you pay for being unremarkable” quote (I wish I could recall who originally said this). I firmly believe that you’ll get coverage if you’ve made something exceptional that people really want. There’s no arguing, however, that that you’ll probably get more if you go to the right parties and conferences, and manage to chat with bloggers like Scoble or Arrington.
• Distribution and deals. Technologists can often be snarky about the idea of bizdev, but it can be damn powerful. At the end of the day, many of the people you want to be doing deals with are probably in the Valley, and deals happen better if you can meet face to face ( and meet often, if necessary). There’s something inherently more comfortable about doing a deal with a company down the street. SV wins here, hands down.
• Lawyers and accountants. SV has more specialized services folks, but I’ve literally never heard of a startup who died from lack of a great startup lawyer. I think there is a healthy supply of these in any of the upstart hubs. Am I being naive here?
• People who buy startups. Acquisitions are like any other deal. They oftentimes happen because of face-to-face meetings and are probably likelier to happen if you are right down the street from your potential suitor. Seattle has Microsoft and Amazon. SV has just about everyone else who buys startups, notably Google and the ailing Yahoo(soft). Your mileage will vary, depending on your startup. A financial software startup might have a better chance of getting bought in NYC.

It’s probably safe to say that each of the above points carry different weights for different startups. A company like mine might not care much about great startup lawyers, but a company like Avvo might. A company like Twitter clearly cares an awful lot about funding– it’s a big play with a ton of upfront expenses and no immediate way to make a pile of money. But for a company like mine (which, ultimately, is probably going to live or die based on the value we can provide to businesses), will living in Silicon Valley give us enough of an edge to justify the expense and distraction of moving?

RescueTime will never be a purveyor of widgets (as a primary business), but there’s no denying that widgets are a damn good way to spread the word about your product, assuming that anyone actually wants to install them.

A widget that displays exactly how you spend your computer time may be creepy to some. As an old skool fella who is a bit more privacy-focused, I never really thought that a widget belonged anywhere on our near-term product roadmap. However, when we did our “What features do you want?” survey, thousands of people filled it out… 26% of ‘em expressed interest in a widget.

Sooooo, we built widgets. You can see mine to the right hand side of this blog– it’s a real time report of exactly what categories of my computer time I’m spending the most time on.

As we started thinking about it, RescueTime widgets could be used for all sorts of fun stuff:

• Lifestreaming. Just a fun little way to tell the world how you spend your time.
• Life hacking. We all know that discipline is hard. As Paul Graham says, there is nothing more motivating than the fear of public failure and ridicule. If your productivity data is available for all to see, do you think you’ll be a touch more productive?
• Workstreaming. Want to telecommute? Whip up a page for your boss with a few of your RescueTime graphs up there so he can feel “in touch”. For extra credit, you could throw a few static graphs ABOVE your real-time graphs, giving your boss graphs showing your pre-telecommute productivity.
• Create your own Dashboard! RescueTime has a handy Dashboard, but maybe you care about other graphs that require a few clicks. You could whip up your own “dashboard” (on a private page or intranet, maybe) that shows exactly what you want to see. Right now we really only offer two graph types (top apps/sites and top tags– or labels), but very soon any graph will be embeddable.
• Speaking of Intranets… You could drop a few graphs there to show what you’re up to. This will really start to sing when we introduce our groups functionality (allowing aggregation of multiple people into one graph).

Widgets are officially a beta product– we’ve got a few kinks to work out. For example, in Firefox there is a Flash bug that results in the status bar continuing to report “transferring data from RescueTime.com…” even though it’s not (you can switch to a different tab and back to make the message go away). Anyone know how to fix this?

I love the idea of contextual advertising, and I think Adsense has been a boon to entrepreneurship across the world. But it’s clearly broken. Today we received some nice feedback about RescueTime:

This is the 3rd such email we’ve received, and given that the concept of PPC advertising is increasingly well understood, is not an uncommon sentiment. Internet software has to be free, right? If so, how can a thankful user reward a company?

I wonder how advertisers feel about this? It’s no wonder that Adsense earnings are sharply dropping.

I just posted what I thought was a pretty darn interesting post about Google’s dominance in my life. By my count (and, with RescueTime, my count is pretty damn accurate), 13% of the time I spend in front of my computer is taken up by Google products.

Note that this is COMPUTER time– not just my online time.

Check out the post!

This Tuesday, I’m going to get a chance to meet Kevin Hale, who is the designer behind Wufoo and proprietor of ParticleTree. Kevin wrote a blog post last month that I think is one of the better summations of what it means to be a web designer. While I don’t want to dwell on the negative, Kevin has a pretty good description of why I hate to refer to myself as a designer (whether it’s “web designer”, “ui designer”, “interaction designer”, or whatever).

“For most designers, the relationships they care about most is the one they have with the design. They seem to only love the design and more often than not, they tend to love the design too much. These designers focus on their legacy at the expense of the audience. The user can suck it. You can hear it in the way they talk about the design and how they talk about their users. They’re arrogant and defensive.”

“…When I started working on Wufoo, I was definitely a bad designer. I thought I was hot shit and knew all the answers. I saw the user as a wild beast that needed to be tamed. He got in MY way. Use the tool the way I designed it, fool—not the way you think it should work. Thinking back, I remember being angry all of the time.“

Another great bit:

“On a web application, the design breathes and exhales through customer support. I’m so glad we have Chris on our team. He’s our customer evangelist. Through him, I’ve come to believe that there’s nothing more important than to monitor and man those incoming emails and respond as quickly as possible to every single inquiry, request and comment. It’s the pulse of not only the application, but the business as well. It’s in support requests that Wufoo lets us know when something isn’t working. It’s there that she lets me know when I’ve done something right.”

Give it a read.

Launching a big batch of new stuff is ALWAYS hard. It’s a lot of work and you’re generally making a substantial bet on some of your own instincts.

Since the launch (a few hours ago), feedback has been pouring in. Much of it is positive, but some is negative– which I think is par for the course any time you change a utility someone is used to. If you’re a RescueTime user, please log in and give us your honest/brilliant feedback!

Details of the release are here.

A reader took the time to shoot me an email with a few questions about design and startups… His questions were interesting enough that I thought they might be worth blogging about. So here goes:

Question #1 - What is the priority balance between programming and design/UI?

In my opinion, it totally depends on your startup, and where the core of your innovation lies. Take a hard look at the problem that you’re attempting to solve and why the current solutions to that problem are inadequate. As Paul Graham says, there’s no shortage of things that suck… presumably, you’re setting about to make something suck less.

How? Are you going to make it faster? More fun? More reliable? Cheaper? Sexier? More powerful? More viral? More social? When you’ve got a match between how you propose to innovate and the skills that your founding team has, you’ve got an exciting opportunity.

I should point out that brilliance can (and often does) manifest outside of a person’s core skillset… I think a person with a background in marketing would never conceive of the viral marketing machine that is Feedjit (the person who did is a PERL coder with a background in systems engineering). I don’t think a person with a journalism background would think that Digg or Reddit were such hot ideas. Innovation can (and often does) come from people who aren’t familiar with the “common wisdom” that maybe shouldn’t be so damn common.

But assuming a big part of your innovation revolves around “creating a better user experience for X”, you need someone who can create great UI. And while people who don’t dream in pixels and CSS can have flashes of UI brilliance, there’s no substitute for a great UI guy on your team.

I’m not going to go into detail, but obviously there are about a billion scenarios where coding is AT LEAST as critical as design. I’ll leave that blog post to someone else.

2. Should we have a layout/ UI figured out before programming has begun? (this is actually in retrospect, because we’ve already begun programming)

I’m a big fan of agile/scrum style development and the iterative design that goes along with it. That being said, I think the idea of having a cohesive vision in the form of a visual prototype is a great guide to build off of (just don’t be married to it). Making design shoot-from-the-hip-agile from start to finish can oftentimes result in a bit less focus and a product that looks duct-taped together.

3. If we are planning to have Facebook app/ MySpace widget a la Slide or YouTube, would it be best to focus on destination site, or on the widget side first?

Joe Kraus recently spoke at a YCombinator dinner and espoused the virtues of chasing the trends. I’ve always referred to it as the idea of “finding a parade and then marching in front of it”. I’d want to know more about what you were building, but on the surface I think that jumping on the Facebook bandwagon is worth doing if you think Facebook users will sign up. A lot of things won’t play well on Facebook (you won’t see us building a RescueTime Facebook app any time real soon). That being said, I’m not real bullish on Facebook’s long term future (from a platform perspective). A lot of the top Facebook apps are down as much as 70% from their peak usage.

I don’t imagine too many people who read this blog would be terribly interested in this, but I have to crow about it anyway. Joe (cofounder and roomie) and I figured that the move to Silicon Valley was an ideal time to adjust our diet and shave off a few pounds.

Since arriving (Jan 4), I’ve lost just over 9 pounds or (as I like to think of it) 36 sticks of butter. This is all with only nominal excercise and eating just about as much as I want. Joe (always the showoff) has lost 15 pounds.

If anyone cares, this was done with a “lazy” South Beach diet. Lots of veggies, plenty of lean meat/fish, and functionally zero sugar/simple carbs.

One of the recent YCombinator dinners that we attended featured Joe Kraus (who founded Excite and then later JotSpot, which sold to Google).

Like all YC guests, Joe had piles of startup wisdom… One of the things that stuck out to me (which I’d never heard much) was when he said, “when we launched JotSpot in beta, we launched it to too many people.” Huh? Too many users? That’s bad?

But as I look at my current workday, there are times when I wish that we had fewer users.

There’s some common wisdom about usability testing: Beyond 5-7 people, you really aren’t going to get much new/interesting data. There are diminishing returns.

Similarly, in a beta test where you are trying to understand your market, figure out your users, hone your funnel, hunt and slay bugs, and make your product better, there has got to me a point at which you have enough users to get the data that you need. For us, given that we have a web app as well as an installable app for both Mac and PC, our need for a diverse body of testers (in terms of the technologies they use) is probably higher than most. But I have no idea what the magic number is.

But we opened it up. To give you an idea of the consequences of this, here’s roughly the amount of communication that I do in a given day:

• 3-8 emails from our contact form - I respond to every single one of these. Sometimes that results in a follow up email that requires a second response.
• 20-30 feedback emails. We have a tiny form in our app asking for any thoughts a user might have. Even though we say below the form that we can’t respond to all of ‘em (and we point them towards the contact form / support forum if they want a response) I read them all and tend to respond to some.
• 3-5 posts on GetSatisfaction, which weird forum-sorta-thing. We try to respond to all of these, and many times they require some ongoing discussion.

When you add all of this up, it’s a pretty tremendous amount of communication. Say it requires an average of 3 minutes to digest and/or respond to each entity (this is 7 days a week, mind you)… That’s about 2 hours and 10 minutes PER DAY. Every day. Not counting the times that some emails require that I involve the whole team in a solution/discussion. That’s a lot of time for a company where all of the founders really ought to be spending almost all of their time working on development. And, as an effectively bootstrapped company, we don’t really have the budget for support staff.

On the Brighter side…

Still, despite the “costs” mentioned above, there are some pretty huge advantages to launching early and openly.

First off, you get over the biggest early hurdle that can slow most startups to a crawl. I think all founders are terrified that when they finally launch their business, no one will want what they have. So they’ll find any reason to delay it. Maybe they should focus on patents? Trademark research? Clever and innovative stock plans? Business cards? Fancy spreadsheets? Business plans? Marketing plans? Anything at all that will allow them to delay the possibility that people don’t like your app. When you’re out there and getting buried in feedback, all of that other stuff falls away… It’s incredible how much it focuses you on your app.

Second, you get to test your inherent marketability. Do people like talking about you? Do they tell their friends? Do they blog about you? Does your app have any virality? A closed beta really doesn’t allow this.

Third (and most important), in the sea of people who reach out to you is (hopefully) people who LOVE you. We’ve gotten feedback emails that simply say, “I love you” (3 so far!). We get long essays from users talking about their time management strategies and how RescueTime has helped. Literally 1-3 emails a day make me walk on air. Reduce that number to 1 a week and I’m not sure I could manage to make the sacrifices I’m making now to push the business ahead.

Fourth, there’s SEO. No need to get into the nitty-gritty, but starting the campaign of building incoming links and pagerank is something you should start as early as possible.

And, of course, there are nebulous concepts like “tipping points” and marketing momentum… If you hear about RescueTime enough, maybe eventually you’ll try it?

On the balance, I don’t know the right answer… And I suppose it’s different for each startup. I’d love to get other folks’ thoughts in the comments.

Joe, Brian and I have arrived in Silicon Valley unscathed, despite the monsterous storm blanketing the region. The trip was rainy, but thankfully the snow was fairly painless except for about a 10 mile stretch at the Oregon border.

We’ve settled into our furnished apartment and have shuffled it around to be dramatically more office-centric.

Not a lot of people know this, but RescueTime was built in a part-time way– generally evenings and some weekends from time to time, on top of day jobs and/or consulting gigs. It’s a testement to technologies like Ruby on Rails and MySQL that we could pull this off. I am incredibly excited to see what we can pull off now that we’re working full-time on this thing with zero distractions. The good news is that we’ve literally had thousands of feedback emails from our users– so we’ve got a pretty good sense of where to go.

Stay Tuned!