What's it like to work at Amazon?

Read an excerpt from "WORKING BACKWARDS: Insights, Stories, and Secrets from Inside Amazon" by former Amazon employees Colin Bryar and Bill Carr.

Amazon culture has many unique ways of operating that help the company move fast and innovate while keeping the customer at the center of everything we do. So when two former Amazon employees, Colin Bryar and Bill Carr, wrote a book about Amazon's culture, we couldn't wait to share their perspective on how we do what we do best. In this excerpt from "WORKING BACKWARDS: Insights, Stories, and Secrets from Inside Amazon," Bryar and Carr share their experience with the concept of working backwards, going from an idea about how to improve a customer experience all the way through the process that leads only the best ideas to get the green light.

Read the excerpt:

Working Backwards

Most of Amazon's major products and initiatives since 2004 have one very Amazonian thing in common—they were created through a process called Working Backwards. It is so central to the company's success that we used it as the title for our book. Working Backwards is a systematic way to vet ideas and create new products. Its key tenet is to start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build. Its principal tool is a second form of written narrative called the PR/FAQ, short for press release/frequently asked questions.

We both witnessed its birth. Colin was in his tenure as Jeff's shadow when the Working Backwards process was launched and he participated in every Working Backwards review presented to Jeff in the twelve months thereafter. And Bill's experience was forged by applying and refining the Working Backwards concept in the early stages of the process that led to the development of every digital media product.

The Features and Benefits of the PR/FAQ

The primary point of the process is to shift from an internal/company perspective to a customer perspective. Customers are pitched new products constantly. Why will this new product be compelling enough for customers to take action and buy it? A common question asked by executives when reviewing the product features in the PR is "so what?" If the press release doesn't describe a product that is meaningfully better (faster, easier, cheaper) than what is already out there, or results in some stepwise change in customer experience, then it isn't worth building.

The PR gives the reader the highlights of the customer experience. The FAQ provides all the salient details of the customer experience as well as a clear-eyed and thorough assessment of how expensive and challenging it will be for the company to build the product or create the service. That's why it's not unusual for an Amazon team to write ten drafts of the PR/FAQ or more, and to meet with their senior leaders five times or more to iterate, debate, and refine the idea.

The PR/FAQ process creates a framework for rapidly iterating and incorporating feedback and reinforces a detailed, , and fact-based method of decision-making. We found that it can be used to develop ideas and initiatives—a new compensation policy, for example—as well as products and services. Once your organization learns how to use this valuable tool, it is addicting. People start to use it for everything.

Over time, we refined and normalized the specifications for the PR/FAQ. The press release (PR) portion is a few paragraphs, always less than one page. The frequently asked questions (FAQ) should be five pages or less. There are no awards for extra pages or more words. The goal isn't to explain all the excellent work you have done but rather to share the distilled thinking that has come from that work.

People who write press releases for a living, or indeed anyone who has been professionally edited, knows the importance of boiling things down as much as possible, but the people in product development don't always understand this. In the early days of the PR/ FAQ, a common mistake people made was to assume that more means better. They'd produce long documents, attach page after page of narrative, insert charts and tables in an appendix. The virtue of this approach, at least from the perspective of the writer, is that it shows all their work and allows them to avoid hard decisions about what's important and what's not—leaving those for the group. However, restricting the length of the document is, to use a term that came up when describing the narratives, a forcing function—we have seen that it develops better thinkers and communicators.

The creation of the PR/FAQ starts with the person who originated either the idea or the project writing a draft. When it's in shareable condition, that person sets up a one-hour meeting with stakeholders to review the document and get feedback. At the meeting, they distribute the PR/FAQ in either soft or hard copy, and everyone reads it to themselves. When they have finished, the writer asks for general feedback. The most senior attendees tend to speak last, to avoid influencing others.

Once everyone has given their high-level responses, the writer asks for specific comments, line by line, paragraph by paragraph. This discussion of the details is the critical part of the meeting. People ask hard questions. They engage in intense debate and discussion of the key ideas and the way they are expressed. They point out things that should be omitted or things that are missing.

After the meeting, the writer distributes meeting minutes to all the attendees, including notes on the feedback. Then they get to work on the revision, incorporating responses to the feedback. When it is polished, they present it to the executive leaders in the company. There will be more feedback and discussion. More revision and more meetings may be required.

The PR/FAQ review process can be stressful, no matter how constructive and unbiased the feedback. Gaps will be found! A PR/FAQ under serious consideration for implementation will typically require multiple drafts and meetings with the leadership. Senior managers, directors, and executive leaders who oversee the authors of PR/FAQs become skilled evaluators and contributors to the process. The more PR/FAQs they read, and the more products they build and launch using the PR/FAQ process, the more capable they become at identifying the omissions and flaws in the author's thinking. And so the process itself creates a tier of master evaluators as it vets and strengthens the idea and aligns everyone involved in the project, from individual contributor to CEO. It also increases the likelihood that a project will be approved and funded. You should plan on making many revisions to the PR/FAQ document, even after the project has formally started, to reflect changes and new elements.

Go Ahead?

It is important to note that, during our time with Amazon, most PR/FAQs never made it to a stage where they were launched as actual products. What this means is that a product manager will put in a lot of time exploring product ideas that never get to market. This may be because of the intense competition for resources and capital among the hundreds of PR/FAQs that are authored and presented each year within the company. Only the very best will rise to the top of the stack and get prioritized and resourced, whether the pool of capital comes from within a large company like Amazon or from a startup investor. The fact that most PR/ FAQs don't get approved is a feature, not a bug. Spending time up front to think through all the details of a product, and to determine—without committing precious software development resources—which products not to build, preserves your company's resources to build products that will yield the highest impact for customers and your business.

Another one of the biggest benefits of a written PR/FAQ is that it enables the team to truly understand the specific constraints and problems that would prevent a new product idea from being viable and aligning on them. At that point, the product or leadership team must decide if they will keep working on the product, addressing the problems and constraints surfaced by the PR/FAQ and developing solutions that will potentially make the product viable, or if they will set it aside.

This process enables a product team and the company leadership to gain a thorough understanding of the opportunity and the constraints. Leadership and management are often about deciding what not to do rather than what to do. Bringing clarity to why you aren't doing something is often as important as having clarity about what you are doing.

If, after the PR/FAQ process, the leadership team still believes in the product and wants it to become a reality, the process will have given them a thorough understanding of the problems that would need to be solved in order to move forward with it. Perhaps a problem can be solved through an acquisition or a partnership. Perhaps it can be solved with the passage of time—new technologies may become available, or the costs of the technology might come down. Perhaps the company decides that the problem or constraint is solvable, that the solution will require risk and cost, and that they are willing to assume that risk and cost because the TAM [totally addressable market] is large and therefore the potential rewards are great.

This last consideration came up frequently in reviews with Jeff, as we would wrestle with product ideas using the PR/FAQ process. A team might identify a hard problem during a review that we did not know how to solve, and didn't know if we could solve. Jeff would say something to the effect of, "We shouldn't be afraid of taking on hard problems if solving them would unlock substantial value."

Above all, keep in mind that the PR/FAQ is a living document. Once it is approved by the leadership team, it will almost certainly still be edited and changed (a process that should be directed by or reviewed with the leadership team). There is no guarantee that an idea expressed in an excellent PR/FAQ will move forward and become a product. As we've said, only a small percentage will get the green light. But this is not a drawback. It is, in fact, a huge benefit of the process—a considered, thorough, data-driven method for deciding when and how to invest development resources. Generating and evaluating great ideas is the real benefit of the Working Backwards process.