"After a few pitches, entrepreneurs realize that the distant future is safer territory than the immediate."

Check out "How to raise money without lying to investors" on VentureHacks.

Nvidia's CEO on Entrepreneurship

This is a great (audio-only) talk by Jensen Huang, Co-Founder and CEO of NVidia: Vision Matters.

He talks about the importance of having a big vision when starting a company and shares some fun anecdotes on raising money and setting price points. Some of the stuff he says ("Favoring Moore's Law over Customer Feedback") is diametrically opposed to the currently favored worldview (the Eric Ries / Steve Blank style of customer demand based iteration), which I found refreshing.

Jeff Bezos on Everything he Knows

This is a great video: "Everything I Know - the List is Short"

Business Opportunities around Google Wave

How could you build a business with the newly announced Google Wave?

Wave is like email mixed with collaborative editing and instant messaging. It's conceivable that the Google Wave paradigm will replace today's group collaboration tools with something less fractured (everything's in one place), universal (document equals IM equals email) and more centralized (one application instead of many). Heck, it could even replace email itself.

What's most exciting, though, is that Google Wave will be open source. Unlike with Google Apps, you'll be able to look inside the box, deploy your own servers, customize, and extend.

Let's say that Google will be able to pull this off, and soon after launch, Wave has millions of users. What business opportunities exist around Google Wave? What can startups, software vendors, and consulting companies offer that could be profitable? Here are a couple of ideas,. I've rated them 1-5 stars based on how promising I think they are.

Migration Tools and Services

Companies today use Outlook and Exchange. If Wave is good enough, some of today's users of Outlook, Exchange, Notes, or even SharePoint could be convinced to switch, either in whole or just for a part of their workflow. Third parties could offer migration tools and services that allow companies to get started and port their existing data - Terabytes of emails and documents - into Google Wave.

Verdict: I think this could be a reasonable play for small service providers and ISVs, provided that Wave is convincing enough for companies. For highly customized Exchange installations, there's no one-size-fits-all approach, so there's a lot of room for service providers and tailored solutions. No billion dollar opportunity here, though.

Rating:

Enterprise Wave

The key to making organizations switch to Google Wave is to make it sufficiently full featured for enterprise use. In particular, it's hard to see anyone switching from Outlook without tightly integrated group calendaring, task lists, and mobile sync. Since Wave is open source, you could add those in and sell an "enterprise version" of Wave under your own brand.

Verdict: This could work. Google doesn't have a stellar record in catering to enterprises. Compare the measly 10 million hosted Gmail accounts with the 40 million paid Zimbra accounts out there. Google is better with consumers, and might leave a lot of room for an enterprise version of Wave built by a third party. Played well, this is a billion-dollar opportunity.

Rating:

Extensions

There is no shortage of plugins, extensions, and add-ins to Microsoft Outlook: Think Xobni, Gwabbit, ClearContext, and many little helpers that can you extract attachments, schedule emails, or remove duplicate contacts. Some of these tools are highly profitable paid extensions, and it's conceivable that you could build and charge for extensions that add useful features to Google Wave.

Verdict: As a business, this isn't promising, at least for the next few years. What makes building Outlook plugins so attractive is the size of the target market - 400 million users. It took Gmail 5 years to get to around 150 million users, and I expect the adoption curve to be similar for Google Wave. It's conceivable that Google Wave will one day add a "Google Wave App Store", where users can buy extensions and themes for cash. If that happens, this becomes much more exciting.

Rating:

Hosting

Since Google Wave is open source, you can host the server on your own hardware. There's no shortage of hosted Exchange providers - a quick search will give you many offerings that will give you an exchange account for $9.95 a month. Similarly, you could host Google Wave accounts for a fee - similar to Acme Wave in the keynote demo (1h:06).

Verdict: Could this work? It depends on what Google will offer for free. My guess is that Google Wave will start as another piece of Google Apps, where it's $50/user account/year, with plenty of space. In hosting, Google has economies of scale - noone runs more servers more cheaply. So forget beating Google on price. Thus, the target market is be reduced to the segment of users that wouldn't trust Google with their data. That segment is pretty small.

Rating:

Wave as a Feature

I imagine that this will be the most common type of use for Google Wave. Once it's released, websites will replace systems for commenting and user-generated content (e.g. restaurant reviews) with Google Wave. I imagine this to be much like the Google Wave inside Orkut, shown in the keynote at 0h:24. Integrating Google Wave can be useful for certain type of sites - think Yelp, Foodoro, Divvyshot, or RetailMeNot.

Verdict: This is not a business by itself. It's something that could improve your existing offering, much like using Disqus will increase the quality and number of comments on your page. I can imagine scenarios in which having Google Wave on your site would improve its quality, thus leading more traffic, which in turn gives you more Pro account signups, ad clicks, etc.

Rating:

Forgot Something?

As you may have noticed, most of my examples in here come from my understanding of the Microsoft Exchange and Gmail ecosystems. Due to my email-heavy background, I've approached this from an email-centric perspective.

You may also have noticed that there's no five-star idea so far. If you have one, let me know or leave a comment below!

Update: Seems like I forgot one very promising idea: An App Store for Google Wave

Releasing Something New, Every Week

I'm trying something new: For the next four weeks, reMail will be releasing a new feature or product every single week.

Pretty radical, eh? Here's why I'm doing this: I'm a perfectionist and need to be constrained by time rather than "good enough". Here are the three recent events that triggered this experiment:

1. I organized a Post-YC dinner for my former batch and invited Dropbox Fouder/CEO Drew Houston to come and speak. He talked about Dropbox's private beta period, and how early audiences don't care about perfect; They care about new ideas and usefulness.
2. I built reBoxed, an experiment in email prioritization, in 3 days, with that specific deadline in mind. Despite being a work-in-progress at launch, the result was successful and gave me plenty of new ideas.
3. I need to start testing my hypotheses about email users (if you've been reading this blog, you know I have a lot of them), and there's no better way to do that than to give them a product to play with.

I have a couple of these products/features in various stages of completion, so I know roughly what I'll be doing for the next few weeks. I'm also thinking about charging for some of these products and features from the get-go, Eric-Ries-style. "Buy before you try", if you will. More on that later.

I'm leaving for a weeklong trip to Europe on May 26 to visit some friends, and that week will conclude this experiment. Until then, watch this space.

reBoxed - An Experiment in Rapid Development

I have a little bit of free time on reMail's main product right now and I've decided to implement a possibly great idea I've been thinking about over the last couple of weeks. reBoxed is a new take on inbox prioritization - and I'll build and launch it in the next 3 days - 75 hours. My deadline is to have it done by Wednesday 3:00 pm Pacific time.

My timeline is something like:

1. Today Sunday: Learn a technology I'll need to understand for reBoxed to work. Write a Design Doc.
2. Monday: Implement all functionality but keep the UI super crude.
3. Tuesday: Brush up the UI. Meet with PG at office hours in the afternoon to get his feedback.
4. Wednesday: Write deployment tools and deploy to a server. Launch.

Don't set your expectations too high: The first version of reBoxed will likely suck. reBoxed is an experiment in how quickly I can develop and launch a mail-related product. And a way to prove out a possibly great idea.

I'll post a daily update on this blog.

Our Productivity during YCombinator

Here's a chart that you might find interesting: reMail's productivity graph during the past YCombinator batch.

We're using Pivotal as our bug tracking system. In Pivotal, you assign points to features and bugs. Roughly, the points represent the time and difficulty of completing each item.

During YCombinator, we had weekly iterations of reMail ending on Tuesday nights, when the YC dinners take place. We'd scramble to have something new version to install, or a new feature to show off every Tuesday. Pivotal shows how many points you finished in each iteration, which yields this graph (click to enlarge):

• In the beginning, we made little measurable progress because we were learning technologies that would let us do more powerful things on the phone. While we learned a lot, that learning wasn't expressed in points.


• The demo we showed on prototype day looked great and was well-received, but we had taken a lot of shortcuts to make it look good. Prototype day was a huge boost for us because after it, the pressure was on to deliver what our demo had promised. We installed our first alpha a few weeks after.


• Investors loved us on Demo Day. But little product work got done immediately before and after the event. We spent many days getting our presentation into shape, and rehearsed the talk ten or twenty times. Also, we took a few meetings in the week after Demo Day, which were inspiring but caused a huge drop in terms of Pivotal points.


• Fueled by the enthusiasm of Demo Day, we got a lot of stuff done. In the iteration afterwards, we started a huge push to tie up the loose ends of our Alpha version. Yet, that spike looks a little too high because Pivotal doesn't (and shouldn't) let you do half-points - there were many small things we fixed that only took a few minutes each.

This graph might not generalize to any YCombinator startup. This batch had multiple companies that had already launched when the program started, and their curves would probably look very different. Others that launched during the program would have their spike earlier on, etc. But this might give you an idea of what happens when heat is on to deliver every single week.

Update 1: The graph doesn't reflect that an estimated 50% of each week's points would be completed on Monday and Tuesday, before the YC dinner. The YC dinners add an enormous amount of pressure to deliver. Wednesdays were usually slow days as a result of that.

Update 2: While the shape of our curve doesn't generalize, there are two effects that probably do: After prototype day, we had a pretty good read of what needs to improve and that sped up things. Also, the post Demo Day productivity slump due to follow-up meetings was probably something that every startup experienced.

Update 3: After reading some of the comments on Hacker News, I'm now thinking that a better measure might be "number of net lines of code produced per week". Maybe I'll post that graph here at a later point.

"It's the Small Steps"

Here's one of my favorite blog posts. I have no idea how I found it in the first place, but I've kept it bookmarked in my browser for those moments when I'm feeling overwhelmed: Patricia Handschiegel - It's the Small Steps:

"After an hour of talking, the reporter said, 'Wow, I’m really surprised at how long and hard you worked, Patricia. You always assume when somebody has success, it was easy.' There is absolutely nothing easy. Any success, however you define success, is going to make you work harder than you could have ever imagined. Add in a start-up, and the to-do list can be enormous. This is why I constantly tell those I advise or mentor to create a list of their goals, a timeline for those goals and then, from there, the individual, small steps to get to each of them. Doing this makes the work easier, more digestable and less overwhelming. [..]

If I were to try to do everything I want to do at once, nothing would get done. I focus on the small things and so far, pretty much everything I’ve set my mind to has happened."

The Early Stage Spaceship

In our pre-release startup, it feels like we’re on a spaceship sometimes, trying to reach a distant planet.

Picking a Planet

With that little ship, and planets that are far away and far apart, you want to make darn sure you're flying to a nice one:

• You don’t want to find yourself on a planet that doesn't seem to support life, like the Facebook app planet.
• Or one that is as unwelcoming like the music planet, where you will find a great beast called the RIAA.
• You'd also want to steer clear of wanting to fly to the operating systems planet: It takes too long to get there and is inhabited by John Hodgman and that annoying Justin Long kid you kind of want to smack in the face.

Oh, you also don't want to pick a planet to which another, bigger spaceship, is already on its way. For example, when Microsoft flies to a planet (for example, video game consoles), their spaceship looks like this:


We looked at various planets through a telescope, and found one that seems pretty appealing and is not too far away. So how do we get there?

Thrust vs. Stabilizers

We're pretty fast already, but are thinking about adding more thrust and stabilizers.



Thrust, in this metaphor, are more engineers/coders/designers who accelerate development and help us get there faster. Adding too much uncontrolled thrust, can lead to veering off course. We could add stabilizers, product and project managers who can keep us on track, but also don't directly add to getting there. We're still debating the right balance.

We’re on Our Way

Please remain seated with your seatbelts buckled. The captain will have some weather updates for you when we’re closer to our destination.

A New Setup

A little more than a week ago, we moved into an apartment in Foster City/San Mateo. The big plus here is that we don’t have to rush through an hour of traffic to get to meetings in the Valley. Suburbia provides fewer distractions here than you would have in San Francisco, but the hipness level is low, and a good bar is hard to find.



Fewer distractions have allowed us to make progress on the prototype. It turns out that this is more productive than working in a coffee shop. My commute now takes 10 seconds, and my workspace has a nice Dell flatscreen monitor and my favorite ergonomic keyboard. In addition, we have blocked YCombinator’s Hacker News and similar sites on our router, which resulted in an additional productivity boost.



Things are progressing well on other fronts, too - I’ll keep you updated. For now, it’s back to work.

Questions for Cofounders

I'm in the middle of solving the highly nonlinear equation of idea, cofounder, and investment. I wrote about my cofounder search here (if you're interested, drop me a line).

Startups fail for many reasons: Running out of money, no product-market fit, and cofounder drama. Now is the time to protect against drama. I want to set reasonable expectations on both sides and have good conflict resolution mechanisms.

Below is the list of questions I want to address with potential cofounders, somewhat inspired by Dharmesh Shah's list (his list is more generally applicable - mine is more about personalities).

1. What's your long term life goal? Some want to be the next Bill Gates, Larry Page, or David Filo. Others want to get rich and retire. How did they come up with their goal? How does this startup fit into that goal? If this fails, would they do another one?


2. What kind of company do we want to build? Should it be a 37signals – a profitable thought leader? Or do we want to shoot for the moon and be a Google? Get a clear reading on your cofounder's ambitions and long-term commitment.


3. What kind of work environment do we want to create? How are we going to treat employees? Lavish perks like Google? Strict hierarchies like GE? Think about what kind of employees you want to have, how open you want to be with them, and whether you want to hire fresh hotshots or experienced veterans.


4. How are we going to split responsibilities? What will we be doing on a daily basis? The best situation is where founders all have clear ownership of one part of the product, or processes like fundraising and bizdev. Make sure you can trust the business guys. Avoid situations where cofounders with similar backgrounds all focus and battle about one part of the puzzle.


5. How are we going to resolve conflicts? Is it enough if we have a one-on-one meeting every week where we discuss problems, or do we feel more comfortable with a written mechanism? A friend pointed out the book Under the Radar which described the Red Hat founders' protocol: A founder with a problem could write a one-page memo on letter paper. The others would have to respond in writing within the next 24 hours.


6. What are our preferred work patterns? You'll have to be able to stand each other all day. Make sure you understand each other's work styles, hours and quirks.


7. Who makes the final decision? I.e., who's the CEO? Multiple founders might want this this position. It seems prestigious but it's hard. Choose wisely.


8. How much of the company will each of us own? A conversation that can easily get heated. Equal parts are probably wrong. Cofounders who contribute less to the equation should get less. Yet it's hard to measure contribution. Also, you should vest - agree on the parameters.

Once you get into the details, the list goes on endlessly. Are we going to sign emails "Founder" or "Co-founder"? Do we have full access to each other's calendars? Who's going to authorize payroll? Do we reimburse our cell phone bills? Most of these won't make a difference though.

Let me know if I'm forgetting something. I'd love to hear your thoughts and experiences from similar situations. What results did you get out of these conversations? Any sources of drama I forgot?

P.S.: I recommend keeping Dharmesh's questions and conflict lists bookmarked.

What's in a Cofounder?

I’m currently recruiting a cofounder for my new startup, and I'm in talks with a couple of people. The choice of cofounder is the most important decision I'll be making anytime soon, and I've thought a lot about what the ideal candidate would look like. Below is a list of criteria I came up with.

1. Honest and open. It's important to work with people you can trust, especially under the pressure of a startup. I’d like to work with someone who is open about their feelings and intentions. A low-drama person who doesn't avoid confrontation if it leads to better decisions.


2. Technical ability. Specifically, this is the ability to make sound technical decisions, and to implement a large part of the product in high-quality code. The controlling variable for the success of this startup depends on that we can launch and iterate a useful product quickly, and my cofounder needs to contribute to that in a major fashion. Ideally, my cofounder would have a degree in computer science, and work experience in an engineering-centric environment such as that of Google or Microsoft.


3. Long-term commitment. I don't want to pull a build-and-flip, and the current environment has made that scenario very unlikely. I can imagine staying with this company for decades, and I expect that my cofounder make a multi-year commitment after some initial period. If after a month, we discover that it isn't working out, that's OK, but I want to avoid the drama of a cofounder bailing when the company is in full swing.


4. Enthusiastic about email and messaging. I believe that this is a field full of billion-dollar problems. I would like to work with someone who shares my optimism.

In the beginning, a large majority of our time will be spent hacking, but we’ll both be spending 10-25% of our time on business stuff. In YCombinator style, I’d like to work out of an apartment. Living and working together is the most effective way to get a product out quickly. We could stay in San Francisco, but I might want to move somewhere around San Mateo, which is strategically situated close to investors and potential employees, and provides fewer distractions than the city.

It's in our best interest to understand each other's styles before we embark on this journey. I'd like to chat, hang out, and work with potential cofounders for four days to a week. That should give us enough time to see if we gel.

If you're interested, drop me a line. Please include your resume.

A Good Time to Start a Company

Fabrice Grinda is one of my favorite entrepreneurs. He writes:

Aspiring Entrepreneurs: There is no better time to start a company!

The opportunity cost has decreased as many high paying jobs have disappeared and employment opportunities in general have lessened. If you have a job, companies will have less room to give generous bonuses and/or raises.

It’s going to be harder for entrepreneurs to raise money, but competitive pressures decrease dramatically in downturns giving you more chances to establish yourself as the leader in your field and more time to do so. [...]

If you have been thinking of creating a company, now is the time to make the plunge!

Paul Graham writes:

The economic situation is apparently so grim that some experts fear we may be in for a stretch as bad as the mid seventies.

When Microsoft and Apple were founded.

As those examples suggest, a recession may not be such a bad time to start a startup. I'm not claiming it's a particularly good time either. The truth is more boring: the state of the economy doesn't matter much either way.

People have been asking me what the downturn means for my plans. The answer is "little". I want to be very capital efficient, and if the investment climate is indeed as bad as the doomsters say, there will just be fewer of us, working more slowly on fewer features. The product might turn out even better.

I Want Your .com For New Startup

My new startup needs a name and the corresponding .com domain. I've spent hours and hours trying to come up with something good. Why not crowdsource it? My blog now has over 400 subscribers. Thus, there must be someone in my audience who owns the perfect domain name for a new email / communications startup.

Here's my "wishlist":

• It has to be a .com as people have difficulties with domains like del.icio.us


• If possible, I'd like to closely follow Guy Kawasaki's naming guidelines.


• Unambiguous spelling: It should be easy to map from how it's pronounced to how it's spelled.


• I like alliterations such as FriendFeed, they really stick to your mind. Not a must, though.


• Either a name that has something to do with communications ... (good examples are PostPath, TellMe, Gmail, or Twitter);


• ... Or a word that sounds good and can be used for any type of business, such as Google, Skype, Yahoo, Zimbra, Groove.

To give you some more inspiration, I like these words: shine, glow, joy, happy, dream, sky, light, utopia, drum, jet, jam, fun, run, hop, leap, fly, flow, fast, now, right, easy, wow, zap, clean, and fresh. (Yes, I've tried combinations of these and ones domains I liked were taken.)

Do you have a .com that fits these criteria? Let's chat! My email address is here.

If you don't have a stack of .com domains piled up, please send a link to this post to your friend who does. Thanks for your help!

Xobni's Journey to the Right Product

This is the second of a three-part series on the Xobni launch. Come back on next Monday to check out Part III of the story. Co-written with Marie Baca. An abridged version of this article was featured yesterday on GigaOm.

I often speak with entrepreneurs applying for funding from YCombinator, and when I do I give them this advice: the most important decisions you make are the ones in the beginning of the process. Choices like what product to build and what market to serve determine whether you’re headed for failure or a multi-million dollar exit. Marc Andreessen, founder of Netscape, calls this "product/market fit" and says that it’s the only thing that really matters when it comes to building a company.

It's fair to say that at Xobni, is that we stumbled into product/market fit. We initially built the wrong product, but then we quickly corrected our course.

Building the Wrong Product

When Adam first wrote up our YCombinator application, Xobni was called "EmailDM"—the DM stood for "Data Mining." Adam included demos of how EmailDM would summarize emails, highlight important passages, and so on. Eventually this vision morphed into Xobni Analytics, which lets you analyze email usage by creating a diagram of your message traffic.



The initial plan was to offer this program to companies as a productivity tool. Workers would install the software into Outlook and use the data to find ways to become more productive. We would then offer this product to corporations so managers could remotely monitor employee email productivity.

This Boston Globe article, the first major coverage of Xobni, illustrates why this model was a bad idea: employees would feel like they were being spied upon. But even beyond the spying problem, Xobni Analytics was the wrong product to build for a more important reason: users would install the software, browse it for a bit, and then close it and quickly forget about it. Analytics was not a sticky application that tempted users to come back again and again.

The Xobni sidebar is completely different. There are many features beyond the analytics that add value for the user. Plus, the sidebar sits right next to the inbox, so users are exposed to it for the 2 hours they spend checking their email every day.

Our mistake became even clearer when we shopped early versions of Xobni around to venture capitalists. We first tried to remedy this problem by designing something called Xobni Feeds, which allowed users to create different types of XML queries that we would show up in the sidebar. Only later did we realize that this way too much flexibility for the average user, and we decided that it was a much better idea to show relevant, people-based default information.

In short, we discovered that our product was most successful when it provided focused information about people, not numbers. It is essential that entrepreneurs remember that they are serving an audience of individuals who need simple solutions to their everyday problems.

Why Outlook?

Unlike the initial problems with product development, Xobni made the right decision early on to target the Outlook market. There are an enormous number of Outlook users out there (around 350-400 million, depending on whose numbers you trust), and yet there is also major dissatisfaction with the program.



After Outlook, users most often requested that we build Xobni for Gmail and Apple’s Mail.app. However, both of those clients have much lower pain levels than Outlook. In addition, the addressable market is much more interesting: Outlook users are more likely to have business credit cards so if we ever switch to a freemium model, we can charge them. Also, there’s a strong demand for advertising partnership opportunities within Outlook, an application that users interact with for hours each day.

I like to think of it this way: there are a huge number of Outlook users out there who are so frustrated with the program that they feel like there hair is on fire. What Xobni offers is a cold bucket of water.

A Generalized Architecture

One of Xobni’s major differentiators is that we didn’t build a simple addin for Outlook, but an email application platform. Whenever we write software, we aim for a more general solution than what is required by our current needs. We can easily build new applications and build integrations into other email clients, as these leaked screenshots illustrate.



Building this platform took a significant amount of time and effort, but I’m happy that Adam made this decision early on: It allows us to quickly iterate on functionality, and build new, exciting products in the future!

Choosing a Look

Here are some mockups I created more than a year ago that illustrate the looks we had in mind for Xobni. The mockup on the right was our original choice: it blends nicely into Outlook, almost as if Xobni was built into it from the start. We created the third one almost as a joke, to show how the sidebar would look if we used a funky color palette.



We decided to go with the bright, saturated colors, because it would have what we call the “What the heck is that?” effect. Jane would walk by Jack’s desk, and see a bright blob on the right side of his Outlook screen, and she would blurt out: “What the heck is that?” Jack would have to explain Xobni and what it does, and Jane would probably download it once back at her desk.

Search as an Afterthought

Ironically, Xobni’s search function was initially an afterthought – Greg Duffy implemented it just a few days before we launched our private beta at TechCrunch 40. Even considering the rapid pace at which startups do product development, this was an immense accomplishment: Xobni’s search is twice as fast as Outlook’s, thanks to highly optimized and efficient search indexes. That combination of speed and usefulness make search our top-clicked feature.

Launch!

Let’s say you have a great product. How do you know when you’re ready to launch? That’s what I asked Gmail creator Paul Buchheit two months before our launch date. At the time, Paul was pretty skeptical, but he inspired us with an idea he repeated at Y Combinator's Startup School: Before launching Gmail, Eric Schmidt gave him the assignment to find 100 happy users. After talking to users, and eliminating their top feature requests and bugs, they met that number and thus, Gmail was ready to fly. We followed a similar spirit by adding the Are You Happy box to the product, and by listening closely to customers via our support team and users we knew personally.

We originally launched a private beta at TechCrunch 40, a conference where 40 startups launch their product within 2 days. The schedule was very tight, and the days leading up to it were a chaotic blur. In retrospect, we probably launched a little earlier than we should have. The product hadn’t been heavily tested at that point, yet we grew our user base by 50x that very day. With our open beta launch on Monday, we were finally ready in terms of speed and stability, and the feedback since has been extremely positive:

"Xobni is such a simple idea, but it is sure to radically change how you handle email." - Tom Spring, PC World

"For those who work in the corporate world - where Outlook is still heavily used - Xobni's public beta will be of great help, allowing them to quickly find and expose the data trapped in their inbox." - Sarah Perez, Read Write Web

"This plugin looks like it would be insanely helpful. Gmail, are you paying attention? :)" - Comment by Ross M, Lifehacker

"Given that Outlook is pretty much de rigueur for most corporate e-mail systems, this should be a welcome addition for those of you trapped in Outlook at work." - Scott Gilbertson, Wired

"Oh Microsoft, you’ve missed the boat yet again it would seem." - Zach Epstein, The Boy Genius Report

"In just a short few days, I can already share my belief that Xobni is a must download for Outlook users." - Kevin Tofel, kjOnTheRun

"Designed to make it easier to handle the deluge of daily messages, Xobni integrates with Outlook and - to quote our original review - becomes an invaluable weapon in the daily war with email." - Tim Danton, PC Pro

Thanks to Evan Solomon and Sean Ellis for reviewing drafts of this article. Be sure to check out Part III of this series, where I’ll talk about how we built a great company, assembled a superstar team, and built a culture that encourages building solid products.

Further Reading

If you enjoyed this post, be sure to check out my earlier blog entry, The Days before the Xobni Launch which talks about the days before launching our private beta at TechCrunch 40.

If you haven’t done so yet, read the first part of the series "Hello World, Meet Xobni".

Startup School: Surfing the Wave

The most interesting pair of talks at Startup School were Greg McAdoo from Sequoia, followed by David Heinemeier Hansson from 37 Signals. McAdoo talked about how to build a billion dollar company, and Hansson spoke about how to create a small profitable one.



The contrast couldn’t have been bigger: The Sequoia talk was about big words and surfing metaphors. The ridicule in the video's comments shows that the audience was displeased. Hansson, on the other hand, wanted small web companies that charge users. A simple model. People loved it.

In reality, the two talks were about different things. Hansson talked about how to create a profitable business with a web site. This is a well-known if underused model. McAdoo, on the other hand, was talking about building the next Cisco, PayPal, Yahoo, or Google. Billion dollar businesses, not million dollar ones.

In order to make a really successful billion-dollar startup, you do have to have find a large, growing technology market. Marc Andreessen agrees. Xobni, for example, found great market when we changed our focus from an analytics package to today’s sidebar, a product people use for hours a day. We’re now in a much better, billion-dollar market, have a wider audience, and greater odds of success.

So why the disconnect? Two reasons.

First, I think that smart technical people – the kind that inhabit the computer science halls of Stanford, Berkeley, MIT, CMU, ETH and Oxford – have a strong appreciation for beautiful technology: The beautiful technology that, for example, made Google what it is today. But it’s not the technology that created that success, but the fact that people wanted fast full-text web search, which was just happened to be very hard to build. The market did it, not technology.

Second, when business guys mention "identifying customer needs", "designing a platform", and "assembling great team DNA", hackers shrug. Why use these big terms for talking to customers, drawing up architecture diagrams, and recruiting that great hacker? Because these are abstractions. Just like you wouldn't discuss each for-loop when describing what that method does, VCs use these abstractions to communicate effectively. It often takes experience to really understand the meaning behind them. Once entrepreneur, you’ll understand what it means to identify markets and customer needs, and you won’t need the baby steps spelled out for you. You’ll be using those big words yourself.

The Startup School Career

I’m at YCombinator’s Startup School at Stanford. There’s a great audience here with lots of hackers. Still, I think a lot of the guys here came with the belief that their first startup is going to be Facebook. That’s not going to be the case.



There’s a disconnect between the public image of doing startups and the realities of the game. The press wants you to believe that startup founders, through a fantastic idea, become billionaires, complete with Boeing jets and petting zoos.

Reality is different: Entrepreneurship is a career. You start your first startup, maybe with backing for YCombinator, and it will probably go well: Paul Graham said that 57 of the 80 startups they funded are still alive, for some value of alive. You’ll learn all these things that today’s speakers are talking about - angel and VC funding, building a product, finding a market, and making money. You might get sold, might go bankrupt, and maybe you’ll make some money. But with a large probability, you won’t own a Boeing jet when you’re done.

The great thing is that you can put another dime in the slot. The second time around, you’ll have more experience, more firepower, and a track record. This was best illustrated by today’s first speaker, who by the time he got around to doing Xfire, instantly got a term sheet, and 100 days later had a built product. Jeff is another great example of this model.

Startups: It’s not a shot for the moon, it’s most likely going to be your career.

PS: I remember the first time I went to Startup School back in 2005. Seems like a decade ago!

Two Views on Europe

I'm on a short trip to Europe to take care of some things. It's nice here: Well-architected buildings line pretty streets with cozy cafes and without homeless people.

But is it a good place for entrepreneurs? Two friends have sent me two articles with vastly different viewpoints.

The first comes from Foreign Policy: "Europe's Phiosophy of Failure". It points out the anti-capitalist attitudes found in Germany's and France's school textbooks. The author, Stefan Theil, claims that these textbooks portray capitalism as brutal, economic growth as a health hazard, and entrepreneurs as money-grabbing dictators. Having gone to high school in Germany myself, I didn't find this to be true. But times and textbooks may have changed since the pro-American 1990s.

The other article comes from BusinessWeek: "Europe's Crop of Billion-Dollar Babies". It features Giuseppe Zocco, co-founder of my favorite European VC firm, Index Ventures. Zocco talks about how "there are a lot of European companies founded in the past 5 to 10 years that can, with the right support, become billion-dollar companies." Can Europe build bigger companies than Silicon Valley with investors that have a longer time horizon? We shall see.

If you liked this, read: Why Startups don't Condense in Europe.

Giants vs. Sprinters

This is a crosspost of an article I wrote for Swiss Entrepreneurship blog Synetgies.

Most revolutionary new technology products and Internet services come from a handful of large companies and small startups. What's the secret sauce?

Successful and profitable large companies such as Apple and Google invent and produce such products as the iPod, the iPhone, Google Maps, and Gmail. In contrast, startups have developed products and services such as Google Search (back when Google was a startup), Hotmail, PayPal, YouTube, Blogger, Facebook, and Twitter.

Users and the press rave about these products, and they have generated large valuations and profits. How does this kind of product innovation happen?

In this article, I'll contrast product development at large and small companies. I've experienced product development at Google (where I worked on Gmail and some unmentionable projects), Yahoo (where I interned at the end of the last bubble). I'm currently working on my startup, Xobni, where my role involves development as well as setting engineering and product priorities. We're a small team of 10 people and are building new ways to search and navigate your email. Thus, I've seen both ends of the spectrum.

Between the two extremes of small and large companies, there are a few common denominators:

• Both types of companies start with good people who are smart, well-educated, and passionate.


• They provide good tools: High-end workstations, great infrastructure, and good benefits. For example, Google will pay employees for health insurance, serve free food and drinks, coupons towards buying hybrids, gym memberships, and the like.


• They set a culture that is centered on engineers. Engineering and is the scarce resource, as it hard to find excellent engineers who can create great products. Openly or covertly, PR, Marketing, Sales, and HR are seen as second-rate citizens. This is most clear at Google, where engineering is kept on the main campus, but HR and PR are located in "Siberia": office buildings so far away that employees have to use bikes and scooters to commute to meetings.

Most people think of "innovation" as "ideas". But there's no lack of good ideas. At Xobni, we have an internal Wiki page with hundreds of product ideas. At Google, there's the ideas mailing list on which you can find thousands of employee-submitted proposals for new features and new products. I'm sure that Microsoft has an equivalent tool. But anyone who has added to that Wiki, or written to the ideas list knows that they are the place that ideas go to die.

What really counts is execution: At large companies, the ideas that survive have a strong proponent who will get support for the idea, find colleagues to work on it with, defend it in meetings, and launch it to a public. This is what happened at Gmail: Paul Buchheit started working on a webmail client, found others to work with, defended it against VPs who said that an ad-supported model would never work, and managers who said that it is prone to extinction because of Microsoft's control of JavaScript. At startups you'll find the same process (but less meetings): Xobni's most popular feature is search, but it was two of us who took it from a feature added as an afterthought one of the core pieces of our functionality.

Yet, there are many differences. Technology giants and startups both have their own set of advantages that play in their favor when executing against ideas:

Large technology companies

• Resources: As the name says, large companies have tons of people. Once management is convinced of the viability of a project, they can put people, infrastructure, and money to work to make the idea become reality. Giants move slowly, but once they do, the earth starts shaking.


• Experienced management: In Silicon Valley, senior managers at large companies typically have startup experience. They started or joined small companies that got bought or went public. They know how to manage innovation and push interesting projects forward.


• Instant credibility: When Apple, Google, Microsoft, or Yahoo launches a new product, the world listens. If a startup had released Google's phone SDK, there would not have been weeks of Google phone speculation in the press, weeks before launch. Consumers will feel safe buying new Apple products when they're launched, because they would know where to buy and what level of quality to expect. Startups have to build a really good product and build it from the start, build press relationships, and resort to guerilla marketing as needed.

Startups

• Focus, clear priorities: You'll never see a company as focused on progress as a startup. At Xobni, the number one priority is to get high-quality software out the door. There's only this one project: There are no distractions, no talks to attend, no other projects for engineers to switch to. We're all sprinting towards a clear goal.


• Aligned incentives: At startups, employees have significant amount of stock in the company, and their financial future is highly correlated with the success of the company. Thus, there is only one controlling variable: Their contribution to the product. If they can add or improve features, they will. On the other hand, large corporations attract resume stampers who are sometimes guided by self-interest: Their priority is to rise in the ranks, not contribute to overall success.


• No lockstep development: Startups have small numbers of people working on small products. Large companies work on large products with lots of people. These people require coordination and planning. For example, I've heard that the feature sets of Microsoft's Office suite are planned out two releases in advance, with two years between each release. This means that a product manager on Word knows what features the product will have in 2011. If you're an engineer at Microsoft and have an idea, it may not get executed upon until four years from now! In addition, there's the burden of reverse compatibility: Every new feature must be compatible with versions of the software that are decades old.

In summary, we explored differences in how startups and large companies run innovation and product development. There are some commonalities - great people, focus on engineering, and good tools - but startups have large advantages because they are more focused and have no existing customers, products, and profit lines to look after.

--

If you liked this article, you will also like Career Advice for High Achievers.

The Xobni Office, Thoughts on Startup Office Space

In mid-May this year, we moved from Adam's apartment into Xobni's now offices at Sutter and Kearney in downtown San Francisco. Xobni was 4 people. Starting Monday, we'll be 9.

Matt looked at dozens of offices. We looked at cheap places, expensive places, places in the Mission, Soma, downtown, and elsewhere. We had nicknames for our options - "Osgood", "Howard", "the dog place", and "the hot girl place" (a building populated by PR and advertising agencies). We went with "the Craigslist place", which was in fact one of the first we looked at. I think we chose well.



You're in a small startup and need to find office space for the team. What should you look for? I'm for inexpensive office space that works. No private offices, no prime office space, no pretentious architects or sixty story buildings.

Note that I won't be talking about how to find a broker, a lawyer, or negotiate with the landlord. Joel can tell you all you need to know about that.

Location, Location, Location

The first rule in real estate also applies to startup offices. You need to be in a great location. At Xobni, we have found that being in San Francisco is invaluable for hiring. Many promising candidates want to be in the city, not an office park in Silicon Valley. Some already live in the city and commute every day via car, Google shuttle, or CalTrain at the expense of 2 to 3 hours per day.

You want to be close to public transportation. The financial district and parts of SOMA are ideal because they're close to Bart, Muni, and the bus system. Parking is expensive but available. (We use the Sutter/Stockton garage.)

You also want to be close to the city center. We were two blocks away from the TechCrunch40 conference where we launched. Same for Web 2.0.

Here's the view from our window.

Eating and Drinking

We typically order in food for lunch and go out for dinner even though we have a fully stocked fridge and snack cabinet. You want to be in a place where this is possible without excessive travel; the hours after dinner are the most productive hours for writing code.

Our lunch options are quite extensive: burgers, salads, Thai, Chinese, Japanese, Korean, Indian, Hawaiian barbecue, crepes, burritos, pasta - you name it. Three of the four surrounding blocks seem to be dedicated to the purpose of feeding office workers. Dinner options are limited by the fact that everything in the financial district closes at 5 pm; you’ll find us at one of a handful of restaurants, Chipotle, the Westfield mall, or the Metreon.

We're also very happy to have a 24-hour 7-11 downstairs, and a Walgreens around the corner to cover our convenience shopping needs. When I need to step out for a bit, I usually grab a Naked juice downstairs and take a walk around the block. Being in the city is hard to beat.

Prime Office Space? Nope

When we were shopping for office space, we looked at a lot of fancy commercial real estate. But as a startup, you won't need fancy Class A space. Marble floors, and monumental glass-and-steel architecture won't make your startup more successful. Paul Graham says: "Professional means doing good work, not elevators and glass walls."

At Xobni, we went for office space with character. Our building was built in 1904, with all the charm of that era. It did come with one luxury, though: prewired Cat 5 Ethernet. The Scribd guys downstairs had to duct tape cable to the floor.

Layout

People have very strong opinions about what office space layouts should look like. Joel, for example, is a strong proponent of private offices. I think private offices are well-intentioned but go overboard.

You probably know that open layouts should be avoided. While everyone in the same room fosters communication, you'll find that you can't focus on complicated tasks because everyone interrupts everyone else all the time.

My experience with cubicles is slightly better. Google's building 41, where I spent all of my Mountain View time, is one big cubicle farm. While there are fewer interruptions, the noise level is still unbearable; cubicles don't filter sound well enough. I also found that Google's compression ratios are unwise. Productivity suffers when you squeeze together with 3 people in the space for 1 person.

We have rooms for 3-4 people each. This is about the size of an engineering subteam will have. Being around people who are all working on the same thing encourages communication about the right things, but keeps interruptions down. I put my 49ers cap and headphones on when I don’t want to be interrupted.



In addition to the offices, we have a central conference room for formal meetings. We also have a quiet nap room with a comfy couch. Taking naps at the workplace sounds unprofessional, but it does make everyone more productive. Adam, for some reason, seems to have missed the memo about the nap room.



There's also a "living room" with nice leather couches. We hold daily meetings with the entire team here. The huge plasma screen shows current bugs and work items, and stats about installs, beta signups, and plus support tickets.

Decoration and Furniture

We didn't get Class A space, but we did spend lots of time decorating our digs. We put opaque glass panes in a wall next to the living room to bring in more light. We painted our walls in Xobni colors, and put up blik wall decals. We recently gave everyone a $100 decoration budget for their personal workspaces. We have yet to see the results, but I'm sure at least one of the Xobnis will get something completely inappropriate.



You only have one back and if you spend a lot of time in a chair, it better be a nice one. That's why we spend money on Aerons, which we buy used from Craigslist. Everything else is Ikea. Everyone gets two desks (Mikael, $69.99) and drawers (Andy, $29.99). Two mikaels per person is a bit too large for our rooms, and we might need to move to a different desk setup when space starts running out.

Developers get three monitors, so some have remarked that our office looks like a Dell commercial. We need to call them up and renegotiate our deal on those LCDs.



I'm very happy with our office. We have room for about 9 more people, which should last for a while. The only item on my wishlist for the next office is a shower.

--

Thanks to Adam Smith for looking over an earlier draft of this.

If you liked this, you might enjoy: Photo Story: The Days Before the Xobni Launch.

Why Startups Don't Condense in Europe

(This post is based on a discussion at BarCampZurich back in October. The opinions expressed here are mine, not those of my employer or other attendees.)

When you ask a random but well-informed person, the only European startup he or she will name is Skype, but when you ask about the US, plenty come to mind: Google, Yahoo, eBay, Youtube, and many more. What's the reason for this disparity?

Many have written about this before, including Paul Graham, Xavier Comtesse, David Heinemeier Hanson, and David Hornik and I doubt that my thoughts on this are unique.

Still, here's my take on why there aren't many more European web startups:

1. Lack of Role Models. Even revolutionaries need role models. The fact that others have hit it big before makes startups look like a much more reasonable option. For Europe, there's the aforementioned Skype. In the US, there dozens of very successful entrepreneurs and companies to look up to.

For recent graduates such as myself, going to a big, established company seems like the smartest option. The traditional way of slowly climbing the ladder at a big company is hardwired in our brains.

2. Lack of Venture Capital. While you can start a business with two guys in a garage and a few of thousand Euros, you may at some point need money to grow and hire employees. This is where Silicon Valley's ecosystem of venture capital comes in. We don't have that here in Europe: Here, good VCs who are willing and able to take risks and give valuable advice seem few and far between.

3. Lack of Ambition. When Larry and Sergey started Google, they had global domination in mind. After all, organizing the world's information and making it universally accessible and useful seems like an ambitious goal.

In contrast, Many European startups often grow to a comfortable size of 10 to 20 people, and then stop. It's fun to work with your dozen best friends and enjoy a family-like atmosphere: If you grow any bigger, some of the fun melts away. While you can change the world with just a dozen people, I doubt that the 'next Google' will have just twenty or so employees, or grow organically from an existing small business. Europeans need to aim higher.

4. Attack of the Clones. Many web startups here are rip-offs of existing US companies with established business models. Alando may have started started it all: This Berlin-based company, started by the Samwer brothers in 1998, cloned eBay's functionality and UI in every detail. They sold it to eBay for $43 million after just 6 months, showing that you can win big by simply copying. For today's examples, look at Sevenload, Yigg.de, or Aimido. A little more creativity wouldn't hurt: The potentio upside of doing something truly original is much larger.

5. Fragmented Markets. The US has a single, relatively homogenous market of 300 million people. Almost everyone speaks English, payment systems are the same everywhere, addresses share the same format, and laws are very similar in all states.

The European Union has a total of almost 500 million people. It is a huge, largely deregulated, but heterogeneous market. This makes it unattractive to web startups: For every language and possibly every culture, you'll need a localized version of your product. You could start with one of the three biggest countries, but you'd still need to localize much sooner.

So what? There are many things that Europe is getting right. We have smart people, good universities, and attractive cities. It's easier for qualified people to get a visa in Switzerland than in the US, it's still possible to IPO without too much overhead, and tax rates are quite nice if you incorporate in the right country.

All Europe needs is a few rebels with great tech skills, original ideas, and good connections to VCs. People who fit this profile will ignore all the difficulties and just go for it.

--

Thanks to Nicolas Berg, Douwe Osinga, Christophe Dessimoz, Alexandru Balut, Philippe Schoen, Keno Albrecht, Florian Walpen, David McCreery, and Corsin Camichel for attending and participating in the discussion.