Systems: How Product Best Practices Drive Success at Amazon

Key Takeaways

  1. Weekly Goal and Metrics Reviews ensure transparency and accountability. 

  2. Communication tools reinforce telling a good product story. 

  3. Product Strategy (Operational Planning) is the most obvious system with a clear, published calendar. 

  4. The Funding Model facilitates team ownership of the outputs with P&L responsibility for both product and engineering. 

Background

This is the second post in a three-part series on what I learned at Amazon, as viewed through the lens of the NeuroLeadership Institute (NLI) Framework: Priorities, Habits, and Systems. I wrote these articles to explain the importance of building systems within your teams that support communication, measurement, and strategic planning habits.

Who Should Read This

  1. Product Leaders seeking to understand best practices

  2. PMs who want to understand Amazon

  3. Ex-Amazonians seeking to implement Amazon best practices in a new environment

If you find this article helpful, I suggest you also read:

When I first left Amazon, I tried to replicate old tools I had used there: a callout here, a 3-page document there. I tried to explain as I went along why these documents would make things better, and why they should be considered table stakes, but nothing really stuck. The biggest barrier seemed to be in a slide-based culture; when the concept of document writing was foreign to the culture, it was hard to get it to work universally. Even when individuals were willing to give it a try, the lack of leadership love for the documents reduced the stickiness of the concept. 

When I realized the very habit of writing those documents was the output of a larger set of systems, it all clicked. The reason these tools worked at Amazon was that they were built on a larger framework for success, which drove a mindset of growth and innovation. 

The Four Systems

I have identified four systems in place at Amazon that empower independent thinking and help product teams develop good habits. They are:

  1.  Goal Setting and Metrics

  2. Communication Best Practices

  3. Strategic Planning

  4. The Funding Model

Social Reinforcement of Rules

What makes these systems work is a culture of accountability through social reinforcement. Each one of these systems has a “public” component that forces you to justify your actions to your peers and leadership. 

The goals you set, the documents you write, the metrics you monitor, and the plans you propose are posted for all to see, allowing a forum for an audience (your colleagues) to ask questions, provide feedback, and raise concerns. You aren’t given the means to execute on your plan unless you make a strong case and project a return on investment (ROI). What does this mean? It means that there’s no faking it. You need to understand what you do—and why you do it—inside and out. If you don’t know your stuff, you will be caught with your pants down. You can never go into a meeting unprepared or present a document that is incomplete. If your financial model is not sound, with an aspirational target, you will have a hard time getting or maintaining headcount.

By introducing a component of peer accountability within the organization, Amazon removes the ability to operate on cruise control or present half-baked ideas. As a result, the groundwork for ensuring these systems are successful is already in place.

1. Goal-Setting and Metrics

The first of Amazon’s four systems requires every team to establish goals for their product. There are different levels of goals, including S-Team, Director-Level, Group, Team, etc. Every week, during a meeting called the Weekly Business Review (WBR), executives discuss each team’s goal, as well as any key supporting metrics that are significantly up or down against plan. 

The Force Behind the Curtain

From a product management standpoint, I believe it could be argued that the WBR meetings are the secret force behind Amazon’s success. I know Bezos loves to talk about the well-written document that forces proper thinking and articulation of ideas. From a systems standpoint, however, the emphasis on goal status is what keeps people honest and keeps products on track. 

These WBR meetings hold everyone accountable. If you are up or down against your goal, the director or senior managers for your group must have sufficient information about your product to withstand a barrage of questions. Your director must speak to counts and figures, to percentages up or down. They must be prepared to discuss, as well as next steps to double down on a good idea or what measures are being taken to solve a problem. This is social reinforcement at play.

Forecasting is Key

At Amazon, all key goals are meticulously forecasted by your finance partner before the start of the year. You can measure your plan, not just at a monthly level, but at a weekly level. You know you have to be ready for this meeting, which typically takes place every Monday or Tuesday. This level of detail means you are constantly aware of the state of your product’s health.  This is one of the strongest accountability tools I have found in the business world. 

Replication at a Team Level

The team-level versions of these WBR meetings are meant to mimic the executive versions. As a result, PMs learn to be accountable to their own goals and metrics. Storytelling in these meetings must be concise. You must be able to answer questions about any emerging patterns with an executive who, through their tough questions, is trying to teach you how to thrive and survive at Amazon. 

Dashboard or Deck for the WBR Meeting

The Weekly Business Review dashboard is built on an old-school Excel spreadsheet. It contains weekly, monthly, and year-over-year views of your key metrics. At the top, the status of your key goals is front and center. Your finance partner has helped you with weekly forecasts of key metrics. This allows you to speak to weekly and monthly trends relative to projections and understand what really matters, without ballparking for seasonality effects. 

2. Communication Best Practices

A strong communication culture drives better articulation of product strategy. Perhaps as a result of the WBR, Amazon’s culture of accountability means you get very good at telling your product story to stakeholders at every turn. Four key communication documents are so ingrained into my memory that I feel they are essential. Together they make up what I consider a Product Communication System:

  1. Weekly Callouts

    • Callouts are email reports to your stakeholders that include your product’s weekly highlights. You are product storytelling in words and numbers, highlighting Hits, Misses, and Learnings while consistently highlighting a standard set of product metrics. This provides transparency and accountability, and, if used correctly, it also helps you prepare your monthly product review

    • Frequency: Weekly

  2. Product Flashes

    •  When something is nearing release and being closely monitored, stakeholders tend to have questions that can’t wait a week. This is when you know it’s time to publish a Product Flash. While lighter than Weekly Callouts, these are still pretty packed with information (this is Amazon, after all). These flashes go out daily from the runup to just after launch, letting stakeholders know how the product is performing at this critical stage.

    • Frequency: Daily

  3. Product Reviews

    • A Product Review is a monthly report summarizing your product’s progress. It has a companion meeting where the report is read by your stakeholders before the meeting begins. It is a cross between a weekly review and an operational planning document.

    • Frequency: Monthly

  4. Launch Announcements

    • When a significant milestone is reached, typically a major feature release or launch of a new product, you'll need to send an announcement addressing the who, what, why, when, where, and how. Don’t forget to credit the team that made it all happen. 

    • Frequency: Situation-Dependent

3. Strategic Planning

One of the most famous outputs of Amazon's systems is the expectation that one must write a "Working Backwards" document for any new product idea. What really gives the system structure, however, is the Operational Planning process. 

The Calendar

This process starts in the spring, with a chance to pitch your moonshot idea, 3-Year Plan (3YP). Then, at the start of summer, you begin the planning process for the next year. Your ultimate output is an Operational Plan. To get the plan right, engineering and product teams need to brainstorm, ideate, and hold themselves accountable to profit and loss (P&L). Knowing you must have this plan to get or maintain your budget is the forcing function that defines the system. It helps Amazon drive outcomes. It pushes teams to have a clear vision for the year. 

Operational Plan 1 (OP1) Document Basics

In order to create your Operational Plan, you need to start with your vision, tenets, and goals. You must also address what you learned over the last year. Next, you will dive into how you are going to meet your goals through product innovation over the following year. You will want to explain how you are enacting your plan by addressing the human and technical resources you have at your disposal. Don’t forget to highlight what fell just “below the line” when you made your prioritization decisions. This will give an idea of what you plan to do with more resources. 

To learn more about the actual documents that make up the Operational Planning system, check out my other article, Communication Habit: 12 Amazon Product Communication Tools.

4. Funding Model: P&L Approach

Some might argue with my claim that the WBR meeting is what truly provides the strongest accountability at Amazon. For many, it is the company's funding model that rules, and this opinion indeed holds weight. Why? Because this system requires you to justify your ROI for everything. It is the magic of a P&L mindset brought to life for all product and engineering teams at Amazon

In order to get your product "funded", to get engineers, designers, data scientists, product managers, and resources with which to build it, you must make a case for why your product ideas are more deserving than the competition. This creates an interesting dynamic, both between teams and across product and engineering. 

The Engineering View

My focus has so far been on the product manager's view, but I want to take a brief moment here to address the unique benefit this P&L approach provides on the engineering side of the house. The engineering manager directs his team by balancing his P&L, which can be funded by one dedicated PM team or spread across multiple teams. There is also another form of funding within the engineering organization, in which pure platform plays can be funded by the engineering leadership. This empowers engineering managers to build and fund their own ideas to improve the underlying architecture. It also fuels independence and longer-term approaches to solving problems for the customer. If there are clear benefits for your product, a PM team can reap the rewards of an enterprising engineering manager. 

The Product View

As a rule, the bulk of an engineering team's time is dedicated to building efforts that the product "funds". However, the engineering team also has two other buckets of "budget", one for KLO, ("Keep the Lights On") efforts, otherwise known as "On Call and Tech Debt", and another for Engineering Excellence (EE). EE ensures that the engineering team has time to develop and explore their big ideas. As a PM, I have to fund the budget, but I can’t touch it. This is simply the cost of doing business. 

What I miss most about this structure is that the engineering manager had something to negotiate with. Without this approach, I have found that tech debt discussions tend to devolve into an absolute mess. With it, systems are protected, and engineering managers are incentivized because they control some of their team’s destiny. 

Two Views on P&L Ownership

Amazon's setup holds both the PM and EM accountable for planning what their resources should work on and making the case for more budgets. While the PM holds the bulk of the budget, to figure out how it is being spent, they must work with their engineering manager to balance things out in order to produce the product and meet goals. However, this system also gives engineering a voice in a world heavily driven by the business and product side of the house. Additionally, when both the PM and the EM manage a P&L there is a sense of shared responsibility and camaraderie. 

Selling your Idea

The other thing I love about Amazon's funding model is that if either a PM or an engineer has a great idea, they can write a Working Backwards document and shop it around. I once pitched a plan I had to several teams to try to get it funded, with mixed results. While this was frustrating, it was a mini case of market forces at work, and a sign that I probably needed to strengthen my proposal. The beauty was that I was encouraged to give my idea a try if I felt that passionate about it. Failure was okay, and I was still respected for trying.

Lines Provide Control and Ownership

The last benefit of this funding model was that it made clear there were lines we couldn’t cross. If we did, there needed to be a negotiation. This meant there was always a budget for tech debt—not necessarily a lot, but always some. This was left in the hands of the engineering team; the product team couldn’t touch it without negotiation. The same went for engineering excellence. As I recall, we ideated so much with our engineering team that we often knew what the EE hours were going toward, and were equally enthusiastic. Regardless, allocating those resources gave engineering teams clear ownership.

I go on about this last one a bit because, outside of Amazon, the absence of this practice leads to a mountain of debt, and causes engineering teams to have less of a voice than they do within Amazon. An empowered engineering team is a dream partnership for any good PM. 

In Conclusion

Amazon’s product systems are brilliant because they work seamlessly to support and reinforce the PM habits that I consider table stakes—Quantify and Measure, Know your Metrics, Develop a Strategic Plan, Communicate to Stakeholders and Keep it Simple for Executives. Goals and Metrics reviews ensure transparency. Communication Best Practices reinforce telling a good product story. Product Strategy (Operational Planning), the most obvious system, provides a clear, polished calendar, while the Funding Model facilitates team ownership of the outputs with P&L responsibility for both product and engineering. Bolstered by a culture of social accountability, these systems work like a well-oiled machine, consistently promoting accountability and innovation. 

Photo by Alexander Andrews on Unsplash

Previous
Previous

System: Communication Best Practices

Next
Next

Habit: Keep It Simple