What Makes a Web App Successful?
Here’s a video of the talk that I gave at Future Of Web Apps in Miami in late February. They finally posted it.
It’s about 30 minutes long. [Transcript below].
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”.
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.
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.
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.
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.
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.
Q + A
Ryan: You have 5 minutes left. I’m going to ask a question for you guys, and if you have any more questions raise your hand. A lot of people ask me, “I’ve got an idea but my problem is marketing. I think my idea is good; how do I become a success?” Obviously, a lot of the stuff you’ve invested in has become a success. Can you share some sort of succinct answer to – okay, you’ve got a web app. It’s built and now how do you market it?
Fred: I think it’s a great question. First of all, I would not hire a marketing person. I think that’s a bad idea. Certainly for early on it’s a bad idea. It’s got to come from you or the team itself. There are two kinds of marketing that I think are really important early on.
One is product marketing itself. The marketing has to be in the product, some of what I talked about: the SEO, social media, and all of that, but the product has to be a marketing vehicle for the product itself. You have to do that, have to focus very hard on that, and you have to test it, measure it, and make sure that it does that.
The second piece is what I would call “guerrilla marketing” or “street marketing” or “stunt marketing”. It’s inexpensive. It’s powerful, and it works. It’s not an accident that two of our most successful companies, Twitter and Foursquare, broke out at SxSW. When they built their application, they built it, certainly the Foursquare team and Dennis, built it specifically thinking they were going to launch it at SxSW. They did some things to the application so that it would work really well there, and when they went there, they did some things to kind of juice the usage, get people using it, and it worked and took off. You don’t have to launch at SxSW; that’s not the point I’m trying to make.
What I’m trying to say is you can do things that will make the application spread that don’t cost a lot of money, but require some chutzpah, creativity, and work. The team at Etsy for example, went to craft shows for 2 years, but they couldn’t go to all of them so they created street teams of crafters who were early users of Etsy, who loved Etsy, who would go and man the Etsy booths at craft fairs. That’s the guerilla marketing street team type of approach.
It’s not expensive. It’s authentic. It’s using your users as your customer base. One more example on that and then I’ll take another question. When Boxee went to CES, not this year but last year, they posted on their blog that they were looking for 5 early Boxee users to come with them to CES. Instead of hiring models, or whatever, to man their booth, they literally ran a contest and got 5 power users. You had to write why you love Boxee and it was 2 or 3 guys and 2 or 3 women. The thing was; they paid your way to CES, put you up in a hotel, paid your airfare, and you had to do 4-6 hours every day in the booth. Then after that you were free to do whatever you wanted in Las Vegas for a week.
They got 50-100 people who applied with some great applications. They picked 5 of them. Abner, the CEO, told me that those 5 people were the best booth attendants he’d ever had because these people were into it. They were into it because they were already into it, but they were also into it because they were getting a free trip. They were having fun and they went out every night with them. That’s another example of kind of street, guerrilla marketing. That’s the kind of thing you’ve got to be good at.
Ryan: Where is Amy from MailChimp? She’s here somewhere, isn’t she? If you’re here, grab her if you want marketing ideas. She’s from MailChimp and they’ve done some really cool guerrilla stuff. You guys have been really successful with it. She knows what she’s talking about. We have time for one quick question, about 45 seconds. Who has a question?
Q: [not audible]
Fred: The full set of principles? I am going to fail that question. Do you mean the total number that have been listed on the blog? The ones that I care about the most are the 10 that I listed. Some of the others that I listed that I think are quite important, there was a raging argument about whether mobile is an important characteristic. I think your application absolutely has to be on mobile devices today, but the question is can it be a mobile web app or does it have to be a downloadable app. That is a debate and I don’t think there is a good answer to that, in my opinion. That would be one that I think is subject of some debate, at least in my mind.
People feel that brand is really important, the name, domain. I will tell you that when we invested in Foursquare, they didn’t own foursquare.com. It was playfoursquare.com. We actually – a young guy in my office, named Eric Friedman, went and found the guy who owned http://foursquare.com, and negotiated with him, and secured it. We acquired it as part and parcel of the financing we made. We felt that it was absolutely critical to own that domain. It’s the same with Delicious. You probably all remember that Delicious was Del.ici.ous and then we insisted that Joshua buy http://delicious.com. Brand is important.
Ryan: Please give Fred a big hand. If you can get some of Fred’s time while you’re here, I would highly advise you to do it. He’s going to be here all day, plus tomorrow. Basically, it’s impossible to get a meeting with him, ever, so this is your chance. He’s a tremendous resource and we really appreciate him being here.
Follow us on twitter@thefastertimes