Monday, December 24, 2012

Pmarca's Guide to Startups for Kindle

I made a Kindle version of Marc Andreessen's "Guide to Startups" so I could read it on a long-distance flight. You can download it here.

(Use Amazon's Send to Kindle application to get it on your Kindle. Or email it to your Kindle's email address which you can find in www.amazon.com > Your Account > Manage Your Kindle > Personal Document Settings.)

Tuesday, December 04, 2012

Startup Naming Stories from the Guy you Saw on Bravo TV

You may have spotted me today on Bravo TV's "Startups: Silicon Valley". Cast member Kim Taylor has just left Ampush and invited Lauren Jacobson, Mike Ihbe, and me over to have a brainstorming session to come up with a name for her new fashion startup.


Prime time TV doesn't really allow for an in-depth look at startup naming strategies. For example, one thing that the show left out today is that I came prepared with this Google spreadsheet of possible names for Kim's startup - but I’ll tell you more about that in a minute.


Instead of giving you a bland “10 Tips for Startup Naming” blog post, I decided to tell you 3 stories from my personal experience: A bad name, a great name, and one that’s somewhere in the middle.

A Bad Name

When I was in grad school in 2005, Google released its Google Maps APIs, which would allow people to show Google Maps on their own sites. But it wasn’t easy to just make a map with your own locations, so learned Ruby on Rails and built a site that let you do that in 2 weeks of caffeine-fueled late night sessions (I managed to attend all my classes at the same time as well). All I was lacking was a name, and I was thinking that this site let you make your Google Map, thus I named it yourgmap.com. That name is really bad for a bunch of reasons:
  • it’s hard to read (3 consonants packed up right next to each other)
  • it’s hard to parse (where do the words begin and end)
  • it’s confusing (is it “my” map or “your” map?)
The site is still alive, and gets a bunch of usage and traffic, but I’m not very proud of the name, which had clearly emerged from the clouded judgement of late-night coding.

A Great Name

The company I sold to Google was called reMail, and we got remail.com. I think it was pretty much the perfect name for a startup with the goal of reinventing email:
  • it fits the business (the word "email" is in the name)
  • it's short (6 letters, two syllables)
  • it’s the .com (very important because that's what people are trained to type in)
  • it's pronounceable
We were working out of a Foster City apartment at the time - we had holed up in suburbia to avoid the distractions of the city. We had raised money from YCombinator and some angels, but we didn't really have a name yet. We came up with a list of 10 email-related .com domain names that were available, and sent them to one of our angels, Paul Buchheit. Paul, of course, is famous not only for inventing Gmail, but also for not holding back on his opinions. He told us he didn't like any of them and that we should go back to the drawing board.

If there is one universally acknowledged truth about domain names, it's that all the good domains are taken. I made a list of ideal domain names for an email startup, and started reaching out to the owners of each domain. (You can find out who owns a domain using a service called WHOIS.) One day I need to write a post about negotiating for domain names, but it comes down to this: If you reach out to 32 domain name owners, 16 of them will respond, 8 of them will be willing to talk about selling, 4 of them will be actually serious, 2 will agree to a price, and 1 of them will actually sell. That’s exactly what happened with remail.com, and we bought it from the previous owner, a gentleman in Tennessee  for $4000.

A Compromise

After I left Google a few months ago, I decided to team up with a former co-worker and a UI designer and work on a fun mobile app together. The most fun idea we could come up with was an app where you could chat with drawings. That sounds fun because it is. We named it DrawChat, but couldn’t get drawchat.com, because it was already taken. Instead, as a domain name, we got drawchat.me - a compomise because:
  • it’s short (two syllables, 8 characters)
  • it’s related to what the app does (you would “draw-chat me”)
  • but it's not the dot-com
For mobile apps, you don’t necessarily have to get the dot-com, because most people will find your app on the App Store, not the web.

As an aside, we didn’t initially know what we were going to build. But one thing about building apps for iOS is that in order to get a company account for the Apple App Store, you have to go through a complex process of incorporating the company, getting a tax ID number, and getting a Dun & Bradstreet number to prove that your company is legit - a process that can easily take a month. Because we didn’t know what we’re going to do, we decided come up with a name for the company that was so bland that your eyes would barely register it when you saw it in the App Store. We called it Watermark Studios. See, it barely even registered in your mind.

We recently sold DrawChat to mobile development company Handmark - futher proof the name wasn't half bad.

The Scientific Approach

Let’s get back to Kim’s startup and our powwow on Bravo TV. I did a little bit of homework before we met up with her and followed the scientific approach of startup naming:
  1. I came up with a list of words related to fashion. I walked into a Walgreens, bought a stack of fashion magazines, and leafed through them, writing up words that caught my attention.
  2. I cut the list down to shorter words that could work as prefixes and suffixes.
  3. I put the list into a domain name generator (my favorite one is the DomBuddy generator), and got a list of available combinations.
You can follow this approach in this Google spreadsheet I put together for Kim. If you’re starting a fashion startup, and are looking for a name, feel free to use any of them.

Shonova.com

The domain that Kim ended up with - shonova.com - is one that she, as a former gymnast, had a personal connection with. Yelena Shushunova is the gymnast’s gymnast, and inspired a move that is shortened to Shonova. Here’s how it scores:
  • it has a personal connection (and Kim does a great job of telling her personal story on Bravo TV)
  • it’s short (three syllables, unambiguous pronounciation)
  • it’s related to gymnastics, which her audience fashionistas would care about
  • it's unique, which allowed Shonova to already take the top spot on Google for that word
It’ll be an exciting journey for Kim. I have signed up for a beta invite and you should too!


Beyond App Stores: Weaving Apps into the Web

The most annoying thing about the mobile web today are the interstitial pages that ask you to download an app instead of visiting a website. They look like this:


Publishers today need to build 4 different versions of the same content: Desktop, mobile browser, iOS, and Android.

On your phone you can read the same content in the mobile browser, and through the publisher's app. Here’s an example with a piece in the New York Times:


The web version of the content allows you to freely navigate and explore in your browser, and visit external links without losing your history. But the mobile app is still superior to the mobile web experience. Apps cache content for flaky mobile connections, and reformat content to be more enjoyable to read on phone and tablet form factors.

No man is an island, but every app is. The New York Times app is completely disconnected from the New York Times site. You can’t just open the app and pick up where you left off in the browser. As a subscriber, you need to log in once in the app and once in the browser. You can’t find an article on Google and have it open in the app: You’d need to manually open the app and type its title into the search bar.

Proposal

What if we married the best of browsing the web - the fact that you can freely move around - with the best of native apps - the fact that native controls, native caching, and scrolling are better on each platform?

My proposal would be to let mobile browsers download small apps and execute them within the browser window. [1] If the browser encounters a specific <meta> in the HTML page, it would download an .apk or .ipa up to a certain size, maybe a few hundred kilobytes, and display the content inside that app. If the user liked what she saw, she could bookmark the app, which would make it show up on the home screen, and optionally download a larger app package with more functionality.

The app could access browser cookies from the affiliated webpage. [2] This would allow zero-step login on mobile apps - something that is painfully lacking today.

Let’s imagine you found the article above with a Google search on your Android device. Below is what the result would look like:


Benefits

Weaving apps into the web would have significant advantages over the status quo. 

For one, every major website already has a corresponding iPhone and Android app. This would free publishers from having to make a mobile-optimized website in addition to their desktop website.

Users would get to try out an app without the heavy cost of installation. Today, installing an app on iPhone today involves finding it in the app store, clicking a button, entering your password, and waiting for the download and install to complete - a process that can easily take a minute or more. Users would be more likely to install apps, and more likely to use them.

Allowing the app to access browser cookies would solve onboarding problems: If you’ve already signed into the website, you don’t need to do so again. Making users type in an email address and a password on a mobile device causes user flow breakage rates of 20% or more. If the app was already installed (which is most often the case), you’d only have to download the pure content.

Allowing apps to be accessible via URLs makes app discovery more like the familiar pattern of browsing sites on the web. All the apps you install today end up cluttering up your home screen. What you get is endless screens of apps, once downloaded, never discarded. 

Apps today are pretty disposable and yet they get backed up and restored as if they were priceless childhood memories. They should be more like websites: If you like it, you better put a bookmark on it. (Apologies for the terrible pun.) Giving an app a permanent spot on the home screen should work like bookmarking a site.

Lastly, a nice side effect of this scheme is that content in apps is connected with the web. A lot of great content is locked away in apps like Instagram. Imagine that you could find content on Google or Reddit or Digg, and clicking on the link would navigate you to a high-definition native experience inside the Instagram app, rather than showing you a degraded web page.

Summary


Many apps you have on your phone today display content from the web in a mobile-optimized way. But apps are isolated and not reachable from the web - they live on their own separate islands. Allowing the browser to download and display small apps from the web would get rid of the tall hurdles of heavyweight app store-based installs, and make app discovery more like browsing the web. This would benefit publishers and consumers alike.

---

Check out the Hacker News thread on this article and enjoy the controversy around this proposal.

---

This post is the latest in a series of posts about the shortcomings of today's app store model. Read more:
  1. Every Step Costs you 20% of Users
  2. The Biggest Problem in App Discovery
  3. Rethinking the App Model
  4. The Two Hurdles of App Adoption
  5. Getting People to Use Your App
---

Notes
[1] User webXL on Hacker News makes a good observation: "Take out that automatic nonsense and I think he makes a good proposal. A URL can currently load a local app rather than a page in webkit. Only in this case, there would be some markup that would tell the browser to check for the installed app, perhaps the browser would present some unobtrusive indicator that a hybrid app was available to download. Just keep the address bar and the rest of the browser chrome there, swap the webkit frame out with the app's window, let the app access some of the history APIs, and you'd have a good portion of this figured out."

[2] There are various DNS and cryptography based ways to prove that both the app and the site are from the same publisher, but I'll leave it to the experts to figure out the details.