Greenspan 3:16

As a Harvard alum and (small & indirect) investor in Facebook, I figured I should read Aaron Greenspan's book AUTHORITAS, subtitled "One Student's Harvard Admissions and the Founding of the Facebook Era". But it's pretty long, so I used Knuth's technique for literary analysis: take a slice through the book and analyzing selected sentences in detail. His calligraphed book 3:16 studies chapter 3, verse 16 of every book in the bible. (He chose those numbers because John 3:16 is a well-known verse and he wanted to make sure he got at least one good one.) Here is chapter 3, paragraph 16 in Brush Script MT Italic:


From a quick scan of the rest of the page I didn't find a definition of A.R.P., but did see that this is set in sixth grade. The paragraph uses digression to build suspense. Readers unconsciously assume that when the writer takes this long to get to the point, it's going to be big. Has Kennedy been assassinated? No, wrong time period. This was early 90s. O.J. Simpson not guilty? Cold fusion? The Pope pardons Galileo? What would make such an impact on him? It turns out, another teacher wanted help installing a computer, so he's excited that his reputation as a guy who knows about computers has spread. Since the teacher just announced to the class that he was going to be setting up a computer, his reputation has spread farther. It says on the book jacket that he started a computer repair business when he was 15, so I assume this is the beginnings of it.

Actually, he's not using digression to build suspense as much as to simply digress. We learn that he sat on the floor in sixth grade, that his class's teacher trusted them, that the phone cord was coiled and light brown. I don't remember the color of the phone cord in my sixth grade class, but I'm sure it wasn't formative to my career. It's fine to give some context, but do we really need this much?

To be fair, chapter 2 or 3 in an autobiography -- the "back to the beginning" chapter, is often like this. His is titled "A Hard Lesson". I theorize that most readers skim this chapter, and autobiographers know it so they load it up with digressions that the editor would excise anywhere else in the book. 

On to the first paragraph of page 316 (in Lucida Handwriting Italic):


In a way it's similar to the first 3:16, in that it serves to set the stage for a conversation but adds a lot of detail. The conversation led to his joining Facebook. What's alarming is that it's on page 316 of 333, he's just meeting the guy who introduced him to Facebook. It seems the vast majority of the book is about his education & computer repair company.

Page 31, .6 of the way down: (in Krungthep):


This happens to be just a few paragraphs below chapter 3, paragraph 16. It leads to a long story about how he tried to copy the software from someone else's computer but it wouldn't fit on a disk and on on. I guess I never understood the fascination of Windows system administration.

Page 31*6  (=186), first para (in Copperplate Gothic):


This comes at the end of a section separated from the next by a little Harvard shield. It foreshadows the next section when he catches his economics teacher in an algebra mistake which he devotes nearly 2 pages to explaining. He criticizes (Harvard) professor Neugeboren for drawing poorly and making algebra mistakes on the blackboard. He writes to the dean, and they get a substitute teacher for the rest of the year. The rest of the chapter is about him negotiating for higher grades by arguing about ambiguous exam questions. Justice is served, he proclaims at the end.

Being at Harvard makes young men and women feel important. They often become important as a result. Feeling the importance of one's own life gives people the courage to attempt great things, with good consequences on average. But some go past "important" into "entitled". He seems to be fairly self-aware, so I assume he gains some perspective later in the book.

OOB

Here's my actual out-of-the-box experience with the iPad:

My iPad arrived Apr 3 morning as promised, a Saturday. Sadly I wasn't in the office yet, so I had only a UPS "we missed you" sticker to play with all weekend.

Monday when I went into the office I opened the box, but it only showed the "Please sync me with iTunes" screen. It was cool that when you turned the iPad the diagram swiveled, but I couldn't show it off much to my coworkers.

When I finally got it home to sync with my iTunes, it didn't recognize it (nothing showed up in the iTunes window). Since iTunes has been nagging me to upgrade from 9.0 to 9.1, I did it (which took 30 minutes, required several password entries and a reboot) and it worked.

I wasn't sure if I should restore my iPhone's configuration onto it, or set it up as a new device. I opted for new. It cranked away, downloading videos & apps for about 3 hours. I think the time was mostly generating small version of my 12000 photo collection.

The next day I got to play with it, and it was lots of fun. But it wasn't the usual Apple out-of-box experience. I'd like to get iPads for my kids, but I worry they'll have a lot of trouble setting it up.

Warranties

"To prevent damage ... please remove the device from your pants pocket before sitting down"

-- HTC / Google Android phone packaging

In the late 80s, my family built a house in Canada for which we bought fancy nitrogen-filled double-pane insulating windows. Each window came with a big red sticker, somewhat hard to remove, proclaiming a 10-year warranty. The not-so-fine print also said the warranty was void if the window wasn't opened for 30 minutes every day.

Perhaps somewhere in Canada there's a dutiful person who actually opens his house to the wind, rain and snow for 30 minutes every day, and  arranges for a neighbor to do it when he's on vacation. But most people who buy either Android phones or that brand of window ignore the warnings and take their chances. 

Building reliable products is hard. At Anybots we're in the middle of this process. We're developing mobile telepresence robots that have to drive around offices and factories. We know people will throw them in the trunk of their car, pack them in luggage, drop them, kick them, crash them, drive them off curbs, spill coffee on them, and 1000 other abuses we haven't even thought of. We're doing our best to make them survive as much abuse as possible, but they're physical objects made of plastic and metal containing optics, electronics, and bearings. They can't survive everything. They won't be falling-anvil-proof.

Actually, places with falling anvils are a great application for telepresence robots. If you have to look around somewhere dangerous, you'd much rather risk a $10,000 robot than yourself. So we'll definitely have customers who drive them into lava fields or unstable mining tunnels or fires or chemical spills. There are military-grade robots costing $100,000+ that would survive more of these situations than ours, but we think 2 of our robots will outlive 1 military-grade robot. That is, for every 2 incidents that would destroy our robot, there'll be at least 1 that would destroy any robot.

So, some customers will use our robot in air-conditioned offices and some will drive them into burning toxic waste. How do we provide a warranty that makes sense for everyone? Robots that fail in office settings didn't meet reasonable customer expectations and we should replace them for free. A robot hit by an anvil or blown up by an IED or melted by flames has already provided fair value to the unharmed customer, and they should pay for the replacement. At either extreme, I think reasonable people will agree on what's fair. It gets trickier in the middle. 

A typical middle scenario will be a user who drives it between buildings in light rain. The robot should survive that sort of thing most of the time, but it's outside our spec and it may eventually fail. Depending on who that user is and how his company budget works, he may offer to pay for repairs or may try to claim warranty work. Auto makers have this problem all the time. People must bring in cars with blown engines caused by racing or never putting oil in, and the dealer has to decide whether to replace it under warranty. It can be an unpleasant, confrontational process that leaves bad feelings all around. I want to avoid that.

The current plan is to offer 3 levels of service contract for different uses: office, dirty environments, and hazardous environments. They'll be priced according to our estimated repair/replacement cost. I want to err on the side of being nice to customers, but we may occasionally have to insist that people upgrade to the next contract if, say, they send us back melted robots for replacement under the "office" service.

I'm open to other ideas that meet our goals. To state our goals explicitly, they are:
  1. Make customers happy by exceeding their expectations.
  2. Collect honest data about why robots fail. Don't force customers to cover up the real reason for failure.
  3. Don't lose large amounts of money on outlier customers.

Early-stage theories

If you'd met the Wright brothers around 1900, when it was just the two of them and some hand-built models, you might have guessed that their flying machine startup was going somewhere.  Wikipedia article:

Despite Lilienthal's fate [died when his glider crashed], the brothers favored his strategy: to practice gliding in order to master the art of control before attempting motor-driven flight. The death of British aeronaut Percy Pilcher in another hang gliding crash in 1899 only reinforced their opinion that a reliable method of pilot control was the key to successful—and safe—flight. At the outset of their experiments they regarded control as the unsolved third part of "the flying problem". They believed sufficiently promising knowledge of the other two issues—wings and engines—already existed. The Wright brothers thus differed sharply from more experienced practitioners of the day, notably Ader, Maxim and Langley who built powerful engines, attached them to airframes equipped with unproven control devices, and expected to take to the air with no previous flying experience. Though agreeing with Lilienthal's idea of practice, the Wrights saw that his method of balance and control—shifting his body weight—was fatally inadequate. They were determined to find something better.

Even without hindsight it's clear they had ideas and momentum. They had done their own experiments, learned about others, figured out some non-obvious things, and developed an original plan of attack. They didn't have the answer to stability, but they knew how they were going to figure it out. They focused on specific problems and didn't get distracted by others. Obviously they knew they'd need strong engines and wings someday, but they decided to start with the control system and build everything else around it later. They were willing to solve the hard problems by strapping themselves to kites on remote hillsides rather than just tinkering with engines on the bench like some of their competition.

In the end, their Wright company made a lot of mistakes and wasn't the biggest financial success of the early aircraft industry, but it could have been. It's the sort of startup we like at Y Combinator: technologically disruptive with a good chance of cashing in.

You can see the same features in good early-stage web 2.0 startups. They are sometimes caricatured as being frivolous companies, but in fact the good ones are based on ideas as valuable as the Wright's scheme for controlling an airplane. When Posterous applied to YC in spring 2008 there were probably as many companies trying to create blogging software as ever tried to make flying machines. The Posterouses stood out because they had been thinking about easy web publishing together for years, built prototypes, tried things, and had some insights nobody else did and a plan for creating a successful product. They had thoughtful reasons why the problems they were going to focus on would make them popular among a growing class of users, while Blogger would continue to focus on its existing user base and stagnate. 

Good founders are open-minded like good scientists. For example, I challenged Garry's assertion that submitting blog entries by email was easier than web forms. Many people seem to prefer Gmail over desktop email software, so why wouldn't they prefer entering their blog posts on the web than their email client (which might even be Gmail?) Bad founders react to such questions like, "What? It's obvious! How dare you question my premises?" Garry's answer was more like, "Yeah, we wondered about that too, but we tried X and saw users do Y so we think it'll work." He had tested his assumptions, evolved his theory, and figured out important details that nobody else seemed to get.

Fundamentally, most YC-funded companies are in the business of providing a digital service that users pay for or advertisers sponsor. There are already thousands of web companies providing a wide range of services, so why will a brand new company make money? At the heart of a web 2.0 startup are several theories:
  1. Our new service will attract the following kinds of users: .....................
  2. They will use it for the following purposes: ..................
  3. Instead of a trusted brand, they will use a startup they've never heard of before because ......................
  4. Even though some of the value is social, we will be useful to the first users because ..........................
  5. Users will recommend us to their friends because ....................
  6. Big competitors won't be able to copy our features as soon as they notice us because ........................
  7. .................... will pay us $................... in return for ........................
  8. Once we get critical mass it'll be hard for new startups to steal our users because ..........................
Those are hard questions and they're interrelated, but startups continue to find answers to all of them. Make sure the existing players don't have better answers than you. For example, Craigslist has a very good answer to #8, so you need something big for #4. We get a lot of "Craigslist for X" applications, and often they miss that. For example:

YC: Why will users prefer you over Craigslist?
Founders: We'll be more localized. Craigslist has listings from all over the city, but we'll just show you listings from your neighborhood.
YC: Maybe Craigslist would be better if it were more localized, but until you're popular you'll have to be *less* localized in order to have any listings show up at all.
Founders: So we won't turn on localization at first.
YC: But then you won't be much different from Craigslist, and there's no reason for people to switch. Your special sauce only works after you're already successful. You need a way to get there.
It's clever of Craigslist to err on the side of large granularity, because it's a phase a startup would have to go through to compete with them. Or:
YC: Why will users use your software instead of Quickbooks?
Founders: Our software will be easier to use.
YC: Are there a lot of people who find Quickbooks too hard?
Founders: Yes.
YC: But a lot of people already know Quickbooks, so it's easiest for them to not change.
Founders: Sure, we won't take away their users. We'll get new users.
YC: How will new users find out about you?
Founders: Their friends will tell them.
YC: Do people tell their friends, "Say, I just found this really easy new accounting system!"
Founders: No, but when people start a business they'll ask their friends what they should use.
YC: But they're going to ask their friend who knows the most about accounting. Won't that person be a Quickbooks user? Won't they recommend what they know?
Suppose you have answers to all the above questions. You build it and nobody comes, so something is wrong. How do you figure out what? I don't have any universal advice, but helps if you have a complete, consistent working theory the team agrees on so you have a basis for debate and experimentation.

Experimenting is hard because people are naturally afraid to put their theories to the test. Often when startups take a long time to launch, it's because they're afraid of bad news. They fear people won't like their product, so they don't release. They plow forward based on their untested theory rather than testing and iterating. Teams that don't really trust each other or where one founder is intellectually domineering are less able to try different approaches. The best advice is to strap on some plums and put whatever you can to the test, so if it's wrong you can adapt and move forward.