Since reading the well known answer on Quora about Amazon’s approach to product development and product management by Ian McAllister I’ve been intrigued about Amazon and its product management function. In his Quora answer, McAllister – General Manager for AmazonSmile explains about Amazon’s approach called “working backwards”.

I guess most non-Amazon product people are familiar with the internal press releases that Amazon product people write to announce the finished product, even though in reality this product has yet to be built (see Fig. 1 below). Apart from following Amazon and its product releases, I’ve always wanted to find out more about Amazon and its approach to product.

Later this week, I’ll be speaking to a senior Amazon figure to find out first hand about Amazon’s product culture and what it’s like to be a product person at Amazon. In preparation for this conversation, I’ll look at three aspects related to Amazon’s product function: (1) product culture (2) product methodologies and (3) structure and approach.

Product Culture

1. Leadership Principles –  It was interesting to read Amazon’s Leadership Principles, which are meant to guide every Amazon employee (see Fig. 2 below). The principles that resonated with me the most were “ownership”, “bias for action” and “vocally self critical”. In addition, from my experience of Amazon product managers, a lot of them seem to possess a great deal of intellectual curiosity and a strong desire to get every detail of the product (experience) 100% right.
2. Founding principles – Each year, Amazon CEO Jeff Bezos writes a letter to his shareholders. In his first letter in 1997, Bezos outlined some of the fundamental principles which underpin Amazon’s decision making. These principals reflect a clear focus on long-term and analytical thinking as well as on the customer and their needs (see Fig. 3 below).
3. Judgment based decisions – In the 2005 edition of Jeff Bezos’ annual shareholder letter, he writes about the importance of judgment (in combination with maths and data analysis) in making decisions: “As you would expect, however, not all of our important decisions can be made in this enviable, math-based way. Sometimes we have little or no historical data to guide us and proactive experimentation is impossible, impractical, or tantamount to a decision to proceed. Though data, analysis, and math play a role, the prime ingredient in these decisions is judgment”. I would file this view under the data informed approach to product decision making of which I’m a big fan.

Product Methodologies

1. Working backwards – As I mentioned above, Amazon is well known for its approach to “working backwards”. As Amazon’s CTO Werner Vogels explained in 2006, the main rationale for this approach is “to drive simplicity through a continuous, explicit customer focus” (see Fig. 4 below). Not only does this approach entail writing a press release but also a Frequently Asked Questions document, a well defined customer experience and a user manual. All four deliverables are in my view testament to Amazon’s customer centric focus. In a 2009 Newsweek interview, Jeff Bezos explained that it all starts with the customer: “We start with the customer and we work backward. We learn whatever skills we need to service the customer. We build whatever technology we need to service the customer.”
2. Continuous learning – Amazon say that they release code every 11.6 seconds. That’s a great figure, especially considering some of the lengthy release cycles out there, even for Internet only companies. This approach of releasing early and often, facilitates what I’d call “continuous learning”. Amazon seems not afraid to launch and iterate product initiatives such as “Amazon Locker” (see Fig. 5 below) and Amazon Storyteller, and are quite ruthless in ditching a product or service if it’s doesn’t generate the desired results.
3. Product documentation and roadmaps – As someone who isn’t the biggest fan of having to write endless product documentation, I was delighted to find out that the use PowerPoint has been banned at Amazon, with Jeff Bezos arguing that with PowerPoint “you get very little information, you get bullet points.  This is easy for the presenter, but difficult for the audience”. Instead, Amazon meetings are structured around a 2 to 6 page narrative memo (see Fig. 6 below). Also, part of the meeting is spent going through the narrative memo together, before discussing it. One of my questions for my contact is how this approach applies to the way in which in Amazon creates opportunity assessments or product roadmaps.
4. Goal setting – I understand that Amazon follow a similar approach to Google when it comes to setting goals.  Google introduced “OKRs” (i.e. Objectives Key Results) a few years ago and I’ve found OKRs a great way to make business objectives very tangible and specific (see Fig. 7 and 8).

Structure and Approach

1. “Two pizza” teams – I really like how Amazon works with so-called “two pizza” teams. The reason why these teams are called “two pizza” teams is because teams should never have more people than you can feed with two pizzas. As a result, most teams consist of 6-10 people. As Amazon CTO Werner Vogels explained, “if you have more than ten people in your team, you’ll need to have meetings”. It’s not so much about the team size, but much more about the team’s “fitness function”. A fitness function is a single key business metric that the senior executive team at Amazon (the “S-team”) agrees on with the team lead. It’s the equivalent of the P&L for a division: a single metric to provide the team with focus and accountability. I like that this provides team with autonomy and accountability, having the remit to ‘just get on with things’.
2. Continuous deployment – Given that Amazon release code every 11 seconds, I’d be keen to find out more about release management at at Amazon. I can imagine that they work in iterations and release code throughout. I like how Etsy go about releasing up to 35 times a day. Naturally, Etsy is a lot smaller by comparison with Amazon, but I can imagine that Amazon use a similar approach whereby they use “config” flags (also known as a feature flags) which enables companies to switch features on or off at a moment’s notice. Through its feature API, Etsy is able to do A/B testing, completely enable or disable a feature or variants of a given feature. Also, I can imagine Amazon having a super sophisticated and easy to access monitoring tool through which everyone in the company can keep abreast with any releases or system failures. It was reassuring to read that Amazon don’t have Product Development Managers, but instead allow their Product Managers to decide on what gets shipped and why.
3. Idea generation and evaluation – How do product ideas get generated at Amazon? Do Amazon product people use methodologies such as design thinking and empathy mapping to identify and prioritise customer needs? If so, why and how? I understand from the aforementioned Ian McAllister that product ideas can come from lots of different perspectives in and outside of Amazon and I get the sense that being able to articulate a product idea and its underlying rationale is a critical requirement for a product person Amazon. It was interesting to read McAllister’s 16 tips for writing upwards in this respect (see Fig. 9 below).

Main learning point: It was interesting to learn more about Amazon’s approach to product management. I’m now looking forward to finding out more from someone who actually lives and breathes Amazon’s product and customer centric approach. These are some of the questions that I’ll ask:

• How involved are Amazon’s product people in its continuous deployments? Do they get to release themselves?
• With Amazon’s continuous deployment mindset, do Amazon product managers apply assumptions and measurable hypotheses to each (major) release?
• How do product ideas get generated at Amazon? What is the role of the product manager in generating, assessing and deciding on product ideas?
• When “working backwards”, how much of the artefacts of this phase are actually used by (target) Amazon customers? How much user input is gathered at this stage (by the product person) and why?
• How often, where and when do Amazon’s product managers interact with actual customers and why?
• How do Amazon product managers interact with “Customer Experience Bar Raisers” who are Amazon employees especially trained to represent the (target) customer?
• How much autonomy do Amazon product managers have to make product decisions and be held accountable for them?

Fig. 1 – Ian McAllister’s answer to the question “What is Amazon’s approach to product development and product management?” on Quora

For new initiatives a product manager typically starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product’s customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.

If the benefits listed don’t sound very interesting or exciting to customers, then perhaps they’re not (and shouldn’t be built). Instead, the product manager should keep iterating on the press release until they’ve come up with benefits that actually sound like benefits. Iterating on a press release is a lot less expensive than iterating on the product itself (and quicker!).

Here’s an example outline for the press release:

• Heading – Name the product in a way the reader (i.e. your target customers) will understand.
• Sub-Heading – Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
• Summary – Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
• Problem – Describe the problem your product solves.
• Solution – Describe how your product elegantly solves the problem.
• Quote from You – A quote from a spokesperson in your company.
• How to Get Started – Describe how easy it is to get started.
• Customer Quote – Provide a quote from a hypothetical customer that describes how they experienced the benefit.
• Closing and Call to Action – Wrap it up and give pointers where the reader should go next.

If the press release is more than a page and a half, it is probably too long. Keep it simple. 3-4 sentences for most paragraphs. Cut out the fat. Don’t make it into a spec. You can accompany the press release with a FAQ that answers all of the other business or execution questions so the press release can stay focused on what the customer gets. My rule of thumb is that if the press release is hard to write, then the product is probably going to suck. Keep working at it until the outline for each paragraph flows.

Fig. 2 – Amazon’s Leadership Principles – Taken from Amazon

Whether you are an individual contributor or the manager of a large team, you are an Amazon leader. These are our leadership principles and every Amazonian is guided by these principles.

Customer Obsession
Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

Ownership
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job.”

Invent and Simplify
Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here.” As we do new things, we accept that we may be misunderstood for long periods of time.

Are Right, A Lot
Leaders are right a lot. They have strong business judgment and good instincts.

Hire and Develop the Best
Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others.

Insist on the Highest Standards
Leaders have relentlessly high standards – many people may think these standards are unreasonably high. Leaders are continually raising the bar and driving their teams to deliver high quality products, services and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

Think Big
Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

Bias for Action
Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

Frugality
We try not to spend money on things that don’t matter to customers. Frugality breeds resourcefulness, self-sufficiency, and invention. There are no extra points for headcount, budget size, or fixed expense.

Vocally Self Critical
Leaders do not believe their or their team’s body odor smells of perfume. Leaders come forward with problems or information, even when doing so is awkward or embarrassing. Leaders benchmark themselves and their teams against the best.

Earn Trust of Others
Leaders are sincerely open-minded, genuinely listen, and are willing to examine their strongest convictions with humility.

Dive Deep
Leaders operate at all levels, stay connected to the details, and audit frequently. No task is beneath them.

Have Backbone; Disagree and Commit
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

Deliver Results
Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

Fig. 3 – Some of Amazon’s fundamental management and decision making principles, as outlined in Jeff Bezos’ shareholder letter in 1997 – Taken from SEC Archives

Because of our emphasis on the long term, we may make decisions and weigh tradeoffs differently than some companies. Accordingly, we want to share with you our fundamental management and decision-making approach so that you, our shareholders, may confirm that it is consistent with your investment philosophy:

• We will continue to focus relentlessly on our customers.
• We will continue to make investment decisions in light of long term market leadership considerations rather than short term profitability considerations or short term Wall Street reactions.
• We will continue to measure our programs and the effectiveness of our investments analytically, to jettison those that do not provide acceptable returns, and to step up our investments in those that work best. We will continue to learn from both our successes and failures.
• We will work hard to spend wisely and to maintain our lean culture. We understand the importance of continually reinforcing a cost-conscious culture, particularly in a business incurring net losses.

Fig. 4 – Four typical steps in Amazon’s approach of “working backwards” – Taken from All Things Distributed

The Working Backwards product definition process is all about is fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build. It typically has four steps:

1. Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists – what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product – not just how we think about it internally.
2. Write a Frequently Asked Questions document. Here’s where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
3. Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.
4. Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.

Fig. 5 – Amazon Locker

Fig. 6 – Main components of Amazon’s 2 or 6 page meeting narratives – Taken from Quora

1. The context or question
2. Approaches to answer the question – by whom, by which method, and their conclusions
3. How is your attempt at answering the question different or the same from previous approaches
4. Now what? – that is, what’s in it for the customer, the company, and how does the answer to the question enable innovation on behalf of the customer?

Fig. 7 – An example of Google’s OKRs, by John Doerr – Taken from Business Insider

Fig. 8 – Key elements of Google’s OKRs by Rick Klau

• Objectives are ambitious, and should feel somewhat uncomfortable
• Key Results are measurable; they should be easy to grade with a number (at Google we use a 0 – 1.0 scale to grade each key result at the end of a quarter)
• OKRs are public; everyone in the company should be able to see what everyone else is working on (and how they did in the past)
• The “sweet spot” for an OKR grade is .6 – .7; if someone consistently gets 1.0, their OKRs aren’t ambitious enough. Low grades shouldn’t be punished; see them as data to help refine the next quarter’s OKRs.

Fig. 9 – Ian McAllister’s tips for “writing upwards” – Taken from Ian McAllister

1. Identify Your Audience
A good doc has a specific audience in mind. The same doc will never be ideal for audiences up, across, down or out. Once you’ve identified the audience, many of the choices you’ll make while writing the doc (e.g. altitude) will be much easier to make. In this post I focus on docs written to be circulated upwards.

2. Identify the Document’s Goal
Documents should have a goal in mind. The goal could be to communicate an operational plan for the year, provide a status update, seek approval for a specific course of action, or explain the root cause and steps to prevent reoccurrence of a problem. Once you know your audience (but not before), and the goal the document is intended to achieve, you’re ready to move on. If you’re unclear on either then punt on the doc or clarify the audience and doc’s goal with whoever asked you to write it.

3. Find Some Good Examples
Hunt around for other similar documents and pore through them. You may find some on your company’s Intranet and you can ask around among peers for good examples they’ve written or come across. I guarantee you, if you read 10 docs you’ll come away with a sense for which were effective and what you can learn (i.e. copy) from them. This is not cheating. Be aware that if you’re writing for a particular exec or group that the format they favor might be different than the format favored by others. Find this out ahead of time if you can.

4. One Doc, One Author
Co-authoring a doc is painful, and the Frankendocs that result are usually painful to read as well. Collaborate on the outline, perhaps, but either write it yourself or have your prospective co-author write it. Don’t tag-team.

5. Add an Executive Summary
Boil the entire doc down into a few bullets or a paragraph. Spill it. Your temptation will be to save the good stuff for the end of the doc to build suspense or get your excuses in ahead of time. Resist! If you are emailing your doc to a group of people many won’t read the whole thing. The exec summary communicates the highlights, which is all some of the audience needs to know. For those that will read the whole doc the executive summary lays out the structure of the doc and answers key questions that might otherwise have clouded comprehension.

6. Take Time on the Outline
Just like it is quicker to fix a software bug during unit testing than in production, it is much more efficient to iterate of the outline of a document than to rework a fully written doc. I often ask my newer product managers to review the outline of a doc with me and incorporate any structural feedback I have before going on to write the full doc. Sometimes I even provide them a rough outline of what I’m looking to get from a doc to help get them started. Simple bullets are ideal. I don’t want sentences or mini-paragraphs.

The outline should tell a story from top to bottom, and it shouldn’t be flat. An outline with 16 sections at the same level isn’t an outline, it’s a list. If you find yourself with more than 5-6 sub-sections underneath any one heading consider grouping them. This gives the reader a framework to attach the information to, and helps them understand what to make of it. You’ll know you’re getting really good at outlines when you can go from the outline to the full doc by replacing each bullet in the outline with a couple sentences.

7. Add Themes for Structure
Themes are a great way to provide structure for a doc. If you’re laying out an operational plan for the year you might want to communicate 2-3 themes for the year, why different themes will be focus areas in different parts of the year, and how resources are going to be allocated between the themes. Themes take a doc from the 100,000 foot view to the 10,000 view. If you skip them, then you risk losing your audience between the high-level content and the tactical content; they don’t know how they got there.

8. Anticipate Key Questions in the Main Content
As you write the individual sections, take the reader from the 10,000 foot view to the 1,000 foot view. Start with the minimum amount of content necessary to achieve your goal. Use plain words and declarative (not flowery) language.

Related links for further learning:

1. http://www.smartinsights.com/digital-marketing-strategy/online-business-revenue-models/amazon-case-study/
2. https://www.linkedin.com/pulse/article/20130805231302-25760-stop-the-presses-a-new-press-lord-appears
3. http://daslee.me/reading-jeff-bezos
4. http://www.sec.gov/Archives/edgar/data/1018724/000119312514137753/d702518dex991.htm
5. http://www.businessinsider.com/jeff-bezos-told-you-how-to-take-over-the-world-2011-11?IR=T
6. http://www.allthingsdistributed.com/2006/11/working_backwards.html
7. http://www.quora.com/What-specific-constraints-does-Amazon-put-on-working-backwards-in-particular-on-length-content-and-other-of-the-press-release-Q-A-customer-experience-and-user-manual-as-part-of-working-backwards-for-product-development
8. http://www.glassdoor.co.uk/Interview/Amazon-com-Senior-Product-Manager-Interview-Questions-EI_IE6036.0,10_KO11,33.htm
9. http://brendansterne.com/2013/11/21/amazon-product-management-working-backwards/
10. http://bits.blogs.nytimes.com/2009/12/24/is-amazon-working-backwards/?_r=0
11. http://www.slideshare.net/nik123hil/brand-management-study-of-amazon
12. http://www.wired.com/2012/04/ff_abtesting/
13. https://news.ycombinator.com/item?id=2971521
14. http://www.forbes.com/sites/netapp/2013/12/05/fail-experiment-amazon-starbucks/
15. http://conorneill.com/2012/11/30/amazon-staff-meetings-no-powerpoint/
16. http://www.reddit.com/r/technology/comments/1ebavs/amazon_staff_meetings_no_powerpoint/
17. http://research.gigaom.com/2013/10/flipped-meetings/
18. http://www.quora.com/How-are-the-six-page-narratives-structured-in-Jeff-Bezos-S-Team-meetings
19. http://www.businessinsider.com/googles-ranking-system-okr-2014-1
20. https://www.thinkwithgoogle.com/articles/start-up-speed-kristen-gil.html
21. http://www.workboard.com/blog/use-okrs-to-achieve-bold-goals.php
22. http://neilperkin.typepad.com/only_dead_fish/2011/10/two-pizza-teams.html
23. http://blog.jasoncrawford.org/two-pizza-teams
24. http://dev.podcasts.com/agile_nyc/episode/episode-78-stephen-hardisty-engineering-manager-at-etsy
25. https://codeascraft.com/2011/02/04/how-does-etsy-manage-development-and-operations/
26. http://www.infoq.com/presentations/etsy-release-cycle
27. http://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day
28. http://www.quora.com/What-value-is-having-product-management-experience-from-Amazon
29. http://www.quora.com/How-can-I-get-over-my-failed-interview-at-Amazon
30. http://www.quora.com/How-should-I-prepare-for-a-Technical-Program-Manager-interview-at-Amazon
31. http://www.forbes.com/sites/georgeanders/2012/04/04/bezos-tips/
32. https://socialsteve.wordpress.com/tag/jeff-bezos/