[edit: I should probably have made a stronger point that I am talking about early early early stage startups. 2-5 people, pre-funding. Carry on!]

There is a tremendous amount of venom loosed towards so called “business guys” or “idea guys” (as I’ve called ‘em) in the startup community. They can’t catch a break.

A big part of the reason is that we’ve all had that hellish experience with the MBA. The guy who has his “big idea” and “just needs someone to build it”, presumably why he stands back and waves his hands a lot (and occasionally plays golf in space). You can find CraigsList littered with ads by biz guys, incredulous that hackers aren’t falling all over themselves to execute on their ideas.

It doesn’t take a lot of hunting around to learn that great technology startups aren’t generally built on the shoulders of a great business guy. Here’s a gem of a quote from a gem of an essay:

If you work your way down the Forbes 400 making an x next to the name of each person with an MBA, you’ll learn something important about business school. You don’t even hit an MBA till number 22, Phil Knight, the CEO of Nike. There are only four MBAs in the top 50. What you notice in the Forbes 400 are a lot of people with technical backgrounds. Bill Gates, Steve Jobs, Larry Ellison, Michael Dell, Jeff Bezos, Gordon Moore. The rulers of the technology business tend to come from technology, not business. So if you want to invest two years in something that will help you succeed in business, the evidence suggests you’d do better to learn how to hack than get an MBA.

Take a look at the genesis of your favorite startup and find me the MBA. Find me the program manager. They just aren’t there.

So your startup doesn’t need a business guy. In fact, there seems to be pretty compelling evidence that having a business guy in your software startup has a reverse corrolation with success.

So, take a walk, biz guy. We don’t need you.

Or do we?

It turns out that it’s not so simple as that. Startups are diverse– each startup has different needs. How do you think SalesForce.com would’ve done if it’d been started by a bunch of hackers? How do you think Zappos.com would have fared if it wasn’t started by a zealot for customer service and support? There are plenty of examples of great software startups with a critical founder who wasn’t really a technologist (arguably, Apple is a great example of this). And there’s no denying that for startups that have something that they intend to CHARGE for, a business guy is incredibly valuable– so long as he actually can dive in and do sales largely full-time. Most business guys I know turn there nose up at cold-call style sales– which is really what you need.

So what does every startup absolutely need?

Startups need BUILDERS. People who make stuff. Absolute animals, as Paul Graham puts it. People whose output is positively awe-inspiring.

But startups also need a product genius. Someone who has great instincts about what people want and need.

So what’s to stop a business guy from being a product genius? Not a darn thing. Sure, there are plenty of biz guys who are stupid about products, but it certainly doesn’t take much work to find a hacker who has a truly awful idea for a product.

It’s just not so simple.

But I’ll tell you something that is simple: a hacker or designer’s output is strongly correlative with their sense of ownership. Here are a pile of modifiers that can effect a sense of ownership:

• The builder *IS* the “idea guy”. It’s his idea. (+50)
• The builder isn’t the “idea guy”, but has the problem that the product is trying to solve. (+40)
• The builder isn’t the “idea guy” and doesn’t really have the problem that the product is trying to solve, but can really empathize with the problem. (+30)
• The builder is a principal author of HOW the solution is built, even if WHAT is being built isn’t entirely his baby. (+20)
• The builder stands to make truckloads of money if the product takes off. (+20 * the number of truckloads)

In a world where startups are beset with endless challenges and frustration, anything you can do to heap on a feeling of ownership among the people who are actually building stuff is critical.

If there’s any indisputable advantage that startups have over big business, it’s the insane amount of sheer output that a startup can generate. Part of this is just being lean and bureaucracy-free, but a huge part of it is the motivation that comes with a sense of ownership. I think it’s pretty safe to say that the bigger a company gets and the more pure-play “managers” that get hired, the farther away the builders get from this feeling.

For all the startups out there who have a biz guy playing golf in space while a collection of hackers and designers slave away on the idea that they don’t really love…. Well, I don’t think you are necessarily doomed to failure. But I think you’ve taken an uphill road that’s a bit too steep for my tastes.

I think that common sense goes a long ways in UI design… But not all the way. It’s a learned skill like any other. I was reading up on calendar controls today (which I’m obsessed with, by the way) and caught a great post by the curmudgeonly Jakob Nielsen. Here’s the snippet I like best (he’s describing the top application design mistakes):

“Affordance” means what you can do to an object. For example, a checkbox affords turning on and off, and a slider affords moving up or down. “Perceived affordances” are actions you understand just by looking at the object, before you start using it (or feeling it, if it’s a physical device rather than an on-screen UI element). All of this is discussed in Don Norman’s book The Design of Everyday Things.

Perceived affordances are especially important in UI design, because all screen pixels afford clicking — even though nothing usually happens if you click. There are so many visible things on a computer screen that users don’t have time for a mine sweeping game, clicking around hoping to find something actionable. (Exception: small children sometimes like to explore screens by clicking around.)

Drag-and-drop designs are often the worst offenders when it’s not apparent that something can be dragged or where something can be dropped. (Or what will happen if you do drag or drop.) In contrast, simple checkboxes and command buttons usually make it painfully obvious what you can click.

Common symptoms of the lack of perceived affordances are:

• * Users say, “What do I do here?”
• * Users don’t go near a feature that would help them.
• * A profusion of screen text tries to overcome these two problems. (Even worse are verbose, multi-stage instructions that disappear after you perform the first of several actions.)

When I tested some of the first Macintosh applications in the mid-1980s, users were often stumped by the empty screen that appeared when they launched, say, MacWrite. What do I do here, indeed. The first step was supposed to be to create a new document, but that command was not shown anywhere in the otherwise highly visible Macintosh UI unless you happened to pull down the File menu. Later application releases opened up with a blank document on the screen, complete with an inviting, blinking insertion point that provided the perceived affordance for “start typing.”

Someone posted an interesting “Ask YC”, asking:

“How to start becoming an entrepreneur while still being an employee?”

Having done this twice (started a company that eventually turned into a full-time startup), I settled in to reply. Before long, it was clear that my response was long enough to justify a blog post.

I’ve done two part-time-to-full-time startups (one resulted in a startup the sold, the second is RescueTime– currently a YC-funded company– cross your fingers).

At the end of the day, I think Paul Graham is right when he says:

“The number one thing not to do is other things. If you find yourself saying a sentence that ends with “but we’re going to keep working on the startup,” you are in big trouble. Bob’s going to grad school, but we’re going to keep working on the startup. We’re moving back to Minnesota, but we’re going to keep working on the startup. We’re taking on some consulting projects, but we’re going to keep working on the startup. You may as well just translate these to “we’re giving up on the startup, but we’re not willing to admit that to ourselves,” because that’s what it means most of the time. A startup is so hard that working on it can’t be preceded by “but.”"

In the beginning, however, it’s not always practical to dive in full-time. And sometimes when your idea is off-the-wall and also easy to build a prototype for, it’s smart to whip something out just to see if what you’re building is as cool as you think it might be before you take the plunge.

So if you’re too poor or too unsure to do the right thing for your business and dive in full-time, here are a few things that seemed to work for us when we did it part-time:

1. You need a co-founder and some cheerleaders… If you can’t find 2-3 friends who are really excited to be beta testers for what you’re building, ponder changing your direction. The arguments for a co-founder are many and varied. For a part-time effort, they are essential to keep you on-track and working. At some point, you’ll hit a motivation wall… If you have a partner who is depending on you, you find a way past that. If you don’t, you’ll often lose interest and find something else to entertain you.
2. Pick a day or two per week where you ALWAYS work, ideally in the same room as your co-founder(s). ALWAYS, no exceptions. We did 1 weekday evening and 1 weekend day. That doesn’t mean we weren’t working other days, but having a fixed schedule helps you through the phases of the project that might not be so fun.
3. Have a boat-burning target. What will it take for everyone to dive in full-time? 5,000 active users? 10,000 uniques a week? Funding? That should be a shared understanding. You don’t want to have one founder ready to go full-time when another has reservations. This is easy to gloss over, but you should really nail it down. I’ve lost 2 co-founders to this issue (they weren’t ready to dive in full time and I was). It wasn’t fair to them and it wasn’t fair to me.
4. Pick an idea that is tractable. Every business is a theory. If your theory is, “we can build a better web-based chat client”, that’s something you could test quickly. If you’re theory is “we can build a car that runs on lemonade”, that’s just not going to work as a part-time effort. The scarcity of available time should force you to distill the idea to the absolute essence that is necessary to test the theory. No extraneous features!
5. Understand that your v1 ia probably going to suck. Read David of Weebly’s post on persistence. It’s a long road. My first startup was a ridiculous fluke (2 months and then sold). 99% of the overnight successes you read about were slogging in the muck for 5 years before the night in question. Be prepared for a long journey and be surprised if your startup is an immediate hit. So with your v1, look for the tiny little flicker than you might be on to something to motivate you to make it better. Every week, make it better than last week and see if that flicker of light can be fanned into a tiny flame.
6. If you’re going to screw off at work (everyone does), spend it getting smarter about the stuff you don’t know. If you’re a coder, read a few design/usability blogs. Read up on what motivates angel investors. Research competitors and write down what they do well. Get brilliant at SEO (it’s not hard). Write a LOT more (blogging helps). Think about virality and research the heck out of it. This is all more valuable (and hopefully just as fun) as looking at LOLcats on Reddit. All that being said, be aware of the fuzzy line between using your cool-down time at work for your startup and stealing time/resources from your employer. If you’re paid to do a job, you need to do it.
7. [edit: Thanks to Ivan in the comments] Be sure you own your startup. I’ve had the fortune to work in places and companies where there was very clear ownership of “after hours” work. If ownership of your personal IP is not clear, do NOT rely on the good will of your employer. Greed can do funny things to people, even if they were initially big supporters of your startup.

At the end of the day, you want to prove whatever you need to prove as quickly as possible, so you can dive in full-time. Near as I can tell, there are plenty of startups that have started as “hobbies”, but you need to take it out of that phase as soon as you can. There is nothing that drives a team forward like the fear of public failure, debt, and starvation. Leap off the cliff and start building the airplane on the way down and you might be surprised with what you can pull off.

Everyone with a fine liberal arts education should be familiar with Zeno’s Dichotomy Paradox (props to Steve Leroux for helping me remember his damn name).

“Suppose Homer wants to catch a stationary bus. Before he can get there, he must get halfway there. Before he can get halfway there, he must get a quarter of the way there. Before traveling a quarter, he must travel one-eighth; before an eighth, one-sixteenth; and so on.”

I can think of no better description of software development releases (or product development in general). At some point you have to say “fuck it”, fall forward, and confound Zeno. Throw caution to the wind and ship too early and you ship crap– and your users know it. Aim for perfection and days stretch to weeks as each day brings you asymptotically closer to greatness (which sucks the life out of any team, IMO). I know teams who literally have worked for a year or more without shipping anything to anyone. I don’t know how they can do it.

But, any way you slice it, those last few days before a release feel like you’re wading through rancid molasses.

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.

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.

Evan Williams (founder of Twitter, fellow corn-fed midwesterner-turned-dotcommer, and someone I get to meet via YCombinator!) has a fabulous post on how to evaluate new product ideas. To sum up his excellent post, here is the matrix he came up with:

Tractability
Question: How difficult will it be to launch a worthwhile version 1.0?

Obviousness
Question: Is it clear why people should use it?

Deepness
Question: How much value can you ultimately deliver?

Wideness
Question: How many people may ultimately use it?

Discoverability
Question: How will people learn about your product?

Monetizability
Question: How hard will it be to extract the money?

Personally Compelling
Question: Do you really want it to exist in the world?

He follows the list by running through a few of his startups through the matrix to see how they fare.

I don’t know if Evan put it first on purpose, but I tend to think that tractability is the most important factor by an order of magnitude. Why? Because there is a pretty good chance that what you think you’re going to build and what you go to market with are radically different. Take a few minutes and ponder this outstanding quote from Fred Wilson’s “Why Early Stage Investments Fail” post:

“…Of the 26 companies that I consider realized or effectively realized in my personal track record, 17 of them made complete transformations or partial transformations of their businesses between the time we invested and the time we sold. That means there a 2/3 chance you’ll have to significantly reinvent your business between the time you take a venture capital investment and when you exit your business.”

Another great quote:

“My friend Dick Costolo, co-founder of FeedBurner, describes a startup as the process of going down lots of dark alleys only to find that they are dead ends. Dick describes the art of a successful deal as figuring out they are dead ends quickly and trying another and another until you find the one paved with gold.”

Given that you have a 2/3 chance of having to reinvent your business (or, as Costolo would put it– you have a 2/3 chance of your first dark alley being a dead end), what could possibly be more important that tractability?

“”Marketing is a Tax You Pay for being Unremarkable”

Robert Stephens
Founder and Chief Inspector, The Geek Squad

While I think that’s a touch on the simple side, it rings pretty true. What would happen if all the people who were concentrating on advertising and PR instead started focusing on making the offering and/or the customer service BETTER?