On Google’s Inability to Innovate
Trying to explain organizational issues from the Product Manager’s perspective
Earlier last week David Pierce summarized a highly discussed article with the words:
Google was right about basically everything about the internet, a decade before everyone else … and now many of its products somehow feel way behind.
There’s probably not a single day on my Twitter feed where this sentiment isn’t strengthened — sometimes even in direct succession.
This blog has some (by no means complete) history in surfacing the wasted potential of Google’s services:
2012: About YouTube (Music)¹
2016: About Android Wear & Smartwatches
2017: About Pixel Phones
2017: About Chrome OS and its integration with Android
2018: About Google+ and Google Contacts
2018: About Google Podcasts and how a platform around Podcasting could be built
2019: About Google Latitude
2019: About Google Reader and exclusive content
2020: About the Android business model
Not to mention markets wherein Google would have had a very good starting position but failed to capitalize on it (yet).
We know that Gmail could be better, because we’ve seen Hey or Superhuman (and even Google Wave!). We know Google Meet could be better, because we’ve seen Zoom. We know the G Office Suite could be better, because we’ve seen Airtable, Notion or Casual.
Just because we haven’t seen a better product brought to market, doesn’t mean there could be none. I guess the base assumption for software in general is: If the product is “radically stagnant” for 5 or more years = there could be innovation.
Now it’s relatively easy to give a Big Tech company advice in how to seize a market.
- The natural tendency of monopolies in capitalism paired with the web’s low marginal costs means they got the most important asset already for free: Users
- Big companies and especially conglomerates have always been bad at efficiency and innovation
So, being a Big Tech tank opens a myriad of lucrative options to pursue while the company gets lost in the details of its daily operations. No wonder that those on the outside look at the big picture and can’t help themselves to scream Why don’t you do X, it’s so obvious!
Still, Google’s black hole of mismanaged products and acquisitions is staggeringly big — even compared to other conglomerates.
In search of clues why that’s the case, one theme comes up. And it’s that Google is a Engineering-driven company.
Steve Yegge described Google’s software development process once as follows:
There are managers, sort of, but most of them code at least half-time, making them more like tech leads.
Developers can switch teams and/or projects any time they want, no questions asked.
Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
Contrast this with Ben Hylak’s experience at Apple.
Of course, empowered engineering is great. Product Management Guru Marty Cagan has the definition of what empowered engineers do.
I’ve long said that if you’re just using your engineers to code, you’re only getting about half their value.
Empowerment of an engineer means that you provide the engineers with the problem to solve, and the strategic context, and they are able to leverage technology to figure out the best solution to the problem.
True. What I noticed, though, is that in search of empowered engineering and because (good) engineers are very hard to get, some tech companies sort of overshoot.
I can look back on more or less a decade of experience in various interpretations of the Product Manager and Product Owner role. When I think of engineering-driven companies, I think of devs hunting perfect code, do rewrites often for the sake of clean code, building what’s technically possible and not what’s useful, stay in their technical bubble and never talk to customers.
Nowhere is this more apparent than at Google. Ben Thompson keeps on repeating: Whatever made a company succeed in the first place will be baked into its culture forever. For Google that’s raw engineering is the solution.
Think about their first product. There was no designer or PM involved — it was 10x better because Larry Page created a whole new technological approach to ranking links in the backend, far away from the user.
Was Google Search tailored to specific audiences? Did somebody thought about monetization? Did somebody think through how the algorithm could be tricked? No, no and no.
No big deal back then, but the same pattern gets repeated in Google products today.
Last year I went to the PMF in Zurich. Jacob Bank from Google was one of the Keynote speakers. Jacob had its own calendar app startup Timeful, before it was bought by Google in 2015. Now he oversees all of Gmail.
I encourage you to watch to the whole talk. Unfortunately the Q&A session is cut off.
Several things are noteworthy for our context:
I. If you think, well, Google plowed down millions of dollars so they have to have some kind of plan what to do with the acquired app, you’re mistaken.
Jacob was aware that he had adapt to Google’s culture to get something done. Otherwise the organism would reject him. So no, culture can’t be changed with external impulses overnight.
II. When you have a very popular product like Gmail, every tiny change gets thousands of opponents. So when Jacob tried to integrate features from Timeful, he got burned by users who didn’t care.
The lesson he took: Features that aren’t along the happy path of Gmail’s millions of pro users have no chance.
While it’s true that you can’t change user behaviour easily, I think that’s the wrong approach. It only allows for the local maximum to be reached.
That’s actually good in case of managing mature products with low desire to innovate. Think airplanes or power plants.
Does something like mature web software even exist? Treating software programs like it does could result in maintenance problems sooner or later.
Us outsiders thinking that Gmail didn’t change the last few years? I guess they were crazy-busy and developed many features — but only the very detail-oriented, backend-oriented and/or ‘safe’ ones.
III. When Jacob took over the Gmail team, they had Gmail and Inbox, its cool cousin.
I think that’s a great setup: Because you don’t want to disrupt the workflows of millions of people, you try out new features at Inbox. Two distinct philosophies about email, packaged and marketed to their respective customer groups (I refuse to call them niches given how big the addressable markets still are).
If that’s to fluffy for you, think of it as staging environment: What works with the Early Adopter crowd at Inbox will flow down to Gmail, what doesn’t, doesn’t.
Jacob and his team decided to merge some features into Gmail and bury Inbox. The reasoning is telling: It’s not that the distinct target audiences vanished (they didn’t) — it’s that they made a feature-by-feature comparison and noticed, after all we got two mail clients! Who needs that?
I don’t think that this will be good for Gmail users in the long term, but call me biased if you will. #TeamInbox
IV. Moving on to another great line (segment starting at 24:15):
The first thing I do whenever I come into a new organization is to cut the number of PM’s in half.
Yes, you can call Product Management “the most dangerous function”. But think about the message that you send: Please don’t think about how our strategy or vision could be enhanced, because that could inhibit my precious engineers from doing what they were told — especially if you’re a good PM.
For one of the remaining PM’s: It’s obvious that they won’t speak their mind as openly or bring innovative ideas to the table in the future. Another inch closer to John Cutler’s Feature Factory.
V. Perhaps because PM’s are so dangerous let off the leash, they should act as secretary to the engineers. No really, he said basically that as answer to how PM’s and Devs should work together.
Again, I get where he’s coming from: Google engineers can choose what project they want to work on. Engineers can launch something on their own — PM’s or UX Designer can’t².
Yet, every time I think of good teamwork the members are valued equally.
Sure, this is a very Product Management-specific angle to look at things. There are other angles about what’s problematic at Google. I suggest you read Ross LaJeunesse take, too.
Sure, Google is not run by Jacob, neither are all the departments the same. Some acquisitions worked out fabulously for Google. They’re getting more user-centric in some areas. And for very technical products this Developer-driven mindset may even be the right approach.
But somebody approved Jacob’s talk and hasn’t seen the issues I saw. That’s worrisome.
I can’t help but wonder what products Google would be producing if they had a Product-driven mindset.
[1] Google followed my suggestion to use the YouTube brand 6 years later.
[2] We have to wait for the no-code revolution.
