A lot of aspiring App Makers contact me, wondering how to get started turning their idea into an actual product. Should they hire a coder, or learn to code themselves? Or should they start with a designer? Or an investor? My advice, as always, is to start at the end. That is, make a video that shows people using your app.
This accomplishes several things. First and foremost, it establishes the story of your product, which is what people will tell each other about your product. It also gives you focus. People always tell you to do one thing and do it well. This establishes that one thing right up front.
When you’re making the video what you’re doing is you’re putting yourself in your customer’s shoes. You’re stopping to think, in a formal way, about what it’s like for people to use your product. As you go through those motions, you realize what the product needs to be, the genesis of design.
Making a video also establishes a vision of the product. I’m a big fan of generating marketing materials early in the product development process, because it helps everyone know just what exactly you’re intending to build. Great products come from great teams, but only if everyone agrees on what they’re building.
By the time your video is finished, you’ll know what you’re building, what it looks like, and how it works. You’ve also got the video itself, which you’ll show to potential recruits, investors, and customers. In addition to showing the world why they would use your product, the video shows them how they would use your product. This is Apple’s favorite trick: pre-training people with commercials, making the products seem intuitive.
App videos have become increasingly popular if only because they fill the gap left by app stores cutting out trial periods. If you can’t try it, at least you can see someone else trying it. For a lot of people, that’s the push they need to buy. That also means that app videos are as competitive as apps themselves.
The standard presentation rules apply. You want to entertain, inspire, and educate, in that order. A minute is a gigabyte of attention span, so try to keep the video short. Be creative, but don’t go overboard. Getting the audio quality right is more important than all the stunts in the world.
This afternoon we saw the second Weekly Wednesday Lunchtime Lecture, hosted by SourceTag. The speaker, Raul Portales, talked about his experiences in marketing his games on the Android Marketplace. Although I’m an iOS guy, the challenges we face on the App Store are even greater on the other side.
Raul presented several graphs showing his total installed base over time as irrefutable evidence to back his assertions, and I took away several lessons that I think are relevant to all platforms, and to product engineering and marketing in general.
When we talk about the business model of your app, we’re talking about whether you’re selling it outright, or giving it away for free and trying to monetize with advertising.
Also common are the hybrid “freemium” models. You can have two versions: a lite version and a paid version. Or you can use the old shareware model, letting people download and try the app for free, then purchase it in-app to remove adds, unlock features, and remove limitations.
Raul proposed a new model, which can be used alone, or in conjunction to other models, which I call the “freebie” model. You have the main, full-featured app available to purchase. You then have a number of simplified spin-off apps you give away for free, which contain ads for the main app.
There are several advantages to this model, and Raul’s numbers prove that it works. His freebie app was featured by Google, which brought in some 80,000 new users. Although the absolute numbers are an order of magnitude lower, the growth curve for the paid app was an exact match to that of the freebie app.
It was no accident the freebie got featured. Raul shrewdly made a stripped down seasonal variant, in this case for the Easter holidays. Not only are customers looking for seasonal things to try, stores are looking for seasonal things to feature.
This is genius. Seasonal apps are a niche market. The number of entries is smaller, meaning the chances of getting picked are much higher. Getting featured is the fastest way to pick up new users, and making the app free makes downloading it a no-brainer.
Not only do a number of users follow the cross promotion to the main app, the quality of the users is particularly high. Every app has a certain “bozo penalty” of users who give it undeservedly low ratings for asinine reasons. The less your app costs, the more bozos end up trying it, with free apps suffering the worst by far.
The freebie model uses the free app to absorb the bozo penalty, and only sends over the users who actually liked the app. This means that not only are your sales higher, your reviews are higher than they would have been with similar growth from other sources, like being featured directly.
I’ve always preferred the shareware model, but this bozo shield effect is a compelling counterargument in favor of the lite model. If my app skinned easily, I think I would eschew them both and just use a pure freebie model.
Raul’s other observations included the superior performance of niche apps over apps for a general audience. Even though the market is smaller, penetration rates are much higher, meaning you capture a larger percentage of possible users. Ratings are also higher.
Why is that? There are a number of possible explanations, but the one I prefer is based on the fact that real users differ from the models of them we use in creating our products. Assuming you know what you’re doing, the closer the actual user is to the model, the more they will like the app.
By extension, the farther the user is from the model, the more they will dislike the app. Users tend to like products more as they get used to them, because mastering the product moves them closer to the model user.
When you make an app for a general audience, you are casting a wide net, and are going to get a lot more people who are so far from the model as to fall into this bozo category. Because they are focused, niche products tend to attract people already closer to the model, leading to better overall satisfaction.
Another problem Raul mentioned is that people who dislike an app are more motivated to rate it than people who actually like it. This causes all reviews to trend downward. This effect is exaggerated by the fact people overuse the lowest rating. Anyone who ever got an F knows what one low score can do to an average.
Andy Ihnatko once made this point about people leaving one-star reviews of his book on Amazon for relatively minor complaints. I am paraphrasing here, but the idea is that if the book contained nothing but insults for the reader, racist jokes, and fond remembrances of Hitler, you would also give it one star.
I think the solution to both these problems is for the store or OS to prompt users after one month, or upon deleting the app, to simply give the app a thumbs up or thumbs down.
This is how we do our speaker ratings after each Weekly Wednesday Lunchtime Lecture. No star ratings. No surveys. We simply ask people to answer a yes-or-no question: would you like to see this speaker again? We get around 75% voter participation, which is pretty damned good.
Any speaker who receives at least an 80% approval rating will be put on the Appsterdam speaker list, which will be online so journalists looking for interviewees, conferences looking for presenters, and schools looking for lecturers know who to talk to.
I spent the weekend as a keynote speaker, mentor, and jurist at Startup Weekend Amsterdam. This was an amazing event with 175 participants giving 75 pitches and forming 24 startups. After a 54 hour hackathon, we awarded prizes in 5 categories.
Expect to see more than 5 companies come out of this, as the whole field was full of great teams building interesting products. Picking winners was an agonizing process, easily as agonizing as being an Apple Design Award judge.
If you did the weekend right, you should have taken home lots of experience, even if you failed to walk away with a trophy, or even launch. Prizes are nice, and winning is nice, but they are fleeting pleasures. Knowledge is priceless.
The panel at Startup Weekend is looking for the same things any set of investors is looking for. Pitching to the jury after days without sleep is as close to the Valley experience as you’re going to get, minus the penalty for failure.
I’d like to share some of the insights I myself brought home.
The number one rule of venture capital is invest in the team. Product ideas and business plans are great, but pretty easy to come by. A great team that enjoys working together is a genuine treasure.
When you start a company, you need to be aware of every other company that has ever tried to solve the same problem. You need to study them, and you need to figure out how to differentiate yourself. You need something other than braggadocio to show that you’re better.
You might think companies that have gone out of business are no threat to you, but if you’re trying to get funding, they are your biggest threat. The only thing worse than an unproven model is a disproven model. You need to know exactly why they failed, and prove that you are different.
You know that hot space you keep hearing about? Forget about it. Investors are looking for tomorrow’s big thing, not yesterday’s. You see an open niche, but investors see a crowded space. Besides, it’s way more fun to invent the future.
When you’re pitching on stage, don’t bother giving a bio. You need that time to show off your products. Plan for failure. That means being ready to present without slides or notes. No live demos. especially ones that rely on WiFi. If this can trip up Steve Jobs, what chance do you have? Make a movie.
If you can do this in a weekend, so can anyone else. Disabuse yourself of the notion that you are particularly talented. Don’t think you’re shipping this thing on Monday. You’re only just beginning the long, hard road to creating and launching a viable product.
One thing I kept trying to drive home to the people who asked me for advice was that there’s a world of difference between Sunday night and Monday morning. Sunday night is all about giving a good demo. Monday morning is about getting down to business.
In my keynote, I talked about taking lessons from negative experiences. Here’s one such lesson: don’t be a dick. Don’t stand around after the show badmouthing the team that beat you. It doesn’t reflect well on you.
Our community is small, and word of bad behavior travels far and wide. Getting caught up in the moment and losing sight of the bigger picture can damage your most precious asset—your reputation. If you don’t have that, you don’t have anything.
Talk is cheap—smacktalk doubly so. Instead, take the loss as that rarest of opportunities to return to your lair and meaningfully say, “Fools! I’ll show them all!” If you think you should have won, prove it. The best revenge is a successful launch.
For those of you working on apps—and what startup these days doesn’t have an app—you’re in the best possible place. As the capital of the Appsterdam movement, Amsterdam has the world’s most advanced infrastructure for developing your technology.
Come work with mentors and colleagues at an Appsterdam Approved Hangout. Take in a Weekly Wednesday Lunchtime Lecture. Stop by after work for Meeten en Drinken. Join an Appsterdam Family Weekend. We’re here to help you succeed.
The title says it all, doesn’t it? In my time in this industry, with the things I’ve worked on, the stories I’ve heard, and the apps I’ve seen, I’ve found certain patterns, certain themes that recur, as fast routes to failure. If you’re doing, or planning on doing, one of these things, be warned.
Make a game.
When people tell me they’ve made an app, I say, “great!” but when they tell me it’s a game, my face falls. I hate giving people bad news. I hate telling people their app is going to fail. I hate having to tell people their games suck, and they always suck. You have a game? Sorry.
Games have to be fun, and game makers have to be brutally honest with themselves about whether their games are fun. If that were easy, the world would be crammed full of great games, instead of being crammed full of crap and copies.
This is why I warn people from writing their games in OpenGL. It just makes it even harder to code a game that is fundamentally unplayable. You should be writing your game on index cards, and playing with your friends, before you ever write a line of code.
Once the game is fun, whether you’ve developed an original concept or are remaking a classic, and once you have the thing coded, you’re maybe halfway there. There is so much extra work that has to go into making a game. So much polish. So many details.
Did you work with a team of people, including character designers, game designers, level designers, and play testers? Of course you didn’t. You probably didn’t even think about it. That’s why your game sucks.
Making games is hard. Everyone wants to be a toymaker, but few people have what it takes to actually pull that off. One of these days I am going to sit down and write down everything I’ve learned on the subject of making games, but it’s more like a book than a blog entry.
Start a social network.
Did I say everyone wants to be a toymaker? That’s only half right. The other half wants to create social networks. Ten years ago it was search engines, but now it’s social networks.
That’s because incorporating social networking has been the easiest way to make your idea sound fundable. The problem is, there is only room for three social networks in the world, and they already exist.
Don’t believe me? Here they are: There’s the realtime social network, which used to be the telephone, then ICQ, IRC, AIM, and eventually Twitter.
There’s the scrapbook social network, which morphed into the personal homepage, then Geocities, then Myspace, and now Facebook.
Then there’s the other social network; the only one properly called “the” social network. That is your actual social network: all the people you know, and the people they know. This remains pretty well locked up in your address book.
Nobody wants to sign up for another social network. Nobody wants to be part of your social network. Your social network has nothing to offer them. No, it doesn’t. The existing social networks are generic services that do not focus on, but are good enough at, your specific area of interest, and everybody is already on them. Nobody wants to switch.
This is good news! You are freed from having to do this odious, server-heavy task. Build your social features on the existing social networks. Go beyond the drop-in “share” button. Get clever with it.
The Appsterdam.rs member site is all backed with Twitter lists. At a previous company, we built a Twitter client that used a middleware layer to add features to Twitter, including the now-standard location, and the then-tenuous uptime.
That architecture was designed so that nobody had to sign up for a new account, and if Twitter went away as we all feared it might, our users would just go on tweeting. It was a good strategy then, and it’s a good strategy now. Don’t replicate, encapsulate. Don’t subclass, compose.
Run a server.
Speaking of running a server, the easiest mistake for you to stumble into is getting screwed on the backend. That’s because most people on the app side of things, which is to say the client side of things, don’t even think about the server.
If your app is touching the server, and you own that server, you are now running an enterprise backend. Yes you are. I don’t care how lightweight or simple your use cases are. If customers are touching a server, it’s enterprise.
You cannot and should not be doing this yourself. You need an enterprise team. These guys are hardcore specialists, and expensive. Requiring a server is the fastest way to require funding.
If someone hires you to make an app for them, and it touches a server, consider any statement about that server to be a dirty, dirty lie until you see it yourself. I won’t take a job with a server until I meet the backend team and convince myself they are not a bunch of yahoos. Never again.
My advice for servers is the same as my advice for social networks—use somebody else’s. Leverage data and services across the network. That’s what the Internet is all about.
Let me stop you.
There’s a kind of hypocrisy in my telling you not to do things that I myself have done, sometimes successfully. It’s the same way I tell people not to become engineers. It’s because I firmly believe if you are meant to do something, you will do it no matter what I, or anyone else, tells you.
If you don’t have the passion to ignore naysayers, you certainly don’t have the passion to succeed—especially at building something as difficult as a hit game, stable backend, or viable social network.
Eighty percent of the people working on these kinds of projects don’t have the passion. They think they do, but they don’t. They don’t have the patience to take as long as it takes to do it right. They don’t have the humility to get help in fixing the things that are wrong. The don’t even have the critical eye it takes to be honest assessors of their own work.
And there are real opportunities out there. You just have to be prepared to go into a project you may never come out of to pull it off. Want an example? I often say ideas are worthless, so here’s one of my most prized:
There is still room for a server-backed social network based around games. Think chess by mail. Now think chess by Twitter. Now think every great game being played with your friends asynchronously over the network.
This future empire is still ripe for the building. I thought Words With Friends would pull this off, but they ended up pretty much sucking in the long run. There are a lot of players trying—Plus+, Game Center, and Facebook off the top of my head—but nobody has managed to be the standout in this space.
We have a basic human need to communicate with each other. We start conversations, not because we have something to say, but because we want to keep in touch with each other, to reach out to our loved ones to say nothing more than “ping.”
When you think about it that way, isn’t a game a kind of conversation? Rather than inventing something to talk about, we break out a board game. Now make that asynchronous, and inject it into online social networking.