Marty Kagan and Elias Lieberich, just published an article titled “The Product Model at Google”. It’s a good article that gets many things right, but I think there’s also a more nuanced picture that’s worth talking about. I see Google as an example of a company that used to have one of the best product operating models, but over time regressed to a much more conventional way of working.
As such, I think Google is a good case study for companies who want to make the journey in the opposite direction, or are worried about regressing themselves.
Caveat: my reflections are based on my time at Google during the years 2010-2016. This may not be a good depiction of Google as it is now..
I will use my 8-part company operating model to talk about Google. Specifically I want to focus on three key parts that many companies find challenging: strategic context, product discovery, and culture.
Strategic Context
Early on, Google had developed a concrete and powerful mission. It wanted to organize the world’s information and make it universally accessible and useful. This was the motivation for Google Search, but Google’s strategy extended to any form of online information — messages, photos, videos, products, …
Early Google was happy to explore any idea that aligned with this strategy. The strategic principles of the time reflected the experimental mindset: Let a thousand flowers bloom, think big but start small, fail fast. This strategy was very effective in guiding the company. Hundreds of ideas were spawned and tested. Some of these were top-down but many came bottom-up. Most failed, but some became successful products; a subset of those grew into Google’s next flagship products — Gmail, Maps, Docs, Chrome, Android, and Cloud. Google practiced very effectively what I call Multiple Strategic Tracks (MuST).
But in the 2010s Google had gradually updated its product philosophy. The mission stayed the same, but the strategy shifted. The leaders wanted employees to focus on a much smaller set of big-bet projects that came top-down (“more wood behind fewer arrows”). I can’t say for sure, but I think this was motivated by the massive success of Apple’s iPhone and iPod, and Google’s own Android that was somewhat of a pet project of the founders. I also suspect that the leaders were worried about losing control over a much larger company.
The impact of this strategic shift was dramatic and not in a positive way. While I was there I saw a long parade of big-bet projects that went nowhere: Google+, Glass, Now, Inbox by Gmail, Daydream, Hangouts, Allo, Duo, Jamboard, Spaces (and others that were never launched).
As Google knew early on, there’s no shame in trying and failing, but the issue was that these projects didn’t “think big but start small”, they started out massive; they didn’t “fail fast” when the data showed that users are not interested; Google doubled down and launched more features to try to save them. At the same time Google missed a lot of good opportunities that much smaller companies — whatsapp, instagram, Slack — were able to capture.
I feel it’s fair to say that Google fell for the big-project syndrome — it hinged the strategy on big projects that were deemed “too important to fail”; when they eventually did fail, so did the strategy. Maybe that’s why no new 1Bn-user products came out of this era (Google Photos may be the exception, but it was seeded in the acquisition of Picasa in 2004, and if anything, was held back years by its integration into Google+).
Takeaway: the modern product operating model calls for a strategy that is tied to specific opportunities and threats, not ideas. The strategic principles should describe what types of solutions the company wants to pursue, but thereafter the company has to discover the path rather than have it be dictated top-down.
Product Discovery
When I joined Google I found a company very well poised to practice product discovery (a term we didn’t know yet back then): we had great user researchers, tons of data, dogfood groups, early-adopter programs, labs, A/B testing infra, and much more. In Gmail, usability tests and dogfood were the norm, and we also practiced field research and quantitative analysis.
But with the big-bet mindset these practices lost a lot of their meaning. Yes, we could tweak the UI based on the results of the usability test, but we couldn’t challenge the core assumption of the idea. There were exceptions, one of which I described in my book Evidence-Guided, but mostly the true spirit of product discovery — evaluating multiple ideas, testing their assumptions, dumping what doesn’t work and doubling down on what does — was missing. The usability tests and dogfoods became mere checklist items in the launch.
Today I sometimes train PMs and teams inside Google and it’s interesting to see how motivated they are to relearn and reintroduce true product discovery.Google is a very diverse company. Some products and teams practice product discovery at a very high level, while others are still doing launch-and-iterate.
Takeaway: product discovery is not just about technical capabilities, it’s also — and foremost — about truly wanting to learn. Testing without taking action on the evidence is just theatrics.
Culture
There were many things I really liked about Google’s culture. The emphasis on hiring strong, capable people that have “culture fit”. The empowered teams and the triad/trio model that went all the way up to VP level. Almost everyone I worked with in my 6 years in the company was good at their job, cooperative, and nice. People cared a lot about user experience, ethics, and the success of the company.
The thing I liked least about the culture was the performance evaluation system. Google’s way of assessing people required them to write “packets” describing their “achievements” and why they were hard to do and impressive. Then anonymous committees would review stacks of these packets randomly collected from different parts of the company, compare them, not knowing any of these people personally, and issue a score on the scale of “missing expectations” to “exceeding expectations” (using disciplinary job ladders as reference). I believe there were other cycles of score refinement on top of that.
People who exceed expectations for multiple quarters would become eligible for a promotion, while those that missed expectations would have to undergo improvement programs. At Google it was the job of the individual to exceed expectations and to get themselves promoted. Those that failed had no one to blame but themselves.
Let’s put aside the question whether something as complex as human behavior in a large organization can really be quantified, scored, and compared to others’. Let’s also not debate whether this process (that felt over-engineered, impersonal, and sometimes unfair to me) makes sense. I do want to talk about some of societal implications it had on Google:
- Incentives — in addition to thinking about what’s best for the company or the users, people had to think about what would look good on their perf packet. I got the impression that this weighed heavily on some people’s decisions, and led many people to optimize towards collecting “achievements”, whether they made sense or not. It could be a contributing reason why leaders felt compelled to launch big-bet projects, and why so many others wanted to “ride the wave” of the these projects where they could get funding and visibility. Any criticism these folk may have had about these projects was best kept to surpassed for performance review reasons.
- Optimizing for output — The ladders mentioned output and scope often — the size of the project you initiated, the number of people involved, how many features or interfaces you touched… The bigger the better. That may have led to an optimization for outputs rather than outcomes that goes against the philosophy of the product operating model.
- Individuals vs. team — while we worked in teams, the perf process sent a clear signal that we’re just a collection of individuals. While I didn’t see this causing interpersonal friction, it did create tension between doing what’s good for the team (eg code reviews, cleaning up messy code) vs. what was good for the individual (e.g. developing a visible feature and letting others review it).
Takeaway: incentives and processes can affect culture in negative ways. Culture, just like products and strategies, has to be based on experimentation, discovery, and iteration. Treating culture change as yet another big-bet project conceived by committees and deployed across the company is very hazardous.
Final Thoughts
I don’t want you to walk away from this article thinking that I feel the Google operating model is bad. First, it’s important to restate that these are my personal observations from years ago. Things today may be very different now
It’s also important to note the positive. As Marty and Elias observe in their article, Google has made a successful leap from the Web to mobile and to AI, anything but a trivial achievement for a 180,000 person company. Google is still creating tremendous value for consumers, companies, and advertisers, and compared to other big-techs, it has more successfully resisted the temptation to sacrifice user/customer/partner value for the sake of its own bottom line.
I wrote this article not to denigrate Google, but to highlight that even very good companies are susceptible to the degradation in operating model that comes with age and size. I believe the lessons I mention above are widely applicable to any company, potentially even yours. As always, if you agree please feel free to share with those that would benefit from reading.