Fred Wilsons 10 golden principles of successful web apps

link to http://vimeo.com/10510576
link to post on thinkvitamin

Transcript

Thank you. Hey everybody, it’s great to be here in Miami. I flew down last night from New York. It was still winter, snow on the ground, and it’s nice and warm here. I’m glad to be here.

When I agreed to come down and talk, the people at Carsonified said “We want you to list 10 things that make a great web app.” I thought to myself, “Gee, I don’t know if I can keep it to 10.” I have put together a list of 10 things, and I want to present them to you today. I think it comes from my experience, for really 15 years, of investing in web applications; what I’ve learned, in terms of what has worked well, and what has not worked well. I’ve used a lot of web apps.

Our style of investing is pretty straightforward. We have a set of things we’re interested in. Anything that doesn’t fit into that set of things we just tell the people behind the project that it doesn’t really fit into what we do. If it does fit into what we do, we use the product. If we find the product really resonates with us, then we invite the team behind the project, the service, or the product in, and we get to know them. If we like both the product/service and the team, then it often leads to investment.

These are 10 things that we look for in an application. I’m sure that some of you will disagree with the list, but that’s the whole point of it in the first place. The topic is “10 Golden Principles for Building Successful Web Applications”.

1. Speed

First and foremost, we believe that speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it. I see this more with mainstream users than I do with power users. I think that power users sometimes have a bit of sympathetic eye to the challenges of building really fast web apps, and maybe they’re willing to live with it, but when I look at my wife and kids, they’re my mainstream view of the world. If something is slow, they’re just gone.

We think that the application has to be fast, and if it’s not, you can see what happens. We have every single one of our portfolio company services on Pingdom, and we take a look at that every week. When we see some of our portfolio company’s applications getting bogged down, we also note that they don’t grow as quickly. There is real empirical evidence that substantiates the fact that speed is more than a feature. It’s a requirement.

2. Instant Utility

What this means is the service is instantly useful to you. If you build a service and the user has to spend an our configuring the service, setting it up, importing contacts, doing a lot of data entry, I don’t think people are going to – most people aren’t going to put up with that. The service has to be useful right out of the box.

We see a lot of people make this mistake. There are a lot of tricks you can use to create instant utility and then go from there. A good example of that is if you’re building an information service, you can crawl the web to populate the service initially, even though long term you expect to get the data some other way. You have to give people something right off the bat that is useful.

Another example of this is when Google launched Google Video maybe 4 or 5 years ago, around the same time that YouTube launched; if you uploaded a video to Google Video, after you uploaded it you would get a note that said, “Come back in about a week and your video will be shown.” Of course, that didn’t work very well. YouTube provided instant encoding and you could see the video literally seconds after you uploaded it. That’s what I’m talking about when I talk about instant utility.

3. Software is Media

This is one that I got a lot of questions on. My view is that software is media today. Particularly consumer software, when people use it, they approach your software in the same way they would approach media. When I say media, I’m talking about a magazine, or a newspaper or a TV show. When you think about the New York Times versus the Wall Street Journal, or you think about Vanity Fair versus Vogue, or you think about Fox News versus CNN, each of these media companies have a voice. They have an attitude, and a style, and it’s unique. It’s different.

I think software has to feel that way. Your software has to have a personality. People have to feel like they’re consuming media when they consume your software. If your software is bland, and has no attitude, something as silly as the “Fail Whale” which became a symbol of Twitter’s inability to stay up, also was a personality. People were walking around wearing “Fail Whale” shirts. It’s embarrassing for the people at Twitter, but nevertheless, it spoke to the fact that there was some attitude and media savvy behind the service and it created a voice that people connected to. That is what I mean by voice, and I think it’s terribly important in a web app.

4. Less is More

4. Less is more, and I really believe this, particularly early on when you launch something. Over time, you can grow the utility of your service, and Facebook today probably offers 20 or 30 different features of significance in their service. But, when they launched, it was really quite simplistic. I think that’s true of most great services.

One of my favorite investments that our firm made is in Delicious. The thing I loved about Delicious was its simplicity. There wasn’t much you could do, but what you could do was really quite powerful. People used it every single day, maybe 5 or 10 times a day. These services where you do one little thing, but you do it all the time, and it’s very reinforcing and you get a lot of utility out of it, and it’s quick, easy, and fast, I think tend to do very well and give you the platform to ultimately grow from there.

5. Make it Programmable

Talking to a group of web app developers, I think this probably goes without saying, but I think it’s important to make your application programmable, and make it possible that others can build on top of or connect to or add value to, in some way, your web application. That means API’s, and in my opinion read/write API’s. The founder of Delicious told me a couple of years ago that if it’s not read/write then it’s not an API. That has sort of become religion inside our firm. We really think if it’s a read-only API, it might as well be RSS.

Not all of our companies, by the way, have launch read/write API’s, and we’re constantly hounding them to do that, but the important thing about programmability is that when people can add value to your application, they are in effect adding energy to your application, bringing more users to your application, and also bringing more data and more richness to your applications. We think this is kind of like speed. This is absolutely essential, and we certainly today, maybe not so much 2 or 3 years ago, but today we would be very hard pressed to make an investment in a web application that wasn’t highly programmable.

6. Make it Personal

Personal means many things to many people, but essentially, it’s a lot like the prior slide. You want third-party developers to infuse your application with their energy. You also want to make your application infused with your users’ energy. The more of their data and their personality and energy that they can contribute to your application, the more ownership that they feel of it, and the more likely they are to advocate it and become, in effect, your marketing force. It’s very important to make your application personal for everybody. That could be allowing people to change their backgrounds. That could be allowing people to put in avatars; clearly, user-generated content, anything like that so that people can start to feel ownership of your web application the better.

It is also true that this can pose problems. I was talking to a woman who was an early employee at Last.fm last week, and she said to me that their community felt like they owned Last.fm and they were in charge, and that every time they made a change, they would get thousands of posts on the forums. I actually think that’s a good thing because it means people care, and care deeply about your application.

That’s true for a bunch of our companies, as well, and it is a headache. When our portfolio company Meetup made a change last week to the Meetup Pages, and there are thousands of comments on the post announcing it, most of them negative. You have to decide whether or not to react to that or engage in that or whatever. Largely, it’s a very good thing because people care and they’ve invested time and energy in your application when they make it personal.

7. RESTful

I don’t know that I’m necessarily using this term correctly. I think most of you know that this term REST means. It eans something very specific in a software architecture point of view, but the reason I put this up here is slightly different. It’s a bit of a misuse of the term, but I’m going to try to make this make sense anyway.

In a REST architecture, your resources have a URL and they can be called at that URL. That’s kind of the software architecture that is outlined in the REST approach. What I mean by this is a bit of a bastardization. What I mean is that the entire application, everything in the application has a URL, and ideally, a very clean and comprehensible URL.

If you think about something like a Twitter list, which is something that they launched about 3 or 4 months ago, and if you go to someone’s page on Twitter, and you click on the “lists” link, you’ll see a URL that says something like “twitter.com/fredwilson/list/…” and that will be all of the lists that I’m on. The entire Twitter application is built that way so there is really nothing that you could click on or look at in the Twitter application that doesn’t have its own unique URL, that isn’t well understood to anybody including my mom would know what that URL meant. You can take that URL, send it via email, or put it out into the social media world.

Google will see that URL, will discover it, and so what it essentially allows is for the web, at large, to discover and get access to your application in very deep ways. I think that people who build web apps that don’t allow very deep and open kind of architectures make a big mistake. Something as popular as LinkedIn, for example, I would argue does a very poor job of this. That is what I mean by this, and I know it’s a bit of a bastardization of the term, but I think it’s terribly important.

8. Discoverabilty

This is similar in some ways, to the last slide. When you launch a web app, it’s a needle in a haystack. There are hundreds of thousands, if not millions of web apps out there on the World Wide Web, and how is anybody ever going to find yours? At its base level, for me, this means search engine optimization. You have to understand search engine optimization and you have to understand the rules; you’ve got to know how to do it. You have to build your application from the ground up to be discovered by Google, and optimized for Google.

But, it also needs to be built from the ground up to be discovered, and optimized by social media. I think this day and age, social media is as important as search, in terms of overall discoverability. That means virality. There is a great blog post written by Josh Kopelman, who is a colleague of mine, Founder of First Round Capital. The blog post was titled something like “We Just Need to Add Some Virality”. The idea was that someone built a web application; nobody was using it, so he said to his team “let’s pour some virality into it.” You can’t do that. The application has to be built from the ground up to be viral. The product itself needs to push itself out into the web, into search, and into social media. That’s how you make it discoverable.

9. Clean

Clean, to me, means that the application cannot be busy on the page. You need to be able to look at it and not be bothered with lots of stuff. It’s white space, or dark space; it doesn’t really matter whether it’s white or dark, but lots of space. I think big fonts, not too much functionality presented on any one page. Make it very inviting, and make it so the people know, right away, what they need to do.

What I actually had on this slide – when I put this deck together, I started with screenshots from applications that I thought did a good job of this, and then I kind of decided that wasn’t a great idea. I moved to just things like soap. But, what I had here was the Tumblr login, and when you go to log into Tumblr, it’s two big fields, huge, nothing else on the page really, just username, password, and I really like how clean that is. It’s like no way is anybody not going to know what they need to do right there. I think that’s really critical and people underestimate how valuable it is to be efficient with the amount of functionality on a page.

10. Playful

Last but not least, is playful. We have 6 words that we live by at Union Square Ventures. Only one of them actually made it into this deck. The 6 words are: mobile, social, global, playful, intelligent, and I’m forgetting what the last one is so I’m going to fail today, but in any case, that’s kind of what we think about thematically in terms of web apps. Only one of them made it onto this slide deck, and that’s “playful”.

I was criticized for putting a picture of an empty playground with a puddle in there, but there is a reason why I did this. This slide is in South Park in San Francisco. There is a little area at the top of the slide where you can hang out. This is where Twitter was invented. A bunch of employees of a company called Odeo took some time off in the middle of a nice, spring day, and went to think about new projects they could build. One group was 4 or 5 people that sat at the top of this slide and basically conceived of Twitter. That’s why I used it.

In any case, the ability to play in an application is really important. The game dynamic is what you can use to get users to do what you want. An example I like to use here is something that’s not even a web app. If you think about Weight Watchers, it’s a game. It has some really important game dynamics. You establish goals, measure yourself against those goals, and you report against those goals, and you get rewarded for meeting those goals. That game dynamic is the thing that ultimately makes Weight Watchers successful for some people.

That kind of approach should be, in some way, shape, or form, in every application. If you look at LinkedIn, when it first launched, I had friends who were manically trying to accumulate relationships in LinkedIn. You saw that with people trying to accumulate followers in Twitter, friends in Facebook, and that’s one kind of game dynamic. There are clearly other kinds of game dynamics out there.

Foursquare would be an example of taking very much game elements like status, badges, and things like that, and using that as a way to empower the development of what is, effectively, a local information service. You don’t have to be as blatant about it as Foursquare is, but I do think that applications need to be playful. It will make users have more fun using your application, and because you can incent the kind of behavior you want to create in your application.

Greg, can we swap over to my blog for a second? I just wanted to finish this by pointing out that I posted the deck on my blog, at www.avc.com, on Sunday. This is the post right here, “10 Golden Principles for Successful Web Apps”. There are 171 comments. There is a raging debate that has gone on for 3 or 4 days, about whether those 10 are the right 10, and if you’re interested in this and thinking about a web app that you’re building right now and whether you’ve included all the key issues; there are at least 5 or 6 other issues that have been raised frequently in the comment thread. These are things like privacy, brand, ease of use, and others that maybe should have made it into this presentation. People at Carsonified asked me to do 10, and I kept it to 10.

The last thing I will say is that I’m doing a workshop tomorrow from 9 to 12:00, is that right? You’re going to do it with me, Ryan, is that right? You’re going to be there. You’re going to keep me out of trouble? It’s 3 hours of question and answer and we can talk about web apps and we can talk about raising capital, and we can talk about anything else you want to talk about. I’m looking forward to that. Hopefully it will be a more intimate setting, and I can get to know some of you much better, tomorrow.