The Product Model at Google

By Marty Cagan and Elias Lieberich

Marty’s Note:

Recently I co-authored articles on The Product Model at Spotify, and The Product Model at Amazon. In this article, we hope to do the same by describing how the product model manifests at Google.

My co-author in this case is the European-based product leadership coach Elias Lieberich. Elias had a long and very successful career at Google working on Search/Ads, YouTube and the Moonshot Factory, and now he helps other companies in their efforts to move to the product model through his work at Product Matters.

Background

Google is one of the most valuable companies in the world, with no fewer than nine products that each have more than one billion monthly active users. These products go well beyond search and advertising, and include YouTube, Maps, Photos, Gmail, Android, and Chrome.

It’s worth noting that none of these products represent new categories. There were already internet searching services, mapping services, photo services, email services, and browsers, for example, but in each case, Google succeeded by solving these problems better than the competition.

Google is a story of how picking the hardest problems and solving them, even if it takes years, pays off in products that are not just “better,” but often dominant.

Google was one of the earliest product model companies, and in this article we hope to show the essential elements of this model, and how they manifest at Google, and how this model has been key to its ability to scale to over 180,000 employees.

Just as people are often confused by Spotify’s use of unusual terminology, many are confused by aspects of Google’s culture. Our hope is to cut through the noise and highlight what we consider the true keys to its ongoing success.

One challenge in talking about Google is that it is not really a single company. There are several divisions, and each has its own culture and norms, sometimes due to the nature of the products they are creating (platform services, consumer services, business services), and sometimes the culture is a reflection of the early leaders.

Moreover, there can be a considerable range of leadership styles and role definitions even within a single division. As just one example, many of the very best product managers I have ever known worked at Google, yet occasionally I meet Google product managers that have no idea how to do their job, or even what they’re responsible for.

But even with so much variance, the company generally does a good job staying true to the product principles, especially the most important ones.

The Product Operating Model

When we consider the product model, we look at how the company decides which problems to solve (product strategy), how product teams solve those problems (product discovery), and how teams build, test and deliver solutions to their customers (product delivery).

Product Strategy

In the Product Model, it is the job of the product leaders to determine the most important problems to solve.

Famous examples of this at Google:

“Internet Search Is Terrible”

While competitors were trying to guess relevance from the content, Larry Page had the technical insight that if they could download the structure of the web, the links themselves could be used as a ranking signal, and PageRank was born.

“Search Ads Suck”

Once Google had established industry leading search, they needed to look at monetizing this service, and the approach the rest of the industry was using was layering on banner advertising. But the ads were rarely relevant, and the experience was not good. The solution to this problem became one of the most financially successful products of all time, AdWords (now called Google Ads).

“Driving is Too Dangerous”

Modern technology has resulted in more distracted drivers than ever before, and the resulting increase in accidents. One potential solution to this problem is automation. The Waymo product currently represents more than a decade of product discovery and delivery, with a gradually expanding rollout, along with continuous learning and improvement.

The pattern is the same for maps, email, browsing, language translation, document collaboration, and dozens of other product areas.

The leaders identify an important problem that needs to be solved, or solved better than it is solved today, and product teams work to discover and deliver winning solutions.

More generally, the leaders are very much in touch with the product teams and the enabling technology they are developing, so it’s not unusual for a technological breakthrough in one area to identify new business opportunities and additional problems to solve.

One difference between Google and most other companies is that rather than leaders assigning specific problems to specific teams, Google leaders sometimes broadcast the problems, and encourage product teams to choose to tackle those problems. This is not something that’s exclusive to Google, but it is a luxury that most companies don’t have. ¹

Another difference is that it is very common at Google to have multiple product teams tackling the same hard problem. While this can introduce redundancy, it also increases the likelihood that an exceptional solution will emerge.

Product Discovery

Google is well known for empowered product teams. It is their fundamental building block of strong products. The team, especially the engineers, are empowered to figure out the best solution to the problem they are trying to solve.

It’s important to understand that while Google is famous for empowered product teams, not all of the product teams are truly empowered teams. Just as with every large company, some are feature teams. This is usually because the particular team has not yet earned the trust of the leaders, or sometimes there is a leader that feels the need to take control.

We often hear about “launch and iterate,” but the reality at Google is more like continuous product discovery. Product teams are running experiments constantly.

Some of these experiments are to answer relatively minor questions (such as the particular shade of blue used in the visual design), and other experiments are very substantial (such as predicting what the user is trying to search for).

But the company has been embracing building and testing prototypes from its very earliest days.

A large part of product discovery at Google is cultural. Hierarchy and politics generally play a secondary role to evidence, which is why experimentation and data are so core to how product teams solve problems.

Because the culture is largely merit-based, teams that rely on evidence tend to outperform those that rely on politics. It is an intellectual environment where options are weighed against the evidence, not job titles.

In addition to constant experimentation, Google is well known for other discovery techniques including dogfooding and beta testing. Before any user sees a Google product, Googlers will have used it heavily, worked through many issues, and provided feedback. The service is often then released in a limited context to early users and customers.

Product Delivery

In order to support products and services that have billions of users (referred to at Google as “planet scale” which of course goes far beyond “enterprise scale”), Google has invested many of its top product teams into building a platform and infrastructure that can scale to meet these extraordinary demands.

The result is that Google’s delivery infrastructure is unparalleled, but beyond the technology, their approach is also a cultural choice. Teams figure out their architecture, and they are on the hook when things break.

There is much more that could be said about enabling product delivery at Google, but as they are already widely recognized as best-in-class, and have been widely copied, we won’t repeat those points here.

Product Outcomes

No discussion of the product model at Google is complete without at least mentioning OKR’s.

Google did not invent OKR’s (Intel did), but they have long been the poster-child for the technique. However, what most people don’t understand is that OKR’s were designed for product model companies with empowered product teams given problems to solve and outcomes to achieve. So for Google, it is a straightforward technique that maps directly to the product teams and the model they use to create products. And Google’s leaders have long argued that the technique is essential to how they work and their focus on outcomes.

However, for companies that are still primarily feature teams chasing roadmaps of features and dates, it’s important to realize that OKR’s are an incongruous technique that rarely provides value.

The Product Model Competencies

The people have always been core to the product model at Google, and they have led the industry for several of these essential competencies:

Individual Contributors

– Engineering Tech Leads

In general, individual contributor engineers at Google are quite strong, and their Tech Leads are their greatest asset.

Tech Leads at Google are “first among equals” with the other engineers. They actively write code, but they also lead a small team of engineers, without being their manager. Moreover, the Tech Lead takes ownership for product delivery.

If you wonder why Google product managers often don’t need to write tickets (many Google product managers haven’t touched a ticket in years), the answer is often because they have a tech lead who is strongly involved in all the product aspects, including discovery.

A strong Tech Lead is the ideal complement to a strong product manager. The tech lead understands the product and business context, and helps translate that to the team, and then works with the engineers to figure out the best way to solve the problem and deliver the solution.

This is much more effective than a PM trying to tell the engineers what needs to be done.

– Product Managers

Google has long had a high bar for product managers. They are expected to have strong business acumen, a solid foundation in technology, and the ability to think through hard problems and drive to successful outcomes.

As one example, when Google acquires smaller tech companies, the CEO usually becomes the product manager of that product team.

As another example, Google looks for a strong entrepreneur mindset in product managers, and one consequence of this is that they fully expect that many of their best product managers will at some point leave to be a founder at their own startups (and further, that’s a strong signal that they selected the right people for this role).

– Product Designers

Initially Google had an extremely minimalist approach to product design, especially with respect to visual design.

Many people even today associate Google’s design approach with their visual design, but interaction design, and more generally an emphasis on usability, also played a substantial role starting very early.

Today, product design is one of Google’s essential product team competencies, with over 5000 product designers.

– Data Analysts and Data Scientists

Google has long realized that one of their major advantages is the data they collect from the billions of users interacting every day with their products and services.

This data often contains a gold mine of insights that can help product teams experiment, make decisions, and continue to improve their products. But in addition to data as a tool to help create products, the data can also power a new generation of data products, including AI products.

As such, data analysts and data scientists are essential to product strategy, product discovery, and to the product teams.

Product and Technology Leaders

A common misconception is that “empowered teams” means flat structures with no management. But the reality is very much the opposite.

Google generally doesn’t rely on non-technical people managers or project managers to coordinate work.

Instead, they depend on a very intentional approach to leadership where experts lead experts.

In too many traditional organizations, engineering managers are “people admins” who have little idea about the technology they oversee; some even have never written a line of code in their life.

– Tech Lead Managers

At Google, the primary unit of engineering management is the Tech Lead Manager (TLM).

These people are usually promoted from among the strongest engineers, and are usually also a hands-on tech lead, but they have been persuaded to take on some people management responsibilities, at least for a small number of engineers.

Because these managers are technically competent, they don’t need a separate layer of “coordinators” to explain the work for them. They can review code, debate architecture, understand technical debt, and coordinate dependencies directly with other TLM’s. Most importantly, they can effectively coach and develop the engineers that report to them.

When a decision needs to be made, it is made by someone who understands the technology.

TLM’s typically have significant street cred, and strong track records, and they stay in their areas for a long time. This is what is meant by the phrase “empowered teams don’t require less management; they require better management.”

– Group Product Managers

Analogous to a Tech Lead Manager for engineers, is the Group Product Manager (GPM).

GPM’s are typically highly leveraged individual contributor product managers, or lead a small team of product managers from the same product area.

They often are defining the product strategy together with their TLMs, as well as coaching the product managers that report to them.

GPM’s are often very knowledgeable about the business and technical aspects of the product, and provide the holistic view of the product.

TLM’s and GPM’s, together with their best reports, form the nucleus of value creation at Google.

These people are often true missionaries that came to their position through product success in an area over many years. They can navigate complex situations, and coordinate both strategy and execution.

This principle of a basis of strong technical and product expertise continues up to middle and even senior management and leadership.

Google and the Product Model in the AI Era

The true test of product model companies is their ability to deliver real business results over time, taking advantage of new opportunities, and responding to new threats.

Thus far, Google has successfully navigated one major disruption: the move from Desktop to Mobile. After declaring they have moved to “Mobile First,” they ended up emerging stronger than ever.

In 2016, Google made the intentional choice to move from “Mobile First” to “AI First.” Many people don’t realize how long Google has been working on AI products and the technologies that enable them. For example, it was Google that invented the transformer technology underlying today’s large language models.²

You can argue that the “killer app” for generative AI was ChatGPT from OpenAI which introduced a conversational interface. But that product was enabled by several layers invented or provided by Google, and since then Google has continued to innovate with AI-specific hardware, infrastructure, large language models, and many AI applications ranging from autonomous driving to language translation to image processing.

Many people wanted to write off Google in the race for AI prominence, but the recent versions of Gemini (as of this writing) have benchmarks comparable to those from OpenAI, Anthropic and others. Gemini already has over 650 million monthly active users, well on its way to a billion.

While it’s still early, Google is well-positioned to not just survive the move to the AI era, but to emerge as a leader.

The product model has continued to deliver real business results for Google for more than 25 years.

Learning More

Much has been written about Google, but to learn more, we’d recommend this article, this book, and this podcast.

These are some of the rewards of a product as financially successful as AdWords. ↩︎
See the 2017 paper Attention is All You Need. ↩︎

The Product Model at Google

Comments