Xobni Man Walking Some thoughts from an entrepreneur

My coworkers and friends know that I buy everything from Amazon, including things like socks, pillows, and laundry detergent.

What don’t I get from Amazon?  Perishables like milk, drinks are too heavy to ship, and cash from the ATM.  But that last one seems silly if you think about it.  Why can’t I order 20 ten dollar bills from Amazon?  Security shouldn’t be an issue below a certain amount, say $500; I’ve ordered more ‘expensive’ things.  Just a funny thought…

P.S. I recommend this life hack.  Be sure to get Amazon Prime.

I was just talking with Greg, when he coined a new term:

Rotational inertia is what you get when you start “spinning” (selling) something to someone.  When circumstances change, and you have to spin in the opposite direction to the same audience, you must overcome and reverse rotational inertia.

This post is a response to Matt Maroon’s post today called Poker People. Matt talks about how straightforward poker players are with each other as compared to Silicon Valley investors.

Read the rest of this entry »

…is when he is a refugee in Austria, escaped from Hungary. He badly wants to go to the United States. I can relate; there have been three or four times in my life when I really wanted something, in the way that you dream about it every night and you put infinite care into every part of getting it. Applying for Y Combinator, to start Xobni, was one of those times for me.

For those of you unfamiliar with Andy Grove, he was the third employee at Intel and its President (and later CEO) for over twenty years. He’s a prolific thinker and businessperson in the valley.

Andy is 20 years old. He had just interviewed with American students from the International Rescue Committee (IRC). These students are picking refugees to bring to America based on English skills, education, etc. He was to find out the results the next day…

“They had read off a list of names. According to people who heard the list, I wasn’t on it.

I felt as if someone had socked me in the stomach, then my heart started beating so hard that I could barely breathe. “Where are the IRC people now?” I asked. Someone said they were conducting another series of interviews at a school some distance away. I took off like a madman. I ran all the way through the cold, dark streets. My heavy shoes hurt my feet as I ran, but I didn’t care.

Sweat was pouring down my face by the time I reached the school. There was a familiar long line of people waiting to be interviewed. I didn’t wait. As the next person emerged from the interview room, I brushed past the person whose turn it was supposed to be and pushed in to stand in front of the table.

The IRC representatives were a different group of students than the ones who had interviewed me the day before. They stared up at me blankly. I didn’t give them time to stay anything. I swiped the sweat off my face with my hands and, still panting, started talking in English as fast as I could.

I explained that I had been interviewed yesterday, that I was not selected, but that I really, really wanted to go to the United States. One of the interviewers asked me why. I told him I had relatives in New York City who would take me in, that I was a chemistry student, that I thought I would become a good chemist, and that I belonged in the United States. The words poured out, not eloquently or coherently, but I talked and talked as if I could overwhelm their objections by the sheer volume of my words. I almost didn’t dare to stop talking, but finally I ran out of things to say. I stood there, panting slightly and still sweating profusely.

The students looked at each other and smiled, then one said, “Okay, you can go to the United States.”

I was speechless. I couldn’t believe my good fortune. I wanted to hug every one of the young men sitting on the other side of the long table.”

I’ve been thinking a lot about APIs lately. Xobni works with MS Outlook; we use its APIs to get to mail data. Xobni’s current value comes from organizing this data in novel ways for our users.

There’s still a ton of great things Xobni can do to (a) tap into other sources of data, including but by no means limited to mail data, and (b) make all of this useful data more accessible to other developers.

Xobni isn’t the only group of developers thinking about this problem. It’s clear to everyone that rich personal and inter-personal information is locked away in data silos.

Social Graph

People are trying to free social graph data, e.g. OpenSocial and the Social Graph Foo camp this coming weekend.

At the end of the day I think it’ll get done. The data is spread through email, social network, IM, and phone platforms, but that won’t stop progress if there is real value to be unlocked. That second piece is what I’m worried about; we are at a lack for compelling use cases of the social graph data. Here are the ones I know of: dopplr, evite invitations, setting permissions based on friendship, and search. What am I missing?

Other Personal Data

People are important but there’s more to life. Facebook, for example, has all kinds of data entities, and all of them are interconnected. It’s a powerful approach. Here’s my illustration.

It’s been a while since I’ve written. Life just hasn’t been the same since getting real users. I feel like blogging is kind of like deep sleep – it helps you organize your thoughts and recent things you’ve learned. Since launching at TechCrunch40, though, I’ve been facing all kinds of new challenges. Some of that terrain is behind me now, so I have a long list of great things to write about.

I was thinking recently about my grand strategies for life. How do I make really important decisions? What principles do I want to inspire my actions?

First, I want to kick ass. I want to be effective, and that means hitting hard.

I still remember Xobni’s first summer. I worked until about 6am when the sun came up. That forced me to go to sleep. Then I rolled out of bed and started writing code in my boxers. We took a few hours off a week to be social, and we read new Paul Graham essays as they came out, but that was it. That was probably the hardest I’ve ever worked for such a long stretch, and it was really tough. Really tough. But we produced. We laid the ground work for Xobni, and learned a lot about our market, customers, etc. It’s the best and most personal example I have of kicking ass.

Kicking ass is about being effective. The other two principles relate to what I want to kick ass at.

Second, I want to always learn. Most people who join Xobni do so because it’s an amazing learning opportunity. Matt left grad school because he’d learn more starting a company. Gabor left Google because he wanted to escape the politics and big company environment. Etc. It’s a great principle because all of these guys are now better equipped to kick ass.

Finally, I want to be a missionary. [1] Spread the word about what’s good and true. If a new grad is considering two career options, I’d love to offer whatever experience I have to help them make a good decision. If someone is raising money, I want them set up for success.

These are small examples. They get bigger. Look to Bill Gates’ latest philanthropic efforts for an example of a missionary. He has conviction that the world needs to change, and he’s up in arms. That’s an awesome example.

Paul Graham thinks that more young hackers should start startups, so he started Y Combinator. You can tell that he legitimately wants to improve the state of things. It’s just evident to anyone paying attention. He’s not interested in money. He’s interested in spreading what’s good.

Notes

[1] I stole this idea from John Doerr.

I mentioned in my last blog post that Xobni is looking for great hackers and a senior QA lead. The kind of people we’re looking for have basically infinite options when choosing where to commit themselves. Why would they chose to work at Xobni?

Aside from our acclaimed product, superhuman team, and great market, we also have a killer culture. I hope this video helps us show that off.

(Edited: fixed a few accounting mistakes towards the bottom.)

Suppose you wanted to make $1 million per month by selling software. You can either go for a few lucrative customers or lots of low paying ones. A half minute in Excel and you have a table.

Ten minutes in MS Paint and you’ve got a nice graph.

The sweet spot for high margin software offerings seems to be in the sub-$10 per month range. Rhapsody charges $13 per month. Yahoo Mail is $1.60 per month. Mozy is $5 per month. [1]

Enterprise customers pay in the same range for commoditized products. MS Exchange costs about $10 per user per month. FogBugz costs $20 per user per month. I’m sure enterprise antivirus is a brutal market for providers, but I don’t have numbers because they don’t have public pricing.

Enterprise customers are willing to shell out the cash in non-commoditized product categories, though. Salesforce.com charges about $100 per seat per month, but they’re going to have to drop their prices soon because of pressure from Microsoft and others. Bit9 is a new kind of enterprise security, so they’re set for a couple of years.

Anyway, so this is the range we’re interested in:

How do we get 100k paying users? Just for fun let’s assume that you have a freemium model. Most users aren’t going to pay, but some will because they get the bike horn that makes the moooo sound.

The rule of thumb is that about 1% of free users will convert to paying customers. The number varies greatly by vertical, product, etc., but let’s just go with 1%. Some quick math and you have another table.

So if you charge $10 per user per month, and 1% go premium, you need 10 million users to hit $1M in revenue per month. For reference, Outlook has 500M users, Skype has 200M users, and Thunderbird has 8M users.

Skype had about 50M users when they were bought. At that time there were about 4M people simultaneously online, so only a fraction of those 50M were active. Why did they get bought for billions? My guess is that a large portion of active users were paying customers. They were obviously still in growth stage. They also enjoy high margins and had recurring revenue for each user.

So what would $1 million of revenue per month do for you, anyway? $12 million in annual revenue, to be sure. Beyond that you’re back in the land of heuristics. Google has a P/E (price to earnings) ratio of 50. If you got the same ratio with margins of 50% then your company would be worth a nice $300M.

Margins vary hugely by business. Grocery stores get about 2% margins in a good year. Software, luckily, traditionally has high margins because the cost of supporting an additional user is so low. 50% sounds extreme, but consider Skype. They don’t have infrastructure costs, and they probably have no more than 50 or 100 people. That’s the kind of company Xobni can be. This 50% margin on $12M annual revenues can support a burn rate can support a head count around 30 or 40 people. That’s not a bad place to be when you hit the $1M per month milestone.

Other public tech companies have similar but not higher ratios. Redhat is at 65, Yahoo is 50, Sun is 40, Oracle is 30. Microsoft is 20, but damn do they have lots of revenue! Salesforce.com is 1053, but until recently was infinite. They’re still selling the dream.
These numbers can end up all over the board. Zimbra sold for $350M on revenues of about $15M, and probably way lower profits. The list goes on. Growth and strategic value to acquirers seems to have the biggest impact. [2]

With some more elementary school math, we can use these numbers to derive a value per user. An average user on the $10 per month row gets us ten cents per month, or $1.20 per year. That’s sixty cents of profit. With a 50 P/E ratio, that’s $30 per user, not far from Fred’s numbers.

P.S. Xobni is hiring. We are currently looking for great software hackers and a senior QA lead.

Notes

[1] The sad part about these prices is that both Rhapsody and Mozy are low margin businesses. Rhapsody is net losing money per user. Yahoo Mail is a high margin business, but it doesn’t matter because the price is so low.

[2] If you want more examples, look here for a list of MS acquisitions, and have fun googling.

(This message was pre-recorded.)

I usually edit two pieces of code when I’m squashing a bug. First I fix the specific bug, and then I go on a hunt for ways to prevent similar bugs in the future.

Can I make the code fail faster?

Bugs that happen earlier in the execution path are easier to investigate.

If an invariant was destroyed, the sooner you detect it the better. It’s great if you can check for the invariant right after you modify the data. If you have complex invariants then you might consider adding a CheckInvariants() function that gets called periodically.

If the bug doesn’t throw an exception, can you test for it and throw an exception when the condition occurs? Exceptions codify error conditions. If you collect exception reports then you’ll know how popular a bug is, you can see patterns of occurrence, you’ll know for certain when it’s fixed, and so on.

Can I make the bug more apparent?

The worst bugs only appear if the user is running Japanese Windows and singing in the shower while holding the control key. As a programmer I don’t do that often so the bug won’t be caught until release. Bugs get exponentially more expensive the longer it takes to find them. You will fix bugs earlier if you can make them more apparent, and everybody wins.

This principle is true even at the small scale. There’s a product category just for apps that tell you when you broke the build one minute after it happened. [1] You get to fix it quickly, instead of getting the email from your annoyed coworker one hour later. There are real dollars there.

Can I make this bug easier to fix in the future?
You might be able to make the bug cheaper to fix if it reappears two months later. Add a comment block detailing how the bug happened and how you fixed it. Reference the bug’s ticket number. Modify the code to include more relevant info in the error report.

One of the things I hate about C# (and Java too?) is that you can’t get the locals of a stack frame. This feature would save us lots of time and money when deciphering error reports from the field.

Can I make the bug impossible?
Wow, wouldn’t it be great if you could do this for every bug??

We don’t use static code analysis at Xobni yet, but that’s something I’d love to change. It can catch so many simple problems. You hard coded a string instead of putting it in the internationalization string table. You write ‘if(x == null) x.Foo()’ instead of !=.

Can I make the bug more obvious to humans?

Great software design makes bugs obvious. Is there some refactoring I can do to make the bug scream at anyone who reads or writes it?

Bonus!
I also like to comment out all exceptions before shipping a release build. That way users never see any errors! [2]

Notes

[1] This idea is called continuous builds. We recently implemented continuous builds and we all have fewer headaches.

[2] (From the joke department.)

[8:01:54 PM] Gabor Cselle says: public enum Options {
Chipotle,
Subway,
Quiznos,
Other
}
[8:02:46 PM] Gabor Cselle says: // yes, we’re pretty predictable, it’s safe to use an enum here

[8:03:36 PM] Adam Smith says:
List open = new List();
foreach(Options option in Enum.GetValues(typeof(Options))) {
if(IsOpenOnLaborDay(option)) {
open.Add(option);
}
}

Adam.OutputStream.WriteLine(Array.Join(open.ToArray(), “, “);

[8:05:42 PM] Gabor Cselle says: internal readonly Person k_nerdContestWinner = adam;