My Experience As An Amazon Product Manager: A Deep Dive

Disclosure: This post might contain affiliate links. If you click through and make a purchase, I’ll earn a commission, at no additional cost to you. Read my full disclosure here.

In the ever-evolving realm of e-commerce, landing a position as an Amazon Product Manager was a significant milestone in my career. Having previously worked as a Microsoft Software Engineer, transitioning to Amazon opened a new chapter filled with anticipation and a zest for what lay ahead. Through this post, I aim to shed light on my journey, the culture at Amazon, and the learnings that shaped my professional outlook.

If you are interested in following my career path, then you can also look at my other posts:

• My Experience As A Microsoft Software Engineer: A Deep Dive
• My Experience As A Microsoft Product Manager: A Deep Dive
• My Experience As A Google Technical Program Manager: Full Story
• Google vs Amazon vs Microsoft PM Roles: A Deep Dive
• Inside the Culture of the Top Tech Companies
• Salaries for Software Engineers are On FIRE!

The Amazon Product Manager Interview

The pursuit of a role as an Amazon Product Manager began during my MBA at Kellogg School of Management. Amazon is one of the biggest employers of MBA graduates. Due to tax implications, Amazon does not send recruiters or any other Amazon employees on campus. Instead, they do everything virtually. I attended their virtual presentation and was intrigued to find out that if I managed to get the offer, then I would be able to select any of Amazon’s product teams to join.

The first round of interviews consisted of two phone interviews. I was sitting in one of the interview rooms at Kellogg, waiting for the phone to ring. Most other companies do in-person interviews in those rooms, so it felt a little strange, but nothing extraordinary. Looking back at those interviews, I remember that my performance was really far apart. One of them went mediocre and the other one went great. During the first interview, I felt struggling. In the second interview, everything clicked perfectly. In the end, I had mixed feelings, not knowing what to expect. I felt amazing when I got the call that I’d be flying to Seattle for the second round.

In the second round, I had 4 interviews with Amazon Product Managers. They asked some common types of Product Manager interview questions, such as product design, strategy, etc. However, almost all questions were regarding different Amazon products. The most difficult interview was with the Bar Raiser. He is typically the most senior interviewer and his role is to push back on your answers. His goal is to determine whether you are better than at least 50% of the Amazonians with the same role as the one that you’re interviewing for.

Some tips that helped me during the interview:

• Study the Amazon Leadership Principles
• Read the letters to the shareholders, especially the first one
• Listen to the earnings conference calls and pay special attention to the section with the analyst questions
• Amazon focuses on the customer a lot. It doesn’t matter if an option might lose money in the short term. The important part is that it helps the customer in the long-term
• Amazon is all about volume, not about margins. So, it’s always better to sell more items than to increase prices

You can find more information about product manager interviews in my blog post How to Prepare for Product Manager (PM) Interviews

It was a great day for me when I got the call about the offer for the Amazon Product Manager position! Since Amazon was one of my target companies, it meant that I would be able to stop recruiting and focus on my MBA program. There were so many times when I had to sacrifice some MBA event in order to recruit! Now, all of this would belong to the past. If you are interested in understanding the value of the MBA, take a look at my blog post Is an MBA Worth It?

The only remaining decision was the team that I would join. Fortunately, Amazon invited me to Seattle once more, in order to talk to different teams and network with other Amazonians. I had lots of interesting options, such as Amazon Web Services and Kindle, but in the end, I decided to join Amazon Marketplace, in order to learn more about e-commerce.

If you are interested in learning more about Product Manager interviews, take a look at my post How to Prepare for Product Manager (PM) Interviews.

The Amazon Campus in Puget Sound

Amazon currently has 45 buildings in the Puget Sound area, out of which 44 are in Seattle and 1 in Bellevue. They employ more than 75,000 employees in Puget Sound. The company is expanding very fast in this area and is taking over Seattle downtown. There is no specific “Amazon campus” area in Seattle, as these buildings are scattered within Seattle’s downtown.

Each building is unique and they are all very different than each other. Also, each building has a different name. The central Amazon buildings, which is also where the New Hire Orientation takes place are called Day 1 North and Day 1 South, as a tribute to Amazon’s motto that Amazon is still in its infancy and there is a lot of room to grow. In my opinion, the most unique building is the Spheres, which is a combination of indoor gardens and meeting spaces. They are also open to the public on Saturdays! I worked in the Varzea building, in the Puget Sound area.

The inside of the buildings are mostly open workspaces and meeting rooms. Art installations by local artists are hanging on the walls. One of Amazon’s Leadership Principles is “Frugality” and this is easily visible inside the offices. Coming from Microsoft, where we used to have our own offices and desks, it felt cramped to be sharing the same desk with another person, while sitting on a floor that was full of desks and barely had any internal walls. Also, Amazon has no cafeterias inside the campus and the only edible items are food from the vending machines.

Team Structure

Amazon Marketplace is split into different smaller teams. Each team consists of:

• Product Manager (PM): Responsible for the product roadmap
• Technical Program Manager (TPM): Responsible for the project plan
• Engineering Manager (EM): Manages the Engineering team
• Engineering team: Write the code

However, that doesn’t mean that all positions within the team will be staffed at all times. While I was working at Amazon, out of the 3 first positions (PM, TPM, EM), we only had 1-2 positions filled in for my team. Other teams had similar coverage as well. This is both due to Amazon’s high attribution, as well as the slow hiring, which leads to managers shuffling people between projects, in order to cover the tasks.

Apart from the core product team, there are also other teams that work with an Amazon Product Manager on the launches:

• Finance: Amazon is very data-driven, so every feature is prioritized based on the potential revenue. The Finance team builds data models that help predict upcoming revenue and track the existing revenue
• Legal: Amazon is keen on avoiding any legal issues in any of the countries that they’ve launched at, so the Legal team is handling this aspect in every launch
• Quality Assurance, Does a sanity check of each feature before the launch
• Localization: Every new feature needs to be localized to all languages that are supported by Amazon Marketplace

The size of each team at Amazon varies a lot, but they typically follow the 2-pizza rule, which says that in any meeting you don’t want to have more people than those that can be fed by 2 pizzas. The idea behind this rule is that you don’t want to have meetings that are so large, that people don’t have time to express their ideas.

What Does An Amazon Product Manager Do?

The role of the Amazon Product Manager is to define how the product works, i.e.

1. Make the business case for the creation of a product (aka “Why should the company invest in the product?”). This includes:
   • Determining the target customers and prioritizing their use cases
   • Estimating the potential revenues and finding the optimal revenue streams
   • Analyzing the competitive space and finding competitive gaps
2. Define how the customers will use the product (aka “What does the product look like?”
   • What features will be implemented?
     • Own the backlog and prioritize each feature
   • How does the User Interface (UI) and User Experience (UX) look like?
   • Define the user metrics, e.g. latency, throughput, etc
3. Voice of the customer:
   • Understand how the customer will use the product
   • Prioritize the use cases that each release will cover
   • Simplify the user experience
   • Make tradeoffs regarding the implementation cost and time-to-market
4. Mini-CEOs of their product
   • Responsible to optimize the metrics (awareness, usage, revenues, etc)
   • Final decision-makers for all product-related decisions
   • Collaborate with lots of teams, including engineering, marketing, legal, support, documentation, etc
   • Need to make sure that the product is staffed adequately
5. Lead without authority
   • The level of their contribution depends on their leadership skills
   • None of the other people, who work in the product, report to the Product Manager
   • Product Managers don’t make any of the hiring decisions or staffing decisions

A Day In the Life of An Amazon Product Manager

Amazon is known for an environment that is data-driven, fast-paced, and high-pressure. These attributes are clearly visible throughout every day of an Amazon Product Manager. In this section, I will try to describe the day-to-day work environment as it changes throughout the year.

At the beginning of each annual cycle, each Amazon Product manager had to set goals. These goals were always very aggressive and in most cases, they seem unrealistic. If a goal seems realistic and achievable, then in most cases it is rewritten in a way that makes it a stretch goal. Amazon does not believe in the “A” of SMART (Specific, Measurable, Achievable, Relevant, and Time-Bound). The goal is for every product team to stretch themselves as much as possible, in order to achieve unattainable goals. In order to track the progress toward these goals, each Amazon Product Manager would create a spreadsheet that tracks several metrics on a weekly, monthly, and quarterly basis, in order to show how close they are to achieving this goal. For example, they could have metrics on awareness, usage, monetization, etc.

Every Monday and Tuesday, we had Weekly Business Reviews (WBR), where we went through the weekly metrics. I have provided a more detailed explanation of these reviews in the “Memorable Moments” section, so I don’t want to copy the information here. The most important part is that during the whole year, every Monday and Tuesday was fully booked, in order to understand everything that happened in your area of ownership during the last week and present it to the Leadership Team. On Monday we presented to US Directors, whereas on Tuesday we presented to International VPs. If there was any additional work that needed to happen during these 2 days, then it meant that we would have to stay late or finish it from home. In general, work ended around 7 pm-9 pm each day.

Of course, the same deep dive on the metrics happened also on a monthly basis (Monthly Business Reviews – MBRs) and a quarterly basis (Quarterly Business Reviews – QBRs). More specifically, on the first Monday of each month, we would look at monthly data, whereas on the first Monday of the quarter, we would look at quarterly data. It was very important for each Amazon Product Manager to know every single data point on their dashboard.

However, the business reviews with the whole team were nowhere near as detailed as the deep dives in each project. On a monthly basis, the team met with the Leadership team and we presented progress towards all of our goals. We had to go through each goal, much of whom were in “red”, as they were initially selected to be unachievable goals and we would explain the remaining path to reach the goal. There was lots of drilling to make sure that each project was still on track and the team was working really hard non-stop, in order to achieve the goal.

The remaining three days of the week, during which we didn’t have Business Reviews, are where we had more time to engage with the team, write any documentation, plan ahead, etc. All meetings, such as the weekly team meeting, the 1:1 with the manager, 1:1 with the Technical Program Manager or the Engineering Manager, meetings with stakeholders, etc would also take place during these days. This means that most of my workday schedule (i.e. 9 am-5 pm) was booked with meetings and that there was very limited time to do work that required me to focus. So, I had to leave work around 7 p.m., eat dinner at home, and then continue working until late. The habit of working 12+ hours/day was typical for most of the Amazon Product Managers.

On top of our regular rhythm-of-business tasks, there was always some high-level planning effort going on. Throughout the year we did 1-year planning, 3-year planning, presentations at conferences, performance reviews, and many other time-consuming, critical tasks that we had to spend our time on. The workload was always high and there was very limited downtime. Comparing this with Microsoft, which has both ups and downs in the work/life balance throughout the year, means that Microsoft allows more breathing room, whereas Amazon feels under constant pressure all the time and without breaks.

Memorable Moments

Never-Ending Business Metric Reviews

The best way to understand the data-driven focus of this company is to start with the weekly business reviews. Every Monday and Tuesday throughout the whole year we did business reviews. This means that the Leadership Team went through all the metrics from every part of the business.

Each Amazon Product Manager was responsible for building a set of spreadsheets that showed the data for every part of their business on a weekly basis. For example, the Product Manager responsible for a particular page in the website would have a dashboard with weekly metrics on views, clicks, sales, etc, as they apply to their business. The Leadership team would ask the Product Manager to summarize what happened during the last week and to provide an explanation of anything different, e.g. a big decline in views or a huge uptick in sales. It was really important for every Amazon Product Manager to know in advance what all their numbers represent and why each major change happened.

The difference between the Monday and Tuesday Weekly Business Reviews (WBR) is that the former was US-only, whereas the latter was international, so it included Product Managers across the world. Also, the first one was organized by Directors, whereas the second one included VPs. It is clear that every Amazon Product Manager needed to be fully prepared for each of these meetings. Not knowing how to explain a particular number in a huge set of metrics was not an option. You can imagine the level of preparation going into these meetings. In essence, all of Monday and Tuesday were tied up in preparation for these meetings. Most of the actual work happened during the other three days of the week.

On the first Monday of every month, as well as the first Monday of every quarter, we did Monthly Business Reviews (MBR) and Quarterly Business Reviews (QBR) respectively. The goal was to make sure that we didn’t get sidetracked by the weekly numbers, but we also looked into longer trends. During these meetings, the Leadership Team was focusing on determining whether each product team was moving closer to achieving its goals.

I have to admit that I’ve never seen this in any other company that I’ve worked at. On one side, it shows how data-driven Amazon is: every metric is drilled on a weekly basis. On the other side, it also shows the constant pressure that Amazon puts on its employees. It’s a matter of each person’s priorities to determine whether this is an environment that works for them or not.

Dreadful Escalations

Amazon is known to be customer-focused. It is in fact one of the most (or maybe the#1) customer-focused companies on the planet. They are so customer-focused that very often the Amazon CEO, Jeff Bezos, would dive deep into customer complaints and make sure that the corresponding project team in the company addresses them. This process is known as an “escalation”. Since I left Amazon, the CEO has changed from Jeff Bezos to Andy Jassy. I don’t know for sure if the escalations are still happening at Amazon (even though I assume so), so I will describe the experience under Jeff Bezos.

The way an escalation starts is when a customer sends a complaint to Jeff Bezos’ personal email, ie. [email protected]. The complaints could be as simple as “I found this product cheaper at Walmart and I thought that Amazon is the cheapest place on earth” or “I bought this product and it was broken” or “I talked to customer service and they did not treat me properly”, etc.

Jeff or somebody from his team would triage all these emails and either respond directly to the customer or ask the product team for more information. In the second case, this means that Jeff would forward the email to the corresponding VP after adding the character “?” in the main body. This means “Ignore everything else that you are doing and give me a response ASAP”. The VP would forward it to the Director, who would forward it to the Senior Manager and the product team, including the corresponding Amazon Product Manager.

At that team, everything else would stop for that product team, until they responded to Jeff. Everybody would meet in a room, evaluate the situation, gather all the appropriate data, and form a reply to Jeff. An escalation would typically take 1-3 days, although in most cases it was around 1 day. During that day, the whole team would just work on this stressful response. After crafting a response, the draft would be sent to the Directors for approval. The Directors would typically request modifications. So, there was a back-and-forth until the response would be finalized. Then the response would go from Director to VP and to Jeff. The whole team would be on standby to make sure that there are no follow-up questions from Jeff.

I want to stress here that these escalations happened on top of a very busy schedule. It didn’t matter, if there were any other priorities that needed to be taken care of: If there was an escalation, then all other work stopped until Jeff was happy with the response.

User Feedback Sessions

One of the most humbling experiences was attending user feedback sessions. Listening to real customers share their experiences, both positive and negative, was a stark reminder of the impact our products have. It was also during these sessions that I had some of my biggest “Aha!” moments, leading to features that I would have not thought of otherwise.

These sessions are driven by the User Experience (UX) team in collaboration with the corresponding Amazon Product Manager. The UX team finds volunteers, who are interested in participating in a user study and providing their own feedback about the user interface (UI). Experience varies among those individuals: from new users to experienced ones. The UX team guides the participant through a set of tasks and collects their feedback. As a Product Manager, my goal was to get a first-hand experience of how customers use my product.

I remember one specific example, where we wanted to test the efficiency of a new feature that we had just released, so the set of tasks that we had created were related to this new functionality. In one of the first questions, the UX member asked the participant to perform a task that was trivial using this new feature, but really time demanding otherwise. At that point, the candidate went into a rant saying that based on their lengthy experience in the area it is really difficult to perform this task. And they were going on and on about the different problems, etc.

The UX member asked the candidate what they would do to solve the problem. The candidate responded that they would add a new option in a specific area of the page. At that point, they realized that indeed that option already existed. So, they clicked on it and they were totally surprised (and maybe slightly embarrassed) to find out that it did exactly what they wanted. At that point, they started asking us if this was new functionality because they had not seen it before and that it did exactly what they wanted, etc.

That day was a great one! Knowing that we had done exactly what the customers needed!

Morale Event At An Amazon Warehouse

During my tenure as an Amazon Product Manager, we didn’t have almost any morale events. After all, “Frugality” is one of Amazon’s Leadership Principles. Imagine my surprise one day, when my manager announced during the team meeting that we would have a morale event to help the team bond. I immediately had my hopes up, wondering what it would be. However, my manager brought my expectations quickly down to earth, when he mentioned that we would be gift-wrapping items from a warehouse during the whole day!

The beginning of the experience was very interesting. I had never been inside a warehouse before, so I was very curious to see one. We started our day, together with the morning shift, so we went through all the appropriate safety checks to make sure that we were not bringing anything inside that could cause damage. After entering the warehouse, we went as a team to the station, where we would gift-wrapping items.

The simplified process was as follows:

• A new order comes in
• A person locates the item(s) inside the warehouse and puts them in a conveyor belt
• The items that needed to be gift-wrapped were brought to us
• We gift-wrapped the items and put them in another conveyor belt
• The items went to the trucks, which would deliver them to the customers

The first couple of hours were quite fun. We started slowly but picked up the rhythm as we learned to gift wrap more efficiently. Items were delivered and wrapped quickly, as we joked among ourselves. However, as we were standing for the whole time, at some point this started taking a toll on us. At lunch time we were all ready for a break! So, we walked to the lunch area and got some items from the vending machine.

The lunch break was very quick, though. Before we knew it, we were asked to go back with the rest of the warehouse workers and continue gift wrapping. At that point, I started empathizing with the warehouse workers and understanding the issues of working in such a difficult environment. There are no chairs in the warehouse, apart from the lunch area, so everyone is either walking or standing. Lunch breaks are very short. And there is no easy way to go on long breaks.

Many months after this event took place, I saw the website The Former And Current Employees (FACE) of Amazon, where Amazon workers describe how difficult it was for them to work at Amazon. A large percentage of these complaints is made by warehouse workers. As I was reading through some of these stories, I believe that to a regular reader, some of them would seem like exaggerations. However, after having been inside a warehouse, I totally felt the pain of these employees.

We remained in the warehouse for the whole day, working a full shift. At the end of the day, everyone was exhausted. It was great to return home knowing that I wouldn’t need to do this the next day. On one side, I’m glad that I had this experience inside the warehouse, as I managed to see something that very few people can. On the other side, though, I’m not sure why my manager thought that it would be a good idea to spend the whole shift there. We all learned our lesson!

Listening To A Customer Call

Amazon is not known for providing training options to employees. This is a stark contrast to Microsoft, which has a wide range of classes, open for everyone for free. However, Amazon does provide a few opportunities for experiential learning, such as the warehouse visit I described above. Another option was to go to the customer support center and listen to customer calls.

I was very excited about this opportunity because it would allow me to see what is actually happening on the other side of the phone line. Amazon is known to focus on the customer, so I was expecting to learn from the best. Indeed, the experience did not disappoint.

I was very fortunate to sit next to a very experienced operator. The way that it works is that I was wearing a headphone that allowed me to listen to the conversation. However, even though I could see the operation, I could not directly talk to the customer.

I remember one particular phone call, which started with a really frustrated customer. He was yelling on the phone, talking about a problem that nobody wanted to solve, that he was being transferred from one customer service operator to the next one, that he had made so many calls, etc. He was going on and on about the problem and his pain.

The operating I was shadowing, was listening patiently and let the customer keep talking. He was also taking notes to make sure that he could address some points later. After the customer cooled down a little, the operator summarized the whole issue. The customer agreed that the summary was correct. The operator assured the customer that they would work out a solution together. The problem was quite complicated indeed. It consisted of a few different issues.

The operator made a list and started addressing them. The customer was cooling down as he saw that there was progress being made. At no point did the operator think about stopping the call or dropping the client. In the end, it took around an hour for the operator to solve the whole problem. And the customer was ecstatic at the end. He thanked the operator multiple times, claiming that they were amazing, that they would leave a great review for them, etc. I was also inspired by the operator. He took a really hostile caller and turned him into a very grateful one. After the call ended, I also congratulated the operator. He told me that it was just his job and that these things happen all the time.

Working During A Sunday On Short Notice

One particular Sunday, around noon, I was at the shopping mall with my wife. I had just dropped her next to the store and was searching for a parking spot. After finding one and walking towards the store, I checked my emails. Suddenly, my jaw dropped. My Director (i.e. my manager’s manager) had sent me an email asking me to perform a very thorough analysis. He had sent me this email around 11 am and the time was around noon. During this 1 hour, my manager emailed me twice asking me about my status on the analysis. I was asked to finish the analysis by 4 pm, i.e. I only had 3 more hours remaining. There was no context why this was needed nor why I had to do this on such short notice, on a Sunday.

I replied to my manager saying that I’d have to get home and work on it. Then, I let my wife know about the situation and I quickly drove home. My task was to collect lots of information, analyze it, create some graphs, and send them to the Director. After that, I had to execute complicated time-consuming SQL queries, in order to gather the data. So, apart from the time that I needed to create the graphs and write the report, I was also worried about the time that it would take for the queries to run.

Amazon gathers a gazillion of data for every user action possible and I needed to analyze several of them for a particular behavior. In the meantime, I was getting regular pings from my manager, who kept asking me about the status. Time passed and the pressure kept adding up. Some of the queries were taking longer than expected and this delayed me.

In the end, I managed to finish the report a few minutes before the 4 p.m. deadline. I shared it with my manager and my director. My director replied with a short “Thank you” email and no further context. I waited to see if he needed any more data or any modifications, but I didn’t receive anything else. So, I drove back to the shopping mall and joined my wife.

This is an incident that helped me understand that there are no work hours at Amazon. The day and time do not matter. Everyone should be on call at any point in time.

New Feature Requests Are Deprioritized

Due to the fast pace and the aggressive goals at Amazon, every team and every employee is working really hard. The project plan for all teams is full. Or at least, every team pretends that it is full, in order to avoid picking up more work.

In a particular case, we were using an underlying infrastructure by a different team. The code of the other team would read some data from a specific data store and present them to us in a specific way. However, at some point, we decided that we needed data from one more field. I wrote the spec explaining the business justification of the new field. I spoke with the Architect, who told me that the modification would be trivial.

And then I set up a meeting with the Engineering Manager of that team. His initial estimation was that this would take at least six months! He kept talking to me about the complexity of the codebase, the different priorities, etc. When I told him that the Architect’s estimation was that it was a matter of hours, he just laughed at it. After additional meetings with that team, we decided that there was no way that they would be able to do this trivial modification for us, so we scrapped the whole feature. I learned that this was the norm when relying on dependencies at Amazon.

In another case, we made a slight modification to our service and we introduced two new strings, i.e. two new sentences. Actually, one string was just one word and the other one was a small sentence. These 2 strings needed to be translated to all languages that are supported by Amazon Marketplace. The actual time to perform this task would be trivial.

I submitted the strings for localization and was told that it would take 3 to 4 months until they would be translated! The reason was the huge queue of strings that needed to be translated before mine. After clarifying that there was no other way to move faster, we updated the timelines for the project showing that we’d be delayed by 3 months. However the Marketplace Leadership team did not want to accept that the timeline was correct, so they kept pushing me to get a better date from Localization. In the end, we decided that it was not worth it, so we reused existing strings that we already localized.

The Amazon Culture

Amazon’s Leadership Principles

At the core of Amazon’s remarkable success and innovative spirit lie its Leadership Principles, a set of standards that guide decision-making at every level of the company. These principles are not just inspirational mottos; they are the operational tools that each Amazon Product Manager uses daily, ensuring that the company remains customer-centric, agile, and ever-evolving. From “Customer Obsession,” which emphasizes the importance of starting with the customer and working backward, to “Think Big,” which encourages boldness and the vision to seek transformative projects, each principle serves as a beacon, illuminating the path forward.

However, it’s not just about grand visions; practicality and execution are equally prized. Principles like “Bias for Action” and “Deliver Results” underscore the importance of swift decision-making and tangible outcomes. Simultaneously, “Learn and Be Curious” and “Insist on the Highest Standards” highlight the company’s commitment to continuous learning and relentless pursuit of excellence. Together, these Leadership Principles weave a tapestry of values and practices that define Amazon’s culture.

These principles are used everywhere at Amazon, including:

• Interviews
• Performance assessments
• Feedback
• Feature prioritization

Documents Replace Slides: 6-pagers, PR-FAQ

In a transformative move, Jeff Bezos, the visionary founder of Amazon, took a decisive step away from conventional corporate communication by banning PowerPoint presentations within the company. In its place, Bezos championed the use of “6-pagers,” meticulously crafted narrative memos that delve deep into topics, allowing for a comprehensive exploration of ideas. This shift was rooted in Bezos’s belief that the concise nature of slide-based presentations often sacrifices depth for brevity, leaving little room for nuanced discussions.

Integral to Amazon’s innovative approach to product development and strategy is the “work backward” method. This approach starts with the envisioned customer experience or outcome and works backward to formulate the necessary steps to achieve that vision. Central to this method is the creation of a “Press Release and FAQ” document (aka “PRFAQ”). Before any product or feature is developed, a hypothetical press release is drafted, detailing the final product’s benefits and value to the customer. Accompanying this are FAQs, addressing both anticipated customer and internal queries. This exercise ensures clarity of vision, customer-centricity, and a roadmap that aligns with the company’s goals.

The 6-pager approach, on the other hand, requires the writer to thoughtfully articulate ideas, ensuring that every facet of the topic is explored in depth. These documents, typically read at the beginning of meetings, allow attendees to immerse themselves in the content, fostering a more informed and robust discussion. The very process of creating a 6-pager encourages presenters to refine their thoughts and anticipate questions, leading to more productive and meaningful conversations. Through this innovative approach, Amazon has not only elevated its internal communication standards but has also reinforced its commitment to thoroughness, clarity, and a relentless focus on delivering value.

A Product and Data-Driven Ecosystem

Amazon’s culture is markedly different from other tech behemoths. Where Google is engineering-driven and encourages a learning phase for its employees, Amazon is unabashedly product and data-driven. From day one, Amazonians are expected to make decisions, be productive, and have their actions evaluated. There’s no honeymoon period; the mantra is to dive deep and be impactful from the get-go.

I remember that I was asked to drive meetings and make critical decisions for my product during the first week of my employment. At the end of the first month, I was reminded that I should not use the excuse that I’m new to the team anymore. This is in stark contrast to Google, where there is a 6-month adjusting period for Nooglers (i.e. new Googlers), or to Microsoft, which is also much more lenient with new hires than Amazon.

Aggressive Growth Targets

Amazon’s growth trajectory is nothing short of astounding. With a staggering 40% year-over-year growth rate, the company’s aggressive targets mean that what sufficed two years ago won’t cut it today. If Amazon rakes in $10 billion one year, the goal is to scale that to $14 billion the next, and almost $20 the following year. Within 2 years, each team needs to double their implementation speed. This rapid growth necessitates a continuous influx of products, features, and fine-grained data analysis that surpasses many other companies.

The relentless pursuit of growth also means that roles evolve rapidly. The tasks and expectations from an Amazon PM today might be vastly different from those two years ago. As the company grows, so do its requirements. For Amazonians, this translates to finding innovative ways to scale personally and professionally. It’s not just about doing more; it’s about multiplying efforts, being efficient, and ensuring that every task adds value.

Navigating the Amazonian Pressure

Amazon’s high-growth culture naturally brings with it certain pressures. Teams often operate at or close to capacity, and aggressive timelines are the norm. Interdependencies between teams can sometimes pose challenges, especially if one team is overburdened. But it’s this very pressure that fuels Amazon’s unparalleled growth. The ethos is clear: deliver results, innovate, and grow.

It’s often said that if you survive your first year at Amazon, you’re set for success. Many face challenges in adapting to the company’s fast-paced environment, and not everyone makes it past the initial phase. However, those who resonate with Amazon’s culture often stay for the long haul, passionately driving the company’s vision forward.

Compensation for An Amazon Product Manager

The best public database for salaries in high-tech companies is provided by Levels.fyi. This website uses data from actual job offers, in order to publicize the compensation across different levels for lots of high-tech companies.

Here is a screenshot of their data for Amazon Product Manager salaries, as of 10/27/2023.

Performance evaluations at Amazon happen annually. At that time, Amazon gave salary increases and promotions to employees. However, they have a very unique compensation structure:

• Every level has a specific compensation target for the year. This corresponds to the maximum compensation that an employee can have this year.
• This compensation target includes all the stock units that were provided during previous years
• If the stock has appreciated in such a way that the total compensation for this year becomes higher than the target for the level (based on the stock that was provided in previous years and vests this year), then the employee gets a 0% salary increase, 0% bonus and 0 stock, regardless of their performance
• If the stock from previous years has not appreciated above the compensation target, then the employee’s compensation will be less or equal to the target, based on the performance review
• Note: Managers at Amazon are almost 100% responsible for the performance evaluation of each employee

Downsides Of Working At Amazon

Bad Work-Life Balance

Amazon’s meteoric rise and relentless drive for innovation have sometimes come at the cost of work-life balance for its employees. The culture of “always-on” can mean extended work hours, weekend brainstorming sessions, and an ever-blurring boundary between professional commitments and personal time. This intensity, while fueling the company’s success, can lead to burnout for some employees. They often find themselves juggling between tight project timelines and personal commitments, leading to a feeling that the scales are tipped more towards ‘work’ than ‘life.’

For more information regarding the culture in the top high-tech companies, take a look at my post Inside the Culture of the Top Tech Companies

High Attrition and PIPs (Performance Improvement Plans)

The rigorous environment at Amazon, marked by its high standards and constant push for excellence, has led to notable attrition rates. Some employees, feeling the weight of these demands, choose to seek opportunities in more lenient environments. Coupled with this is the company’s approach to performance evaluations. Falling short of Amazon’s exacting standards might result in an employee being placed on a Performance Improvement Plan (PIP). While these plans are theoretically designed as a tool for growth, helping employees identify areas of improvement, they are often perceived as stressful. The looming shadow of a PIP can be daunting for many, seen as a step towards potential termination rather than genuine professional development.

Frugality

Amazon’s leadership principle of frugality encourages employees to “do more with less.” On the surface, this principle has been a catalyst for innovation, pushing teams to think outside the box and optimize resources. However, there’s a flip side. Some employees feel that this principle translates to a lack of amenities and resources, especially when compared to other tech giants. The emphasis on frugality, while fostering creativity, can sometimes be perceived as a reluctance to invest in tools, training, or facilities that might enhance employee well-being and productivity.

Unachievable Goals and Zero Downtime

Amazon’s ambition knows no bounds, and this is evident in the goals set for its teams. These targets, designed to push boundaries, can sometimes feel overwhelming. Employees often grapple with objectives that, while designed to inspire, can lead to undue stress and a perpetual race against time. This relentless pursuit of goals often dovetails into the challenge of taking breaks. The rapid pace of projects and the overarching expectation to constantly deliver results means that holidays or extended breaks become a luxury. Even when on vacation, employees might feel the invisible tether of work, making it challenging to truly disconnect and rejuvenate.

Conclusion

Being an Amazon Product Manager is both an exhilarating and challenging journey. The company, a giant in the e-commerce and tech landscape, offers boundless opportunities for growth, innovation, and making a tangible impact on millions of users worldwide. However, it comes with its set of challenges that potential Amazonians must be prepared for. It’s the balance between leveraging the unparalleled opportunities and understanding the demands that make the Amazonian experience truly unique. As with any career choice, introspection, research, and aligning one’s personal and professional aspirations are crucial.

If you’re thinking about becoming an Amazon Product Manager, make sure its values align with what you’re looking for in a job. Be prepared to sacrifice your work-life balance and work in an environment of high stress. You will have lots of responsibilities that will help you grow, but you will need to constantly perform on high standards, without being able to have downtime. Also, take a look at experiences from other ex-Amazonians at the website The Former And Current Employees (FACE) of Amazon. At that point you’ll have all the necessary information that you need to make your own informed decision about Amazon.