It’s okay for Google to kill your favorite features — in fact, they must

Google is certainly on one end of a spectrum in its approach to app development. If another software maker is conservative and careful about the features they add to their apps and when, you could say Google is… the opposite. It’s long established that A/B testing is a deep part of the company’s culture, and its consumer-facing apps are no exception.

You’re most likely familiar with this concept at a macro level — e.g. “If we try five approaches to messaging apps, at least one should work out in the long run, right?” (I hope that Google, in this particular case, admits that the answer is mostly “not really”.)

But it applies on a micro level, too. Google might have a desire to, for example, have an established peer-to-peer payments service. So they might try to put that functionality in the Messages app, in a standalone Google Pay app, and maybe even somewhere else weird that you might not expect, like in Google Maps (no, that’s not a feature). They’ve done weird things.

“Who knows?”, Google asks. “Maybe people want to send money to friends in Gmail?” Or maybe, if presented with the option, people will learn that it’s an absolutely critical part of their daily workflow (lifeflow?) that they can’t live without. Yes, you can actually send money to people via Google Pay in Gmail in the U.S. I don’t use it and have never used it. Have you?

There tends to be a large number of “on ramps” into the Google services that they want you using. Google can then measure which pathways are converting into actual users of that feature or functionality. In the meantime, some percentage of users have grown to depend on certain pathways as part of their workflow, and generally ignore others. One person might use Google Pay Send in Gmail every single day, for example, but skip on Google Pay in Messages.

A natural consequence of this A/B approach to development is that eventually, when the data shows that A was far more successful than B, you have no choice but to cut ties with B. Many people think of how they use their phone in a vacuum, so they don’t understand that. From their perspective, the question is “What good does removing this feature do?”.

https://twitter.com/hallstephenj/status/1149328042180993024

The problem: If you applied that question and logic to every single feature removal — given Google’s A/B development paradigm, which necessarily introduces features that are assumed will possibly, or even likely, be removed later — you would be left with dozens of apps with overlapping features and functionality. Many unmaintainable, messy, bloated, and very not-user-friendly apps. That is not the Google app experience that you want. I promise.

It is true that removing that removing a particular feature for a particular person is often both annoying and inconvenient. I’m not denying that. By the time Google realizes they have to trim the fat from an app, Google tends to have a certain subset of users who absolutely adore the “B.” And at Google’s scale, 1% of people is a lot of people. So, then, we see these tweets…

Why is Google removing the GIF Camera feature in GBoard in future versions? I only recently discovered it and it's pretty cool!

— Paul (@paul2dart) June 20, 2019

The Gboard is ridding the gif maker. That blows. @Google

— O (@OldeDetroiter) June 20, 2019

Look, I empathize. To some extent, I really do. I’ve been on the receiving end of this one. In fact, I am right now. Abner and I stream the Alphabet Scoop podcast on Google Hangouts on Air every single week. It’s part of our workflow. It’s literally our job. And Google has decided that Hangouts on Air is unnecessary bloat that probably costs more to maintain than it’s worth.

A few things worth noting here. First, Google has significant data that supports the killing of the features they kill. It’s a tendency that the apps and features that get killed are the ones that 1) don’t have any benefit to Google’s bottom line (read: advertising), 2) are soon to be replaced by something better, or 3) just don’t have significant enough adoption to justify ongoing maintenance. As one mobile developer who follows me on Twitter said, “every little extraneous feature is something that can break when you make architectural changes.” (As always, there’s also a relevant xkcd.)

Making overtly user-hostile changes because they don’t directly contribute to Google’s ad revenue is a hard thing to defend, so I won’t really try. Killing features that (relatively) no one uses makes simple sense, and no matter whose platform you’re using, you should always be careful about building your workflows around things that might simply be deprecated from lack of use. (There are egregious, near-unjustifiable exceptions to this… I’m looking at you, Reader.)

But let’s zoom in a bit on the second point. Google very often has plans to replace the features that they “kill”. Or in some cases, they are already redundant and a minor tweak in workflow you could do much the same thing using another Google app. Google just killed the GIF camera in Gboard (why was there a camera in a keyboard in the first place, hmm?). Here’s an (admittedly imperfect) alternative: Take a Motion Photo, open Google Photos, and download it as GIF.

There’s another example I have right off the top of my head. With the release of the second beta of Android Q at Google I/O this year, it became clear that Google would be deprecating Android Beam. It’s easy to argue in favor of killing this feature solely based on the fact that only a minority of Android users even knew it existed, but there was something else going on behind the scenes. Google was working on what appears to be a far more robust and helpful alternative, called Fast Share. I’d argue that’s the case more often than not.

Google is notorious for trying new technologies in a new app or service, “killing” them, and resurrecting them later better than they ever were. Think: Stickers or Google Assistant, from Allo, resurrected in Messages, Goggles to Google Lens, or Snoozing from Inbox, now in Gmail proper. We’ve even heard a rumor that Google is working on a new video chat platform based on Duo’s technology.

In the end, Google’s apps tend to get better. On average, features don’t really tend to go away. Our phones, over the long haul, are only getting more and more useful — even amidst Google sometimes “killing” the features we love. I’d argue that useful functionality and new use cases evolve much more quickly on Android than on competing platforms, and that’s one thing that people have always loved about the platform. It just comes with trade offs.

Now, I can’t say that the paradigm of (strategically, not randomly) throwing everything at the wall to see what sticks (what I’ve called Google’s “A/B testing culture” in this piece) is objectively the best way to approach things. For whatever reason, though, Google has clearly decided this approach is better than the relatively methodical, conservative, and intentional approach that is taken by others (Apple being one good example).

It doesn’t seem that this approach to app development is changing any time soon, so here’s what I say to you, Google and Android user: By purchasing a Google or Android-powered product, this is what you signed up for. It’s an unavoidable reality of Google’s approach — the approach that has in part made Android the dominant mobile operating system in the world. And while it certainly has its drawbacks, it’s never as awful as it seems, and it can have its benefits too.