Adam Smith

09/04/2007

I Love Talking in C#

[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;

09/03/2007

Challenge Yourself, as applied to girls

I played squash today with Nomi from Peanut Labs. We’ve been playing together since we both started relearning the sport. We played six games and he won four of them.

It’s really good for me to play someone who’s better than me because they bring me up. I think that’s a good strategy for life – challenge yourself.

You know you’re challenging yourself when you lose or make mistakes. It comes with the territory. So if you’re not failing then you can’t be challenging yourself, and that is surely a bad thing.

Let’s apply this to girls instead of startups. If I’m ever more than about 25% successful with girls then I don’t think I’m challenging myself enough. If I’m significantly less than 25% successful, I’m challenging myself too much.

09/03/2007

Controlled Fires and Source Control

I deleted a big chunk of code recently. It was written months ago and just wasn’t in use, so it needed to go. There’s always an emotional attachment to code, though, so deleting it is like burning up your old love letters. You know you should probably do it, but you’re conflicted and it’s painful.

I bet the people who set off controlled forest fires have a similar feeling. They have to burn down trees and fauna that they helped create. But you’ve got to toss out the old to make room for the new.

Luckily, though, there’s source control! You can delete whatever you want and it will still be in your revision history. You’ll never go back and restore deleted code, but knowing that you could helps you do what’s necessary.

As I write this, I remember that there’s a whole namespace in XobniCommon that needs to die. I’ll take care of that tomorrow.

08/14/2007

Raising Money, Post Script

I forgot an important thought in my previous post, Raising Money.

Sam Altman: "Every morning wake up and say to yourself: 'They need me more than I need them.' Entrepreneurs are the limiting reagent in the startup equation, not investors."

Oh so true.

I previously wrote to upcoming Y Combinator companies about:

1 - Having courage to face reality and change direction as appropriate

2 - Raising their next round.

08/08/2007

Raising Money, Some Data and Tactical Advice, Letter #2 to Graduating YC Companies

Dear YC Graduate,

You’re presenting to a room full of investors this week. What should you know?

First, your demo will probably break, but that’s okay. Our demo broke. I fixed the code between our demo and the mingling. I remember telling investors “Look it works now!” but nobody cared. : )

Follow the introductions. Your lead investor will likely be a friend of an angel who you met through the advisor you met at your girlfriend’s father’s 55th birthday party. Joe Kraus has written about this. He says Take a cookie.

 

Here’s the tree of how we met our investors, of who introduced us to who. Click on it to get the full version.

Y Combinator has the largest branching factor in the tree; they introduced us to nine angels and VCs. 23 out of the 28 investors we spoke with are descendants of Y Combinator in the tree.

I've written about the value of Y Combinator before. You’ll basically be borrowing their network. They kick ass. [1]

We spoke with 16 angels and 12 VCs. Angels made 24 introductions; VCs only made four. The average angel introduced us to 1.5 other investors, but the average VC only introduced us to 0.33 other investors. That’s a 5x difference!

So angels can be helpful even if you’re raising a mostly VC round.

It’s an unwritten rule in the valley that if node x invests then every ancestor of x must be given the opportunity to invest. They can’t be cut out of the deal. You can probably figure out why.

Okay, tree stuff aside, you want to have more than one major investor. If one firm is out of line then the other firm will be there to say This is unreasonable. You’ll get more varied inputs. Having more than one major investor means you’ll take a little more dilution, but I think it’s worthwhile.

Our series A didn’t happen quickly. We excited the people we met with, but we were timid about getting started having recently closed a $100k angel round. One firm had interest, so we thought “We better talk to someone else to make sure we’re getting a good deal.” That incremental approach went on for a few months. We were always in late stages with one investor but just beginning the dialogue with another. Deciding to raise money should be an atomic decision; don’t try to just dip your toe in.

You want a small option pool. The investors will tell you that the company needs a large option pool. Balony. The debate is really about who pays for the option pool. VentureHacks has a relevant article.

Traunching is bad for the company. If your investors exercise the traunche(s) then it means that the company is now worth more than they’re paying you, so you're leaving value on the table. You might want to raise a smaller round and go to the market again when your valuation is higher. [2]

There’s also the 10x rule: you shouldn’t raise 10x more than your last round. I think it’s a pretty good heuristic. [3])

But some people will tell you to take money whenever you can get it. There’s also some truth in that.

Finally, Sam Altman: "Every morning wake up and say to yourself: 'They need me more than I need them.' Entrepreneurs are the limiting reagent in the startup equation, not investors."

Oh so true.

At the end of the day I’ve done exactly one financing and have very little experience. There are entire blogs devoted to these topics. I encourage you to read and learn all you can. Ask for help when needed. You’ve got a great network surrounding you.

Good luck, and best wishes,
Adam

P.S. In case you didn't receive my previous correspondence, I previously wrote to you about 'Courage to Change Direction' here.

Notes

[1] That said, don’t expect them to do the work for you. Just as the summer stage, you get back what you put into it.

[2] Yes, that does mean that you’ll spend more time raising money. And market conditions could change by the time you go to the market again. It’s a trade off.

[3] YC’s initial investment might not apply well as an input to this function.

07/30/2007

Courage to Change Direction, Letters to Graduating YC Companies, Letter 1

(The latest group of Y Combinator companies graduate in two weeks. There are some thoughts I’d like to share with them. This is the first of a few letters.)

Dear YC Graduate,

First, I hope you’re excited. I remember the rush of the super early days. Wow, what a rush!

It’s important for you to focus on your demo for the next 10 days before demo day. Focus focus focus, and you’ll do great.

After demo day, though, I think you should consider where you’re taking the company in terms of its market/product/positioning. You applied to YC with a promising technology and a vision for the future. After working on the company for three months, now would be a good time to do some introspection.

We worked on a product called Xobni Analytics over the YC summer. It was a great product, but not the right product for our market. We scrapped [1] that product and are now working on something much better.

The YC company that became Scribd was working on something totally different over the summer. They realized it wasn’t going to pan out and had the guts to change direction completely.

Do you need a direction change, or are you already on the right vector?

Well, do you still believe that your market is large and addressable? Does your product solve a real pain? Does it create lots of tangible value? [2]

It's worth plowing through on your product over the summer without too much thought to the question Is this a $300M dollar company? But the time has come to ask yourself such questions.

This letter boils down to: Have the courage to say We need to change something. We were wrong about this or that. Be agile; don’t be stubborn.

Notes

[1] I spoke more about this in the 'Idea Due Diligence' paragraph of this post.
[2] All of these questions equal, ironically: Is it something people want?

07/06/2007

The Coolest Hack I've Ever Pulled Off

I was 17 and it was the last lecture of biology class. Dr. Donahue was the lecturer. He was also the academic director of the early college program I was at. And he was retiring. It was the last lecture he would give after a career that was decades long.

Lecture began at 8am. My friend and I snuck into the classroom at 6am. It was a big lecture hall that could hold 300 people. We booted up the lecture computer. I can’t remember how we managed to log in, but we did. I installed the hidden program I had written, and we left.

At 8:32am, in the middle of Dr. Donahue’s powerpoint lecture to 200 students, the screen went black. It started flashing, and the following video played.

Some of the inside jokes:

• Dr. Donahue used to erupt “Scoff!” at things he disagreed with
• "Street LSD is not pure. It’s made by biochem dropouts" he used to say

We got the photoshop’ed pictures by posting a black and white photo of him onto somethingawful.com.

Dr. Donahue asked Who did this? after the video ended. Aaron Jacobs and I didn’t volunteer ourselves because we didn’t know if he was happy or upset. Afterwards we decided he was happy, and we stepped forward.

What a great hack! I really need to beat it out; seventeen years old was some time ago! Any good ideas?

I recently wrote about the ugliest hack I’ve ever pulled off here.

07/02/2007

My Startup Age

My startup self was born on March 14, 2006. It started asexually, created by its only parent, Y Combinator. I was such an infant. I didn’t know how to do anything other than write code. I could write code really well, but that was it.

During my early years I ran into walls and tripped on toys. We spent five months making a product that nobody really wanted. We missed a key hiring opportunity. I was the only one doing software development.

My teens were filled with growing pains and an identity crisis. Talking to investors constantly, doing a financing, setting up an office, and starting to act like a “real” company. *Wince*

My startup persona is a little older now. I’m learning more than ever, and making more mistakes than ever before. But I am taking more measured risks and making fewer rash decisions. I have some familiarity with the startup world, and have an easier time facing reality. I feel like I’m in my early twenties startup wise. There’s still a long way to go, and it will probably never stop.

People like Paul Graham, Josh Kopelman, and Rob Hayes have been around a while and pretty much know how to kick ass at everything. They’re senior citizens.

Vinod Khosla is 100 years old. You know he knows how to do everything, from chasing ladies (raising money) to retired travel in foreign countries (sitting on the boards of Fortune 500 companies).

I might be completely off the mark when I say I’m in my startup early twenties. Making a statement like that is a huge risk. There’s a reasonable chance that I’m way off the mark, and that five years from now I’ll be laughing at myself. But, hell, guessing is fun.

06/25/2007

Why Engineers Suck at Selling

I’ve been thinking about why programmers/engineers are bad at selling things – products, ideas, themselves.

First, engineers suck at spin. They deal in facts, not emotions. The suspension bridge is going to stay up or collapse. The software works or it doesn’t, and no amount of framing, rhetoric, or rapport will change the facts. An engineer who spins things to themselves or others would be a bad engineer; facts are king.

It gets worse. Not only do engineers focus on facts, they focus on the negative.

Programmers survive by paying attention to the ugliness in their code. If you wake me up in the middle of the night and ask what I’m dreaming about, I’ll probably tell you what the two ugliest parts of our code are, and how I’m going to fix each of them.

So when someone asks me about the code, my instinct is to describe the bugs. They’re just the first order of business! We have a natural tendency to look for and focus on the things that are not perfect.

Redemption

Luckily entrepreneurs know that they need to be able to wear many hats. If you’re already an engineer, you just need to learn how to sell the company, what you’re doing, and the product to people when you’re hiring, raising money, or talking to customers. You need new skills to do this selling.

It’s quite possible to pull it off.

I went to a talk by Bob Metcalfe at MIT in aug-05 where he talked about selling. He recalled his personal journey of learning how to sell. Remember, Bob came into the entrepreneurship world from MIT and Xerox PARC.

Bob said he went through four stages of learning how to sell:

1. Build a better mouse trap and the world will beat a path to your door
2. Once he realized that doesn’t happen, he’d argue with the customer. “You really need this product.” He would win the argument, but that left the customer with a bad taste in their mouth. He told the customer they were wrong.
3. So that didn’t work. He switched to Suffering fools gladly. Tell them what they want to hear. Over promise and under deliver.
4. Finally, nirvana. Listen to the customers, understand their problems, and make sure you can create value for them. Under promise and over deliver.

I’d say I’m at about stage 2.5. When I’m talking to a recruit, my basic pitch is “Your life would be better if you joined us. We kick ass and you’d find much more fun/responsibility/learning here.”

I think this can improve. I’m working on it.

06/11/2007

The Ugliest Hack I've Ever Pulled Off

Machine learning (6.867) was my favorite class at MIT. I just ran across the report from my final project in that class, which I've uploaded to Scribd: Friendship Prediction on Facebook.

As part of my project, I wrote a web site that allowed someone to type in their name and get back a list of people I thought they were friends with in real life but not on facebook. I put together the web site between about 10pm and 8am the day the report was due. [1]

The web site was the ugliest hack I've ever pulled off; it was in the final hour and I just needed it to work. Once someone entered their name, a task record was created in a MySQL table. I had a Java process polling the DB for new requests. Once pulled, that Java process would create 6000 feature vectors, one for each person at MIT that the query user might be friends with. Those were saved to a file. Then I needed to invoke a program called Weka to evaluate the feature vectors and output yes or no for each one. Trying to do this Shell() from Java wasn't working, so I had the Java app write out a Windows batch file with the appropriate command. I wrote a VB app to poll for batch files, and execute them as they came up. [2]

I had another Java app poll for result files, parse them, and put them into the DB.

Each request, end to end, would take a couple minutes if there wasn't any other load. The first java app kept about 1.8 GB of data in RAM that it needed to determine how close two people were in the friendship network, including things like how many photos they were both in, what their gender was, and so on. (See the paper for the full details!)

Meanwhile, the client was being shown a page with a <META REFRESH..> so every 20 seconds it would invoke PHP to poll the MySQL DB for results.

Ah, the beauty of throw away code!

Notes
[1] One of my favorite essays talks about the productive pressure of a deadline. Indeed.
[2] Here's the main part of the VB app!
Private Sub Timer1_Timer()
File1.Refresh
For i = 0 To File1.ListCount - 1
Path = File1.Path & "\" & File1.List(i)
Open Path For Input As #1
Input #1, toexec
Close #1
Kill Path

Dim k As Integer
Math.Randomize k = Int(Math.Rnd() * 984)
On Error Resume Next
Kill "c:\a" & k & ".bat"
On Error GoTo 0
Open "c:\a" & k & ".bat" For Output As #2
Print #2, toexec
Print #2, ""
Close #2
Shell ("c:\a" & k & ".bat")
Next
End Sub

05/12/2007

What You Should Be Measuring

The first screen on any web analytics package is visitors over time. That’s a horrible graph! Traffic over time is really produced by two forces, new visitors and stickiness. These two forces are what really matter.

Stickiness

The left and right graphs below are the familiar visitors over time. The middle graph is stickiness; it says how long the average user continues to visit. For example, the blue line expresses that five days after their first visit, only 10% of users are still coming back. The magenta line is better; five days after their first visit, 70% of users are still visiting.

Three Web Sites
Imagine three web sites – blue, magenta, and black.

Blue is a photo social networking site that requires visitors to sign up before seeing anything. The average new visitor sticks around for 0.13 days, so their Total Visitors closely resembles New Visitors. A couple days into launch they meet with investors and yell “Look! We’re getting loads of traffic!” The traffic is all from Digg, TechCrunch, and Reddit, though; pretty soon they will be old news and their traffic will die, as seen on the Total Visitors graph.

The best stickiness you can get is a constant 1.0, right? Then you would retain all of your traffic and total visitors would be the integral of all new visitors over time. [1]

No, you can do better! Black is facebook. Not only does the average new visitor stick around, but she brings friends and your traffic explodes! (2009 update: the cool kids are now calling this a "viral coefficient".)

The median web site is actually worse than all three shown here. The median TechCrunch'ed web site will have 5% of new visitors show up the next day. It's a sad state of affairs.

The Secret

The secret is that New Visitors aren’t that hard to come by. If you’re a startup building a web site, you can get coverage on blogs. If you have the right luster you can get on Scoble, The Today Show, and ABC Nightline. If you’re in a boring market then you can use adwords. If you’re competing with Girl Scout cookies then you can hang a sign outside the Safeway.

It’s easy to get excited by huge traffic spikes when you first launch. You haven’t accomplished anything, though; tomorrow the spotlight will be on another startup. You need both new visitors and stickiness to build a successful business. Stickiness is harder to get, but nobody measures it!

What This Means

All subscription businesses run on one metric – Average Revenue Per User (ARPU). [2] When a decision is to be made, the first question to ask is How will this affect our ARPU?

If you’re building a web site, stickiness should be your key statistic. You should write code to measure it before launching. After you have launched, put it on an LED display outside your elevators.

Announce it at all of your meetings. When making a decision, ask How will this affect our stickiness?

And actually measure and follow up! You make what you measure.

Stickiness Built In

Some products have stickiness built in. Social networks encourage you to bring in your friends. Desktop applications have a persistent presence after being installed, so the user doesn't have to remember a web site name. PayPal has some of your money in your PayPal account, so of course you'll come back. Interesting writers like Joel on Software or Paul Graham promise to give you new thoughts occasionally, so you're compelled to always come back. And so on.

So, how can you make yourself stickier?

Notes

[1] The math is simple; total visitors is just the convolution of new visitors and stickiness. For those who had the delight (or misfortune) of a Signals and Systems class in college, this is just a system where new visitors is the input and stickiness is the impulse response.

[2] Thanks to Joe Kraus for the example.

04/30/2007

Visceral Advice

I’m now sure that most advice is wasted.

I’ve ran into several problems recently, after which I thought Gosh, so-and-so’s advice was right! The problem is that I never remember so-and-so’s advice when I’m actually in the situation. There’s a bug somewhere between hearing the advice and recalling it in the situation.

I’ve been trying to fix this bug. I’m going to try to imagine two things whenever I hear advice: the experience that generated it, and myself in a situation that calls for the advice.

I think this exercise will help me generate better questions for the advice giver, too.

04/26/2007

A Great Day

Yesterday was a tough day. We were distracted by hiring and long meals and meetings.

Today was great. Gabor and I had lunch and coffee for two hours. We talked about how we can improve our hiring process and how we feel about the way things are generally going. We exchanged lots of ideas. It was fun.

Afterwards we got a large shipment from Dell. That was fun too.

I also played some squash tonight with Greg from Snipshot and two guys from XuQa.com who frequent the Bay Club. I won three out of six games. I’m quite a beginner. It’s so much fun when you get to play with someone at your level!

Other than that, I just hacked away. I worked on some code that’s pretty fundamental to a new direction of our product. After refactoring and refactoring to get the right interfaces, I spent lots of time optimizing memory and run times. It’s hella fast.

I have a few emails to respond to, and then I’ve got to convince myself to go to sleep. I hate ending days like today.

04/23/2007

Startup Advice and Lookup Tables

(This post is partially derived from some things I said at Startup School 2007.)

Startup founders really need advice, especially first timers. It’s like you’re put in a big dark room with booby traps, and your only hope of survival is to draw upon the wisdom of those who came before you.

The good news is that you’ll be bombarded with advice. It comes from everywhere – investors, advisors, blogs, books, users, and rap artists. [1] Most startup advice, though, is not relevant to your current situation. You might be thinking about finding a cofounder, but the blog you’re reading is discussing corporate bylaws.

What you’ve got to do is build up a hash table in your head to store the out-of-context advice. The hash table is a map from situations to what you should do in each situation.
The person giving advice has a hash table in their head, mostly built by learning the hard way. The point of advice is to copy their hash table over to your hash table. [2] This copy is very hard to do. How can you internalize all of that knowledge?

I can give you two hacks.

First, use repetition. Download the audio versions of Paul Graham’s essays, burn them on a CD, and listen to them over and over again. Read books once, identify the ones you like, and then read those again and again, every six months.

The second hack is to get the stories. Punch lines are harder to remember than plots like “We faced this problem, chose this action, and it blew up.”

My two favorite startup books are 100% stories. Jessica Livingston’s Founders at Work is filled with interviews of successful founders recalling the Good Ole Days, in full color.

My other favorite startup book is High Stakes No Prisoners by Charles Ferguson. [3] It’s the story of Vermeer, the company that made Frontpage and sold to Microsoft for $140M. The book is only moderately insightful; it is a real win because Charles tells the story in gross detail. He names names, and trash talks everyone for their ugly actions, including himself. It’s remarkably raw.

No Storage

Of course, the real win is if you don’t have to do the hash table copy from books and other data sources. Instead, when you face a challenging situation, just ask your advisors. Essentially, do a lookup in their hash table instead of making a copy.

Having access to these kinds of resources is incredibly valuable. It’s yet another reason that you should be in Silicon Valley to start a startup: experienced advisors are at hand. [4]

Notes

[1] For example, Master P relates some wisdom: “Nigga told me, ‘C, leave that dope, cause rappin is yo thang.’”

[2] This blog post is an example of such a transfer. Most of my thoughts are unoriginal, though, so you’re getting a second hand copy.

[3] Used copies are available on Amazon for seventy nine pennies.

[4] Having great investors also helps. And, okay, maybe Boston qualifies too. : )

04/02/2007

Physics at the Symphony

I really enjoy going to the symphony. I’ve been to the San Francisco Symphony twice since moving here last October. My favorite part is watching the violinists stroke their instruments in unison. This would be artful even without the music, but with beautiful music as a side effect – oh the glory!

Xobni is staying lean, though, so I buy the nose bleed seats. If I’m 300 feet from the orchestra pit, the music is delayed about 300 milliseconds behind what I’m seeing. (Sound travels at about one foot per millisecond.)

Humans can typically observe delays over 100ms. I might just be imagining it, but I'm pretty sure I can actually notice the delay between what I see and what I hear!

04/02/2007

Why programmers are bad at spin

Programmers survive by paying attention to the ugliness in their code. If you wake me up in the middle of the night and ask what I’m dreaming about, I’ll probably tell you what the three ugliest parts of our code are, and how I’m going to fix each of them. So when someone asks me about the code, my instinct is to describe the bugs. They’re just the first order of business! I think that’s why programmers have a hard time putting a positive spin on things, as compared to salespeople. We have a natural tendency to look for and focus on the things that are not perfect.

03/21/2007

The Life of an Entrepreneur, in 33 Seconds

I was listening to my MP3 collection, and heard one of the theme songs from Aladdin. Its lyrics at the end of the song personify the life of an entrepreneur:

One jump, ahead of the hoofbeats,
One hop, ahead of the hump,
One trick, ahead of disaster,
They're quick, but I'm much faster!

Here goes,
Better throw my hand in,
Wish me happy landing,
All I've gotta do is juuuuuuuump!

Here's the audio: One Jump Ahead

03/19/2007

Reinventing Code

When it comes to ideas or products, you want to cover new territory. It's the same in the programming world. You want to build on others' abstractions. Sometimes, though, you just can’t help it. We’re writing our software on the .NET platform. In .NET, all user interface elements have their own window handle in the operating system. Window handles are expensive resources. Parts of our user interface needed a lot of user interface elements, but we couldn’t afford to allocate so many window handles. So I started writing what a critic would call a reimplementation of the System.Windows.Forms namespace [1], but using a windowless model. Whereas the .NET top level interface element is called Control, ours was called LightControl. We also had LightButton, LightPictureBox, etc. I was only implementing about 2% of the namespace, but I was still nervous. It should set off alarms whenever you’re doing something that is both low level, and similar to something that already exists. But I just couldn’t think of any alternative. This was a few months ago. I was relieved yesterday when I randomly stumbled upon a blog post by Raymond Chen in which he validates my strategy. Raymond Chen is the man. This isn’t the first time this has happened. I wrote our own file system about eight months ago because NTFS didn’t have the right performance characteristics. We needed to store lots of small files, but traditional file systems have horrid performance in this scenario. They seek the disk like crazy! We also didn’t need directories, shortcuts, or any operations other than { create, append, read entire file, delete }. Surprisingly, a good open source implementation didn’t exist, so we bit the bullet.


The Point First, don’t be afraid to code a variant of something that already exists. Do your homework first, but do what you’ve gotta do. Second, if you’re making something new, don’t hide power. You might be able to save someone from having to write new code. [2]
Notes [1] This would take a hundred developers two years to finish. Luckily we don't need all of the functionality, but more importantly we don't need an uncrashable API. [2] I'm not blaming MS on this one. Although many criticize them for not providing a windowless control framework, they couldn’t have done so just by exposing an extra option. They're not hiding power; it's just not there.

03/19/2007

Reinventing Ideas

About two years ago, I was in the shower. [1] I had an idea: genetic algorithms modify data so as to optimize for something you care about. Lisp encourages programmers to think of programs as data. Why not use genetic algorithms to find the optimal program to achieve something? For example, find the program that is the best at playing checkers! [2]

I enthusiastically proposed the idea to my machine learning professor at our next meeting. She said Ah, that’s a great idea. It’s called evolutionary programming. People have written PhD theses on it. They haven’t gotten much traction because the search space is way too large, unless you’re working on a small problem with a specialized programming language.

Well, then.

I felt proud to have thought of the idea, but moreso I felt disappointed that the idea had already been explored and found fruitless.

Whenever I have a new idea, I find myself hoping that I’m the first to think of it. You've got to check with alumni, though, to make sure you're not spending cycles rediscovering something that's already known.

We've met several times with Eric Hahn to discuss what we're doing. Eric is the universally acknowledged email expert in Silicon Valley. He did cc:Mail, Lotus, Netscape, Lookout Search, and probably a few others. He has been a great source of wisdom when it comes to our product.

The other lesson from this experience? Take plenty o' showers.

Notes

[1] Okay, wise guy, not that that was my last time to take a shower..

[2] Paul Graham has spoken to this exact method of coming up with ideas. It's actually kind of eerie. He talks about making familiar mental gestures against a new substrate in the shower. In my case, I was in the shower, thinking about programs as data, and the genetic algorithm gesture got invoked.

03/15/2007

Y Combinator, Should You?

I encourage most startups or would-be startups to apply to Y Combinator, our first investors. Most people are really excited about the possibility of getting YC funding.

Of the people who are lukewarm, the number one objection I hear is that the valuations are too low. The number two objection people give is that "We’re too late stage for them."

Baloney.

When someone says that the valuations are low, they're comparing YC to a traditional investment. The rule of thumb usually doesn't apply because the stage is super early (more on this later) and YC isn't investing very much. But even from a higher level, valuations are a tactical matter; you should be thinking about grand strategy when making this decision. If Y Combinator funding increases your expected outcome by 2x, you should be willing to give up 50%, right?

I have a lot of empirical evidence about the entrepreneur’s upside so far. On average, Y Combinator will increase your expected outcome by at least 5x. They usually take 2-10% of your stock in exchange. That's a great deal! (I think it’s really 20x or higher, but I’m being on the safe side.)

How do they increase your outcome so significantly? It’s not about the money at all; it’s about the advice and connections. These things seem fluffy before you’ve experienced their significance. I applied to Y Combinator mostly to be around Paul, not to get introductions to important people. I didn’t have any use for important people. Boy, have things changed. I can also say very empirically that the network really matters. More details and proof on that in a few months.

YC doesn’t just casually introduce you to investors, reporters, and potential employees. They really work their tails off to make it happen. Your job is to only give equity to people who are going to contribute to the company. You don’t want to give shares to investors who are just going to give you money and not help you out. You want to give shares to investors who will give you their cell phone number, who will write emails to recruits encouraging them to join, and so on.

I mentioned that YC also gives you great advice. There was a YC dinner last summer when we went to Paul and said Paul, we're ready to launch. He said, very simply, No you aren't. I went home demoralized. As Steve Jobs said, It was awful tasting medicine, but I guess the patient needed it. We weren't ready to launch.

I could go on and on about this, but I’ve got to get to work on the second objection: We’re too late stage for YC.

This objection might be true for some. YC doesn’t invest in $20M series B rounds. Usually, though, I hear this retort from people who have been working on the product without funding for one or two years. They’ve built a lot of technology, and are afraid that their valuations won’t reflect that.

I can see why people might think this way. For years YC’s web site said that they take 5-7% of the company. Only recently did it change; now it says 2-10%. (You can use the Internet archive to see old versions of their site.)

What’s going on here? YC is seeing more teams that have already made something, and they’re accommodating those situations. Their #1 goal is to work with great people and companies, not to own the largest possible percentage. So, no, you probably aren’t too late stage for them.

The founders of Weebly were working on their site for a year before taking YC money. They were on TechCrunch the day of their YC interview. They still took the money, and I am sure they haven’t regretted it.

03/14/2007

The 2006-2007 Pumpkin is Dead

I always buy a pumpkin around Halloween to keep, uncarved, until it dies. They're festive and can really brighten up a room.

This year's pumpkin lasted for about four months.

Rest In Peace, 2006-2007 Pumpkin. (Maybe next year I'll name it something more creative than by year!)

03/10/2007

Complaints About Visual Studio

I love Visual Studio 2005. Microsoft repeatedly hits home runs it comes to IDEs. But it isn't perfect; it has two thorns that prick me every day.

First, Visual Studio doesn’t have multimon support. I have three monitors, and only get to write code on one of them. You can open the same solution on multiple VS instances, but that doesn’t work because editing a file in one instance will confuse the other instance.

In contrast, Eclipse really nailed multi monitor support. You can have the same project open in multiple windows, and you can instantly see any edits in all the windows.

It’s funny that this bug impacts our hardware purchase decisions. Because VS 8 lacks multimon support, we prefer one huge monitor to multiple average ones. I’m running 1600x1200 vertical now, which means I can see 80 vertical lines of code at a time. I'm looking forward to getting even more in the near future.

Second, Visual Studio doesn’t have Edit And Continue support for anonymous functions. The code below executes as you would expect.

 

Except that I’m from Texas. We don’t say “hello” in Texas; we say “howdy!” I didn't see my mistake until I ran the code in debug mode, so I hit Pause and change “Hello” to “Howdy.” I hit Continue, but…

 

I think that anonymous functions should be rarely used, but this bug really hampers my willingness to use them when they would otherwise make sense. I am proud that C# has anonymous functions, though. Many languages don’t.

03/08/2007

Top Mistakes in Year One

Sam Altman from loopt was the speaker at the Y Combinator dinner last night. (Sam is a close friend and one of the best entrepreneurs I know.) During Q & A, Paul Graham asked: “What do you wish you’d known when you were at these guys’ early stage?”

I asked myself the same question. What do I wish I could tell my past self?

I think we’ve done a great job so far. That being said, if I had known these things when we began, Xobni might be worth twice its current value.

Equity

First, offer significant equity to rock stars you find early in the company. When we met Gabor Cselle in August, we were in love. We asked our friends how much we equity we should offer, and the feedback was all over the board. We took the wrong advice and offered him too little.

We recently corrected that mistake, and Gabor is now joining the company about seven months later. I’m really happy about this, but we left a lot of value on the table by not getting him earlier.

Conflicts of Interest

Matt and I passed up three introductions to a VC firm because of their investment in another email company.

The truth is that there are going to be other companies in your space, but if they’re not competing directly then it might be foolish to turn down a meeting with their investors. As John Doerr said, “No conflict, no interest.”

We eventually realized we were wrong. We took the fourth introduction, and haven’t regretted it.

So don’t be so paranoid about conflicts of interest as long as you’re not a direct competitor.

Idea Due Diligence

We knew we wanted to leverage hidden email data. The most obvious thing to do with hidden data is to display it with graphs and tables, so we spent the first six months working on that product.

It turned out that Xobni Analytics didn’t generate enough recurring value for individuals. Whoops.

We didn’t know how to judge an idea, so we started with the most natural idea. Instead, we should have forced ourselves to answer “Why do people want this?”

This goof only slowed us down by about 30% because we used bottom up programming. Most of those six months were spent building out the baseline platform that we’ll need for any product in our space.

Saving Grace?

The common theme of these mistakes is that we eventually woke up and recovered. I’d love to say this implies that we’re brilliant at spotting our mistakes. Instead I’m compelled to ask myself: what big mistakes are we making now that we don’t know about?

03/05/2007

Well Hello

My name is Adam Smith, and I am the author of this blog. (As a side note, I don’t see why I should be the only author of this blog. Perhaps I should host guest authors at times.)

Xobni Man Walking is about my experiences as an entrepreneur and software developer. Xobni is a year-old startup focused on organizing your personal information, centered around email. We have a company blog.

Xobni only had two people until recently, so it made sense to put all of our thoughts on the company blog. As Xobni grows, so does the difference between ‘I’ and ‘we.’ Enter individual blogs.

This particular blog is going to discuss growing a company and growing a software product. Growing a company is really something you do so you can grow a product, but it’s such a daunting task that I think it deserves its own bullet in the agenda.

Of course, growing a product could also be seen as something you do in order to grow a company. (This is where a picture of a ying-yang would go.)