Lessons learned from launching first app

November 22nd, 2011

You don’t know about execution, user experience, product management & design unless you’ve launched something of your own. That’s lesson #1 for me after the ups and downs of launching 4sqwifi on the AppStore the other day.

Launching is maybe one of the most critical stages of your product. I don’t feel like there’s a difference between a startup or a “weekend-show-HN” project. Launching is launching, is critical and will remain this way for better or for worse.

Aside critical, it’s the one that offers you the most knowledge, as a developer, marketer, professional, hobbyist, […], and in the and even as a human, whether it’s a software project or not. Let me explain myself.

Keep It Simple, STUPID

Keeping your first version as simple as possible is top priority. You want to show people what’s the core of what your app-project-whatever does, yet not overbloated with features and chaotic design. It must be inspiring too, letting people know that this product has a feature, a vision behind it.

I could have included all possible features in the first version of 4sqwifi. Venue checkin, Twitter/Facebook sharing, in-app tip section for each venue so people can add wifi passwords within 4sqwifi, map view and hell knows what more. Inspite all this glitter I decided to keep only the most core feature of all and 4sqwifi’s promise: show nearby venues which have wifi and their password. But of course, along with a basic package of usability: Google Map for each venue, address, by whom-and-when each tip was written, number of all nearby 4sqwifi venues.

Beta test like a B*TCH, BITCH

You don’t want to launch with bugs. Seriously, I repeat: you don’t want to launch with bugs. Users in their vast majority won’t give you a second chance, unless a) they’ve seen a whole lot of potential behind your buggy product in its idea/vision b) were smart enough to figure out how to bypass the bug, c) where lucky to not spot the bug, d) you wrote a post, released a public announcement and whatnot about the bug and they were aware of it. But probably they won’t give a second chance.

And that’s what happened with 4sqwifi. A stupid bug that didn’t appear in the testing period (on-iPhone 4S/3GS, on Xcode iOS 4.3/5.0 simulators) or to a handful of other users. Suppose 1,000 people downloaded the app, 100+ had the bug, they wrote bad reviews in AppStore (which, by the way, its review system sucks big time) and that prevented other people to download the app. Plus, it annoyed me. The bug was very simple: it appeared after a user logged-in with his Foursquare account. A callback URL of the 4sqwifi website didn’t disappear and users thought that the app was crap and shit. The solution? One simply had to kill the app from multitasking and re-open it. Users don’t know about, don’t care, don’t want to do these kinds of stuff so they were totally right being wrong. Anyway, it’s already fixed and waits to be shipped. Mentioning shipping: real artists ship & launch fast, fail faster.

Ratings do NOT fucking matter

Clear example: Facebook Messenger for the iPhone has 2.5* stars in the Greek AppStore and Facebook itself has 3. The average user doesn’t know how to rate — that will remain so — and most of your users will be average users. Fact. The sooner you understand it, the better.

4sqwifi started with a solide 6/6 5* star rating, then dropped to 4.5* and finally to 3.5*. The main reason behind the low ratings is the bug itself, the other is that users didn’t get actually what 4sqwifi is about. Many thought it is a cracking tool, you see a wifi nearby, open 4sqwifi and it cracks it for you, showing the password. No, nein, όχι. Others didn’t get that it requires a Foursquare login so they were like “WTF IS THIS CRAP, DUDE,” I don’t want to sign up for anything. Others thought it’s a scam or a non-app app. Your idea might be perfect, your product might have the best intentions and potential behind it but without a excellent user experience, the rest is meaningless (quoting Pascal Finette, a Mozilla dude I met in my Silicon Valley trip.) Oh, remember Color? Yeah.

Listen to people that are of VALUE

Feedback from the average users doesn’t mean anything. Feedback from someone who is of value means a lot. Doesn’t matter who he is (can be, theoretically, your mom), it matters what is he doing and what’s he done. Experience that can be shared matters.

And how did this apply to 4sqwifi? I got feedback from Chris Wanstrath, co-founder of Github, Google engineers, Google semi-execs, founders of 8tracks, Crowdbooster, Higear, a Twitter Product Manager, i/o ventures. That’s valuable feedback. AppStore reviews in principle are not. Curate your feedback, understand better your users. That’s key for you. I’m not saying don’t listen to negative feedback. You should, but don’t get overwhelmed of it and start thinking that’s the end of the world. No, it’s not. But: don’t listen to the average user for future features. Don’t do that, it’s going to destroy you.

Sharing is good, oversharing is fucking LAME

Unless you want to appear like a 14 year-old girl cheering the one whose name shall not be spoken in this blog, do not overshare about your app. Don’t spam Facebook, Twitter, Instagram, Quora, Foursquare, Google+, LinkedIn, Tumblr, your blog and whatnot about the new product. This will kill the interest people might have in you and your product and start consider you like a douche. And probably they’ll be right.

I did overshare once about 4sqwifi. The moment when the 3 Push notifications from Apple came saying “Your app is under Review” blah, blah, blah. I did about 3-4 consecutive tweets and 1-2 Facebook posts. In retrospect, I don’t like it — I don’t regret it either. Being more discrete is valuable for everyone — your product, your users, our timelines. Luckily it didn’t kill the interest people had. Nor did it increase it, methinks. Things I shared afterwards and in the next days were: direct link to download the app, some “inside-statistics,” a couple of photos with AppStore rankings. Be descrete, not secretive; share, not overshare.

~fin.

Comments

  1. Pingback: ghambas [dot] net
  2. Imho, you got it wrong in the ‘Listen to people that are of VALUE’ paragraph; you confused me between:

    – ‘Feedback from the average users doesn’t mean anything’. I assume this means feedback about the product you are shipping NOW (your app in the appStore) and

    – ‘don’t listen to the average user for future features’.

    These two are way different things and I completely disagree on your approach that average users cannot give you anything back. It is exactly those users that you should listen/focus to more than experts. If you prioritize the feedback you are getting, they should be No1 in the list. Their feedback is gold.

    Now, as for the second, there is no clear answer. It is mostly you on this -or your team-. But always take into account user feedback -even by average people on feature releases-. That said, you are lucky to have free feedback, other people are paying big bucks for it.

  3. Hm, I see your point. Now I think I didn’t make myself clear enough.

    Feedback from the average user is, actually, either “gold” or nonsense. And that is because the average user needs the simplicity (without knowing it) and less clutter in UI, features, etc (again, without knowing it) — that means, in his quest of better apps, he might share a valuable insight about your product that it’s indeed valuable. On the other hand the average user does not understand UI, UX, less is more, UI workflows, perhaps the idea/vision behind each product (it doesn’t matter if it is an app or whatnot.) and his demands as future features or feedback might be bloated (integrate this and that, add something of this here too, change this, blah blah yada yada…)

    I’m not talking about experts. As said, people of value can be your mom, too. It’s basically people who understand things & concepts, have a vision. They think big. They can help you out.

    Plus, none said that they’re the same thing. Two different aspects. Yet, almost the same answer “no.” And there’s a difference between taking into account and building upon/atop it. I’m talking about the latter.

Comments are closed.