Google vs. Amazon PMs: How does it compare?

I spent 13 years working at Amazon, having started my career there back in 2001 as a software engineer. For five of those years, I was a product manager. Most recently I worked in Amazon Web Services (AWS) as a Principal Technical Product Manager until 2018.

So when I joined Google nearly 3 years ago, I was actually a bit nervous about whether I’d fit in. Will there be culture shock? Can I be as successful at Google as I was at Amazon? Now that I’ve had some time to reflect, I’ll share some of my observations on Google vs. Amazon — for product managers and in general.

1. The Interviews

The Amazon interview loop is based on behavioural questions. Questions typically begin with “Tell me about a time when you…” I have literally conducted more than 500 of these interviews myself. Every question is designed to assess how well you have demonstrated each of Amazon’s leadership principles in your past work. And your work will be evaluated for its scope and complexity, which determines your leveling (e.g. L6 senior product manager vs. L7 principal product manager).

The first time I showed up for Google product manager onsite interviews, I was in for a rude surprise. At the time, I wasn’t actively looking for a job, so I figured I’d just wing it and see how I do, not knowing the big differences in the Google interview style. The Google product manager interview loop is all about assessing your abilities, e.g. strategy, product design, analytical skills, rather than what you’ve accomplished. I was baffled when I didn’t get any questions about my past launches and how I overcame many challenges to achieve my goals. Instead, I was asked to imagine if I were the CEO of Yahoo and what strategy I’d apply to turn the company around. Needless to say, I did not pass the loop.

My take is that both interview styles have their own merit in evaluating candidates. I found determining leveling was a little easier with the Amazon interviews, e.g. you can tease out whether someone owned a set of features vs. a portfolio of products by talking about their experiences. At the end of the day, the PM interview is an exercise in selling yourself and showcasing your skills and experience to convince your interviewers that you’re more than qualified for the job. And I think that in itself is a very important quality in a product manager, since you will be the spokesperson for your product and your team. Expect to spend a few hours preparing for the interviews, just like you would an important exam. For the Amazon interview, go through all the leadership principles and think back to your experiences then pick the most compelling examples that demonstrate them. For the Google interview, go on Glassdoor or YouTube to find sample questions then practice. Make sure you get comfortable with questions about estimation, 10x innovations and designing for specific user needs. While I think both interview loops are difficult and exhausting (5–6 hours), if I’m forced to choose, I’d say the Google interview is slightly harder. You’re more likely to have to think on your feet in case you get a question that wasn’t what you prepared for (see my example above).

2. Collaborating with User Experience Designers

You might have heard of the product design “3-legged stool” metaphor, made up of product, user experience (UX) design and engineering. This stool represents how important it is for these three disciplines to work together to build a successful product. The relationship between the PM and their UX designer peer is an important one, especially early in the product development process. There should be some healthy tension where the designer strives for the ideal solution that solves the user’s needs, while the PM optimizes for time to market and feasibility in partnership with engineering.

Google’s organizational structure mirrors this 3-legged stool. There are often separate product, UX and engineering teams each led by a vice president (VP). From what I’ve seen, this empowers each discipline to have an equal and independent voice when discussing product strategy or approving launches. For example, launches can be blocked if the UX quality bar is not met. However, one down side with this structure is that if two disciplines don’t agree, it could be harder to reach alignment. Sometimes the director or VP feels the need to represent their team by standing their ground. In that case, we have a tie breaker meeting, which is at the senior vice president (SVP) level. These SVP meetings are scheduled weeks in advance and require a similar amount of preparation. As a result, some decisions can take much longer.

Amazon, on the other hand, is often organized in the “general manager” (GM) model. For example in AWS, each product line is led by a L7 (principal) or L8 (director) level leader that manages a cross functional team. This team includes engineers, UX designers, product managers, and sometimes sales and marketing. In this case, the tie breaker is typically the GM. Decisions hardly need to be escalated beyond the GM so they’re often made quicker. On the flip side, I have seen first hand UX being overruled by a GM, who often doesn’t have a UX background, because of the reporting structure.

When I joined Google, I recognized the difference in the UX-product dynamic early on. I respected and embraced the importance of UX because of the massive number of users around the world that use Google products everyday. We have to not only put the user first, but we have to serve every type of user. At the same time, at Google product managers are still measured by what they get done. And I’ve had to negotiate the right balance with my UX partners to meet our product goals.

3. Access to User Research

If you’re a believer in user research, then you’ll agree with me when I say that building a product without user research is like writing software without testing. At Google, user research is an essential part of the product development process. We typically have a dedicated UX researcher paired with a UX designer. It’d be quite unusual to start building a new feature or product without at least some early validation from users. When you ask for approval for your product launches, you might be asked what feedback you’ve already gotten from your users through research. As a product manager, one of the most rewarding things for me is talking and listening to users. So I’m very grateful that Google does prioritize user research.

Since Amazon.com also has millions of customers, you’d think that user research is equally important to the product development process. However, in the years that I worked as a PM on the Amazon retail website (2008–2011), it was very difficult to get access to user research. The user research team was minimally staffed. My team, which owned an entire category of retail products, would get access to at most one user study per quarter. I remember wanting to do my own guerilla user research by going to shopping malls and interviewing shoppers, but it was rejected for confidentiality reasons. What Amazon lacked in user research we made up with experiments. Lots of them. At any given time, there are dozens of experiments running on a single page of the Amazon.com site, all trying to optimize for some sales metric. At AWS, there was also little user research. Instead, we relied heavily on alpha and beta testing by existing customers who were friendly to us. There would be a lot of hand holding to help beta customers use the early releases of new products. We were less worried about getting it right at launch. We iterated quickly based on user feedback. Regardless of the amount of user research, Amazon has clearly also built many successful products.

4. Slides vs Narratives

Amazon is known for its “working backwards” process where you start a project by writing a press release, describing the benefits of this new, yet to be built, product. This is just one example of Amazon’s heavy use of narratives for proposals and plans. At the start of a product review meeting, the presenter brings printed copies (yup, hard copies) of their document and distributes them to reviewers. Then the reviewers spend up to 20 minutes reading in silence, while making notes in the margins. Then the rest of the meeting is used for comments and discussions. As a PM at Amazon, you never use slide decks. Ever.

At Google, we typically use slide decks to present our proposals and plans. The presenter voices over ideas and points on the slides and the last few minutes in the meeting are used for discussion and decisions. Sometimes, the slides are made available before the meeting, so that more time could be dedicated to the discussion. I have also seen Google use the narrative format for annual planning and new investment proposals. But most PMs use slide decks for product and roadmap reviews.

Both methods lead to effective review meetings and decisions. However, I find the narrative method much more rigorous. If your ideas are not well formed, it’s very difficult to write a coherent narrative. There were times when I’ve found myself stuck writing and rewriting the first paragraph of a narrative, and that was an obvious sign that my ideas weren’t fully baked. Slide decks are a bit more forgiving, and they leave some room for you to improvise in the moment with your voice over. However, building a rational narrative with good flow using slides is also no easy task, and it’s a handy tool to have in the PM tool belt.

5. Career Path

When I switched over to become a Product Manager at Amazon in 2008 there was no formal transfer process across job families. The previous PM had left a vacancy on the team and my manager at the time supported my case. I was immensely grateful for the opportunity because I had had no formal training or even experience as a PM. I was given the chance because of my motivation and my track record. I knew of many other colleagues who similarly switched job families. Nowadays, Amazon recruits new product managers from its MBA intern program as well as campus recruiting efforts from business schools. Job family transfers are also possible, but it’s less common.

Google has been known for its Associate Product Manager (APM) program for developing its next generation of product managers. In addition, existing Googlers can apply for a job family (aka ladder) transfer to become a product manager if they pass the PM interview process. Googlers can also do a “PM rotation” where they try out the role for 6 months or so on a real team, then go for the interview process. I’ve been meeting a lot of Googlers who are in the ladder transfer process by helping them with interview practice. I really like seeing Googlers from various disciplines (e.g. engineering, sales) having the opportunity to achieve their goal of becoming a PM. This also brings a diversity of perspectives to the PM community so that you’re not only getting the people with the same type of education and experiences.

Once you’re officially on the PM ladder, the levels between Amazon and Google are similar. By the time you get to L7 PM, you’re likely managing a team of PMs. At Google, you can be L7.5 as a Group Product Manager and then L8 as Director of Product Management. This is where Amazon offers additional options as you progress further. As I mentioned above, there’s the GM role, or the Single Threaded Leader (STL) role as it’s known at Amazon. As a L7 PM, you can potentially take on a product area with a cross functional team reporting to you. That means you’d be managing UX designers, engineering managers and maybe sales or marketing. This is a good way to gain management experience of a team anywhere from 7 to a few dozen, whereas you’re unlikely to manage more than five PMs of a manager of PMs. The STL role is a really challenging and rewarding role because you’re truly in control of your destiny running a mini startup within Amazon. Mobility is better with the STL role, since there are often many of these STL roles open, whereas finding a manager of PMs role might be a bit more difficult. The L7 STL role also makes it easier to advance to a L8 director role as your product area grows.

6. Alpha Male Culture

When I was studying computer science in university, the ratio of female to male students was roughly 1:3. This hasn’t changed too much. According to Google’s recent annual diversity report, the proportion of females in tech jobs is roughly 20%. I don’t believe Amazon has made this metric public, but I’d estimate it between 15% — 20%. Therefore, I often found myself as the only female employee in a conference room filled with a dozen male colleagues. I had to learn early in my career to make myself heard. I appreciated that Amazon valued “have backbone; disagree and commit”, which gave all of us permission to speak up and voice our opinions.

At Amazon, I always felt an air of intimidation and posturing where engineers and product people alike would try to assert their dominance. For example, at AWS, the executive review is called “CHOP”. I asked someone, “what does CHOP stand for”? And they said, it doesn’t stand for anything. *Gulp*. Some of the Amazon review meetings were so notoriously harsh that attendees would spend hours pre-reviewing with their own peers, and try to anticipate every possible question they would get asked. The result was that the presenter was always well prepared, but there was certainly a lot of anxiety over being pounced on in case you made a misstep.

At Google even though the tech jobs are also dominated by males, I didn’t find the same level of “alpha male” culture I saw at Amazon. At YouTube, where I work, the executive product and engineering review meeting is called “Pulse”. Ahh, a much less hostile sounding name. Don’t get me wrong, these review meetings are also high stakes and high intensity with lots of tough questions. Presenters also spend a lot of time preparing and pre-reviewing. I just don’t get the same feelings of fear and intimidation when walking into the Google reviews. And if I were to stumble, I don’t feel like it would give others an opportunity to pile on.

7. Wellbeing

My 13 year tenure at Amazon actually took place over two different periods. The first was from 2001–2011 right after I finished university. I quit in 2011 after my second child because I felt completely overwhelmed and burnt out. I rejoined in 2016, by then my children were 9 and 6, and I felt like a stronger person. Nevertheless, I was again sucked into working late after the kids had gone to bed. However, I look back on my most recent time at Amazon with a lot of pride and satisfaction. I accomplished a lot with my team in a short time. At Amazon, it’s very easy to be addicted to the fast pace of delivery. You feel like if you work more you will get more done. You look around and you see how much everyone else was getting done as well, so you hesitate to slow down. But I knew that I was working at a pace that I wasn’t willing to sustain for the next 10 years.

When I joined Google in Switzerland everyone warned me about the late night meetings since we worked with our colleagues in the US (6pm in Switzerland is 9am in California). This meant that I would eat dinner with my family and then get back to work at least two to three nights a week. Since I had expected this, I didn’t think it was so bad and found a way to cope. What struck me was the amount of attention our leads, i.e. directors and executives, gave to this situation. In my 13 years at Amazon, I don’t think I ever got one email from any leader about wellbeing. At Google, our engineering director conducted wellness interviews with other colleagues, talking about their strategies for maintaining work-life balance. Even though these are simple gestures that have no immediate impact on your life, when you see many examples of these gestures, you begin to relax and give yourself permission to work in a more sustainable way. My personal feeling is that Google values their employees as people, as well as what the employees deliver. On days when I have to work late, I allow myself to go for a run in the morning or spend some time in the middle of the day with my children. I’ve met a variety of colleagues who have been with Google for five years or 10+ years. Whereas at Amazon, the people who have been there for 10 or more years are the hardened veterans. They’ve all worked really hard, mastered the culture, consistently delivered, and have been rewarded as such. Having said that, recently Amazon added new leadership principles for the first time in six years, including “Strive to be Earth’s Best Employer”. Knowing how deeply ingrained the Amazon leadership principles are in the Amazon culture, I think this new principle is a positive signal that Amazon is starting to prioritize employee well being.

Final Thoughts

Being a PM at either Amazon and Google is a very special and rewarding experience. You’re building products that are used by millions, if not billions of users. Really high caliber people work at both companies, which means you will be working and learning from the best. If you value getting things done and quickly, Amazon’s fast pace of delivery can be incredibly satisfying. I think this is especially valuable early in your career when you’re thirsty for experience and having launches under your belt. If your desire is to feel more supported overall then I think Google currently provides a better experience. You’re challenged professionally by the problems you work on everyday, plus there’s also support for your daily needs (e.g. food), health (e.g. on-site gym, fitness classes) and your family (e.g. care leave). At the end of the day, if you know what you want to get out of your PM experience, then you will be able to get the best out of either of these companies.