<- BACK
JANUARY 11, 2024

Key Differences Between Meta & Google Product Management Culture

Google and Meta are two of the most successful product companies of our time. Both play an important role in shaping the practice of Product Management since many companies in Silicon Valley aspire to emulate their success.

Both giants are ads-supported which requires operating at a huge scale and thinking big. They both hire brilliant people, pay really well & are used by billions of people daily. However, there are important differences in their product culture.

I spent over a decade combined at both, in a variety of product areas, so I have an insider perspective on their product management approaches. Let's dive in:

#1 Employee Evaluation

"Show me the incentive, and I will show you the outcome." — Munger

Both companies do 360 reviews and calibration committees to ensure fairness and consistency across managers. However, there are significant differences, which has tremendous downstream impact.

Meta: There's a tight coupling between the review cycles and the 6-months planning cycles. Managers have a more significant influence on their reports' scores in calibration, so can more easily drive their agendas. Meta utilizes sticks (this was always been the case) in addition to carrots, which creates more urgency in execution, but also more incremental goals when planning. Engineers are incentivized by product success metrics, which sometimes means speed is prioritized over craft.

Google (pre-layoffs, but from my understanding it's largely true since layoffs were based on teams/areas) had a supposedly carrots-only system, enabling psychological safety and more self-reflection, since employees were more vocal/critical about management. There's a weaker link between team planning cycles and goals and review cycle timelines, which allows people to take more ambitious initiatives without fear of stick. Overall, there was more coasting as promotions got exponentially harder at higher levels and people felt "safe".

#2 Planning & Goals

Meta planning is every 6 months, closely tied to the employee performance cycle. Most goals are numeric, 50/50 confidence levels are encouraged (on paper) for risk-taking. In practice, teams lean towards "sure bets" by focusing on many smaller incremental projects. In product reviews the focus is on specific metrics, their trend and target.

Google follows annual and quarterly bottom-up & top-down OKRs process. Since there's less fear about not hitting goals, the questions in product reviews are focused on "10x industry impact" and "Google's strengths" rather than very specific metrics goals. This encourages ambitious "moonshots"; which are sometimes too far to reach.

#3 Execution

Meta: A big emphasis on "Perfect Execution". If you want to drive a bigger impact from incremental changes, you'll have to make many incremental changes! Since there's a strong metrics focus there are great experimentation tools like Gatekeeper & Deltoid which are optimized for fast decision making. Fast iteration is key.

Google has longer-term qualitative goals, it emphasizes craft and more foundational changes as opposed to incremental. There's also more bureaucracy in launching — you need a few external-to-the-team approvers that ensure craft (and protect the company from lawsuits).

For example, during my first month at Meta, I was surprised that one of the teams I was leading (video search) had 10 experiments to review with 20 engineers, and the review + launch decisions were at the team level. At Google, many search experiments were reviewed personally by the VP of search, and we had about 10 experiments per week for the entire search team (1,000+ people). One of my teams spent about a year scoring the touristiness level of every place in the world, without launching anything. The end result was great and worked at scale, but such a project wouldn't be possible at Meta.

#4 PM Community

During my time at least, Meta wins here with a robust PM community: PMEmmy awards, mentorship circles, PM conferences, and more. Google PM events were more limited during my tenure.

#5 Hiring Bar and its Unintended Impact on Diversity

Google is a lot more risk-averse, prioritizing prestige schools and CS/EE backgrounds. Google often declines candidates who are "good" but not "great", and "false negatives" are abundant. In my cohort of 8 PM interns, we were 7 males, and 7 were from Berkeley/Stanford/Harvard. Only 3 got return offers.

Meta takes more risks on candidates because it uses sticks with "false positives" — it will fire low performers (that's true even pre-layoffs). The flip side: working at Meta exposes you to a broader spectrum of PMs with more diverse skill sets and varied perspectives. In contrast, Google's higher bar and risk-averse approach yield teams with fewer weaker PMs.

Interestingly, as a calibrated interviewer at both companies, I used pretty much the same questions for the product sense interview. At Google, candidates meeting my bar didn't always pass the company's bar. Conversely, at Meta, candidates falling short of my bar were occasionally accepted.

#6 Cross-Functional Teams

Google's typical team is composed of Eng/PM/Design. PMs need to be more hands-on — they need to do more user research, data analysis, UX writing, etc. Eng has more weight in decision making, and going back to incentives this sometimes leads to tech-first solutions, as opposed to people-first.

Meta product teams also include content design, user research, data science and sometimes product marketing and program management. PMs lead a cross-functional team of experts. As an example, on one of my Meta teams I had 3 content designers, 2 UXR, 2 designers, 2 data scientists and 10 engineers — the same number of "XFN" team members as "Eng".

---

Differences are reinforced by the incentive system and partly stem from founding stories — Zuck's 2 weeks of dorm room coding vs. Larry & Sergey's PhD research. I learned a lot from being in both environments, so choose based on the culture you want and the skills you are after.

Caveat: There are many other things that are different (workplace vs. groups/email communication could be an entire topic of its own), and many things that are different across teams; also the companies are ever-changing, so take everything with a grain of salt!

Originally published on Typeshare. New writing coming soon.