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.



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.



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.



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

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.

Investor tree

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.

Mad school bus

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] (Credit: Josh Kopelman.)

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

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. 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.



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!

Hong Kong at night

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?

Is your market 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 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?



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.



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.

Silly Guy

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.



Why Engineers Suck at Selling

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

Suspension Bridge

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

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.



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: Friendship Prediction on Facebook.

A Hack

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]

Facebook Friendship Prediction - The Machine



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.

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




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.



Traffic graphs



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!

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.