Ajay Kulkarni

(More cross-posting from my Quora blog. I’ll probably keep doing this until I decide which platform I like better.)

Big, new, evolutionary product features are like pornography: they’re hard to define, but you know it when you see it. [1]

Finding these new features, the ones that make your product 10x better, is one of the hardest things you have to do as a “builder.”

And if you’re a startup, they’re even more important. Because startups either grow, or they die.

I’m not talking about tightening funnels, cleaning up the UI, or reducing friction. Those things are important, and you should always be doing them, but they lead to incremental improvements.

I’m talking about the big features, the ones that expand what your product does and means, that take it to a new level.

There are no checklists, frameworks, methodologies that will identify them for you. Surveys and focus groups won’t help either.

You won’t find them talking to your users. What we’ve seen at GroupMe and Sensobi is that users typically have a narrow scope of what the product should do. They’re vocal when something is broken (and you should listen to them when they are). But if you asked your users what new features they’d like to see, what you hear is almost always an incremental feature. [2] [3]

So where do these evolutionary features come from?

I had a conversation the other day with a coworker, discussing something we were considering adding to GroupMe. He asked a simple, but very dangerous question: “Why are we building this? No one is asking for it.”

My response: “We’re building it because we want to use it. And even though no one’s asking for it, we think that they will love it when they get to use it." 

Because evolutionary product features don’t come from your users, they come from within. 

They come from understanding the fundamental mission of your company, what you do well, and what people love about it. And then, from finding ways to do more of it, to expand the scope of what you’re doing. 

In other words, to find one, you need to understand what you currently do well, and then, think bigger.

And, if the moment’s just right, it hits you: "That’s what we should be doing.”

But then you test it. 

And that’s where the frameworks, methodologies, surveys and focus groups come in. That’s when you talk to your users.

Here’s how you test it: If it’s something that’s easy to build, then build it, see how it feels to you, show it to other people inside the company, and then show it to your users. If it’s hard to build, then mock it up: draw wireframes, hi-fidelity designs, showing them to other employees and users. [4]

Build, test, refine, repeat. 

And if something doesn’t work, if the initial feedback is “meh”, then cut bait and move on. There’s a massive new feature out there waiting for you. Don’t get caught hunting a small local maximum.

All of the big successful features we’ve launched at GroupMe have started with someone inside the company who wanted to use it. [5]

Not every new feature we’ve designed has made it into the final product. Some we killed early on after using them ourselves, others when we started showing them to users. But that’s okay: if your new feature ideas don’t fail every now and then, then you’re not taking enough risks, not thinking creatively enough.

Of course, how do you know if a feature’s successful? And an even harder question: if you launch a new feature that you love, but your users don’t, do you go with your instinct and wait it out, or do you just revert? 

Great questions - for another post.



[1] I know it when I see it.

[2] Some of the ones we’ve heard at GroupMe that we’ve acted on: iPad support, the ability to hide conversations, custom ringtones for groups. Again, incremental features aren’t a bad thing, they make the product better. But what we really want is to move the needle.

[3] Also, I don’t want to undermine the importance of listening to your users. In fact, Andy Cheung and I once wrote a chapter on it for TechStars (Do More Faster: TechStars Lessons to Accelerate Your Startup: Brad Feld, David Cohen: 9780470929834: Amazon.com: Books). But listening to user requests is not enough.

[4] Showing something new to users should include a wide spectrum of activity, including one-on-one user testing sessions, larger focus groups, betas, releasing to a small percentage (e.g., 5% of all users) and A/B testing, etc.

[5] A quick, small, non-comprehensive sample list: the latest GroupMe 4.0 app redesign, the current GroupMe web chat, the ability to share groups. There are also a few more awesome features in the pipeline that I can’t talk about right now but can’t wait to show you.

Looks like Quora is adding (pivoting to?) blogging. So I thought I’d give it a shot.

Here’s my first post: 

$AAPL is down 10% after hours. Android has 70%+ of the worldwide smartphone market.  

I can already see the look of self-doubt and confusion in the new mobile developer’s eyes.

Take a deep breath, young padawan.

Don’t let the numbers fool you. If you’re building a new app today, you still need to start with iOS.

Here are a few reasons why*: 

1. iPhone users are better than Android users. They tend to be earlier adopters, use more data (3.5x more, according to some studies), and spend more money. [1] [2] [3]
2. Building an awesome app is a lot easier on iOS than on Android. Android’s fragmentation (platform and hardware) makes awesome app development a lot more difficult: it’s harder to design a beautiful UI because of different screen sizes, resolutions, standard orientations; it’s harder to take advantage of new APIs; it’s harder to test everything and make sure it’s perfect. [4]
3. iPhone users upgrade their apps on average 2-3x faster than Android. So when you launch a new feature, bug fix, etc., you can expect most of your iPhone users will have it within the first few weeks, while on Android that will take 2-3 months. Which is weird, considering Android allows automatic upgrades, but perhaps speaks to the type of user. [5]
4. It’s easier to prototype on iOS with webviews. Yes, webviews suck, but when you’re building an MVP you can use them judiciously to speed up your iterations. However, on Android, thanks to device/platform fragmentation, it’s a lot harder to get webviews to work correctly, if at all. [6]
5. With iOS, you’ll avoid the “Sensobi Problem”: building an app on a more open platform that’s not possible on a more restrictive but popular one, thereby radically shrinking your market. This is a problem we made at Sensobi in 2009 (with BlackBerry as the open platform), and I see people make this mistake with Android today. They pick Android because it’s less restrictive, and then build an app that can’t exist on iOS. And then they shut down or pivot. If you start with iOS, you’re a lot less likely to have this happen to you. [7]

Start with iOS. Build your awesome app. Make it beautiful and indispensible. Get traction. Make people fall in love with it.

And then, when you’re ready, build it for Android. 

And maybe, somewhere down the line, start thinking about Windows Phone. But let’s not get ahead of ourselves.


* DISCLAIMERS:

• This is mostly a US-centric argument, which is the market I know best. I don’t pretend to understand what goes on overseas, especially since “overseas” isn’t really a thing (every region has its own dynamics).
• I’m assuming you eventually want to build an app that works on both iOS and Android. I don’t know why you’d only pick one, but obviously if you had a good reason to pick one and ignore the other, and that one was Android, then the rest of this is moot.
• I’m still a huge fan of Android, really like my Nexus 4, have used almost every new Android phone as soon as it comes out (we have a pretty deep stash at GroupMe), and really enjoy some of the unique features people have built that are only possible on Android. And we’re constantly working to make the GroupMe Android app better and better: in fact we just released a major version today (GroupMe 4.0 for Android Android users, it’s your…). I’m just saying that you should start with iOS.

SOURCES:
[1] Why are Android users less engaged than iOS users?

[2] Android vs. iOS usage

[3] Class Warfare, Fragmentation, Usability Gap? The Android vs iOS Engagement Paradox - Forbes

[4] I feel like these points have been discussed ad naseum, but if you want data, here you go: Based on Google’s own data, roughly 50% of all Android users today are on Gingerbread (or earlier) - which was released in February 2011 (almost 2 years ago!), 2-3 major Android releases behind the latest version, Jellybean (Dashboards | Android Developers). Apple doesn’t release data in terms of upgrades, but from what I hear the vast majority of iOS users are on iOS 6 (at GroupMe, that number is over 90%). And if you want data on hardware fragmentation, just visit your local AT&T/Verizon/T-Mobile store. But don’t say I didn’t warn you.

[5] This is from our own data at GroupMe. Let me know if you’re seeing something substantially different. 

[6] This should probably be a post in itself, but in short: on older versions of Android (Gingerbread and earlier), webviews do not always render HTML correctly (and when they do, it’s often very slow), not even supporting everything they claim to support. And don’t get me started on testing. 

[7] At Sensobi (my last company, with Andy Cheung), we made many mistakes (and have learned from them). But one of the biggest ones was building on BlackBerry - and not for the reason you might think. We chose BlackBerry because between iOS/Android/BlackBerry, BB was actually the most open platform. Specifically, the BB SDK gave you access to tracking calls, emails, and texts. But guess what - iOS doesn’t. It didn’t give you access then, and it still doesn’t today. So we built this nice app BlackBerry users loved, and that we could never build on iOS. Don’t make the same mistake we made and build an app that half the market won’t be able to use. Pick iOS. (Luckily, everything worked out ok for us: Sensobi acquired - First exit from Boston 2009 class - TechStars).