When aggregation works and when it doesn’t

All consumer internet products are either about consumption, production or both. A blog site is primarily about consumption. A photo transforming app is primarily about production. Social networks are consumption heavy. Good Messaging apps are symmetric. And a grievance collection product like BBB is production heavy.

Building aggregation on top of similar products is a well-known strategy.  The hard realization to note is that it can succeed only in very specific scenarios. Look at all the successful aggregation products, travel booking sites, news aggregators, RSS readers, discount coupon aggregators. As opposed to that, attempts to write an email aggregator, a social media aggregator etc. have not been as successful. And that’s the underlying theme, aggregator works well for consumption only interfaces where the product is sourced from many sources (more the better) and  is standardized in the eyes of the consumer. They have limited success almost everywhere else. And this just doesn’t apply to software products. Microsoft tried and failed to have their own hardware stores since their offerings were similar and a subset of BestBuy whereas Apple succeeded in the same strategy despite the naysayers.

The Android-Chrome merger saga

Articles with the following titles would be considered a joke
1. “BMW is planning to merge its series i5 cars and Motorrad bikes”
2. “P&G is planning to merge tissue paper and toilet paper”
3. “Arm and Hammer is working on merging face wash, body soap, shampoo, laundry detergent, and dish cleaner”
Not that these combinations can’t be made or have never been made but consumers would just not buy them. They are usually inferior or more convoluted, or even worse, both.
But the Android-Chrome OS merger stories keep popping up every few months. Excluding the technical jargon, it’s as much of hogwash as the first three. In the longer run, markets specialize and not generalize.
Note: The only time when generalization appears to wins is when an entirely new market is created which renders multiple existing markets customer-less. And that too is a head fake in favor of generalization.

Startup valuations

In 2001, Amazon’s share price crashed from 100$ to 6$, they had to do a 15% layoff. But it was Jeff Bezos’s perseverance, tenacity and grit because of which Amazon survived. As several startups from the Bay area to Bangalore get a mark-down of their valuations, the question about how many will survive and eventually produce a [positive] return for their investors is being asked. Between what a startup’s real value is and how viable is its business model, the real question to ask is how committed are the founder(s) to make things works. In the longer run, only that will matter.

Voice Interfaces: The Missing User Interaction Element

Amazon Echo

Amazon Echo

Apple Siri, Google Now, Amazon Echo, and Microsoft Cortana have garnered a lot of press lately. But one thing which is still missing out is voice-native user experience.

Let me illustrate that with the evolution of user experience on touchscreens. When they first came out, there was a stylus, and that’s it. It was an inferior version of the mouse-keyboard-monitor trio. Then some fantastic interactions were invented. Interactions like double tap to zoom, multi-finger rotation, swipe to like/dislike, pull down to refresh, long-press for options, and a Swype keyboard. All of these were native to a touchscreen-based environment. Porting them back to a mouse-keyboard-monitor trio was of limited utility at based and useless at worst.

Read More

File size should always be of “long” type

A 32-bit signed int can deal with ~2GB worth of data. And if your code is not going to deal with files larger than 2GB, why worry? But what if  someone wants to use the same code for a video file some day? Or What if someone writes another code to iterate over all the files in the BASE_DIR directory? Most likely they will be inclined to use int for the final sum as well. Adding integers in most languages results in int and automatic overflows into a negative number (and even worse, back to a positive number). The caller code might think that BASE_DIR does not exist. Therefore, the best future-proofing is to never have file size stored as an integer. Even, Android platform got it wrong with StatFs#getBlockSize and corrected it by adding StatFs#getBlockSizeLong.


Standards exist so that products from different vendors can interoperate with each other, for example, sending email from Gmail to Yahoo! mail, and use common interfaces, for example, sockets for electrical appliances. The standardization does not always have to come from imposed standards; sometimes, it comes from the user expectations. For example, the interface of a Calander/Scheduling application is pretty standardized. There is little scope to differentiate a new Calendar application from the existing products like Outlook Calendar, Google Calendar, and iCal while just implementing the standard is still pretty hard.

One problem which standardization introduces for the product vendor is that there is little left to differentiate itself. For example, either the cables are compliant with USB-C standard, or they are not. The lack of differentiation produces perfect competition and hence, razor-thin margins. The model, thus, works only at scale. The same problem of standardization seems to have plagued products focused on email, calendar and RSS feeds. All three of them are pretty standardized. While one can provide a better UI like Sunrise does for Calendar, or over-the-top functionality like MixMax does, there is still relatively little scope for a product solving any of these to differentiate itself from others. Therefore, big companies with established distribution channels dominate.

The only exception to the rule is producing premium quality products, either in reality or perception and then wait for a niche market which will be willing to pay a premium hoping that they are getting the best product, for example, 41$ mini-USB cable and a 50$ MailMate email client.

When marketplaces work and when they don’t

Thanks to Uber’s meteoric rise in valuation, several startups are trying to mimic the idea of building marketplaces with instant gratification. So much so, that there is an aptly titled poem, “Uber for X“, devoted to this. Though the jury is still out on Uber or Airbnb, some others like Exec and Homejoy have already failed to be sustainable businesses. Here are a few thoughts on the characteristics of marketplaces, including so-called sharing economy startups, which decides their eventual fate.

Characteristics of an on-demand marketplace

  1. Price
    For a low-ticket item like Uber ride whose average price is 16$, chances of a buyer looking for cheaper alternatives are lower. For a high-ticket item like Airbnb where an average rental is ~100$, the chances a buyer will look for alternatives is higher. That might explain the success of VRBO/HomeAway which undercuts Airbnb with lower fees.
  2. Standardization/Commoditization of goods/experiences sold
    Riders are OK with their Uber drivers as long as the drivers are good enough. And the driver has to provide, more or less, the same service to every customer.  That’s not true for a  cleaning service like Homejoy, both the cleaner and the cleaning job has a huge amount of variation.  This makes the job of providing a consistent service much harder.
  3. Interaction frequency
    The frequency of use should be high, or else buyers or sellers might forget that the marketplace even exists. PiggyBee is Uber for shipping goods, a traveler whose journey matches with the journey of your good to be delivered. Such a service would have a hard time converting and retaining users. This is crucial, a marketplace not only needs users but needs the right balance of suppliers and buyers in time and if interaction frequency is low, it is very challenging to attain that.
  4. Low platform leakage
    The underlying structure should be such that there is no practical advantage for a bond outside of the marketplace. Regular Uber riders can’t just take the phone number of a driver and call him for the next ride. Since the driver might not be in the proximity or might be with other riders. That’s not true for say hiring a home tutor, once you have found a good one, you can take the next purchase offline undercutting the marketplace of its revenue share. That is what probably killed Tutorspree, touted as “Airbnb for tutors”.
    An even better structure is where taking the dealing outside would be disadvantageous. Consider, for example, buying goods on eBay. It is better to perform the transaction on eBay to get the buyer’s protection. Or, for example, when borrowing money directly outside of LendingClub, the borrower will have a  little negative consequence if s/he decides not to pay back.
    Another thing which encourages platform leakage is the lack of urgency. An Uber rider might not want to wait one hour for his/her previous driver to be free, but a homeowner would usually be fine waiting a few hours or sometimes days, for a good cleaner.
    In almost all cases, though, a transaction can migrate to a similar platform if service being provided is commoditized/standardized. For example, Uber will have a higher chance of losing customers to Lyft than StyleSeat losing customers to LifeBooker, as long the same service providers are not listed on LifeBooker.
  5. Trustworthiness
    While the platform does vet both the supplier and buyer to some extent including providing insurance for the transaction, there might be a further requirement of trust. An Uber rider and driver would have much less requirement of mutual trust that the guest-host pair staying in the same house. The problem is worse for renting physical goods since the lender does not even know if the good returned is the same shape or not. So, a car owner renting a car on RelayRides (now Turo), would require more trust in the borrower than a homeowner would require in an Airbnb host.
  6. Fully online vs. online-to-offline interaction
    Lending club is a purely online experience for the lender and the borrower; Uber is not. A purely online model not only allows for easier scalability but also it makes intermediation easy in case of a dispute. This point, though, is relatively minor compared to others.
  7. Goods vs. experience
    If a dispute arises, it matters whether the transaction involved a good or an experience. It would be relatively easier for the marketplace to be an intermediary in case of a dispute involving a good. When it’s an experience, it is words of buyers against the words of the seller. This point, though, is relatively minor compared to others.

Below is an analysis of some popular marketplaces based on the above characteristics

Note: Some ideas mentioned in this post are based on conversations with friends and are not entirely mine.

Thoughts on Tizen

Users won’t buy a phone till they know that their basic set of apps are available on the device.
That pretty much rules out players like BlackBerry 10JollaUbuntu OS and Firefox OS.
Even Microsoft is still struggling.
OEMs like Samsung, HTC, LG, Sony have been hit hard by commoditization of Android. Google makes money from Google Play, cheaper phones imply more users. So, commoditization of Android OEMs is good for Google.
These OEMs have to customize Android as per Google’s requirements which have increased over time.
They cannot manufacture a competing version of Android (like Amazon’s Fire Phone) either.
This leaves us with iOS and Google-experience Android duopoly.
The only way to break that duopoly is Samsung, which is big enough that it can convince major developers to develop apps for its devices and throw money at marketing to reach out to end users.
It can make money from selling devices as well as selling apps (via app store).
A completely open source OS can pull open source developers from GNU/Linux and Android to develop it.
A completely open source OS can convince other OEMs to use it and in lieu, they can partner with Samsung on app store revenue sharing.
It remains to see what Tizen’s delayed launch eventually leads to but its a matter of survival for Samsung.


“Material design” and Google’s strategy



Before 2008, smartphones OS market was fragmented.
There were a few big names like Palm and Symbian, but most phone manufacturers were doing their custom operating systems. For example, Motorola alone had five operating systems.
In 2008, Google came out with an open-source smartphone OS.
Mobile phone manufacturers like Samsung, Motorola, and HTC, embraced it and made short-term profits till they got commoditized by a standardized OS controlled by Google.
On the other hand, Nokia and Blackberry decided to ignore and badly lost market share.
Eventually, they embraced it as well, albeit, in different forms but it seems its a bit late.
The only winner (till now) is Apple, who was simultaneously working on iPhone and has held its ground well primarily, due to superior UI design and user experience on iOS.

Material Design

Till 2014, web design has been fragmented, flat design is popular, but no one controls it.
There are a few big names in web UI development like BootstrapFoundation but most companies are either using homegrown or open source jQuery libraries/CSS libraries for design.
In 2014, Google came out with Material Design, and just like Android, it’s being given out for free.
Even Android 5.0 is using the same material design.
While app developers are almost bound to replicate material design for Android apps, the choice of offering the design to web developers is an interesting one.
If a sizable chunk of web developers decide to embrace material design, Google will control look and feel of the web.
If the android apps and websites look similar, then it will only persuade more and more iOS developers to use material design in iOS apps.

The end game is to corner Apple in user experience by producing a design which Apple will be either forced to adopt or create something different and superior.
As far as others big players are concerned, both embracing and ignoring material design will be an equally lousy proposition.

Disclaimer: Thoughts are solely mine. 
Disclosure: I used to work at Google.

Subscribe For Latest Updates

Signup for our newsletter and get member-only articles