The iPhone vs Android Approaches to Building a Product
The iPhone, when it launched, didn’t even have basic features like copy and paste or multitasking. What it did have was very polished, and the first one iPhone bought, the 3GS, met a bar I didn’t know existed. Over the years, Apple added these and a lot more missing features, while maintaining a minimum level of polish.
By contrast, Android had features like multitasking from the very beginning, and added features faster than the iPhone in its first few years, always remaining ahead in this regard. It was a crappy user experience, built with no attention to detail. Over the years, Google polished it, to the extent that it’s a very similar product as the iPhone, as of today. Both have a polished UX, both are responsive, have good battery life, are more extensible than most people need, have all the apps you need, have great screens, and more. You can always come up with minute reasons to prefer one or the other, but they’re at par.
So, iPhone and Android took different paths to the same end state:
When you build a product, you can take either path. Starting from not having enough features or quality of those features, you can first add features then improve quality (Android) or the other way around (iPhone).
With Futurecam, for example, I took the Android path: within a few months, we launched a phlethora of features: long exposure with liquid shutter, light trail video, timelapse and burst, with a low bar. We then slowly improved them over subsequent months.
The point here is not to argue that one is better, but that both paths exist, and you can consciously pick one when building a new product. But, whatever you do, be clear about the tradeoff. Saying “we need to both have a lot of features and they should be polished” only shows your inability to prioritise and come up with a practical plan.